[Bug tree-optimization/95565] [Feature request] add a flag to only instrument function entry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95565 --- Comment #1 from AK --- I believe we need to conditionally disable the following code, but I'm not sure of all the implications. If someone can implement it that'd be great. ``` gcc/gimplify.c Around Line:14997 x = builtin_decl_implicit (BUILT_IN_RETURN_ADDRESS); call = gimple_build_call (x, 1, integer_zero_node); tmp_var = create_tmp_var (ptr_type_node, "return_addr"); gimple_call_set_lhs (call, tmp_var); gimplify_seq_add_stmt (, call); x = builtin_decl_implicit (BUILT_IN_PROFILE_FUNC_EXIT); call = gimple_build_call (x, 2, this_fn_addr, tmp_var); gimplify_seq_add_stmt (, call); tf = gimple_build_try (seq, cleanup, GIMPLE_TRY_FINALLY); ```
[Bug tree-optimization/95565] New: [Feature request] add a flag to only instrument function entry.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95565 Bug ID: 95565 Summary: [Feature request] add a flag to only instrument function entry. Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hiraditya at msn dot com Target Milestone: --- The flag -finstrument-functions instruments both entry and the exit of function. There are many scenarios (like cheap profiling) only instrumenting the function entry is sufficient. But gcc instruments exit as well contributing to unwanted code size increase.
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
--- Comment #29 from bouanto at zoho dot com ---
This API looks fine.
Another test would be to create a simple function, the equivalent of this:
#include
asm(
"add:\n"
"movq %rdi, %rax\n"
"add %rsi, %rax\n"
"ret\n");
extern int add(int, int);
int main(void) {
assert(add(40, 2) == 42);
}
(In reply to David Malcolm from comment #27)
> Created attachment 48694 [details]
> v3 of the work-in-progress patch
>
> Here's an updated version of the patch; also uploaded to:
> https://dmalcolm.fedorapeople.org/gcc/2020-06-06/0001-FIXME-WIP-on-extended-
> asm-support-v3.patch
>
> In particular, this adds a new:
> gcc_jit_context_add_top_level_asm
> entrypoint. On implementing this, it hooks into the symbol table like the C
> frontend does, so it looks like it will respect ordering as much as the C
> frontend does.
>
> How does this look? The top-level asm code is barely tested though; I'd
> appreciate a way to verify it from the automated test case.
>
> Changes in v3:
> * added gcc_jit_context_add_top_level_asm
> * drop redundant gcc_jit_extended_asm_add_goto_label
> * added gcc_jit_extended_asm_as_object
> * started adding documentation
> * added comments to libgccjit.h
> * consolidated test-asm.c, grouping create/verify pairs
> * add test coverage for "volatile"
> * initial implementation of make_debug_string
> * added some error-checking
[Bug fortran/95091] ICE in gfc_hash_value, at fortran/class.c:538
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95091 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Priority|P3 |P4 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-06-06 --- Comment #2 from anlauf at gcc dot gnu.org --- Slightly improved patch posted for review: https://gcc.gnu.org/pipermail/fortran/2020-June/054475.html
[Bug fortran/95091] ICE in gfc_hash_value, at fortran/class.c:538
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95091 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Created attachment 48695 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48695=edit Patch to adjust buffer sizes Obvious fix for buffer overflows. Will submit soon.
[Bug c++/95516] [coroutines] incorrect warning "'coro.gro' is used uninitialized"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95516 --- Comment #4 from Iain Sandoe --- (In reply to Iain Sandoe from comment #3) > (In reply to Michael Bruck from comment #2) > > I was using -Ofast -Wall: > > https://gcc.godbolt.org/z/pAkVS8 > > I can repeat it with -Ofast. > [this still might have nothing to do with coroutines, but rather the > tracking of var usage, since the complaint is in the ramp function (which is > a regular c++ function)] ... and now it's gone again ...
[Bug fortran/95512] gcc/fortran/trans-decl.c:1066: array sanity check after use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95512 --- Comment #4 from David Binderman --- (In reply to anlauf from comment #3) > I didn't write the code, but for more context: Thanks for the extra context. > Maybe it is bad style, but I still consider it a false positive. If you go back and check what cppcheck is saying, it is merely mentioning what it thinks is bad style. > cppcheck's view is probably too narrow to understand the range of dim. Agreed. AFAIK cppcheck merely searches and reports on source code patterns like if (arrayName[ X] && X < someExpression) Whether you want to keep the code in bad style is up to you. I did originally suggest some code that looked IMHO to be better style.
[Bug bootstrap/95555] [11 regression] bootstrap build failure starting with r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 Martin Sebor changed: What|Removed |Added Target Milestone|--- |11.0 Host||powerpc64*-linux Target||powerpc64*-linux Last reconfirmed||2020-06-06 Build||powerpc64*-linux Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Keywords||patch Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #6 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547436.html
[Bug lto/95548] ice in tree_to_shwi, at tree.c:7321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95548 --- Comment #5 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:eca7a60bd24ebd91addd785e420a06d8f5086634 commit r11-1016-geca7a60bd24ebd91addd785e420a06d8f5086634 Author: Jan Hubicka Date: Sat Jun 6 22:19:46 2020 +0200 Fix ICE in ODR enum streaming [PR95548] gcc/ChangeLog: 2020-06-06 Jan Hubicka PR lto/95548 * ipa-devirt.c (struct odr_enum_val): Turn values to wide_int. (ipa_odr_summary_write): Update streaming. (ipa_odr_read_section): Update streaming. gcc/testsuite/ChangeLog: 2020-06-06 Jan Hubicka * g++.dg/torture/pr95548.C: New test.
[Bug target/95478] CPP stack pointer SP is 0x5d but assembly shows __SP_L_ at 0x3d (target AVR MEGA2560)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95478 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Georg-Johann Lay --- Closed as invalid: avr-gcc is using the I/O address here, not the SRAM address. Mind SFR-I/O address offset as documented with the built-in macros.
[Bug fortran/95512] gcc/fortran/trans-decl.c:1066: array sanity check after use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95512
--- Comment #3 from anlauf at gcc dot gnu.org ---
I didn't write the code, but for more context:
trans.h has:
#define GFC_TYPE_ARRAY_LBOUND(node, dim) \
(TYPE_LANG_SPECIFIC(node)->lbound[dim])
#define GFC_TYPE_ARRAY_UBOUND(node, dim) \
(TYPE_LANG_SPECIFIC(node)->ubound[dim])
The loop in trans-decl.c:
for (dim = GFC_TYPE_ARRAY_RANK (type);
dim < GFC_TYPE_ARRAY_RANK (type) + GFC_TYPE_ARRAY_CORANK (type); dim++)
{
if (GFC_TYPE_ARRAY_LBOUND (type, dim) == NULL_TREE)
{
GFC_TYPE_ARRAY_LBOUND (type, dim) = create_index_var ("lbound",
nest);
TREE_NO_WARNING (GFC_TYPE_ARRAY_LBOUND (type, dim)) = 1;
}
/* Don't try to use the unknown ubound for the last coarray dimension.
*/
if (GFC_TYPE_ARRAY_UBOUND (type, dim) == NULL_TREE
&& dim < GFC_TYPE_ARRAY_RANK (type) + GFC_TYPE_ARRAY_CORANK (type) -
1)
{
GFC_TYPE_ARRAY_UBOUND (type, dim) = create_index_var ("ubound",
nest);
TREE_NO_WARNING (GFC_TYPE_ARRAY_UBOUND (type, dim)) = 1;
}
}
So the relevant check is in the loop header, and the current check is there
for the last index.
Maybe it is bad style, but I still consider it a false positive.
cppcheck's view is probably too narrow to understand the range of dim.
[Bug c++/95516] [coroutines] incorrect warning "'coro.gro' is used uninitialized"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95516 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Target Milestone|--- |10.2 --- Comment #3 from Iain Sandoe --- (In reply to Michael Bruck from comment #2) > I was using -Ofast -Wall: > https://gcc.godbolt.org/z/pAkVS8 I can repeat it with -Ofast. [this still might have nothing to do with coroutines, but rather the tracking of var usage, since the complaint is in the ramp function (which is a regular c++ function)]
[Bug c++/95440] [coroutines] ICE with static members in promise_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95440 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2020-06-06 Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |10.2 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #1 from Iain Sandoe --- thanks for the report
[Bug tree-optimization/95295] g++ produces incorrect code with -O3 for loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95295
Shubham Narlawar changed:
What|Removed |Added
CC||gsocshubham at gmail dot com
--- Comment #9 from Shubham Narlawar ---
I found the ICE - "internal compiler error: in hoist_memory_references, at
tree-ssa-loop-im.c:2615" with below testcase when compiled with -Og on trunk.
The testcase is obtained by fuzzing function attributes in Csmith -
--Testcase---
a, b, c, d, f;
**e;
g() __attribute__((optimize("Ofast")));
g(h) {
int *i =
for (; f;) {
c = 5;
for (; c; c--) {
char *j =
**e = (h && d) == a;
*i = 0;
*j = 0;
}
}
}
-
I see above ICE has been fixed now.
[Bug c++/94829] ICE in poplevel, at cp/decl.c:585 since r10-6063-g49789fd08378e3ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94829 Iain Sandoe changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Iain Sandoe --- fixed on master and for 10.2
[Bug c++/95087] [11 Regression] ICE in gimplify_expr, at gimplify.c:14382
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95087 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Iain Sandoe --- fixed on master and for 10.2
[Bug c++/94817] ICE in add_stmt, at cp/semantics.c:392 since r10-6063-g49789fd08378e3ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94817 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Iain Sandoe --- fixed on master and for 10.2
[Bug jit/95498] unhandled conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95498 --- Comment #3 from bouanto at zoho dot com --- (In reply to David Malcolm from comment #2) > Try putting a breakpoint on add_error (there are a few classes with > add_error methods; a sufficiently smart gdb ought to put the breakpoint on > all of them). I added the call to gcc_jit_context_dump_to_file (ctxt, "/tmp/something.c", 1 /* update_locations */); right after create_code(ctxt) but the parameter loc is NULL when I reach add_error in gdb so that I cannot print the line number. It was also null when I tried with the reproducer of this issue: https://gcc.gnu.org/bugzilla//show_bug.cgi?id=95521 Is there anything else to change in the reproducer so that it updates the locations accordingly?
[Bug jit/95498] unhandled conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95498 --- Comment #2 from David Malcolm --- Try putting a breakpoint on add_error (there are a few classes with add_error methods; a sufficiently smart gdb ought to put the breakpoint on all of them).
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #28 from David Malcolm --- Generated HTML for docs (albeit without css) here: https://dmalcolm.fedorapeople.org/gcc/2020-06-06/asm-v3.html
[Bug libstdc++/95561] std::is_signed_v<__int128> is false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95561 --- Comment #5 from Janez Zemva --- Thank you for the "fix", I am writing my own 128-bit integral type, but in the mean time, I'm using __int128.
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 David Malcolm changed: What|Removed |Added Attachment #48684|0 |1 is obsolete|| --- Comment #27 from David Malcolm --- Created attachment 48694 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48694=edit v3 of the work-in-progress patch Here's an updated version of the patch; also uploaded to: https://dmalcolm.fedorapeople.org/gcc/2020-06-06/0001-FIXME-WIP-on-extended-asm-support-v3.patch In particular, this adds a new: gcc_jit_context_add_top_level_asm entrypoint. On implementing this, it hooks into the symbol table like the C frontend does, so it looks like it will respect ordering as much as the C frontend does. How does this look? The top-level asm code is barely tested though; I'd appreciate a way to verify it from the automated test case. Changes in v3: * added gcc_jit_context_add_top_level_asm * drop redundant gcc_jit_extended_asm_add_goto_label * added gcc_jit_extended_asm_as_object * started adding documentation * added comments to libgccjit.h * consolidated test-asm.c, grouping create/verify pairs * add test coverage for "volatile" * initial implementation of make_debug_string * added some error-checking
[Bug fortran/95543] [PDT] ICE in is_CFI_desc, at fortran/expr.c:1080
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95543 --- Comment #4 from Steve Kargl --- On Sat, Jun 06, 2020 at 05:13:31PM +, sgk at troutmask dot apl.washington.edu wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95543 > > --- Comment #3 from Steve Kargl --- > On Sat, Jun 06, 2020 at 04:34:53PM +, kargl at gcc dot gnu.org wrote: > > > > This cures the ICE, which then I believe leads to wrong-code. > > > > PDT are completely broken. When this is parsed > >type t(a, b) > integer, kind :: a = 1 > integer, kind :: b = a >end type > > the internal representation of for 't' has two components; > namely, a component for 'a' and a component for 'b'. Neither > 'a' nor 'b' is a component, and should therefore not be > in the link list of components. All of the programs in this > bug report should likely print nothing. > A little debugging shows *ts->u.derived->param_list = 0x0 ts->u.derived->components->name = 'a' ts->u.derived->components->next->name = 'b' It seems that param_list is populated when the derived type definition is used in an actual derived type declaration, ie., type(t(b=6)) would have a param_list item for 'b'. Looking in gfortran.h shows param_list is a 'gfc_actual_arglist *' type, ie., a list of actual arguments. Probably not a bad idea, since 't(b=6,a=4)' is valid and 'a' and 'b' can be treated as-if they are actual arguments to a function 't'. components are 'gfc_symbol *', so we cannot simply move then to the param_list.
[Bug libstdc++/95561] std::is_signed_v<__int128> is false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95561 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Jonathan Wakely --- Not a bug. Marc was asking *which* option you're using, -std=gnu++17 or -std=c++17. __int128 is not an integral type, so in strict -std=c++17 mode the standard requires that is_integral_v<__int128> is false and therefore is_signed_v<__int128> has to be false too. With -std=gnu++17 both are true. This is by design, not a bug. If you want to use non-standard extensions like __int128 and have them treated as integral types, don't ask for strict standard conformance with -std=c++17.
[Bug libstdc++/95561] std::is_signed_v<__int128> is false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95561 --- Comment #3 from Janez Zemva --- BTW: std::is_integral_v<__int128> is also false. I'm not certain, whether this is a bug, but reporting nonetheless.
[Bug libstdc++/95561] std::is_signed_v<__int128> is false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95561 --- Comment #2 from Janez Zemva --- (In reply to Marc Glisse from comment #1) > Are you using -std=gnu++17 or -std=c++17 ? yes, of course.
[Bug middle-end/95556] Not replacing __builtin___memcpy_chk() as documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556 --- Comment #8 from Jakub Jelinek --- (In reply to Jeff Davis from comment #7) > "...built-in functions are optimized into the normal string functions like > memcpy if the last argument is (size_t) -1..." > > My reading of the document lead me to believe that a last argument of -1 > *would* be a normal library call. And certainly should be with > -fno-builtin-memcpy, right? No. Because -fno-builtin-memcpy only disables the special behavior if one uses memcpy, when one uses __builtin_memcpy, it behaves always as builtin. And you are using __builtin___memcpy_chk which is also a builtin and thus not affected by -fno-builtin*. You can use -fno-builtin-__memcpy_chk but then you'll get __memcpy_chk calls if you call it that way. As I wrote, if you for whatever reason want to use the library call, e.g. always, you can just use -mmemcpy-strategy=libcall:-1:1 or so, but then even very small ones will not be done inline, which is not really beneficial.
[Bug fortran/95543] [PDT] ICE in is_CFI_desc, at fortran/expr.c:1080
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95543 --- Comment #3 from Steve Kargl --- On Sat, Jun 06, 2020 at 04:34:53PM +, kargl at gcc dot gnu.org wrote: > > This cures the ICE, which then I believe leads to wrong-code. > PDT are completely broken. When this is parsed type t(a, b) integer, kind :: a = 1 integer, kind :: b = a end type the internal representation of for 't' has two components; namely, a component for 'a' and a component for 'b'. Neither 'a' nor 'b' is a component, and should therefore not be in the link list of components. All of the programs in this bug report should likely print nothing.
[Bug middle-end/95556] Not replacing __builtin___memcpy_chk() as documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556 --- Comment #7 from Jeff Davis --- "...built-in functions are optimized into the normal string functions like memcpy if the last argument is (size_t) -1..." My reading of the document lead me to believe that a last argument of -1 *would* be a normal library call. And certainly should be with -fno-builtin-memcpy, right? If that's not what's happening, should the document be clarified?
[Bug c++/94817] ICE in add_stmt, at cp/semantics.c:392 since r10-6063-g49789fd08378e3ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94817 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:03da87235697eab344cde609d81d3f405f450c42 commit r10-8259-g03da87235697eab344cde609d81d3f405f450c42 Author: Iain Sandoe Date: Sat Jun 6 09:48:31 2020 +0100 coroutines: Improve error recovery [PR94817, PR94829, PR95087]. When we have completely missing key information (e.g. the coroutine_traits) or a partially transformed function body, we need to try and balance returning useful information about failures with the possibility that some part of the diagnostics machinery or following code will not be able to handle the state. The PRs (and revised testcase) point to cases where that processing has failed. This revises the process to avoid special handling for the ramp, and falls back on the same code used for regular function fails. There are test-cases (in addition to the ones for the PRs) that now cover all early exit points [where the transforms are considered to have failed in a manner that does not allow compilation to continue]. Diagnosing bad uses of 'return' in coroutines is somewhat tricky, since the user can use the keyword before we know that the function is a coroutine (where such returns are not permitted). At present, we are just doing a check for any use of 'return' and erroring on that. However, we can't then pass the function body on, since it will contain unlowered coroutine trees. This avoids the issue by dropping the entire function body under that circumstance. Backport c7100843831147a034fe37d231c54ac53ceace45 and a1bb808504643e6c3c0df0fdd68a941ed2a64c7f0 gcc/cp/ChangeLog: PR c++/94817 PR c++/94829 PR c++/95087 * coroutines.cc (morph_fn_to_coro): Set unformed outline functions to error_mark_node. For early error returns suppress warnings about missing ramp return values. Fix reinstatement of the function body on pre-existing initial error. If we see an early fatal error, drop the erroneous function body. * decl.c (finish_function): Use the normal error path for fails in the ramp function, do not try to compile the helpers if the transform fails. gcc/testsuite/ChangeLog: PR c++/94817 PR c++/94829 PR c++/95087 * g++.dg/coroutines/coro-missing-final-suspend.C: New test. * g++.dg/coroutines/coro-missing-initial-suspend.C: New test. * g++.dg/coroutines/coro-missing-promise-yield.C: Check for continuation of compilation. * g++.dg/coroutines/coro-missing-promise.C: Likewise. * g++.dg/coroutines/coro-missing-ret-value.C: Likewise * g++.dg/coroutines/coro-missing-ret-void.C: Likewise * g++.dg/coroutines/coro-missing-ueh-3.C: Likewise * g++.dg/coroutines/pr94817.C: New test. * g++.dg/coroutines/pr94829.C: New test. * g++.dg/coroutines/co-return-syntax-08-bad-return.C: Adjust the testcase to do the compile (rather than an -fsyntax-only parse). * g++.dg/coroutines/coro1-ret-int-yield-int.h (MISSING_INITIAL_SUSPEND, MISSING_FINAL_SUSPEND): New.
[Bug c++/94829] ICE in poplevel, at cp/decl.c:585 since r10-6063-g49789fd08378e3ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94829 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:03da87235697eab344cde609d81d3f405f450c42 commit r10-8259-g03da87235697eab344cde609d81d3f405f450c42 Author: Iain Sandoe Date: Sat Jun 6 09:48:31 2020 +0100 coroutines: Improve error recovery [PR94817, PR94829, PR95087]. When we have completely missing key information (e.g. the coroutine_traits) or a partially transformed function body, we need to try and balance returning useful information about failures with the possibility that some part of the diagnostics machinery or following code will not be able to handle the state. The PRs (and revised testcase) point to cases where that processing has failed. This revises the process to avoid special handling for the ramp, and falls back on the same code used for regular function fails. There are test-cases (in addition to the ones for the PRs) that now cover all early exit points [where the transforms are considered to have failed in a manner that does not allow compilation to continue]. Diagnosing bad uses of 'return' in coroutines is somewhat tricky, since the user can use the keyword before we know that the function is a coroutine (where such returns are not permitted). At present, we are just doing a check for any use of 'return' and erroring on that. However, we can't then pass the function body on, since it will contain unlowered coroutine trees. This avoids the issue by dropping the entire function body under that circumstance. Backport c7100843831147a034fe37d231c54ac53ceace45 and a1bb808504643e6c3c0df0fdd68a941ed2a64c7f0 gcc/cp/ChangeLog: PR c++/94817 PR c++/94829 PR c++/95087 * coroutines.cc (morph_fn_to_coro): Set unformed outline functions to error_mark_node. For early error returns suppress warnings about missing ramp return values. Fix reinstatement of the function body on pre-existing initial error. If we see an early fatal error, drop the erroneous function body. * decl.c (finish_function): Use the normal error path for fails in the ramp function, do not try to compile the helpers if the transform fails. gcc/testsuite/ChangeLog: PR c++/94817 PR c++/94829 PR c++/95087 * g++.dg/coroutines/coro-missing-final-suspend.C: New test. * g++.dg/coroutines/coro-missing-initial-suspend.C: New test. * g++.dg/coroutines/coro-missing-promise-yield.C: Check for continuation of compilation. * g++.dg/coroutines/coro-missing-promise.C: Likewise. * g++.dg/coroutines/coro-missing-ret-value.C: Likewise * g++.dg/coroutines/coro-missing-ret-void.C: Likewise * g++.dg/coroutines/coro-missing-ueh-3.C: Likewise * g++.dg/coroutines/pr94817.C: New test. * g++.dg/coroutines/pr94829.C: New test. * g++.dg/coroutines/co-return-syntax-08-bad-return.C: Adjust the testcase to do the compile (rather than an -fsyntax-only parse). * g++.dg/coroutines/coro1-ret-int-yield-int.h (MISSING_INITIAL_SUSPEND, MISSING_FINAL_SUSPEND): New.
[Bug c++/95087] [11 Regression] ICE in gimplify_expr, at gimplify.c:14382
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95087 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:03da87235697eab344cde609d81d3f405f450c42 commit r10-8259-g03da87235697eab344cde609d81d3f405f450c42 Author: Iain Sandoe Date: Sat Jun 6 09:48:31 2020 +0100 coroutines: Improve error recovery [PR94817, PR94829, PR95087]. When we have completely missing key information (e.g. the coroutine_traits) or a partially transformed function body, we need to try and balance returning useful information about failures with the possibility that some part of the diagnostics machinery or following code will not be able to handle the state. The PRs (and revised testcase) point to cases where that processing has failed. This revises the process to avoid special handling for the ramp, and falls back on the same code used for regular function fails. There are test-cases (in addition to the ones for the PRs) that now cover all early exit points [where the transforms are considered to have failed in a manner that does not allow compilation to continue]. Diagnosing bad uses of 'return' in coroutines is somewhat tricky, since the user can use the keyword before we know that the function is a coroutine (where such returns are not permitted). At present, we are just doing a check for any use of 'return' and erroring on that. However, we can't then pass the function body on, since it will contain unlowered coroutine trees. This avoids the issue by dropping the entire function body under that circumstance. Backport c7100843831147a034fe37d231c54ac53ceace45 and a1bb808504643e6c3c0df0fdd68a941ed2a64c7f0 gcc/cp/ChangeLog: PR c++/94817 PR c++/94829 PR c++/95087 * coroutines.cc (morph_fn_to_coro): Set unformed outline functions to error_mark_node. For early error returns suppress warnings about missing ramp return values. Fix reinstatement of the function body on pre-existing initial error. If we see an early fatal error, drop the erroneous function body. * decl.c (finish_function): Use the normal error path for fails in the ramp function, do not try to compile the helpers if the transform fails. gcc/testsuite/ChangeLog: PR c++/94817 PR c++/94829 PR c++/95087 * g++.dg/coroutines/coro-missing-final-suspend.C: New test. * g++.dg/coroutines/coro-missing-initial-suspend.C: New test. * g++.dg/coroutines/coro-missing-promise-yield.C: Check for continuation of compilation. * g++.dg/coroutines/coro-missing-promise.C: Likewise. * g++.dg/coroutines/coro-missing-ret-value.C: Likewise * g++.dg/coroutines/coro-missing-ret-void.C: Likewise * g++.dg/coroutines/coro-missing-ueh-3.C: Likewise * g++.dg/coroutines/pr94817.C: New test. * g++.dg/coroutines/pr94829.C: New test. * g++.dg/coroutines/co-return-syntax-08-bad-return.C: Adjust the testcase to do the compile (rather than an -fsyntax-only parse). * g++.dg/coroutines/coro1-ret-int-yield-int.h (MISSING_INITIAL_SUSPEND, MISSING_FINAL_SUSPEND): New.
[Bug target/94833] vec_first_match_index does not function as described in its description
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94833 --- Comment #4 from CVS Commits --- The releases/gcc-9 branch has been updated by Carl Love : https://gcc.gnu.org/g:a47259fa7737ff6d4a7def074fb30bc7baef2f86 commit r9-8659-ga47259fa7737ff6d4a7def074fb30bc7baef2f86 Author: Carl Love Date: Wed Apr 29 10:23:11 2020 -0500 pr94833, fix vec_first_match_index for nulls Backported patch from mainline. Updated ChangeLog format commit 24f68831d25bad739a6fe167a58b5b4c0c3cbf9a Author: Carl Love Date: Wed Apr 29 10:23:11 2020 -0500 2020-04-30 Carl Love gcc/ PR target/94833 * config/rs6000/vsx.md (define_expand): Fix instruction generation for first_match_index_. gcc/testsuite/ PR target/94833 * gcc.target/powerpc/builtins-8-p9-runnable.c (main): Add additional test cases with zero vector elements.
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #26 from David Malcolm --- (there's also -fno-toplevel-reorder which makes me wonder if we do need to preserve ordering with such constructs)
[Bug fortran/95543] [PDT] ICE in is_CFI_desc, at fortran/expr.c:1080
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95543
kargl at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
--- Comment #2 from kargl at gcc dot gnu.org ---
This cures the ICE, which then I believe leads to wrong-code.
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 280157)
+++ gcc/fortran/trans-decl.c(working copy)
@@ -708,7 +708,7 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym)
are SAVE_NONE but have an initializer. Otherwise explicitly
initialized variables are SAVE_IMPLICIT and explicitly saved are
SAVE_EXPLICIT. */
- if (!sym->attr.use_assoc
+ if (!sym->attr.use_assoc && !sym->attr.pdt_kind && !sym->attr.pdt_len
&& (sym->attr.save != SAVE_NONE || sym->attr.data
|| (sym->value && sym->ns->proc_name->attr.is_main_program)
|| (flag_coarray == GFC_FCOARRAY_LIB
@@ -1554,7 +1554,9 @@ gfc_get_symbol_decl (gfc_symbol * sym)
fun_or_res = byref && (sym->attr.result
|| (sym->attr.function && sym->ts.deferred));
- if ((sym->attr.dummy && ! sym->attr.function) || fun_or_res)
+ if (((sym->attr.dummy && !sym->attr.function)
+ && !(sym->attr.pdt_kind || sym->attr.pdt_len))
+ || fun_or_res)
{
/* Return via extra parameter. */
if (sym->attr.result && byref
[Bug c++/95564] New: GCC rejects lambda expression with "noexcept(1+1)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95564
Bug ID: 95564
Summary: GCC rejects lambda expression with "noexcept(1+1)"
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This code test.cc
int main(){
auto a = [ & ] (...) noexcept(1+1) {};
return 0;
}
$g++-trunk test.cc
test.cc:2:38: error: narrowing conversion of '2' from 'int' to 'bool'
[-Wnarrowing]
2 | auto a = [ & ] (...) noexcept(1+1) {};
|
GCC fails to compile it, while clang, icc, or msvc accept it.
[Bug libstdc++/95561] std::is_signed_v<__int128> is false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95561 --- Comment #1 from Marc Glisse --- Are you using -std=gnu++17 or -std=c++17 ?
[Bug fortran/95543] [PDT] ICE in is_CFI_desc, at fortran/expr.c:1080
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95543 kargl at gcc dot gnu.org changed: What|Removed |Added Summary|ICE in is_CFI_desc, at |[PDT] ICE in is_CFI_desc, |fortran/expr.c:1080 |at fortran/expr.c:1080 Last reconfirmed||2020-06-06 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Priority|P3 |P4 CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Yet, another PDT bug.
[Bug c++/95302] function attributed to be deprecated cannot include a typedef/using
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95302 Anatol changed: What|Removed |Added CC||anatol.pomozov at gmail dot com --- Comment #1 from Anatol --- Shyouhei, thank you for filing this ticket. I agree that GCC should not complain about deprecated usage if the symbol is not really used. Such GCC behavior causes excessive compile time warnings when using SWIG library https://github.com/swig/swig/issues/1689#issuecomment-636109918
[Bug ipa/95558] Invalid IPA optimizations based on weak definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558 --- Comment #3 from Rich Felker --- In addition to a fix, this is going to need a workaround as well. Do you have ideas for a clean one? A dummy asm in the dummy function to kill pureness is certainly a big hammer that would work, but it precludes LTO optimization if the weak definition doesn't actually get replaced, so I don't like that. One idea I think would work, but not sure: make an external __weak_dummy_tail function that all the weak dummies tail call to. This should only take a few bytes more than just returning, and precludes pureness analysis in the TU it's in, while still allowing DCE at LTO time when the definition of __weak_dummy_tail becomes available. Is my reasoning correct here?
[Bug ipa/95558] Invalid IPA optimizations based on weak definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558 --- Comment #2 from Rich Felker --- Wow. It's interesting that we've never seen this lead to incorrect codegen before, though. All weak dummies should be affected, but only in some cases does the pure get used to optimize out the external call. This suggests there's a major missed optimization around pure functions too, in addition to the wrong application of pure (transfering it from the weak definition to the external declaration) that's the bug.
[Bug translation/95563] High memory usage and possible infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95563 --- Comment #1 from Madhur Chauhan --- (In reply to Madhur Chauhan from comment #0) > Created attachment 48693 [details] > Original code My bad, this is the simplified version of the code but its name is misleading. The original code is in the URL at the bottom.
[Bug translation/95563] New: High memory usage and possible infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95563 Bug ID: 95563 Summary: High memory usage and possible infinite loop Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation Assignee: unassigned at gcc dot gnu.org Reporter: madhur4127 at gmail dot com Target Milestone: --- Created attachment 48693 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48693=edit Original code Attached simplified.cc, which aims to be a complete example. For the original code please see [1] (at bottom). simplified.cc aims to be minimal in nature. But please verify the issue with the original code. Logic: Computing a binomial coefficient over a few iterations using a Modular<> struct which is a wrapper over integer supporting modular arithmetic. Combinatorics struct contains two arrays of "Modular" integers, one for factorials and other for inverse factorials (modular multiplicative inverse of the corresponding factorial). On Linux, compilation took over 3.3GB of memory and 100% CPU utilization for over 30 minutes, and thereafter I had to kill it. This hints for an infinite loop. command: g++ simplified.cc -o simplified GCC version: Default GCC package (gcc 10.1.0-2) of Arch Linux Target: x86_64-pc-linux-gnu If the issue is simple to fix, then I would like to fix it for GCC (some pointers would be appreciated as I have no experience in developing compilers). References: 1. Original Code: https://gist.github.com/madhur4127/4eb29246463ed5a0538e1d9c8a2a7192
[Bug c++/95562] New: ICE when using noexcept depending on boolean template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95562
Bug ID: 95562
Summary: ICE when using noexcept depending on boolean template
parameter
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: philipp.koegel at mailbox dot org
Target Milestone: ---
* gcc version: 10.1.0
* system type: x86_64-linux-gnu
* configured with: ../gcc-10.1.0/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran,ada,d
--enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto
--enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build
* The command line that triggers the bug:
g++ -c noexcept_bug.cpp
* Source code that triggers the bug:
template
struct Functions
{
void (*func)(void*) noexcept(Nothrow);
};
void test()
{
Functions f{nullptr};
}
* Compiler output:
: In instantiation of 'struct Functions':
:9:21: required from here
:4:12: internal compiler error: Segmentation fault
4 | void (*func)(void*) noexcept(Nothrow);
|^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug fortran/42693] Missing gcc-internal-format on messages from gfc_arith_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42693 --- Comment #5 from Göran Uddeborg --- (In reply to markeggleston from comment #4) > Does this mean that this is fixed? I don't think so. The "_" define typically marks the string for translation, but it doesn't add the information this is a format string using "gcc-internal-format" rather than regular printf() style formatting. According to comment 3, that can be achieved by using the define "G_" rather than plain "_" for those strings using "%L" or any other GCC specific formatting directives..
[Bug jit/95498] unhandled conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95498 --- Comment #1 from bouanto at zoho dot com --- I'm trying to create a smaller reproducer by calling gcc_jit_context_dump_to_file, but I don't know where to stop in gdb in order to get the source info. How did you do it in https://gcc.gnu.org/bugzilla//show_bug.cgi?id=95521 ?
[Bug libstdc++/95561] New: std::is_signed_v<__int128> is false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95561 Bug ID: 95561 Summary: std::is_signed_v<__int128> is false Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: janezz55 at gmail dot com Target Milestone: --- As the comment says, std::is_signed_v<__int128> should evaluate to true.
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #25 from bouanto at zoho dot com --- (In reply to David Malcolm from comment #24) > (In reply to bouanto from comment #23) > > Created attachment 48685 [details] > > Example of global assembly > > [...snip; thanks for the feedback] > > > I attached an example of global assembly. > > Thanks. > > > I don't understand the ordering issue. > > I also don't understand how gcc_jit_context_new_function is used here. > > I see that you have a balanced .pushsection/.popsection pair in your > example. Is it ever the case that people might want to have a .pushsection, > then some C code, then a .popsection? (and, by analogy, the same for > libgccjit rather than C). That's the ordering issue I'm concerned about, > since at that point it matters what order the hand-written asm is in > relative to the compiler-generated asm. I think we can assume that people won't try to mix top-level assembly and C code. So, we can assume the order won't matter and document this behavior.
[Bug c++/95560] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95560 --- Comment #2 from RJE --- Created attachment 48692 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48692=edit assembler source
[Bug c++/95560] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95560 --- Comment #1 from RJE --- Created attachment 48691 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48691=edit Compile information .ii file compressed
[Bug c++/95560] New: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95560
Bug ID: 95560
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rebel at ameritech dot net
Target Milestone: ---
Created attachment 48690
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48690=edit
C++ program to compile
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=d:/mingw/bin/../libexec/gcc/x86_64-w64-mingw32/10.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../src/configure --enable-languages=c,c++
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --disable-multilib --prefix=/d/temp/gcc/dest
--with-sysroot=/d/temp/gcc/dest --disable-libstdcxx-pch
--disable-libstdcxx-verbose --disable-nls --disable-shared
--disable-win32-registry --with-architechture=native --enable-threads=posix
--enable-libgomp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (GCC)
g++ -std=c++20 -Wall -Wextra test_cv.cpp
test_cv.cpp: In function 'void testTimedIWait(bool, bool, Dur)':
test_cv.cpp:464:28: internal compiler error: Segmentation fault
464 | enum class State { loop, ready, interrupted };
|^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug middle-end/95556] Not replacing __builtin___memcpy_chk() as documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556 --- Comment #6 from Jakub Jelinek --- See -mno-align-stringops, -minline-all-stringops, -minline-stringops-dynamically, -mstringop-strategy= , -mmemcpy-strategy= options and their documentation in the GCC manual.
[Bug middle-end/95556] Not replacing __builtin___memcpy_chk() as documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556 --- Comment #5 from Jakub Jelinek --- And note that - if (lt->pos >= (8192-sizeof(S))) + if (lt->pos >= (8192-16)) is not an insignificant change, the first one is unsigned comparison, the second one signed.
[Bug middle-end/95556] Not replacing __builtin___memcpy_chk() as documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- It is unclear what you are complaining about. for i in gcc-7 gcc-8 gcc-9 gcc-10 gcc; do echo $i; for j in 1 2 3; do /usr/src/$i/obj/gcc/cc1 -quiet -O2 pr95556-$j.c; done; grep 'memcpy\|rep.movs' pr95556-*.s; done gcc-7 pr95556-1.s:rep movsq pr95556-2.s:callmemcpy pr95556-3.s:callmemcpy gcc-8 pr95556-1.s:rep movsq pr95556-2.s:callmemcpy pr95556-3.s:callmemcpy gcc-9 pr95556-1.s:rep movsq pr95556-2.s:callmemcpy pr95556-3.s:callmemcpy gcc-10 pr95556-1.s:rep movsq pr95556-2.s:rep movsq pr95556-3.s:callmemcpy gcc pr95556-1.s:rep movsq pr95556-2.s:rep movsq pr95556-3.s:callmemcpy There are no __memcpy_chk calls, which means GCC did in all cases what is documented, replace the __builtin___memcpy_chk calls with the corresponding __builtin_memcpy calls and handled that as usually (which isn't always a library call, there are many different options how a builtin memcpy can be expanded and one can find tune that through various command line options. It depends on what CPU the code is tuned for, whether it is considered hot or cold code, whether the size is constant and what constant or if it is variable and what alignment guarantees the destination and source has.
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #24 from David Malcolm --- (In reply to bouanto from comment #23) > Created attachment 48685 [details] > Example of global assembly [...snip; thanks for the feedback] > I attached an example of global assembly. Thanks. > I don't understand the ordering issue. > I also don't understand how gcc_jit_context_new_function is used here. I see that you have a balanced .pushsection/.popsection pair in your example. Is it ever the case that people might want to have a .pushsection, then some C code, then a .popsection? (and, by analogy, the same for libgccjit rather than C). That's the ordering issue I'm concerned about, since at that point it matters what order the hand-written asm is in relative to the compiler-generated asm.
[Bug ipa/95558] Invalid IPA optimizations based on weak definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org,
||marxin at gcc dot gnu.org
Component|middle-end |ipa
Keywords||wrong-code
--- Comment #1 from Alexander Monakov ---
All functions are incorrectly discovered to be pure, and then the loop that
only makes calls to non-weak pure functions is eliminated.
Minimal testcase for the root issue, wrong warning with -O2
-Wsuggest-attribute=pure:
static void dummy(){}
void weak() __attribute__((weak,alias("dummy")));
int foo()
{
weak();
return 0;
}
[Bug bootstrap/95555] [11 regression] bootstrap build failure starting with r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 Andreas Schwab changed: What|Removed |Added Host|powerpc64*-linux-gnu| Build|powerpc64*-linux-gnu| Target|powerpc64*-linux-gnu| --- Comment #5 from Andreas Schwab --- Can we please get bootstrap back?
[Bug target/95523] aarch64:ICE in register_tuple_type，at config/aarch64/aarch64-sve-builtins.cc:3434
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95523 --- Comment #4 from z.zhanghaijian at huawei dot com --- > Could you try setting DECL_USER_ALIGN on the FIELD_DECL? > that should (hopefully) force the field to keep its > natural alignment. Do you mean to change the alignment to natural alignment when processing arm_sve.h, and then change it back after handle_arm_sve_h? I tracked the calculation process of TYPE_ALIGN (tuple_type), which is determined by maximum_field_alignment in layout_decl, not from DECL_USER_ALIGN. We can set maximum_field_alignment in sve_switcher to achieve the purpose of natural alignment. like: diff --git a/gcc/config/aarch64/aarch64-sve-builtins.cc b/gcc/config/aarch64/aarch64-sve-builtins.cc index bdb04e8170d..c49fcebcd43 100644 --- a/gcc/config/aarch64/aarch64-sve-builtins.cc +++ b/gcc/config/aarch64/aarch64-sve-builtins.cc @@ -878,6 +878,9 @@ sve_switcher::sve_switcher () aarch64_isa_flags = (AARCH64_FL_FP | AARCH64_FL_SIMD | AARCH64_FL_F16 | AARCH64_FL_SVE); + m_old_maximum_field_alignment = maximum_field_alignment; + maximum_field_alignment = 0; + m_old_general_regs_only = TARGET_GENERAL_REGS_ONLY; global_options.x_target_flags &= ~MASK_GENERAL_REGS_ONLY; @@ -895,6 +898,7 @@ sve_switcher::~sve_switcher () if (m_old_general_regs_only) global_options.x_target_flags |= MASK_GENERAL_REGS_ONLY; aarch64_isa_flags = m_old_isa_flags; + maximum_field_alignment = m_old_maximum_field_alignment; } function_builder::function_builder () diff --git a/gcc/config/aarch64/aarch64-sve-builtins.h b/gcc/config/aarch64/aarch64-sve-builtins.h index 526d9f55e7b..3ffe2516df9 100644 --- a/gcc/config/aarch64/aarch64-sve-builtins.h +++ b/gcc/config/aarch64/aarch64-sve-builtins.h @@ -658,6 +658,7 @@ public: private: unsigned long m_old_isa_flags; + unsigned int m_old_maximum_field_alignment; bool m_old_general_regs_only; bool m_old_have_regs_of_mode[MAX_MACHINE_MODE]; };
[Bug fortran/95512] gcc/fortran/trans-decl.c:1066: array sanity check after use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95512 --- Comment #2 from David Binderman --- I fail to understand how this can be a false positive. if (array[ X] && X < something - 1) looks like a pretty convincing case of use before sanity checking to me. It is a standard pattern to sanity check array indexes before use. The previous if doesn't sanity check the array index, so there is no chance of getting the sanity check in a non standard place.
