[Bug target/109349] riscv: Add --print-supported-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109349 Kito Cheng changed: What|Removed |Added CC||kito at gcc dot gnu.org --- Comment #4 from Kito Cheng --- MaskRay: I would prefer to adding -march=help rather than --print-supported-extensions on GNU toolchain side, that should be satisfy the conventions in GCC and also having consistent with clang, although I am personally prefer -march=? rather than -march=help, but I know clang has rename -mcpu=? -mtune=? to -mcpu=help and -mtune=help, anyway that's minor. BTW, 4vtomat is our(SiFive) team member, so actually we've plan to add that on GNU toolchain side but because it's stage 4 for GCC so I still hold there :P Andrew Pinski: Yeah, I plan to make up document stuffs and release notes at April...
[Bug tree-optimization/109029] __builtin_signbit for 64bit fp does not vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109029
--- Comment #7 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #6)
> (In reply to Hongtao.liu from comment #5)
> > We need to support signbit2 for vector double/_Float16. Also similar
> > like popcnt, there's a mismatch of input and output between builtin and
> > signbit_optab, it could be handled in vectorizer pattern match.
>
> After support signbit{v2df,v4df,v8df}2, vectorizer still failed, currently,
> we only support simple integer narrowing, but not for v4df->v8si.
>
> 3480 /* First try using an internal function. */
> 3481 tree_code convert_code = ERROR_MARK;
> 3482 if (cfn != CFN_LAST
> 3483 && (modifier == NONE
> 3484 || (modifier == NARROW
> 3485 && simple_integer_narrowing (vectype_out, vectype_in,
> 3486 _code
> 3487ifn = vectorizable_internal_function (cfn, callee, vectype_out,
> 3488 vectype_in);
> 3489
One solution is handling it in ix86_builtin_vectorized_function just like other
math functions which has different input/output sizes.
[Bug tree-optimization/109029] __builtin_signbit for 64bit fp does not vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109029
--- Comment #6 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #5)
> We need to support signbit2 for vector double/_Float16. Also similar
> like popcnt, there's a mismatch of input and output between builtin and
> signbit_optab, it could be handled in vectorizer pattern match.
After support signbit{v2df,v4df,v8df}2, vectorizer still failed, currently, we
only support simple integer narrowing, but not for v4df->v8si.
3480 /* First try using an internal function. */
3481 tree_code convert_code = ERROR_MARK;
3482 if (cfn != CFN_LAST
3483 && (modifier == NONE
3484 || (modifier == NARROW
3485 && simple_integer_narrowing (vectype_out, vectype_in,
3486 _code
3487ifn = vectorizable_internal_function (cfn, callee, vectype_out,
3488 vectype_in);
3489
[Bug target/109349] riscv: Add --print-supported-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109349 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=106530 --- Comment #3 from Andrew Pinski --- Note I filed PR 106530 for the whole lack of documentation on what is allowed for -march= for riscv even. Other targets documentation is so much better in documenting options.
[Bug target/109349] riscv: Add --print-supported-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109349 --- Comment #2 from Andrew Pinski --- Also from reading the merge request, this really should just be in the gcc user manual instead of just in the compiler. Gcc's user manual should document what is supported. It is how all other targets handle this.
[Bug target/109349] riscv: Add --print-supported-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109349 --- Comment #1 from Andrew Pinski --- Target options always start with -m
[Bug target/109349] New: Add --print-supported-extensions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109349 Bug ID: 109349 Summary: Add --print-supported-extensions Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: i at maskray dot me Target Milestone: --- Clang may add a RISC-V specific option --print-supported-extensions to list implemented ISA extensions with the corresponding versions: https://reviews.llvm.org/D146054 I think it will be nice if GCC and Clang agree on the feature and spelling :)
[Bug tree-optimization/109029] __builtin_signbit for 64bit fp does not vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109029 --- Comment #5 from Hongtao.liu --- We need to support signbit2 for vector double/_Float16. Also similar like popcnt, there's a mismatch of input and output between builtin and signbit_optab, it could be handled in vectorizer pattern match.
[Bug tree-optimization/109029] __builtin_signbit for 64bit fp does not vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109029 --- Comment #4 from Hongtao.liu --- Also found a document missing for signbitm2 in md.texi.
[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106069 --- Comment #37 from Xionghu Luo (luoxhu at gcc dot gnu.org) --- https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614932.html
[Bug fortran/101047] Pointer explicit initialization fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101047 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #3 from Jerry DeLisle --- Did we let this fall in a crack or was there some other holdup?
[Bug target/85048] [missed optimization] vector conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85048 --- Comment #11 from Hongtao.liu --- Fixed in GCC13.
[Bug target/85048] [missed optimization] vector conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85048
--- Comment #10 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:fe42e7fe119159f7443dbe68189e52891dc0148e
commit r13-6951-gfe42e7fe119159f7443dbe68189e52891dc0148e
Author: liuhongt
Date: Thu Mar 30 15:43:25 2023 +0800
Rename ufix_trunc/ufloat* patterns to fixuns_trunc/floatuns* to align with
standard pattern name.
There's some typo for the standard pattern name for unsigned_{float,fix},
it should be floatunsmn2/fixuns_truncmn2, not ufloatmn2/ufix_truncmn2
in current trunk, the patch fix the typo, also change all though
ufix_trunc/ufloat patterns.
Also vcvttps2udq is available under AVX512VL, so it can be generated
directly instead of being emulated via vcvttps2dq.
gcc/ChangeLog:
PR target/85048
* config/i386/i386-builtin.def (BDESC): Adjust icode name from
ufloat/ufix to floatuns/fixuns.
* config/i386/i386-expand.cc
(ix86_expand_vector_convert_uns_vsivsf): Adjust comments.
* config/i386/sse.md
(ufloat2):
Renamed to ..
(floatuns2):..
this.
(_ufix_notrunc):
Renamed to ..
(_fixuns_notrunc):
.. this.
(fix_truncv16sfv16si2):
Renamed to ..
(fix_truncv16sfv16si2):.. this.
(ufloat2): Renamed to ..
(floatuns2): .. this.
(ufloatv2siv2df2): Renamed to ..
(floatunsv2siv2df2): .. this.
(ufix_notrunc2):
Renamed to ..
(fixuns_notrunc2):
.. this.
(ufix_notruncv2dfv2si2): Renamed to ..
(fixuns_notruncv2dfv2si2):.. this.
(ufix_notruncv2dfv2si2_mask): Renamed to ..
(fixuns_notruncv2dfv2si2_mask): .. this.
(*ufix_notruncv2dfv2si2_mask_1): Renamed to ..
(*fixuns_notruncv2dfv2si2_mask_1): .. this.
(ufix_truncv2dfv2si2): Renamed to ..
(*fixuns_truncv2dfv2si2): .. this.
(ufix_truncv2dfv2si2_mask): Renamed to ..
(fixuns_truncv2dfv2si2_mask): .. this.
(*ufix_truncv2dfv2si2_mask_1): Renamed to ..
(*fixuns_truncv2dfv2si2_mask_1): .. this.
(ufix_truncv4dfv4si2): Renamed to ..
(fixuns_truncv4dfv4si2): .. this.
(ufix_notrunc2):
Renamed to ..
(fixuns_notrunc2):
.. this.
(ufix_trunc2): Renamed to ..
(fixuns_trunc2):
.. this.
gcc/testsuite/ChangeLog:
* g++.target/i386/pr85048.C: New test.
[Bug c++/109323] No error when neither of return_value or return_void is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323 --- Comment #5 from Enrico Maria De Angelis --- I've asked some feeback here https://stackoverflow.com/questions/75891694/is-it-legal-for-a-coroutines-promise-type-to-lack-both-return-void-and-return-v
[Bug c++/109323] No error when neither of return_value or return_void is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323 --- Comment #4 from Enrico Maria De Angelis --- The more I read the standard, specifically http://eel.is/c++draft/dcl.fct.def.coroutine#6 and http://eel.is/c++draft/stmt.return.coroutine, the more I'm convinced that it's just fine that a coroutine's promise_type lacks both return_void and return_value, as long as it has no co_return and the execution never flows off the end of the coroutine itself.
[Bug c++/105452] [10/11/12/13 Regression] static_assert inside anonymous union inside a templated struct causes invalid "inaccessible within this context" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105452 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:58df5350753c00f140c86e60ba5ce0cac686ec4b commit r13-6949-g58df5350753c00f140c86e60ba5ce0cac686ec4b Author: Jason Merrill Date: Wed Mar 29 23:27:38 2023 -0400 c++: anonymous union member reference [PR105452] While parsing the anonymous union, we don't yet know that it's an anonymous union, so we build the reference to 'v' in the static_assert relative to the union type. But at instantiation time we know it's an anonymous union, so we need to avoid trying to check access for 'v' in the union again; the simplest approach seemed to be to make accessible_p step out to the containing class. While looking at this I also noticed that we were having trouble with DMI in an anonymous union referring to members of the containing class; there we just need to give current_class_ptr the right type. PR c++/105452 gcc/cp/ChangeLog: * search.cc (type_context_for_name_lookup): New. (accessible_p): Handle anonymous union. * init.cc (maybe_instantiate_nsdmi_init): Use type_context_for_name_lookup. * parser.cc (cp_parser_class_specifier): Likewise. * cp-tree.h (type_context_for_name_lookup): Declare. gcc/testsuite/ChangeLog: * g++.dg/lookup/anon8.C: New test.
[Bug c++/105221] [10/11/12/13 Regression] gcc rejects true ? [](auto) noexcept {} : [](int) {} in C++17+ (works for C++14) since r7-4383-g51dc660315ef83dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105221 --- Comment #7 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:85131af0603c0af2aa6b40de6cc929905f22bd50 commit r13-6948-g85131af0603c0af2aa6b40de6cc929905f22bd50 Author: Jason Merrill Date: Thu Mar 30 11:07:17 2023 -0400 c++: generic lambda and function ptr conv [PR105221] We weren't properly considering the function pointer conversions in deduction between FUNCTION_TYPE; we just hardcoded the UNIFY_ALLOW_MORE_CV_QUAL semantics, which are backwards when deducing for a template conversion function like the one in a generic lambda. And when I started checking the ALLOW flags, I needed to make sure they stay set to avoid breaking trailing13.C. PR c++/105221 gcc/cp/ChangeLog: * pt.cc (unify) [FUNCTION_TYPE]: Handle function pointer conversions. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/noexcept-type27.C: New test.
[Bug tree-optimization/109334] tree-object-size: Improve size computation in arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109334 --- Comment #1 from Martin Uecker --- Created attachment 54796 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54796=edit partial fix Simply removing the condition based on internal_p would make it work for the most important cases as in the attached patch. The check for constant sizes already prevents the original ICE.
[Bug c++/109319] [12/13 Regression] ICE in build_min_non_dep_op_overload, at cp/tree.cc:3793 since r12-5510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109319 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c016887c91a79d67b6a3c7e19b9219f5ab1e2a4d commit r13-6946-gc016887c91a79d67b6a3c7e19b9219f5ab1e2a4d Author: Jakub Jelinek Date: Thu Mar 30 23:08:25 2023 +0200 c++: Fix up ICE in build_min_non_dep_op_overload [PR109319] The following testcase ICEs, because grok_array_decl during processing_template_decl handling of a non-dependent subscript emits a -Wcomma-subscript pedwarn, we decide to pass to the single index argument the index expressions as if it was wrapped with () around it, but then when preparing it for later instantiation we don't actually take that into account and ICE on a mismatch of number of index arguments (the overload expects a single index, testcase has two index expressions in this case). For non-dependent subscript which are builtin subscripts we also emit the same pedwarn and don't ICE, but emit the same pedwarn again whenever we instantiate it, which is also IMHO undesirable, it is enough to warn once during parsing the template. The following patch fixes it by turning even the original index expressions (those which didn't go through make_args_non_dependent) into a single index using comma expression(s). 2023-03-30 Jakub Jelinek PR c++/109319 * decl2.cc (grok_array_decl): After emitting a pedwarn for -Wcomma-subscript, if processing_template_decl set orig_index_exp to compound expr from orig_index_exp_list. * g++.dg/cpp23/subscript14.C: New test.
[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322 --- Comment #11 from Steve Kargl --- On Thu, Mar 30, 2023 at 07:21:21PM +, pinskia at gcc dot gnu.org wrote: > > For ILP32 (32bit x86) and LLP64IL32 (64bit Windows/mingw) targets, it will use > c_long_long which is outputted wrong. Anyways I fixed the bug with respect of > c_long_long being outputted incorrectly as long_long rather than "long long" > too. (r13-6940-ga7df3bea9cf1e4 and backported to GCC 12: > r12-9370-g429b75db39aa89 ). > I quite agree that your patch fixed a problem. My comment was meant for the OP, who would like to "integer(c_int64_t) a" translated to "int64_t a;" That's isn't going to happen anytime soon. I left the PR open as an enhancement request. In 10 years, if I'm still around I close it.
[Bug middle-end/109128] [Offload][OpenMP][OpenACC] Static linking with unused offload function will lead to mismatch number of offload fn/symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109128 --- Comment #5 from Tobias Burnus --- New idea for the lto-plugin.c: Currently, as soon as a file pops up (as seemingly here for the common block in libone.a), the file is claimed via claim_file_handler, which collects the file names. Later, in all_symbols_read_handler it is output. I wonder whether some check using get_symbols is needed to check whether there is any symbol used for that file.
[Bug middle-end/109347] [lra] Spill failure for architecture without CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347
--- Comment #9 from Andrew Pinski ---
Even for pre-LRA with reload in GCC 4.7.0:
t.c: In function ‘f’:
t.c:91:1: note: unable to find a register to spill in class ‘GR_REGS’
t.c:91:1: note: this is the insn:
(insn 33 32 34 2 (set (reg:DI 198)
(plus:DI (reg:DI 194 [ t9.0 ])
(const_int 1 [0x1]))) t.c:60 11 {*adddi3}
(expr_list:REG_DEAD (reg:DI 194 [ t9.0 ])
(nil)))
t.c:91:1: internal compiler error: in spill_failure, at reload1.c:2120
unrecognized DWARF version in .debug_info at 6
0x70e2bf _fatal_insn
/bajas/pinskia/src/toolchain-47/scripts/../src/gcc/rtl-error.c:106
0x705bab spill_failure
/bajas/pinskia/src/toolchain-47/scripts/../src/gcc/reload1.c:2120
0x705bab find_reload_regs
/bajas/pinskia/src/toolchain-47/scripts/../src/gcc/reload1.c:2046
0x705bab select_reload_regs
/bajas/pinskia/src/toolchain-47/scripts/../src/gcc/reload1.c:2066
0x705bab reload
/bajas/pinskia/src/toolchain-47/scripts/../src/gcc/reload1.c:993
0x65fe6e do_reload
/bajas/pinskia/src/toolchain-47/scripts/../src/gcc/ira.c:3733
0x65fe6e rest_of_handle_reload
/bajas/pinskia/src/toolchain-47/scripts/../src/gcc/ira.c:3824
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
So I am sure this is almost not a regression.
[Bug middle-end/109347] [lra] Spill failure for architecture without CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347
Andrew Pinski changed:
What|Removed |Added
Known to fail||7.3.0
--- Comment #8 from Andrew Pinski ---
MIPS64 fails even for GCC 7:
t.c: In function ‘f’:
t.c:91:1: error: unable to find a register to spill
}
^
t.c:91:1: error: this is the insn:
(insn 36 73 72 2 (set (reg:DI 200 [198])
(plus:DI (reg:DI 201 [orig:194 t9.0_1 ] [194])
(const_int 1 [0x1]))) "t.c":60 14 {*adddi3}
(expr_list:REG_DEAD (reg:DI 201 [orig:194 t9.0_1 ] [194])
(nil)))
t.c:91:1: internal compiler error: in assign_by_spills, at lra-assigns.c:1476
[Bug middle-end/109347] [lra] Spill failure for architecture without CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Target||riscv32-elf, riscv64-elf, ||mips64-eabi Status|UNCONFIRMED |NEW Last reconfirmed||2023-03-30
[Bug middle-end/109347] [lra] Spill failure for architecture without CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347 Andrew Pinski changed: What|Removed |Added Attachment #54791|0 |1 is obsolete|| Attachment #54793|0 |1 is obsolete|| Attachment #54794|0 |1 is obsolete|| --- Comment #7 from Andrew Pinski --- Created attachment 54795 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54795=edit testcase for riscv64-elf and riscv32-elf This is new testcase fails for both riscv32 and riscv64 at -O0 and -O1. disabling s0 for -O0 too.
[Bug middle-end/109347] [lra] Spill failure for architecture without CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347 --- Comment #6 from Andrew Pinski --- Oh if we add back the s0 case, it fails at -O1 and above too.
[Bug middle-end/109347] [lra] Spill failure for architecture without CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347 --- Comment #5 from Andrew Pinski --- Created attachment 54794 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54794=edit testcase for riscv32-elf Here is a testcase which also fails for riscv32-elf. Note it only fails at -O0.
[Bug middle-end/109347] [lra] Spill failure for architecture without CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347 --- Comment #4 from Andrew Pinski --- Created attachment 54793 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54793=edit Fixed up riscv64 testcase
[Bug middle-end/109347] [lra] Spill failure for architecture without CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347 --- Comment #3 from Andrew Pinski --- On the trunk I get: t.c: In function ‘f’: t.c:94:1: error: s0 cannot be used in ‘asm’ here 94 | } | ^ First with the RISCV example. After removing the s0 variable usage I still get the ICE.
[Bug middle-end/109347] [lra] Spill failure for architecture without CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347 --- Comment #2 from Andrew Pinski --- (In reply to Piggy NL from comment #0) > The assertion was introduced in e3b3b59683c1. r11-5002-ge3b3b59683c1e7
[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
--- Comment #10 from Andrew Pinski ---
(In reply to Steve Kargl from comment #9)
>
> If one instruments, write_decl() in dump-parse-tree.cc to
> dump the table of bind(c) types, one can see why you get
> what you get.
>
> % cat a.f90
> module foo
> use, intrinsic :: iso_c_binding
> implicit none
> public :: bar
> type, bind(c) :: bar
> integer(c_int64_t) a
> end type
> end module
>
> % gfcx -fc-prototypes -fsyntax-only a.f90 | grep "value=8 IN"
> 2 value=8 INTEGER c_long
> 3 value=8 INTEGER c_long_long
> 4 value=8 INTEGER c_intmax_t
> 5 value=8 INTEGER c_intptr_t
> 6 value=8 INTEGER c_ptrdiff_t
> 7 value=8 INTEGER c_size_t
> 12 value=8 INTEGER c_int64_t
> 17 value=8 INTEGER c_int_least64_t
> 22 value=8 INTEGER c_int_fast64_t
>
> typedef struct bar {
> long a;
> } bar;
>
> The for-loop in write_decl() breaks on the first match to
> to both value=8 and INTEGER. It never reaches the 12th
> table entry for c_int64_t.
For ILP32 (32bit x86) and LLP64IL32 (64bit Windows/mingw) targets, it will use
c_long_long which is outputted wrong. Anyways I fixed the bug with respect of
c_long_long being outputted incorrectly as long_long rather than "long long"
too. (r13-6940-ga7df3bea9cf1e4 and backported to GCC 12:
r12-9370-g429b75db39aa89 ).
[Bug fortran/109171] initialization using %re causes segfault, as an assignment does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109171 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- *** Bug 109348 has been marked as a duplicate of this bug. ***
[Bug fortran/109348] Pointer initialization fails for target with references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109348 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||anlauf at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from anlauf at gcc dot gnu.org --- Reported already in pr109171. *** This bug has been marked as a duplicate of bug 109171 ***
[Bug middle-end/109128] [Offload][OpenMP][OpenACC] Static linking with unused offload function will lead to mismatch number of offload fn/symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109128
--- Comment #4 from Tobias Burnus ---
Minor observations (unrelated to this bug but should be fixed. separately or
together):
- '@' file in lto-wrapper.cc's compile_offload_image's fork_execute call is
always the same. (Matters if there is more than one offloading target
configured)
- The sections ".gnu.offload_funcs" and ".gnu.offload_vars" are 'wx' but they
could be 'x' (i.e. read only as the function addresses do not need to be
written to). → TREE_READONLY (funcs_decl) = 1; (same for 'vars_decl').
* * *
Tried the following, but it did not help – 'ld' does not import any symbol from
the 'libone.a' library – neither before nor after the patch; not did
-no-as-needed help and -Wl,--print-gc-sections does not show any discarded
sections.
diff --git a/gcc/omp-offload.cc b/gcc/omp-offload.cc
index 3bd144e9ccf..e1b22729994 100644
--- a/gcc/omp-offload.cc
+++ b/gcc/omp-offload.cc
@@ -437,0 +438,13 @@ omp_finish_file (void)
+ TREE_READONLY (funcs_decl) = 1;
+ TREE_READONLY (vars_decl) = 1;
+#ifndef ACCEL_COMPILER
+ if (SUPPORTS_SHF_GNU_RETAIN)
+ {
+ DECL_ATTRIBUTES (funcs_decl) = tree_cons (get_identifier ("retain"),
+ NULL_TREE, NULL_TREE);
+ DECL_ATTRIBUTES (vars_decl) = tree_cons (get_identifier ("retain"),
+ NULL_TREE, NULL_TREE);
+ }
+ else
+ sorry ("support for % required for offloading");
+#endif
diff --git a/libgcc/offloadstuff.c b/libgcc/offloadstuff.c
index 4e1c4d41dd5..59e191c5e19 100644
--- a/libgcc/offloadstuff.c
+++ b/libgcc/offloadstuff.c
@@ -51 +51 @@ const void *const __offload_func_table[0]
- __attribute__ ((__used__, visibility ("hidden"),
+ __attribute__ ((__used__, visibility ("hidden"), retain,
@@ -54 +54 @@ const void *const __offload_var_table[0]
- __attribute__ ((__used__, visibility ("hidden"),
+ __attribute__ ((__used__, visibility ("hidden"), retain,
@@ -60 +60 @@ const void *const __offload_funcs_end[0]
- __attribute__ ((__used__, visibility ("hidden"),
+ __attribute__ ((__used__, visibility ("hidden"), retrain,
@@ -63 +63 @@ const void *const __offload_vars_end[0]
- __attribute__ ((__used__, visibility ("hidden"),
+ __attribute__ ((__used__, visibility ("hidden"), retrain,
* * *
What's interesting is the file -foffload-objects=a.ofldlist - produced by
lto-plugin:
* If there is a common block in 'one.f90' (and via module use also in
'two.f90'), the a.ofldlist file contains both 'two.o' and the ./libone.a@0xc0
library.
* But if there is no common block in 'one.f90' (and hence also not in
'two.f90'), the a.ofldlist file contains only 'two.o'.
[Bug fortran/84779] [10/11/12/13 Regression] Compiling gfortran.fortran-torture/execute/entry_4.f90 with -O1 or -Os and -fdefault-integer-8 gives an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84779 anlauf at gcc dot gnu.org changed: What|Removed |Added CC|anlauf at gmx dot de |anlauf at gcc dot gnu.org --- Comment #13 from anlauf at gcc dot gnu.org --- I've come back to this PR again and spent a while trying to further narrow things down and to find the gcc options that make the code compile or fail. Minimal reproducer: complex function f2 (a) implicit none integer a logical e2 entry e2 (a) if (a > 0) then e2 = .true. else f2 = 45 endif end Basic command line: "gfortran -fdefault-integer-8", plus: these all lead to an ICE: ! -O1 ! -O1 -fno-tree-pre ! -O2 -fno-tree-pre but no ICE with: ! -O2 ! -O1 -ftree-pre ! -O2 -ftree-pre ! -O1 -fno-tree-sra ! -O2 -fno-tree-sra ! -O1 -fno-tree-sra -fno-tree-pre ! -O2 -fno-tree-sra -fno-tree-pre So is this now a frontend bug - what could it be? - or a middle-end issue?
[Bug fortran/109322] -fc-prototypes does not correctly translate INTEGER(KIND=C_SIZE_T), and other sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
--- Comment #9 from Steve Kargl ---
On Wed, Mar 29, 2023 at 07:42:08PM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109322
>
> --- Comment #3 from Steve Kargl ---
> On Wed, Mar 29, 2023 at 05:50:05PM +, emr-gnu at hev dot psu.edu wrote:
> >
> >
> > Extending my original demonstrator, if you add a "INTEGER(KIND=C_INT64_T) ::
> > E", you get the following output:
> >
> > > gfortran -m32 -fc-prototypes -fsyntax-only foo.f90
> >
> > long a;
> > {...}
> > long_long e;
> > } bar;
>
> The companion C processor is gcc. It is generating
> prototypes for that C processor. If one is manipulating
> the environment with a command line option such as -m32
> or -m64, then one likely needs to use the same option
> with gcc. Does 'gcc -m32' support "long_long"? If it
> doesn't, then you'll need to hack on
>
> gcc/fortran/dump-parse-tree.cc
> gcc/fortran/iso-c-binding.def
> gcc/fortran/trans-types.cc
If one instruments, write_decl() in dump-parse-tree.cc to
dump the table of bind(c) types, one can see why you get
what you get.
% cat a.f90
module foo
use, intrinsic :: iso_c_binding
implicit none
public :: bar
type, bind(c) :: bar
integer(c_int64_t) a
end type
end module
% gfcx -fc-prototypes -fsyntax-only a.f90 | grep "value=8 IN"
2 value=8 INTEGER c_long
3 value=8 INTEGER c_long_long
4 value=8 INTEGER c_intmax_t
5 value=8 INTEGER c_intptr_t
6 value=8 INTEGER c_ptrdiff_t
7 value=8 INTEGER c_size_t
12 value=8 INTEGER c_int64_t
17 value=8 INTEGER c_int_least64_t
22 value=8 INTEGER c_int_fast64_t
typedef struct bar {
long a;
} bar;
The for-loop in write_decl() breaks on the first match to
to both value=8 and INTEGER. It never reaches the 12th
table entry for c_int64_t.
[Bug middle-end/109347] [lra] Spill failure for architecture without CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347 --- Comment #1 from Piggy NL --- Created attachment 54792 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54792=edit Reproduce for mips64
[Bug fortran/109348] New: Pointer initialization fails for target with references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109348 Bug ID: 109348 Summary: Pointer initialization fails for target with references Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: pault at gcc dot gnu.org Target Milestone: --- As posted by Peter Klausler on clf complex, save, target :: a(4) = [(1.,0.),(2.,0.),(3.,0.),(4.,0)] real, pointer :: p(:) => a(1:3:2)%re print *, p end gfc doesn't even attempt to initialise the pointer. Malcolm Cohen and Steve Lionel both agree that this is valid F2018. complex, save, target :: a(4) = [(1.,0.),(2.,0.),(3.,0.),(4.,0)] real, pointer :: p(:) p(1:) => a(1:3:2)%re print *, p end Works, as long as an lbound is provided on the lhs. nagfor behaves similarly, whereas ifort does not even accept this version. Cheers Paul
[Bug middle-end/109347] New: [lra] Spill failure for architecture without CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109347
Bug ID: 109347
Summary: [lra] Spill failure for architecture without CC
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: piggynl at outlook dot com
Target Milestone: ---
Created attachment 54791
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54791=edit
Reproduce for riscv64
For all architectures without condition code, when all registers are in use,
gcc fails to perform a spill.
mips64 and riscv64 are failing with certain code.
For example, the codes for mips64 and riscv64 reproducing the bug are in
attachments.
The expected behavior is generating a spill asm sequence before the `if` block
and a restore sequence after, so it will be a free register in the `if` block.
gcc is failing an assertion error with the examples. With a release build, gcc
falls into an infinity loop.
The assertion fails in lra.c:
if (e->dest != EXIT_BLOCK_PTR_FOR_FN (cfun))
{
/* We already made the edge no-critical in ira.c::ira */
lra_assert (!EDGE_CRITICAL_P (e));
^^
rtx_insn *tmp = BB_HEAD (e->dest);
if (LABEL_P (tmp))
The assertion was introduced in e3b3b59683c1.
[Bug target/109279] RISC-V: complex constants synthesized should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #14 from Vineet Gupta ---
(In reply to Andrew Pinski from comment #12)
> Here is something to look into:
> #define const1 0x0101010101010101ULL
> #define const0 const1
> unsigned long long f(unsigned long long occ, const unsigned int sq) {
> unsigned long long t= (const0)>>32<<32 ;
> unsigned long long t1= (unsigned int)(const0) ;
> asm("":"+r"(t));
> return t | t1;
> }
Before commit 2e886eef7f2
li a5,16842752
addia5,a5,257
sllia0,a5,32
or a0,a0,a5
ret
With commit 2e886eef7f2
li a0,16842752
addia0,a0,257
mv a5,a0
sllia0,a0,32
or a0,a0,a5
ret
With commit 2e886eef7f2 + in_splitter check removed from riscv_move_integer()
li a0,16842752
li a5,16842752
addia5,a5,257
addia0,a0,257
sllia0,a0,32
or a0,a0,a5
ret
[Bug target/109068] bpf: "error: too many function arguments for eBPF" for always_inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109068 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-03-30 Status|UNCONFIRMED |NEW Keywords||diagnostic --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154 --- Comment #41 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:429a7a88438cc80e7c58d9f63d44838089899b12 commit r13-6945-g429a7a88438cc80e7c58d9f63d44838089899b12 Author: Andrew MacLeod Date: Tue Mar 28 12:16:34 2023 -0400 Add recursive GORI recompuations with a depth limit. PR tree-optimization/109154 gcc/ * gimple-range-gori.cc (gori_compute::may_recompute_p): Add depth limit. * gimple-range-gori.h (may_recompute_p): Add depth param. * params.opt (ranger-recompute-depth): New param. gcc/testsuite/ * gcc.dg/Walloca-13.c: Remove bogus warning that is now fixed.
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #31 from Jakub Jelinek --- If the important side-effect is allocation of some GC memory, then perhaps (assuming you also see just 5 initialize_cfun calls with 2xint, TFmode float, uint and bool) testing hack might be: --- a/gcc/tree-inline.cc +++ b/gcc/tree-inline.cc @@ -2787,6 +2787,8 @@ initialize_cfun (tree new_fndecl, tree callee_fndecl, profile_count count) /* Get clean struct function. */ push_struct_function (new_fndecl, true); targetm.target_option.relayout_function (new_fndecl); + if (INTEGRAL_TYPE_P (TREE_TYPE (DECL_RESULT (new_fndecl +gen_raw_REG (GET_MODE (TYPE_MODE (DECL_RESULT (new_fndecl))), 8); /* We will rebuild these, so just sanity check that they are empty. */ gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL); If that would help, then it is just bad luck and bug somewhere else than here.
[Bug c++/109323] No error when neither of return_value or return_void is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323 --- Comment #3 from Enrico Maria De Angelis --- However, I'm not entirely sure (not anymore now that I've read the standard more carefully) that not having any of those two memebrs is an error.
[Bug c++/84075] [10/11/12/13 Regression] Template parameter not resolved: invalid application of ‘sizeof’ to incomplete type ‘boost::serialization::U’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075
Patrick Palka changed:
What|Removed |Added
Target Milestone|--- |10.5
CC||ppalka at gcc dot gnu.org
Summary|Template parameter not |[10/11/12/13 Regression]
|resolved: invalid |Template parameter not
|application of ‘sizeof’ to |resolved: invalid
|incomplete type |application of ‘sizeof’ to
|‘boost::serialization::U’ |incomplete type
||‘boost::serialization::U’
--- Comment #12 from Patrick Palka ---
(In reply to Andrew Pinski from comment #11)
> (In reply to ensadc from comment #4)
> > Further reduced:
> >
> > template < int > struct b { };
> > template < typename n > struct g {
> > typedef b< sizeof(n) > l;
> > };
> > template < typename h, typename = typename g< h >::l > class aa {};
> > template < typename h, typename bz >
> > void bj(aa< h, bz >, int);
> > template < template < class > class ct > void bj(ct< class U >);
> > void f() {
> > bj(aa(), 0);
> > }
> >
>
> Hmm, it comes with -std=c++11 and -std=c++14 but not -std=c++17.
Started to be rejected (with -std=c++17) since the introduction of
-fnew-ttp-matching r7-5537-g31bfc9b9dd65ec
[Bug debug/109346] New: RFE add DW_AT_location to DW_TAG_subprogram
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109346 Bug ID: 109346 Summary: RFE add DW_AT_location to DW_TAG_subprogram Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: woodard at redhat dot com Target Milestone: --- There is a currently an issue filed against the DWARF5 standard that asks for DW_AT_location to be the DW_TAG_subprogram and DW_TAG_inlined_subprogram. https://dwarfstd.org/issues/221105.1.html At least for DW_TAG_subprogram the issue seems to have fairly widespread support. Due to the general permissiveness of the DWARF standard, I have found no place in the DWARF5 standard where it says that you can't do this currently even without a textual change in the future DWARF6 standard. In addition to the reasons listed in the DWARF issue, there are a some additional reasons to have it. First of all there is DW_AT_GNU_vector. Because there is ambiguity in the calling convention for array types vs vector types, DW_AT_GNU_vector is required so that GDB can infer using the platform standard ABI where the return value of a function would be located. This is discussed here: https://lists.dwarfstd.org/pipermail/dwarf-discuss/2023-March/002212.html With a location on a DW_AT_subprogram the needs of GDB could be met without DW_AT_GNU_vector. Furthermore, elfutils libdw has the following function which tries to find the location of a function's return value. /* Return location expression to find return value given a DW_TAG_subprogram, DW_TAG_subroutine_type, or similar DIE describing function itself (whose DW_AT_type attribute describes its return type). The given DIE must come from the given module. Returns -1 for errors. Returns zero if the function has no return value (e.g. "void" in C). Otherwise, *LOCOPS gets a location expression to find the return value, and returns the number of operations in the expression. The pointer is permanently allocated at least as long as the module is live. */ extern int dwfl_module_return_value_location (Dwfl_Module *mod, Dwarf_Die *functypedie, const Dwarf_Op **locops); This currently requires a libebl backend for the architecture that knows the standard ABI for the particular return type. And it would indeed give the wrong answer currently if the function doesn't follow the standard calling convention. The problem is with the increasing use of LTO, particularly within GNU/Linux distros,the number of places where this function cannot correctly determine the location of the return value is greatly increased. This is also true for static functions, since programmers are being taught to be more careful with their exported interfaces and they recognize the performance advantages given by optimization passes that use a non-standard calling convention for static functions the number of static functions is increasing. The only really contested point of the proposal is what to do about DW_TAG_inlined_subprogram. However, not adding DW_AT_location to DW_TAG_inlined_subprogram would just be a quality of implementation issue and so it could be omitted for the time being. How to add the location information is not disputed but whether it would be possible for the compiler to correctly emit it, and how much additional DWARF would be required to implement that feature. It would end up being a huge location list for all the places where the inlined subprogram is called. For the moment, I think everyone would be happy if DW_AT_location were just applied to DW_TAG_subprogram and DW_TAG_inlined_subprogram were skipped.
[Bug c++/109323] No error when neither of return_value or return_void is defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109323 --- Comment #2 from Enrico Maria De Angelis --- Created attachment 54790 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54790=edit Attachment for report 109323
[Bug tree-optimization/104970] [12 Regression] ICE in execute_todo, at passes.cc:2133 since r12-6480-gea19c8f33a3a8d2b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970 --- Comment #15 from Martin Uecker --- Thanks. I still wonder whether the original example should be added to the test suite?
[Bug c++/102419] [11/12/13 Regression][concepts] return-type-requirement of "Y" does not check that T::type actually exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102419 Patrick Palka changed: What|Removed |Added CC||cjdb.ns at gmail dot com --- Comment #8 from Patrick Palka --- *** Bug 109337 has been marked as a duplicate of this bug. ***
[Bug c++/109337] c++2a test concepts4.C passes when it should fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109337 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #7 from Patrick Palka --- dup of PR102419 AFAICT *** This bug has been marked as a duplicate of bug 102419 ***
[Bug c++/109338] `S auto>` isn't valid C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109338 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=96464 | Resolution|--- |DUPLICATE --- Comment #2 from Patrick Palka --- I reckon it makes sense to call this a dup of PR96464 even, since we incorrectly accept with or without the type constraint. *** This bug has been marked as a duplicate of bug 96464 ***
[Bug c++/96464] GCC accepts 'auto' in template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96464 Patrick Palka changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=109338| CC||cjdb.ns at gmail dot com --- Comment #3 from Patrick Palka --- *** Bug 109338 has been marked as a duplicate of this bug. ***
[Bug ipa/109303] [13 Regression] ICE in push_agg_values_from_plats, at ipa-cp.cc:1458 since r13-3358-ge0403e95689af7d5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303
Martin Jambor changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot
gnu.org
--- Comment #8 from Martin Jambor ---
Thanks a lot for the testcase. The divisions must always be exact.
After having one more look, I moved the check a bit earlier still and am
currently testing this:
--- a/gcc/ipa-prop.cc
+++ b/gcc/ipa-prop.cc
@@ -2086,7 +2086,9 @@ determine_known_aggregate_parts (struct
ipa_func_body_info *fbi,
whether its value is clobbered any other dominating one. */
if ((content->value.pass_through.formal_id >= 0
|| content->value.pass_through.operand)
- && !clobber_by_agg_contents_list_p (all_list, content))
+ && !clobber_by_agg_contents_list_p (all_list, content)
+ && (content->offset + content->size - arg_offset
+ <= (HOST_WIDE_INT) UINT_MAX * BITS_PER_UNIT))
{
struct ipa_known_agg_contents_list *copy
= XALLOCA (struct ipa_known_agg_contents_list);
[Bug tree-optimization/109327] [13 Regression] ICE on valid code at -O1 and above with "-fno-tree-ccp": Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109327 Andrew Pinski changed: What|Removed |Added Summary|ICE on valid code at -O1|[13 Regression] ICE on |and above with |valid code at -O1 and above |"-fno-tree-ccp":|with "-fno-tree-ccp": |Segmentation fault |Segmentation fault Target Milestone|--- |13.0
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #30 from Jakub Jelinek --- So, if I add the --- a/gcc/tree-inline.cc +++ b/gcc/tree-inline.cc @@ -2787,6 +2787,7 @@ initialize_cfun (tree new_fndecl, tree callee_fndecl, profile_count count) /* Get clean struct function. */ push_struct_function (new_fndecl, true); targetm.target_option.relayout_function (new_fndecl); + aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl); /* We will rebuild these, so just sanity check that they are empty. */ gcc_assert (VALUE_HISTOGRAMS (cfun) == NULL); I see 5 calls of this in this spot, two with int return type, one with TFmode floating one, one with uint and one with bool. aggregate_value_p calls targetm.calls.return_in_memory but I don't see sparc_return_in_memory to have any side-effects other than return value. Next it calls reg = hard_function_value (type, 0, fntype, 0); which does allocate a REG rtx, but doesn't save it anywhere. It then calls fntype_abi and hard_regno_nregs and predefined_function_abi::clobbers_full_reg_p, but I don't see any side-effects in those either. Nothing seems to cache its results in any way. Confused...
[Bug c++/105644] ICE in a fold expression with a requires expression: in iterative_hash_template_arg, at cp/pt.cc:1805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105644 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 --- Comment #22 from Jakub Jelinek --- Sure. The point was to avoid regressions on the release branch because of so big changes for the tunings which were supported before already. So we might want both the LRA changes and perhaps zen1-3 reversion.
[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 --- Comment #21 from Jan Hubicka --- Zen 1-3 changes were intentional in the original tuning patch (it is also briefly mentioned in the commit message). By allowing 256 bit AVX moves instead of 64bit integer moves (or 128bit) we can move bigger blocks of memory without loops and it was faster in micro-benchmarks I made on all zens, even on znver1. We also automatically go for 128bit moves when ISA allows that. We could revert that part of backport, but won't we get same hangs with -march=znver4 or core512 which also enables avx512 moves? (I am rebuilding gcc12 to see what happens)
[Bug middle-end/109128] [Offload][OpenMP][OpenACC] Static linking with unused offload function will lead to mismatch number of offload fn/symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109128 --- Comment #3 from Tobias Burnus --- My initial thought was to handle it via lto1. This works well if all relevant files are compiled with "-flto" as then the callers of the offload functions, the offload functions themselves are available, permitting to generate __OFFLOAD_TABLE__ directly. However, if -flto is not used or not used for all translation units (with offload code), this approach will fail due to visibility problems. Namely, the offload functions have local binding. This could be solved by forcing global binding (with visibility hidden), but this approach will fail if the assembler name is not unique. * * * Thus, placing the symbols into a section will work (current behavior), except that the linker might remove symbols (this bug) and one needs to hope that the linking order is the same on the host as it is with LTO. Still remains the question how to handle this PR...
[Bug c++/105221] [10/11/12/13 Regression] gcc rejects true ? [](auto) noexcept {} : [](int) {} in C++17+ (works for C++14) since r7-4383-g51dc660315ef83dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105221 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/105221] [10/11/12/13 Regression] gcc rejects true ? [](auto) noexcept {} : [](int) {} in C++17+ (works for C++14) since r7-4383-g51dc660315ef83dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105221
--- Comment #6 from Jason Merrill ---
Reduced:
void (*p)(int) = [](auto) noexcept {};
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #29 from Jakub Jelinek --- So aggregate_value_p has some side-effects other than return value then? Ugh. Anyway, my patch intention has been to avoid the relayouts. So, just calling aggregate_value_p there or perhaps instead later when we finalize DECL_RESULT and the like is an option, just would like to understand what side-effects it has. Will step through on the cross-compiler.
[Bug target/109104] [13 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1171 with -fzero-call-used-regs=all -march=rv64gv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109104 Kito Cheng changed: What|Removed |Added Status|NEW |ASSIGNED CC||kito at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pan2.li at intel dot com --- Comment #4 from Kito Cheng --- Pan Li from Intel is working on fixing that
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #28 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #25 from Jakub Jelinek --- > Anyway, as I said for the second version, it would be nice to also try > subvariants: > // relayout_decl (DECL_RESULT (new_fndecl)); > for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN > (parm)) > relayout_decl (parm); > targetm.target_option.relayout_function (new_fndecl); > // aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl); > and > relayout_decl (DECL_RESULT (new_fndecl)); > // for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN > (parm)) > //relayout_decl (parm); > targetm.target_option.relayout_function (new_fndecl); > // aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl); > and > // relayout_decl (DECL_RESULT (new_fndecl)); > // for (tree parm = DECL_ARGUMENTS (new_fndecl); parm; parm = DECL_CHAIN > (parm)) > //relayout_decl (parm); > targetm.target_option.relayout_function (new_fndecl); > aggregate_value_p (DECL_RESULT (new_fndecl), new_fndecl); > so see if the comparison failure is fixed by the result relayout, or by > argument > relayout or by the aggregate_value_p call actually having some side-effects > other than return value. Of those three subvariants, only the third one passed the build without the comparison failure.
[Bug tree-optimization/91645] Missed optimization with sqrt(x*x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91645
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Status|NEW |ASSIGNED
--- Comment #13 from Jakub Jelinek ---
Created attachment 54789
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54789=edit
gcc13-pr91645.patch
This seems to work right on the testcase I've been trying:
float sqrtf (float);
float foo (float x) { return sqrtf (x); }
float bar (float x) { if (__builtin_isless (x, 0)) __builtin_unreachable ();
return sqrtf (x); }
float baz (float x) { if (!__builtin_isless (x, 0)) __builtin_unreachable ();
return sqrtf (x); }
float qux (float x) { x = x * x; return sqrtf (x); }
Do we want this for GCC 13, or at least parts of it like the range-op-float.cc
fixes and/or the value-range.cc change, or defer everything for GCC 14?
[Bug middle-end/85563] [10/11/12/13 regression] -Wmaybe-uninitialized false alarm regression with __builtin_unreachable and GCC 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85563 Richard Biener changed: What|Removed |Added CC||amacleod at redhat dot com, ||rguenth at gcc dot gnu.org Last reconfirmed|2021-04-15 00:00:00 |2023-3-30 --- Comment #23 from Richard Biener --- Re-confirmed. On the testcase in comment#6 we have before EVRP : Vframe_list.0_1 = Vframe_list; a.1_17 = (long int) Vframe_list.0_1; _15 = (unsigned int) a.1_17; _13 = _15 & 7; _10 = _13 == 3; if (_13 != 3) goto ; [INV] else goto ; [INV] : __builtin_unreachable (); : # frame1_6 = PHI # tail_7 = PHI a.1_19 = (long int) tail_7; _20 = (unsigned int) a.1_19; _21 = _20 & 7; _22 = _21 == 3; if (_21 == 3) goto ; [INV] else goto ; [INV] : _25 = tail_7 + 18446744073709551613; _26 = __builtin_assume_aligned (_25, 8); frame1_16 = _26->u.s.car; tail_18 = _26->u.s.u.cdr; goto ; [INV] : do_switch_frame (frame1_6); and we fail to realize we are never exiting the loop in the first iteration. The diagnostic happens because we run into loop header copying which then results in a jump around the loop with an obviously uninitialized argument to frame1_6. And that's because we have thrown away the __builtin_unreachable before loop header copying (in VRP1, after the first threadfull). Re-ordering CH before VRP fails to optimize even when I also put a copyprop between CH and VRP. We then see [local count: 118111600]: # PT = nonlocal escaped null Vframe_list.0_1 = Vframe_list; a.1_12 = (long int) Vframe_list.0_1; _10 = (unsigned int) a.1_12; # RANGE [irange] Lisp_Type [0, 7] NONZERO 0x7 _8 = _10 & 7; if (_8 != 3) goto ; [0.00%] else goto ; [100.00%] [count: 0]: __builtin_unreachable (); [local count: 118111600]: a.1_21 = (long int) Vframe_list.0_1; _22 = (unsigned int) a.1_21; # RANGE [irange] Lisp_Type [0, 7] NONZERO 0x7 _23 = _22 & 7; if (_23 == 3) but for some reason VRP doesn't optimize the second compare. We'd probably need to value-number here (loop header copying does, but only parts of the function and not including this leading block). So somewhat of a pass ordering issue. The next CSE is DOM and then PRE.
[Bug tree-optimization/91645] Missed optimization with sqrt(x*x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91645
--- Comment #12 from Jakub Jelinek ---
WIP which still doesn't work:
--- gcc/value-query.cc.jj 2023-03-23 15:25:47.069740988 +0100
+++ gcc/value-query.cc 2023-03-30 14:56:58.809298424 +0200
@@ -230,9 +230,11 @@ range_query::get_tree_range (vrange ,
default:
break;
}
- if (BINARY_CLASS_P (expr))
+ if (BINARY_CLASS_P (expr) || COMPARISON_CLASS_P (expr))
{
- range_op_handler op (TREE_CODE (expr), type);
+ range_op_handler op (TREE_CODE (expr),
+ BINARY_CLASS_P (expr) ? type
+ : TREE_TYPE (TREE_OPERAND (expr, 0)));
if (op)
{
Value_Range r0 (TREE_TYPE (TREE_OPERAND (expr, 0)));
--- gcc/tree-call-cdce.cc.jj2023-01-02 09:32:45.940944935 +0100
+++ gcc/tree-call-cdce.cc 2023-03-30 14:54:25.248544702 +0200
@@ -36,6 +36,7 @@ along with GCC; see the file COPYING3.
#include "builtins.h"
#include "internal-fn.h"
#include "tree-dfa.h"
+#include "gimple-range.h"
/* This pass serves two closely-related purposes:
@@ -425,12 +426,9 @@ comparison_code_if_no_nans (tree_code co
null tree. */
static void
-gen_one_condition (tree arg, int lbub,
- enum tree_code tcode,
- const char *temp_name1,
- const char *temp_name2,
- vec conds,
- unsigned *nconds)
+gen_one_condition (tree arg, int lbub, enum tree_code tcode,
+ const char *temp_name1, const char *temp_name2,
+ vec conds, unsigned *nconds, gimple *stmt)
{
if (!HONOR_NANS (arg))
tcode = comparison_code_if_no_nans (tcode);
@@ -451,10 +449,24 @@ gen_one_condition (tree arg, int lbub,
gimple_assign_set_lhs (stmt1, tempn);
tempc = create_tmp_var (boolean_type_node, temp_name2);
- stmt2 = gimple_build_assign (tempc,
- fold_build2 (tcode,
- boolean_type_node,
- tempn, lbub_real_cst));
+ tree tcond = build2 (tcode, boolean_type_node, arg, lbub_real_cst);
+ int_range_max r;
+ range_query *q = get_range_query (cfun);
+ if (q == get_global_range_query ())
+q = enable_ranger (cfun);
+ /* Ask the ranger whether it knows the condition will be always false or
+ always true. */
+ if (!q->range_of_expr (r, tcond, stmt) || r.undefined_p ())
+tcond = NULL_TREE;
+ else if (r.upper_bound () == 0)
+tcond = boolean_false_node;
+ else if (r.lower_bound () == 1)
+tcond = boolean_true_node;
+ else
+tcond = NULL_TREE;
+ if (!tcond)
+tcond = fold_build2 (tcode, boolean_type_node, tempn, lbub_real_cst);
+ stmt2 = gimple_build_assign (tempc, tcond);
tempcn = make_ssa_name (tempc, stmt2);
gimple_assign_set_lhs (stmt2, tempcn);
@@ -475,16 +487,15 @@ gen_one_condition (tree arg, int lbub,
for lower bound check, one for upper bound check. */
static void
-gen_conditions_for_domain (tree arg, inp_domain domain,
- vec conds,
- unsigned *nconds)
+gen_conditions_for_domain (tree arg, inp_domain domain, vec conds,
+ unsigned *nconds, gimple *stmt)
{
if (domain.has_lb)
gen_one_condition (arg, domain.lb,
(domain.is_lb_inclusive
? UNGE_EXPR : UNGT_EXPR),
"DCE_COND_LB", "DCE_COND_LB_TEST",
- conds, nconds);
+ conds, nconds, stmt);
if (domain.has_ub)
{
@@ -496,7 +507,7 @@ gen_conditions_for_domain (tree arg, inp
(domain.is_ub_inclusive
? UNLE_EXPR : UNLT_EXPR),
"DCE_COND_UB", "DCE_COND_UB_TEST",
- conds, nconds);
+conds, nconds, stmt);
}
}
@@ -518,9 +529,8 @@ gen_conditions_for_domain (tree arg, inp
and *NCONDS is the number of logical conditions. */
static void
-gen_conditions_for_pow_cst_base (tree base, tree expn,
-vec conds,
- unsigned *nconds)
+gen_conditions_for_pow_cst_base (tree base, tree expn, vec conds,
+unsigned *nconds, gimple *stmt)
{
inp_domain exp_domain;
/* Validate the range of the base constant to make
@@ -532,11 +542,9 @@ gen_conditions_for_pow_cst_base (tree ba
real_from_integer (, TYPE_MODE (TREE_TYPE (base)), 256, UNSIGNED);
gcc_assert (!real_less (, ));
- exp_domain = get_domain (0, false, false,
- 127, true, false);
+ exp_domain = get_domain (0, false, false, 127, true, false);
- gen_conditions_for_domain (expn, exp_domain,
- conds, nconds);
+ gen_conditions_for_domain (expn, exp_domain, conds, nconds, stmt);
}
/* Generate error condition code for pow calls with
@@ -554,9 +562,8 @@
[Bug tree-optimization/81958] [10/11/12/13 Regression] spurious -Wmaybe-uninitialized warning in gcc-8, or with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81958 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #8 from Richard Biener --- We see [count: 0]: # eq_7 = PHI # ivtmp.7_23 = PHI <0(2), ivtmp.7_24(8)> _25 = (unsigned int) ivtmp.7_23; if (maxidx_15(D) > _25) goto ; [0.00%] else goto ; [0.00%] // loop exit [count: 0]: if (maxidx_15(D) == _25) goto ; [0.00%] else goto ; [0.00%] [count: 0]: # eq_9 = PHI printk (eq_9); [tail call] return; and the appearant uninit use is on the 10->7 edge, when maxidx != _25 but at the same time maxidx > _25. We don't realize that the maxidx == _25 condition is always true. The possible easiest way is probably to rewrite the in-loop condition to maxid != _25 somewhere (ivcanon?). uninit analysis itself just sees maxid <= _25 && maxid ==_25 as the initialized cases - it could possibly analyze how _25 evolves when defined in a loop to further optimize this to true.
[Bug rtl-optimization/109343] invalid if conversion optimization for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109343
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Andrew Pinski ---
If we mark sga_var as weak then there is no ifcvt.
extern int sga_mapped;
extern int sga_var __attribute__((weak));
int func(int j){
int i=0;
if(sga_mapped)
i=i+sga_var;
return i;
}
[Bug fortran/109345] New: class(*) variable that is a string array is not handled correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109345 Bug ID: 109345 Summary: class(*) variable that is a string array is not handled correctly Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: lchilutti at gmail dot com Target Milestone: --- program test implicit none character(len=255) :: str_array(2) !< Array of strings str_array(1) = "" str_array(2) = "" str_array(1) = "2880:2880,1:2160::1:1,1:2160" str_array(2) = "1:1440,2160:2160::2880:1441,2160:2160" call foo(str_array) !< class(*) call foo2(str_array) !< char type call foo3(str_array) !< class(*) with str copy contains subroutine foo ( var) !< Uses class(*) class(*), intent(in) :: var(:) integer :: i select type (var) type is (character(len=*)) print *, "Using class(*)" print *, "The size of var:", size(var) do i = 1, size(var) print *, len_trim(var(i)), "data:", trim(var(i)) enddo end select end subroutine subroutine foo2 (var) !< Uses char type character(len=*), intent(in) :: var(:) integer :: i print *, "Not using class(*)" print *, "The size of var:", size(var) do i = 1, size(var) print *, len_trim(var(i)), "data:", trim(var(i)) enddo end subroutine subroutine foo3 (var) !< Uses class(*) with a workaround class(*), intent(in) :: var(:) integer :: i character(len=:), dimension(:), allocatable :: str select type (var) type is (character(len=*)) str = var !< if you copy the class(*) var to an allocatable string it works print *, "Using class(*), with string copy workaround" print *, "The size of str:", size(str) do i = 1, size(str) print *, len_trim(str(i)), "data:", trim(str(i)) enddo end select end subroutine end program If I compile the above program with gfortran (gcc version 12.2.0), I get the following output: Using class(*) The size of var: 2 28 data:2880:2880,1:2160::1:1,1:2160 255 data:880:2880,1:2160::1:1,1:2160 1 Not using class(*) The size of var: 2 28 data:2880:2880,1:2160::1:1,1:2160 37 data:1:1440,2160:2160::2880:1441,2160:2160 Using class(*), with string copy workaround The size of str: 2 28 data:2880:2880,1:2160::1:1,1:2160 37 data:1:1440,2160:2160::2880:1441,2160:2160 You can see that when we give an array of strings as an argument to a function using class(*) and select type, the string returned within the select type function is incorrect. We found a workaround in which we can copy the class(*) input variable to an allocatable string within the select type statement, but we should not have to do this.
[Bug c++/109344] feraiseexcept produces incorrect code when optimizations are enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109344 --- Comment #5 from Xi Ruoyao --- (In reply to albin from comment #4) > Thanks for the info. If it was fixed three years ago how come it is still > seen when using gcc (trunk) on Compiler Explorer? Is Compiler Explorer using > an obsolete glibc? It uses Glibc-2.31: https://godbolt.org/z/h348q7fbh
[Bug c++/109344] feraiseexcept produces incorrect code when optimizations are enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109344 --- Comment #4 from albin --- Thanks for the info. If it was fixed three years ago how come it is still seen when using gcc (trunk) on Compiler Explorer? Is Compiler Explorer using an obsolete glibc?
[Bug bootstrap/101834] make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #12 from Jonathan Wakely --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614893.html
[Bug c++/107897] [13 Regression] mangling conflicts with a previous mangle since r13-3601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107897 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jason Merrill --- Fixed.
[Bug c++/108887] [13 Regression] ICE in process_function_and_variable_attributes since r13-3601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108887 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Jason Merrill --- Fixed.
[Bug target/109104] [13 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1171 with -fzero-call-used-regs=all -march=rv64gv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109104 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | Last reconfirmed||2023-03-30 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Started with r13-2819-gb4feb49cf308b3, it was rejected before the revision with: :1:17: sorry, unimplemented: argument ‘all’ is not supported for ‘-fzero-call-used-regs’ on this target
[Bug bootstrap/101834] make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #11 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #10) > @@ -22,6 +22,7 @@ libexecdir := @libexecdir@ > target_noncanonical := @target_noncanonical@ > gcc_version := $(shell @get_gcc_base_ver@ $(srcdir)/../gcc/BASE-VER) > libexecsubdir := $(libexecdir)/gcc/$(target_noncanonical)/$(gcc_version) > +INSTALL := @INSTALL@ Without this, the 'all' target in c++tools is broken. It only works as part of a bootstrap because the top-level Makefile sets INSTALL in the environment when recursively calling 'make -C c++tools all' > INSTALL_PROGRAM := @INSTALL_PROGRAM@ > INSTALL_STRIP_PROGRAM := $(srcdir)/../install-sh -c -s > AUTOCONF := @AUTOCONF@ > @@ -41,13 +42,14 @@ all:: > mostlyclean:: > rm -f $(MAPPER.O) > > -clean:: > +clean:: mostlyclean > rm -f g++-mapper-server$(exeext) > > -distclean:: > - rm -f config.log config.status config.h > +distclean:: clean > + rm -f config.log config.status config.h config.cache Makefile > + rm -f $(MAPPER.O:%.o=%.d) > > -maintainer-clean:: > +maintainer-clean:: distclean These ensure the clean targets progressively clean more, instead of only removing disjoint sets of files, so that all the *clean targets need to be run to clean up properly. > @@ -132,6 +134,6 @@ config.h: config.status config.h.in > config.status: $(srcdir)/configure $(srcdir)/config.h.in > if test -x $@; then ./$@ -recheck; else $< @configure_args@; fi > > -.PHONY: all check clean distclean maintainer-clean > +.PHONY: all check mostlyclean clean distclean maintainer-clean And this was just missing. There might be other problems, but this means that "make distclean" works, and you can also do "make clean all" in the c++tools dir (rather than only being able to build c++tools from the top-level).
[Bug bootstrap/101834] make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #10 from Jonathan Wakely --- This seems like an improvement ... --- a/c++tools/Makefile.in +++ b/c++tools/Makefile.in @@ -22,6 +22,7 @@ libexecdir := @libexecdir@ target_noncanonical := @target_noncanonical@ gcc_version := $(shell @get_gcc_base_ver@ $(srcdir)/../gcc/BASE-VER) libexecsubdir := $(libexecdir)/gcc/$(target_noncanonical)/$(gcc_version) +INSTALL := @INSTALL@ INSTALL_PROGRAM := @INSTALL_PROGRAM@ INSTALL_STRIP_PROGRAM := $(srcdir)/../install-sh -c -s AUTOCONF := @AUTOCONF@ @@ -41,13 +42,14 @@ all:: mostlyclean:: rm -f $(MAPPER.O) -clean:: +clean:: mostlyclean rm -f g++-mapper-server$(exeext) -distclean:: - rm -f config.log config.status config.h +distclean:: clean + rm -f config.log config.status config.h config.cache Makefile + rm -f $(MAPPER.O:%.o=%.d) -maintainer-clean:: +maintainer-clean:: distclean install:: @@ -132,6 +134,6 @@ config.h: config.status config.h.in config.status: $(srcdir)/configure $(srcdir)/config.h.in if test -x $@; then ./$@ -recheck; else $< @configure_args@; fi -.PHONY: all check clean distclean maintainer-clean +.PHONY: all check mostlyclean clean distclean maintainer-clean -include $(MAPPER.O:.o=.d)
[Bug tree-optimization/91645] Missed optimization with sqrt(x*x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91645
--- Comment #11 from Jakub Jelinek ---
(In reply to Aldy Hernandez from comment #9)
> It looks like what we want for this test is actually !isgreaterequal() not
> isless(), since we want to exclude the possibility of a NAN. Like this:
>
> float test (float x)
> {
> if (!__builtin_isgreaterequal (x, 0.0))
> __builtin_unreachable();
> return sqrtf (x);
> }
No, what we emit for sqrtf is effectively:
if (!__builtin_isless (x, 0.0))
asm ("sqrtss %0, %0" : "+x" (x));
else
x = sqrtf (x); // The library version
return x;
So, the
if (__builtin_isless (x, 0.0)
__builtin_unreachable ();
is all we need.
We should either ask in tree-call-cdce.cc before trying to create this whether
x range is [-0.0, +Inf] NAN or some subset thereof, in that case just use
the .SQRT internal call, or if it is [-Inf, nextafterf (-0.0, -Inf)] or subset
thereof,
then use the library call only.
Or try to fold it in vrp2 or when, but in that case we don't know that easily
whether
the comparison can be optimized away completely (it still raises exceptions on
sNaN).
[Bug bootstrap/101834] make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #9 from Segher Boessenkool --- (In reply to Segher Boessenkool from comment #8) > (In reply to Jonathan Wakely from comment #6) > > Also, after 'make clean' you can no longer do 'make all' > > Of course you cannot. Where do you see this? Erm, scratch that, confusing clean and distclean myself now, heh.
[Bug bootstrap/101834] make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #8 from Segher Boessenkool --- (In reply to Jonathan Wakely from comment #6) > Also, after 'make clean' you can no longer do 'make all' Of course you cannot. Where do you see this?
[Bug bootstrap/101834] make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #7 from Segher Boessenkool --- Thank you for looking at this! (In reply to Jonathan Wakely from comment #5) > c++tools/Makefile.in has: > > mostlyclean:: > rm -f $(MAPPER.O) > > clean:: > rm -f g++-mapper-server$(exeext) > > distclean:: > rm -f config.log config.status config.h > > > Should distclean have clean as a prerequisite and clean have mostlyclean as > a prerequisite? That is what all other Makefiles do, and that makes sense yes. Is it that simple? I'll test with that now. > That would still leave config.cache and Makefile and the .d fragments though. Yup, but those I know how to handle :-)
[Bug tree-optimization/103559] Can't optimize away < 0 check on sqrt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103559 --- Comment #11 from Jakub Jelinek --- Actually, I was just misreading the tree dumps, we use hw insn for x u>= 0.0, which is UNGE_EXPR, so it is true if x is NAN or GE_EXPR, or as described in the tree-call-cdce.cc comment: y = sqrt (x); ==> if (__builtin_isless (x, 0)) y = sqrt (x); else y = IFN_SQRT (x); So we don't need to inspect anything on the libc sides, we already use the hw insn even for NANs. All we need to do is to use the ranger in tree-call-cdce.cc or perhaps later, and fold the x UNGE_EXPR 0.0 into true whenever frange says so (i.e. that the range is a subset of [-0.0, +INF] NAN).
[Bug bootstrap/101834] make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #6 from Jonathan Wakely --- Also, after 'make clean' you can no longer do 'make all' c++tools$ make clean all # --enable-maintainer-mode to rebuild /home/jwakely/src/gcc/gcc/c++tools/configure, or make MAINTAINER=touch # --enable-maintainer-mode to rebuild /home/jwakely/src/gcc/gcc/c++tools/config.h.in, or make MAINTAINER=touch rm -f g++-mapper-server g++ -g -O2 -fno-exceptions -fno-rtti -I/home/jwakely/src/gcc/gcc/c++tools/../libcody -I/home/jwakely/src/gcc/gcc/c++tools/../include -I/home/jwakely/src/gcc/gcc/c++tools/../gcc -I. -I../gcc \ -MMD -MP -MF server.d -c -o server.o /home/jwakely/src/gcc/gcc/c++tools/server.cc g++ -static-libstdc++ -static-libgcc -o g++-mapper-server server.o resolver.o ../libcody/libcody.a ../libiberty/libiberty.a g++-mapper-server ../gcc/g++-mapper-server make: g++-mapper-server: No such file or directory make: *** [Makefile:101: ../gcc/g++-mapper-server] Error 127
[Bug bootstrap/101834] make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 --- Comment #5 from Jonathan Wakely --- c++tools/Makefile.in has: mostlyclean:: rm -f $(MAPPER.O) clean:: rm -f g++-mapper-server$(exeext) distclean:: rm -f config.log config.status config.h Should distclean have clean as a prerequisite and clean have mostlyclean as a prerequisite? That would still leave config.cache and Makefile and the .d fragments though.
[Bug c++/107897] [13 Regression] mangling conflicts with a previous mangle since r13-3601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107897 --- Comment #7 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a23b33a1bdeff7bc2289d9ebb7cb7b7ec0a605f5 commit r13-6944-ga23b33a1bdeff7bc2289d9ebb7cb7b7ec0a605f5 Author: Jason Merrill Date: Mon Mar 6 15:33:45 2023 -0500 c++: lambda mangling alias issues [PR107897] In 107897, by the time we are looking at the mangling clash, the alias has already been removed from the symbol table by analyze_functions, so we can't look at n->cpp_implicit_alias. So just assume that it's an alias if it's internal. In 108887 the problem is that removing the mangling alias from the symbol table confuses analyze_functions, because it ended up as first_analyzed somehow, so it becomes a dangling pointer. So instead we call reset() to neutralize the alias. To make this work for variables, I needed to move reset() from cgraph_node to symtab_node. PR c++/107897 PR c++/108887 gcc/ChangeLog: * cgraph.h: Move reset() from cgraph_node to symtab_node. * cgraphunit.cc (symtab_node::reset): Adjust. Also call remove_from_same_comdat_group. gcc/cp/ChangeLog: * decl2.cc (record_mangling): Use symtab_node::reset. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-lambda3.C: Use -flto if supported. * g++.dg/cpp0x/lambda/lambda-mangle7.C: New test.
[Bug c++/108887] [13 Regression] ICE in process_function_and_variable_attributes since r13-3601
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108887 --- Comment #9 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a23b33a1bdeff7bc2289d9ebb7cb7b7ec0a605f5 commit r13-6944-ga23b33a1bdeff7bc2289d9ebb7cb7b7ec0a605f5 Author: Jason Merrill Date: Mon Mar 6 15:33:45 2023 -0500 c++: lambda mangling alias issues [PR107897] In 107897, by the time we are looking at the mangling clash, the alias has already been removed from the symbol table by analyze_functions, so we can't look at n->cpp_implicit_alias. So just assume that it's an alias if it's internal. In 108887 the problem is that removing the mangling alias from the symbol table confuses analyze_functions, because it ended up as first_analyzed somehow, so it becomes a dangling pointer. So instead we call reset() to neutralize the alias. To make this work for variables, I needed to move reset() from cgraph_node to symtab_node. PR c++/107897 PR c++/108887 gcc/ChangeLog: * cgraph.h: Move reset() from cgraph_node to symtab_node. * cgraphunit.cc (symtab_node::reset): Adjust. Also call remove_from_same_comdat_group. gcc/cp/ChangeLog: * decl2.cc (record_mangling): Use symtab_node::reset. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-lambda3.C: Use -flto if supported. * g++.dg/cpp0x/lambda/lambda-mangle7.C: New test.
[Bug c++/109344] feraiseexcept produces incorrect code when optimizations are enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109344 Xi Ruoyao changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #3 from Xi Ruoyao --- INVALID then.
[Bug target/108640] ICE compiling busybox for m68k in change_address_1, at emit-rtl.cc:2283
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
CC||marxin at gcc dot gnu.org
Keywords|needs-reduction |
Last reconfirmed||2023-03-30
--- Comment #3 from Martin Liška ---
Reduced test-case:
$ cat pr108640.i
int option_mask32;
enum {
OPTBIT_F = 12,
OPTBIT_R,
OPTBIT_Z,
OPTBIT_c,
OPTBIT_t,
OPT_t = 1 << OPTBIT_t
} ls_main() {
option_mask32 |= OPT_t;
}
$ ./xgcc -B. ~/Programming/testcases/pr108640.i -c -Os
during RTL pass: final
/home/marxin/Programming/testcases/pr108640.i: In function ‘ls_main’:
/home/marxin/Programming/testcases/pr108640.i:12:1: internal compiler error: in
change_address_1, at emit-rtl.cc:2287
12 | }
| ^
0xee4b72 change_address_1
/home/marxin/Programming/gcc/gcc/emit-rtl.cc:2287
0xee5684 adjust_address_1(rtx_def*, machine_mode, poly_int<1u, long>, int, int,
int, poly_int<1u, long>)
/home/marxin/Programming/gcc/gcc/emit-rtl.cc:2421
0x190e4e3 output_iorsi3(rtx_def**)
/home/marxin/Programming/gcc/gcc/config/m68k/m68k.cc:5513
0x1fd17bd output_255
/home/marxin/Programming/gcc/gcc/config/m68k/m68k.md:3779
0xf64f4f get_insn_template(int, rtx_insn*)
/home/marxin/Programming/gcc/gcc/final.cc:2029
0xf66b5e final_scan_insn_1
/home/marxin/Programming/gcc/gcc/final.cc:2774
0xf66fd2 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
/home/marxin/Programming/gcc/gcc/final.cc:2887
0xf64d79 final_1
/home/marxin/Programming/gcc/gcc/final.cc:1979
0xf69bbc rest_of_handle_final
/home/marxin/Programming/gcc/gcc/final.cc:4240
0xf69f1a execute
/home/marxin/Programming/gcc/gcc/final.cc:4318
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 107561, which changed state. Bug 107561 Summary: [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #26 from Richard Biener --- Fixed.
[Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561 --- Comment #25 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:04b0a7b1a6d9e0f3782888f1ebf187c26690038b commit r13-6943-g04b0a7b1a6d9e0f3782888f1ebf187c26690038b Author: Richard Biener Date: Wed Mar 29 13:49:24 2023 +0200 tree-optimization/107561 - reduce -Wstringop-overflow false positives The following tells pointer-query to prefer a zero size when we are querying for the size range for a write into an object we've determined is of zero size. That avoids diagnostics about really varying size arguments that just get a meaningful range for example because they are multiplied by an element size. I've adjusted only one call to get_size_range since that's what I have a testcase for. PR tree-optimization/107561 * gimple-ssa-warn-access.cc (get_size_range): Add flags argument and pass it on. (check_access): When querying for the size range pass SR_ALLOW_ZERO when the known destination size is zero. * g++.dg/pr71488.C: Remove XFAILed bogus diagnostic again. * g++.dg/warn/Warray-bounds-16.C: Likewise.
[Bug ipa/109341] [12/13 Regression] ICE in merge, at ipa-modref-tree.cc:176 since r12-3142-g5c85f29537662f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109341 Jan Hubicka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Jan Hubicka --- mine.
[Bug c++/109344] feraiseexcept produces incorrect code when optimizations are enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109344
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
I get the same result for all of -O0/-O1/-O2, all 3 functions raise both
exceptions and that is correct, glibc has removed the inline versions some time
ago:
https://sourceware.org/pipermail/libc-alpha/2020-March/111753.html
The bug was on the glibc side:
both the
/* One example of an invalid operation is 0.0 / 0.0. */
float __f = 0.0;
# ifdef __SSE_MATH__
__asm__ __volatile__ ("divss %0, %0 " : : "x" (__f));
and
float __f = 1.0;
float __g = 0.0;
# ifdef __SSE_MATH__
__asm__ __volatile__ ("divss %1, %0" : : "x" (__f), "x" (__g));
part, because glibc didn't tell the compiler the inline assembly actually
modifies the register.
So, the first one was supposed to be
__asm__ __volatile__ ("divss %0, %0 " : "+x" (__f));
and the second
__asm__ __volatile__ ("divss %1, %0" : "+x" (__f) : "x" (__g));
Not a bug on the GCC side and on glibc side it has been fixed by the removal of
the inline version.
[Bug tree-optimization/103035] [meta-bug] YARPGen bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103035 Bug 103035 depends on bug 109342, which changed state. Bug 109342 Summary: [13 Regression] Wrong code with -O2 since r13-5348-gc29d85359add80 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109342 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/109342] [13 Regression] Wrong code with -O2 since r13-5348-gc29d85359add80
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109342 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener --- Fixed.
[Bug tree-optimization/109342] [13 Regression] Wrong code with -O2 since r13-5348-gc29d85359add80
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109342 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:1d0ba4467dd9cad11eb9ff547442e3ce6292b892 commit r13-6942-g1d0ba4467dd9cad11eb9ff547442e3ce6292b892 Author: Richard Biener Date: Thu Mar 30 11:32:19 2023 +0200 tree-optimization/109342 - wrong code with edge equivalences in VN The following testcase shows a problem in how we query valitity for equivalences on edges when the edge is a backedge and thus refering to a block thats later in the iteration order we use for VN. That causes the dominated_by_p_w_unex helper to look at edge executable state that's not yet computed and thus still at optimistic not executable state. The following makes sure to use a plain dominance check in these cases. PR tree-optimization/109342 * tree-ssa-sccvn.cc (vn_nary_op_get_predicated_value): New overload for edge. When that edge is a backedge use dominated_by_p directly. * g++.dg/torture/pr109342.C: New testcase.
[Bug analyzer/107943] [11/12/13 Regression] gcc -fanalyzer hangs in openssl curve25519.c since r11-3840-gaf66094d03779377
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107943 Richard Biener changed: What|Removed |Added Last reconfirmed|2022-12-01 00:00:00 |2023-3-30 Known to fail||13.0 --- Comment #8 from Richard Biener --- Re-confirmed on trunk btw. I killed cc1 after 55min (release checking build)
[Bug bootstrap/101834] make distclean forgets ./c++tools/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101834 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2023-03-30 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #4 from Segher Boessenkool --- This still happens, and still is incredibly annoying. Left over after distclean are $ ll c++tools/ total 3620 -rw-rw-r-- 1 segher segher4781 Mar 29 10:39 Makefile -rw-rw-r-- 1 segher segher4972 Mar 29 10:39 config.cache -rwxrwxr-x 1 segher segher 2578928 Mar 29 10:39 g++-mapper-server -rw-rw-r-- 1 segher segher1319 Mar 29 10:39 resolver.d -rw-rw-r-- 1 segher segher 593464 Mar 29 10:39 resolver.o -rw-rw-r-- 1 segher segher2020 Mar 29 10:39 server.d -rw-rw-r-- 1 segher segher 518552 Mar 29 10:39 server.o
[Bug tree-optimization/103559] Can't optimize away < 0 check on sqrt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103559 --- Comment #10 from Xi Ruoyao --- (In reply to Jakub Jelinek from comment #9) > isless (NAN, 0.0) should be false, no, so NAN shouldn't errno = EDOM for > glibc. Oh, I misunderstood your question.
