Related to r12-6208-gebc853deb7cc0487de9ef6e891a007ba853d1933
"libgomp: Fix GOMP_DEVICE_NUM_VAR stringification during offload image load"
That commit fixed an issue with omp_get_device_num() on gcn/nvptx that
resulted in having always the value 0.
This commit modifies the tests to iterate over all devices such that on a
multi-nonhost-device system it had detected that always-zero issue.
libgomp/ChangeLog:
* testsuite/libgomp.c-c++-common/target-45.c: Iterate over all devices.
* testsuite/libgomp.fortran/target10.f90: Likewise.
This avoids running simple_dce_from_worklist on partially not up-to-date
SSA form (in unreachable code regions) by scheduling CFG cleanup
manually as is done anyway when tail-merging runs.
2022-01-04 Richard Biener <rguenther@suse.de>
PR tree-optimization/103690
* tree-pass.h (tail_merge_optimize): Adjust.
* tree-ssa-tail-merge.c (tail_merge_optimize): Pass in whether
to re-split critical edges, move CFG cleanup ...
* tree-ssa-pre.c (pass_pre::execute): ... here, before
simple_dce_from_worklist and delay freeing inserted_exprs from
...
(fini_pre): .. here.
This patch to the nvptx backend changes the backend's STORE_FLAG_VALUE
from -1 to 1, by using BImode predicates and selp instructions, instead
of set instructions (almost always followed by integer negation).
Historically, it was reasonable (through rare) for backends to use -1
for representing true during the RTL passes. However with tree-ssa,
GCC now emits lots of code that reads and writes _Bool values, requiring
STORE_FLAG_VALUE=-1 targets to frequently convert 0/-1 pseudos to 0/1
pseudos using integer negation. Unfortunately, this process prevents
or complicates many optimizations (negate isn't associative with logical
AND, OR and XOR, and interferes with range/vrp/nonzerobits bounds etc.).
The impact of this is that for a relatively simple logical expression
like "return (x==21) && (y==69);", the nvptx backend currently generates:
mov.u32 %r26, %ar0;
mov.u32 %r27, %ar1;
set.u32.eq.u32 %r30, %r26, 21;
neg.s32 %r31, %r30;
mov.u32 %r29, %r31;
set.u32.eq.u32 %r33, %r27, 69;
neg.s32 %r34, %r33;
mov.u32 %r32, %r34;
cvt.u16.u8 %r39, %r29;
mov.u16 %r36, %r39;
cvt.u16.u8 %r39, %r32;
mov.u16 %r37, %r39;
and.b16 %r35, %r36, %r37;
cvt.u32.u16 %r38, %r35;
cvt.u32.u8 %value, %r38;
This patch tweaks nvptx to generate 0/1 values instead, requiring the
same number of instructions, using (BImode) predicate registers and selp
instructions so as to now generate the almost identical:
mov.u32 %r26, %ar0;
mov.u32 %r27, %ar1;
setp.eq.u32 %r31, %r26, 21;
selp.u32 %r30, 1, 0, %r31;
mov.u32 %r29, %r30;
setp.eq.u32 %r34, %r27, 69;
selp.u32 %r33, 1, 0, %r34;
mov.u32 %r32, %r33;
cvt.u16.u8 %r39, %r29;
mov.u16 %r36, %r39;
cvt.u16.u8 %r39, %r32;
mov.u16 %r37, %r39;
and.b16 %r35, %r36, %r37;
cvt.u32.u16 %r38, %r35;
cvt.u32.u8 %value, %r38;
The hidden benefit is that this sequence can (in theory) be optimized
by the RTL passes to eventually generate a much shorter sequence using
an and.pred instruction (just like Nvidia's nvcc compiler).
This patch has been tested nvptx-none with a "make" and "make -k check"
(including newlib) hosted on x86_64-pc-linux-gnu with no new failures.
gcc/ChangeLog:
* config/nvptx/nvptx.h (STORE_FLAG_VALUE): Change to 1.
* config/nvptx/nvptx.md (movbi): Use P1 constraint for true.
(setcc_from_bi): Remove SImode specific pattern.
(setcc<mode>_from_bi): Provide more general HSDIM pattern.
(extendbi<mode>2, zeroextendbi<mode>2): Provide instructions
for sign- and zero-extending BImode predicates to integers.
(setcc_int<mode>): Remove previous (-1-based) instructions.
(cstorebi4): Remove BImode to SImode specific expander.
(cstore<mode>4): Fix indentation. Expand using setccsi_from_bi.
(cstore<mode>4): For both integer and floating point modes.
For VxWorks, replace an attempt at providing a posix API for
mkdir via macro by a varargs prototype, which works better for
C++ references like std::mkdir(arg1, arg2).
2021-12-16 Olivier Hainque <hainque@adacore.com>
fixincludes/
* inclhack.def (vxworks_posix_mkdir): Refine to expose a
varargs interface.
* tests/base/sys/stat.h: Update expected results.
* fixincl.x: Regenerate.
This change adjusts the processing of --sysroot to save the option in the
internal "switches" array, which lets self-specs test for it and provide a
default value possibly dependent on environment variables, as in
--with-specs=%{!-sysroot*:--sysroot=%:getenv("WIND_BASE" /target)}
2021-12-20 Olivier Hainque <hainque@adacore.com>
gcc/
* gcc.c (driver_handle_option): do_save --sysroot.
In the patch that implemented omp_get_device_num(), there was an error where
the stringification of GOMP_DEVICE_NUM_VAR, which is the macro expanding to
the actual symbol used, was erroneously using the STRINGX() macro in the
libgomp offload image symbol search, and expansion of the variable name
string through the additional layer of preprocessor symbol was not properly
achieved.
This patch fixes this by changing to properly use XSTRING(), also from
include/symcat.h.
libgomp/ChangeLog:
* plugin/plugin-gcn.c (GOMP_OFFLOAD_load_image): Change uses of STRINGX
into XSTRING when looking for GOMP_DEVICE_NUM_VAR in offload image.
* plugin/plugin-nvptx.c (GOMP_OFFLOAD_load_image): Likewise.
This generalizes the fix for PR103544 to also cover reductions that
are not reduction chains and does not consider reductions wrapped in
sign conversions for SLP reduction handling.
2022-01-04 Richard Biener <rguenther@suse.de>
PR tree-optimization/103864
PR tree-optimization/103544
* tree-vect-slp.c (vect_analyze_slp_instance): Exclude
reductions wrapped in conversions from SLP handling.
(vect_analyze_slp): Revert PR103544 change.
* gcc.dg/vect/pr103864.c: New testcase.
On Thu, Dec 30, 2021 at 04:08:25AM -0600, Segher Boessenkool wrote:
> > The following simple patch makes sure we call can_get_prologue even after
> > the last former iteration when vec is already empty and only break from
> > the loop afterwards (and only if the updating of pro done because of
> > !can_get_prologue didn't push anything into vec again).
During the development of the above patch I've noticed that in many cases
we call can_get_prologue often on the same pro again and again and again,
we can have many basic blocks pushed into vec and if most of those don't
require pro updates, i.e.
basic_block bb = vec.pop ();
if (!can_dup_for_shrink_wrapping (bb, pro, max_grow_size))
while (!dominated_by_p (CDI_DOMINATORS, bb, pro))
isn't true, then pro is can_get_prologue checked for each bb in the vec.
The following simple patch just remembers which bb we've verified already
and verifies again only when pro changes. Most of the patch is just
reindentation.
2022-01-04 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/103860
* shrink-wrap.c (try_shrink_wrapping): Don't call can_get_prologue
uselessly for blocks for which it has been called already.
After the PR90030 patch, which removes the universal casting of all Fortran
array pointers to 'c_char*', a Fortran descriptor based array passed into an
affinity() clause now looks like:
- #pragma omp task private(i) shared(b) affinity(*(c_char *) a.data)
+ #pragma omp task private(i) shared(b) affinity(*(integer(kind=4)[0:] * restrict) a.data)
The 'integer(kind=4)[0:]' incomplete type appears to be causing ICE during
gimplify_expr() due to 'is_gimple_val, fb_rvalue'. The ICE appears to be fixed
just by adjusting to 'is_gimple_lvalue, fb_lvalue'. Considering the use of the
affinity() clause, which should be specifying the location of a particular
object in memory, this probably makes sense.
gcc/ChangeLog:
PR middle-end/103643
* gimplify.c (gimplify_omp_affinity): Adjust gimplify_expr of entire
OMP_CLAUSE_DECL to use 'is_gimple_lvalue, fb_lvalue'
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/pr103643.f90: New test.
This testcase was fixed by r12-1744-g3eecc1 as it make
sense it fixed a few other class deduction issues.
So I thought I would add a testcase for this PR and close
it as fixed.
Committed after a quick test of the testcase.
PR c++/90782
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/class-deduction100.C: New test.
It would be nice to handle language-specific codes in the tree
pretty-printer, but until then we can at least indent them appropriately.
gcc/ChangeLog:
* tree-pretty-print.c (do_niy): Add spc parameter.
(NIY): Pass it.
(print_call_name): Add spc local variable.
I'm tired of seeing
cp/parser.c:15923:55: warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]
cp/parser.c:15925:57: warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]
every time I compile cp/parser.c, which happens...a lot. I'd like my
compilation to be free of warnings, otherwise I'm going to miss some
important ones.
"decl-specifiers" is a C++ grammar term; it is not actual code, so
should not be wrapped with %< %>. I hope we can accept it as an exception
in check_tokens.
It was surrounded by %< %> in cp_parser_decl_specifier_seq, so fix that.
In passing, fix a misspelling in missspellings.
PR c++/103758
gcc/c-family/ChangeLog:
* c-format.c (check_tokens): Accept "decl-specifier*".
gcc/cp/ChangeLog:
* parser.c (cp_parser_decl_specifier_seq): Replace %<decl-specifier%>
with %qD.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-condition.C: Adjust dg-error.
Middle end tries to generate V4QImode moves to implement V2QImode inserts
and calls emit_move_multi_word when V4QImode moves are unavailable, as is
the case with 32-bit vector moves, constrainted with TARGET_SSE2.
However, this triggers
gcc_assert (mode_size >= UNITS_PER_WORD);
in emit_move_multi_word, since mode_size of V4QImode operand is less than
UNITS_PER_WORD of 64-bit targets.
The patch unconditionally enables 32-bit vector moves to match 16-bit
vector moves. This also enables implementation of 32-bit vector logic
operations with GPR in a follow-up patch.
2022-01-03 Uroš Bizjak <ubizjak@gmail.com>
gcc/ChangeLog:
PR target/103894
* config/i386/mmx.md (mov<V_32:mode>): Remove TARGET_SSE2 constraint.
(mov<V_32:mode>_internal): Ditto.
(*push<V_32:mode>_rex64): Ditto.
(movmisalign<V_32:mode>): Ditto.
(*push<V_32:mode>_rex64 splitter): Enable for
TARGET_64BIT && TARGET_SSE.
(*push<V_32:mode>2): Remove insn pattern.
gcc/testsuite/ChangeLog:
PR target/103894
* gcc.target/i386/pr103894.c: New test.
While cleaning up the bug database, I noticed there was a request
to improve the documentation of the _Complex type extensions.
So I rewrote part of the documentation to make things clearer on
__real/__imag and even added documentation about casts between
the scalar and the complex type.
I moved the documentation of __builtin_complex under this section
too because it makes more sense than having it in the other
built-in section and reference it.
OK? Built make info and make html and checked out the results to
make sure the tables look decent.
gcc/ChangeLog:
PR c/33193
* doc/extend.texi: Extend the documentation about Complex
types for casting and also rewrite the __real__/__imag__
expression portion to use tables.
Move __builtin_complex to the Complex type section.
The Fortran front end was generating invalid code for the array
copy-out after a call to a BIND(C) function for a dummy with the
CONTIGUOUS attribute when the actual argument was a call to the SHAPE
intrinsic or other array expressions that are not lvalues. It was
also generating code to evaluate the argument expression multiple
times on copy-in. This patch teaches it to recognize that a copy is
not needed in these cases.
2022-01-03 Sandra Loosemore <sandra@codesourcery.com>
PR fortran/103390
gcc/fortran/
* expr.c (gfc_is_simply_contiguous): Make it smarter about
function calls.
* trans-expr.c (gfc_conv_gfc_desc_to_cfi_desc): Do not generate
copy loops for array expressions that are not "variables" (lvalues).
gcc/testsuite/
* gfortran.dg/c-interop/pr103390-1.f90: New.
* gfortran.dg/c-interop/pr103390-2.f90: New.
* gfortran.dg/c-interop/pr103390-3.f90: New.
* gfortran.dg/c-interop/pr103390-4.f90: New.
* gfortran.dg/c-interop/pr103390-6.f90: New.
* gfortran.dg/c-interop/pr103390-7.f90: New.
* gfortran.dg/c-interop/pr103390-8.f90: New.
* gfortran.dg/c-interop/pr103390-9.f90: New.
On Wed, Jan 27, 2021 at 12:27:13PM +0100, Ulrich Drepper via Gcc-patches wrote:
> On 1/27/21 11:37 AM, Jakub Jelinek wrote:
> > Would equality comparison against 0 handle the most common cases.
> >
> > The user can write it as
> > __atomic_sub_fetch (x, y, z) == 0
> > or
> > __atomic_fetch_sub (x, y, z) - y == 0
> > thouch, so the expansion code would need to be able to cope with both.
>
> Please also keep !=0, <0, <=0, >0, and >=0 in mind. They all can be
> useful and can be handled with the flags.
<= 0 and > 0 don't really work well with lock {add,sub,inc,dec}, x86 doesn't
have comparisons that would look solely at both SF and ZF and not at other
flags (and emitting two separate conditional jumps or two setcc insns and
oring them together looks awful).
But the rest can work.
Here is a patch that adds internal functions and optabs for these,
recognizes them at the same spot as e.g. .ATOMIC_BIT_TEST_AND* internal
functions (fold all builtins pass) and expands them appropriately (or for
the <= 0 and > 0 cases of +/- FAILs and let's middle-end fall back).
So far I have handled just the op_fetch builtins, IMHO instead of handling
also __atomic_fetch_sub (x, y, z) - y == 0 etc. we should canonicalize
__atomic_fetch_sub (x, y, z) - y to __atomic_sub_fetch (x, y, z) (and vice
versa).
2022-01-03 Jakub Jelinek <jakub@redhat.com>
PR target/98737
* internal-fn.def (ATOMIC_ADD_FETCH_CMP_0, ATOMIC_SUB_FETCH_CMP_0,
ATOMIC_AND_FETCH_CMP_0, ATOMIC_OR_FETCH_CMP_0, ATOMIC_XOR_FETCH_CMP_0):
New internal fns.
* internal-fn.h (ATOMIC_OP_FETCH_CMP_0_EQ, ATOMIC_OP_FETCH_CMP_0_NE,
ATOMIC_OP_FETCH_CMP_0_LT, ATOMIC_OP_FETCH_CMP_0_LE,
ATOMIC_OP_FETCH_CMP_0_GT, ATOMIC_OP_FETCH_CMP_0_GE): New enumerators.
* internal-fn.c (expand_ATOMIC_ADD_FETCH_CMP_0,
expand_ATOMIC_SUB_FETCH_CMP_0, expand_ATOMIC_AND_FETCH_CMP_0,
expand_ATOMIC_OR_FETCH_CMP_0, expand_ATOMIC_XOR_FETCH_CMP_0): New
functions.
* optabs.def (atomic_add_fetch_cmp_0_optab,
atomic_sub_fetch_cmp_0_optab, atomic_and_fetch_cmp_0_optab,
atomic_or_fetch_cmp_0_optab, atomic_xor_fetch_cmp_0_optab): New
direct optabs.
* builtins.h (expand_ifn_atomic_op_fetch_cmp_0): Declare.
* builtins.c (expand_ifn_atomic_op_fetch_cmp_0): New function.
* tree-ssa-ccp.c: Include internal-fn.h.
(optimize_atomic_bit_test_and): Add . before internal fn call
in function comment. Change return type from void to bool and
return true only if successfully replaced.
(optimize_atomic_op_fetch_cmp_0): New function.
(pass_fold_builtins::execute): Use optimize_atomic_op_fetch_cmp_0
for BUILT_IN_ATOMIC_{ADD,SUB,AND,OR,XOR}_FETCH_{1,2,4,8,16} and
BUILT_IN_SYNC_{ADD,SUB,AND,OR,XOR}_AND_FETCH_{1,2,4,8,16},
for *XOR* ones only if optimize_atomic_bit_test_and failed.
* config/i386/sync.md (atomic_<plusminus_mnemonic>_fetch_cmp_0<mode>,
atomic_<logic>_fetch_cmp_0<mode>): New define_expand patterns.
(atomic_add_fetch_cmp_0<mode>_1, atomic_sub_fetch_cmp_0<mode>_1,
atomic_<logic>_fetch_cmp_0<mode>_1): New define_insn patterns.
* doc/md.texi (atomic_add_fetch_cmp_0<mode>,
atomic_sub_fetch_cmp_0<mode>, atomic_and_fetch_cmp_0<mode>,
atomic_or_fetch_cmp_0<mode>, atomic_xor_fetch_cmp_0<mode>): Document
new named patterns.
* gcc.target/i386/pr98737-1.c: New test.
* gcc.target/i386/pr98737-2.c: New test.
* gcc.target/i386/pr98737-3.c: New test.
* gcc.target/i386/pr98737-4.c: New test.
* gcc.target/i386/pr98737-5.c: New test.
* gcc.target/i386/pr98737-6.c: New test.
* gcc.target/i386/pr98737-7.c: New test.
This makes sure to release moved & remapped SSA names during OMP
outlining which happens before going into SSA but with SSA names
created by gimplification around.
2022-01-03 Richard Biener <rguenther@suse.de>
PR middle-end/103851
* tree-cfg.c (move_sese_region_to_fn): Always release SSA names.
* g++.dg/gomp/pr103851.C: New testcase.
On Thu, Dec 09, 2021 at 06:09:12PM -0500, Jason Merrill wrote:
> For the more general comparison of decls like your a != b example above I
> think clang is in the right; in manifestly constant-evaluated context
> (folding_initializer) we should return that they are unequal and prevent a
> later alias declaration, like we do for comparison to 0 in
> maybe_nonzero_address. It's possible that this gives a wrong answer based
> on something in another translation unit, but that's unlikely, and taking
> that chance seems better than rejecting code that needs a constant answer.
I agree. This is an incremental patch to do that.
2022-01-03 Jakub Jelinek <jakub@redhat.com>
PR c++/94716
gcc/
* symtab.c: Include fold-const.h.
(symtab_node::equal_address_to): If folding_initializer is true,
handle it like memory_accessed. Simplify.
gcc/testsuite/
* gcc.dg/init-compare-1.c: New test.
* g++.dg/cpp0x/constexpr-compare1.C: New test.
* g++.dg/cpp1y/constexpr-94716.C: New test.
* g++.dg/cpp1z/constexpr-compare1.C: New test.
If the tinfo vars are emitted in the current TU, they are emitted at the end
of the compilation, and for some types they are exported from
libstdc++/libsupc++ and not emitted in the current TU at all.
The following patch allows constant folding of comparisons of typeid
addresses and makes it possible to implement P1328R1 - making type_info
operator== constexpr (Jonathan has a patch for that).
As mentioned in the PR, the varpool/middle-end code is trying to be
conservative with address comparisons of different vars if those vars
don't bind locally, because of possible aliases in other TUs etc.
and so while match.pd folds &typeid(int) == &typeid(int) because
it is equality comparison with the same operands, for different typeids
it doesn't fold it.
On Wed, Dec 08, 2021 at 08:53:03AM -0500, Jason Merrill wrote:
> Would it make sense to assume that DECL_ARTIFICIAL variables can't be
> aliases? If not, could we have some way of marking a variable as
> non-aliasing, perhaps an attribute?
I think DECL_ARTIFICIAL vars generally can overlap.
The following patch adds a GCC internal attribute "non overlapping"
and uses it in symtab_node::equal_address_to.
Not sure what plans has Honza in that area and whether it would be useful
to make the attribute public and let users assert that some variable will
never overlap with other variables, won't have aliases etc.
> During constant evaluation, the operator== could compare the type_info
> address instead of the __name address, reducing this to the previous
> problem.
Ah, indeed, good idea. FYI, clang++ seems to constant fold
&typeid(x) != &typeid(y) already, so Jonathan could use it even for
clang++ in the constexpr operator==. But it folds even
extern int &a, &b;
constexpr bool c = &a != &b;
regardless of whether some other TU has
int a;
int b __attribute__((alias (a));
or not.
2022-01-03 Jakub Jelinek <jakub@redhat.com>
PR c++/103600
gcc/
* symtab.c (symtab_node::equal_address_to): Return 0 if one of
VAR_DECLs has "non overlapping" attribute and rs1 != rs2.
gcc/c-family/
* c-attribs.c (handle_non_overlapping_attribute): New function.
(c_common_attribute_table): Add "non overlapping" attribute.
gcc/cp/
* rtti.c (get_tinfo_decl_direct): Add "non overlapping" attribute
to DECL_TINFO_P VAR_DECLs.
gcc/testsuite/
* g++.dg/cpp0x/constexpr-typeid2.C: New test.
This adds the second testcase which we now also handle eliminating
a redundant PHI node.
2022-01-03 Richard Biener <rguenther@suse.de>
PR tree-optimization/66502
* gcc.dg/tree-ssa/ssa-fre-98.c: New testcase.
This adds a testcase for a fixed wrong-code bug.
2022-01-03 Richard Biener <rguenther@suse.de>
PR tree-optimization/103615
* gcc.dg/torture/pr103615.c: New testcase.
2022-01-02 John David Anglin <danglin@gcc.gnu.org>
gcc/testsuite/ChangeLog:
* gcc.target/hppa/shadd-2.c: Adjust count to 3.
* gcc.target/hppa/shadd-3.c: Likewise.
While working on PR66139 I noticed that if the destructor of a temporary
created during array initialization throws, we were failing to destroy the
last array element constructed. Throwing destructors are rare since C++11,
but this should be fixed.
gcc/cp/ChangeLog:
* init.c (build_vec_init): Append the decrement to elt_init.
gcc/testsuite/ChangeLog:
* g++.dg/eh/array2.C: New test.
Since C++11, the vast majority of destructors are noexcept, so
wrap_temporary_cleanups adds a bunch of useless TRY_CATCH_EXPR to be removed
later in the optimizers. It's simple to avoid adding them in the first
place.
gcc/cp/ChangeLog:
* decl.c (wrap_cleanups_r): Don't wrap if noexcept.
gcc/testsuite/ChangeLog:
* g++.dg/eh/cleanup6.C: New test.
2022-01-02 John David Anglin <danglin@gcc.gnu.org>
libgcc/ChangeLog:
* config/pa/linux-atomic.c (_ASM_EFAULT): Define.
(__kernel_cmpxchg): Nullify illegal iitlbp instruction if error
return is not equal _ASM_EFAULT.
(__kernel_cmpxchg2): Likewise.
2022-01-02 John David Anglin <danglin@gcc.gnu.org>
gcc/ChangeLog:
* config/pa/pa.md (atomic_storeq): Use optab_libfunc to access
sync_lock_test_and_set libfunc. Call convert_memory_address to
convert memory address to Pmode.
(atomic_storehi, atomic_storesi, atomic_storedi): Likewise.
The darwin system headers error out on __FLT_EVAL_METHOD__ == 16, which
occurs when the compiler is called with -mavx512fp16 on i386. Allow this
value to proceed past the check (nothing else depends on it in the
system headers).
fixincludes/ChangeLog:
* inclhack.def: Add new fix on darwin.
* fixincl.x: Regenerate.
* tests/base/math.h: Regenerate.
These were fixed as part of the fix for PR 99766,
I thought it would be useful to add a few testcases
for the other cases that were failing.
Committed as obvious after running the tests to make
sure they work.
PR rtl-optimization/100241
PR rtl-optimization/99787
gcc/testsuite/ChangeLog:
* gcc.c-torture/compile/pr100241-1.c: New test.
* gcc.c-torture/compile/pr99787-1.c: New test.
The r11-3302-g3696a50beeb73f changes broke the following ObjC testcase.
in_statement is either 0 (not in a looping statement), various IN_* flags
for various kinds of looping statements (or OpenMP structured blocks) or
those flags ored with IN_SWITCH_STMT when a switch appears inside of those
contexts. This is because break binds to switch in that last case, but
continue binds to the looping construct in that case.
The c_finish_bc_stmt function performs diagnostics on incorrect
break/continue uses and then checks if in_statement & IN_OBJC_FOREACH
and in that case jumps to the label provided by the caller, otherwise
emits a BREAK_STMT or CONTINUE_STMT. This is incorrect if we have
ObjC foreach with switch nested in it and break inside of that,
in_statement in that case is IN_OBJC_FOREACH | IN_SWITCH_STMT and
is_break is true. We want to handle it like other breaks inside of
switch, i.e. emit a BREAK_STMT.
The following patch fixes that.
2022-01-01 Jakub Jelinek <jakub@redhat.com>
PR objc/103639
* c-typeck.c (c_finish_bc_stmt): For break inside of switch inside of
ObjC foreach, emit normal BREAK_STMT rather than goto to label.
2022-01-01 Iain Sandoe <iain@sandoe.co.uk>
PR objc/103639
* objc.dg/pr103639.m: New test.
REAL128 is a named constant, so we cannot simply use
(REAL128 > 0) to conditionally compile for targets with
REAL128.
gcc/testsuite/ChangeLog:
PR fortran/89639
* gfortran.dg/ieee/ieee_9.f90: Adjust test for targets without
REAL128.
