[Bug libstdc++/103629] [11/12/13 Regression] wrong-code when mixing mutex with visibility=hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103629 --- Comment #27 from Mathieu Malaterre --- Symptom may go away with: * https://github.com/AcademySoftwareFoundation/openvdb/pull/1589
[Bug plugins/108634] [13 regression] 'undefined symbol: tree_code_type' when building kernel GCC plugins since r13-5431-gb0241ce6e37031
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:be6195c7e7adc7465214a0dc347c592822713c3f
commit r13-6730-gbe6195c7e7adc7465214a0dc347c592822713c3f
Author: Jakub Jelinek
Date: Fri Mar 17 08:44:19 2023 +0100
gdbhooks: Update gdbhooks.py for recent tree_code_type changes [PR108634]
On Mon, Mar 13, 2023 at 04:15:12PM -0400, Jason Merrill wrote:
> The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects
broke
> gdbhooks, which expects tree_code_type to always be available. I
considered
> trying to make gdbhooks more robust, but it seemed simpler to define
> tree_code_type as a reference to the template.
As I said earlier, I think it is better to tweak gdbhooks.
The following patch does that, I've tested it now both with gcc 12 and
older gcc as system compiler and the patch fixed the latter while keeping
the former working as before.
2023-03-17 Jakub Jelinek
PR plugins/108634
* gdbhooks.py (TreePrinter.to_string): Wrap
gdb.parse_and_eval('tree_code_type') in a try block, parse
and eval 'tree_code_type_tmpl<0>::tree_code_type' instead if it
raises exception. Update comments for the recent tree_code_type
changes.
[Bug middle-end/108685] [10/11/12/13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:713fa5db8ceb4ba8783a0d690ceb4c07f2ff03d0 commit r13-6731-g713fa5db8ceb4ba8783a0d690ceb4c07f2ff03d0 Author: Jakub Jelinek Date: Fri Mar 17 08:46:28 2023 +0100 openmp: Fix up handling of doacross loops with noreturn body in loops [PR108685] The following patch fixes an ICE with doacross loops which have a single entry no exit body, at least one of the ordered > collapse loops isn't guaranteed to have at least one iteration and the whole doacross loop is inside some other loop. The OpenMP constructs aren't represented by struct loop until the omp expansions, so for a normal doacross loop which doesn't have a noreturn body the entry_bb with the GOMP_FOR statement and the first bb of the body typically have the same loop_father, and if the doacross loop isn't inside of some other loop and the body is noreturn as well, both are part of loop 0. The problematic case is when the entry_bb is inside of some deeper loop, but the body, because it falls through into EXIT, has loop 0 as loop_father. l0_bb is created by splitting the entry_bb fallthru edge into l1_bb, and because the two basic blocks have different loop_father, a common loop is found for those (which is loop 0). Now, if the doacross loop has collapse == ordered or all the ordered > collapse loops are guaranteed to iterate at least once, all is still fine, because all enter the l1_bb (body), which doesn't return and so doesn't loop further either. But, if one of those loops could loop 0 times, the user written body wouldn't be reached at all, so unlike the expectations the whole construct actually wouldn't be noreturn if entry_bb is encountered and decides to handle at least one iteration. In this case, we need to fix up, move the l0_bb into the same loop as entry_bb (initially) and for the extra added loops put them as children of that same loop, rather than of loop 0. 2023-03-17 Jakub Jelinek PR middle-end/108685 * omp-expand.cc (expand_omp_for_ordered_loops): Add L0_BB argument, use its loop_father rather than BODY_BB's loop_father. (expand_omp_for_generic): Adjust expand_omp_for_ordered_loops caller. If broken_loop with ordered > collapse and at least one of those extra loops aren't guaranteed to have at least one iteration, change l0_bb's loop_father to entry_bb's loop_father. Set cont_bb's loop_father to l0_bb's loop_father rather than l1_bb's. * c-c++-common/gomp/doacross-8.c: New test.
[Bug middle-end/108685] [10/11/12 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11/12 Regression] ICE |ICE in |in verify_loop_structure, |verify_loop_structure, at |at cfgloop.cc:1748 since |cfgloop.cc:1748 since |r13-2388-ga651e6d59188da |r13-2388-ga651e6d59188da| --- Comment #8 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109145
--- Comment #10 from Richard Biener ---
(In reply to Jakub Jelinek from comment #7)
> So, I think we can either use:
> 2023-03-16 Jakub Jelinek
>
> PR testsuite/109145
> * gcc.dg/tree-ssa/forwprop-39.c (CMPLXF): Define if not defined.
>
> --- gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c.jj2023-03-13
> 10:18:59.545433477 +0100
> +++ gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c 2023-03-16
> 18:48:04.408908088 +0100
> @@ -3,6 +3,10 @@
>
> #include
>
> +#ifndef CMPLXF
> +#define CMPLXF(x, y) __builtin_complex (x, y)
> +#endif
> +
> extern void push1(void *p, float _Complex x);
> void foo (void *q, float _Complex *x)
> {
> or
> 2023-03-16 Jakub Jelinek
>
> PR testsuite/109145
> * gcc.dg/tree-ssa/forwprop-39.c: Don't include complex.h.
> (foo): Use __builtin_complex rather than CMPLXF.
>
> --- gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c.jj2023-03-13
> 10:18:59.545433477 +0100
> +++ gcc/testsuite/gcc.dg/tree-ssa/forwprop-39.c 2023-03-16
> 18:49:40.563504504 +0100
> @@ -1,14 +1,12 @@
> /* { dg-do compile } */
> /* { dg-options "-std=c11 -O2 -fdump-tree-forwprop1 -fdump-tree-optimized"
> } */
>
> -#include
> -
> extern void push1(void *p, float _Complex x);
> void foo (void *q, float _Complex *x)
> {
>float r = __real *x;
>float i = __imag *x;
> - push1 (q, CMPLXF (r, i));
> + push1 (q, __builtin_complex (r, i));
> }
>
> /* { dg-final { scan-tree-dump-not "COMPLEX_EXPR" "forwprop1" } } */
>
> I think my preference would be the latter...
Yes, can you push that please? Then also the -std=c11 is no longer necessary.
[Bug testsuite/109145] new test case gcc.dg/tree-ssa/forwprop-39.c from r13-6624-geb337d28c32b1b fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109145 --- Comment #11 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2bb71424636fba7944b36b1689e9df22a53f1a3f commit r13-6732-g2bb71424636fba7944b36b1689e9df22a53f1a3f Author: Jakub Jelinek Date: Fri Mar 17 09:58:08 2023 +0100 testsuite: Fix up forwprop-39.c testcase [PR109145] As written in the PR, newlib headers aren't C11 compliant in that they don't define CMPLXF macro, and glibc before 2.16 doesn't define that either. I think it is easier to use __builtin_complex directly, over another patch which keeps including complex.h but defines CMPLXF if it isn't defined, we want to test how forwprop behaves rather than what complex.h defines or doesn't define. 2023-03-17 Jakub Jelinek PR testsuite/109145 * gcc.dg/tree-ssa/forwprop-39.c: Remove -std=c11 from dg-options. Don't include complex.h. (foo): Use __builtin_complex rather than CMPLXF.
[Bug target/105554] [10/11/12/13 Regression] ICE: in emit_block_move_hints, at expr.cc:1829 since r9-5509-g5928bc2ec06dd4e7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554
--- Comment #16 from Richard Biener ---
(In reply to Jakub Jelinek from comment #14)
> So, I have tried
> --- gcc/cgraphclones.cc.jj2023-02-24 11:05:19.704595633 +0100
> +++ gcc/cgraphclones.cc 2023-03-16 19:12:30.452503051 +0100
> @@ -1094,6 +1094,15 @@ cgraph_node::create_version_clone_with_b
>|| in_lto_p)
> new_version_node->unique_name = true;
>
> + if (target_attributes)
> +{
> + push_cfun (DECL_STRUCT_FUNCTION (new_decl));
> + for (tree arg = DECL_ARGUMENTS (new_decl); arg; arg = DECL_CHAIN
> (arg))
> + if (VECTOR_TYPE_P (TREE_TYPE (arg)))
> + SET_DECL_MODE (arg, TYPE_MODE (TREE_TYPE (arg)));
> + pop_cfun ();
> +}
> +
>/* Update the call_expr on the edges to call the new version node. */
>update_call_expr (new_version_node);
>
> but that really didn't help, the problem seems to be actually different.
>
> From what I can see, tree_function_versioning does:
> 6240DECL_RESULT (new_decl) = DECL_RESULT (old_decl);
> 6241DECL_ARGUMENTS (new_decl) = DECL_ARGUMENTS (old_decl);
> 6242initialize_cfun (new_decl, old_decl,
> 6243 new_entry ? new_entry->count :
> old_entry_block->count);
> and initialize_cfun will call allocate_function, which does:
> 4845/* Now that we have activated any function-specific attributes
> 4846 that might affect layout, particularly vector modes,
> relayout
> 4847 each of the parameters and the result. */
> 4848relayout_decl (result);
> 4849for (tree parm = DECL_ARGUMENTS (fndecl); parm;
> 4850 parm = DECL_CHAIN (parm))
> 4851 relayout_decl (parm);
> So, we temporarily set DECL_ARGUMENTS and DECL_RESULT of new_decl to
> arguments/result of old_decl and allocate_function called relayout_decl on
> those, later on we create new arguments (which supposedly have correct
> DECL_MODE). But we've changed the old DECL_RESULT/DECL_ARGUMENTS.
Ick - that's one of the worst place to do this ... what happens if we
postpone setting DECL_RESULT/DECL_ARGUMENTS to after initialize_cfun
(and remove the setting of them there)?
I suppose on its own this doesn't fix the original issue but possibly
clobbering the original function arg decls layouts looks wrong ...
[Bug tree-optimization/109170] New: New glibc warning: open_catalog.c:86:16: error: pointer ‘old_buf’ may be used after ‘realloc’ [-Werror=use-after-free] since r13-6707-g0a07bfad12530bca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109170 Bug ID: 109170 Summary: New glibc warning: open_catalog.c:86:16: error: pointer ‘old_buf’ may be used after ‘realloc’ [-Werror=use-after-free] since r13-6707-g0a07bfad12530bca Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Created attachment 54688 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54688&action=edit Unreduced test-case Happens for the current glibc master with the latest GCC compiler: $ gcc -c open_catalog.i -O2 -Wall open_catalog.c: In function ‘__open_catalog’: open_catalog.c:86:16: warning: pointer ‘old_buf’ may be used after ‘realloc’ [-Wuse-after-free] open_catalog.c:86:148: note: call to ‘realloc’ here open_catalog.c:102:17: warning: pointer ‘old_buf’ may be used after ‘realloc’ [-Wuse-after-free] open_catalog.c:102:149: note: call to ‘realloc’ here open_catalog.c:109:17: warning: pointer ‘old_buf’ may be used after ‘realloc’ [-Wuse-after-free] open_catalog.c:109:149: note: call to ‘realloc’ here open_catalog.c:118:14: warning: pointer ‘old_buf’ may be used after ‘realloc’ [-Wuse-after-free] open_catalog.c:118:140: note: call to ‘realloc’ here open_catalog.c:134:18: warning: pointer ‘old_buf’ may be used after ‘realloc’ [-Wuse-after-free] open_catalog.c:134:144: note: call to ‘realloc’ here open_catalog.c:151:18: warning: pointer ‘old_buf’ may be used after ‘realloc’ [-Wuse-after-free] open_catalog.c:151:144: note: call to ‘realloc’ here open_catalog.c:158:17: warning: pointer ‘old_buf’ may be used after ‘realloc’ [-Wuse-after-free] open_catalog.c:158:143: note: call to ‘realloc’ here open_catalog.c:171:13: warning: pointer ‘old_buf’ may be used after ‘realloc’ [-Wuse-after-free] open_catalog.c:171:139: note: call to ‘realloc’ here open_catalog.c:175:12: warning: pointer ‘old_buf’ may be used after ‘realloc’ [-Wuse-after-free] open_catalog.c:175:138: note: call to ‘realloc’ here
[Bug target/105554] [10/11/12/13 Regression] ICE: in emit_block_move_hints, at expr.cc:1829 since r9-5509-g5928bc2ec06dd4e7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554 --- Comment #17 from Jakub Jelinek --- (In reply to Richard Biener from comment #16) > Ick - that's one of the worst place to do this ... what happens if we > postpone setting DECL_RESULT/DECL_ARGUMENTS to after initialize_cfun > (and remove the setting of them there)? If DECL_RESULT is NULL, then allocate_struct_function will segfault. I think if DECL_ARGUMENTS was NULL there, it would be ok with it. But initialize_cfun starts with: if (!DECL_ARGUMENTS (new_fndecl)) DECL_ARGUMENTS (new_fndecl) = DECL_ARGUMENTS (callee_fndecl); if (!DECL_RESULT (new_fndecl)) DECL_RESULT (new_fndecl) = DECL_RESULT (callee_fndecl); which makes it redundant with the only caller of it doing: DECL_RESULT (new_decl) = DECL_RESULT (old_decl); DECL_ARGUMENTS (new_decl) = DECL_ARGUMENTS (old_decl); initialize_cfun (new_decl, old_decl, new_entry ? new_entry->count : old_entry_block->count);
[Bug target/105554] [10/11/12/13 Regression] ICE: in emit_block_move_hints, at expr.cc:1829 since r9-5509-g5928bc2ec06dd4e7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554 Jakub Jelinek changed: What|Removed |Added Attachment #54686|0 |1 is obsolete|| --- Comment #18 from Jakub Jelinek --- Created attachment 54689 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54689&action=edit gcc13-pr105554.patch This also works.
[Bug target/105554] [10/11/12/13 Regression] ICE: in emit_block_move_hints, at expr.cc:1829 since r9-5509-g5928bc2ec06dd4e7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554 --- Comment #19 from Richard Biener --- Created attachment 54690 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54690&action=edit not working patch So this one fails badly in ipa_param_body_adjustments::common_initialization where it needs struct function. Possibly it could be refactored to spit out the get_new_param_chain early and doing the rest late. I'm leaving the param_adjustments case untouched with a comment. Let me test what I have.
[Bug fortran/109171] New: initialization using %re causes segfault, as an assignment does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109171 Bug ID: 109171 Summary: initialization using %re causes segfault, as an assignment does not Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- program boom implicit none complex, save, target :: a(4) #ifdef INITIALIZE real, pointer :: p(:) => a(1:3:2)%re #else real, pointer :: p(:) p => a(1:3:2)%re #endif a = [(1., 0.), (2., 0.), (3., 0.), (4., 0)] print *, p end program boom when compiles with "gfortran" and so using the assignment it works; when compiled with "gfortran -DINITIALIZE" it compiles but gets a segfault on execution.
[Bug fortran/109171] initialization using %re causes segfault, as an assignment does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109171 --- Comment #1 from urbanjost at comcast dot net --- per discussion in https://groups.google.com/g/comp.lang.fortran/c/zBaOPfeFrOU
[Bug target/109092] [13 Regression] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1932 when building libgcc on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109092 --- Comment #7 from CVS Commits --- The master branch has been updated by Kito Cheng : https://gcc.gnu.org/g:02880e7803b19c357718abd2f0d567b4a761f318 commit r13-6733-g02880e7803b19c357718abd2f0d567b4a761f318 Author: Ju-Zhe Zhong Date: Mon Mar 13 22:17:57 2023 +0800 RISC-V: Use reg_or_subregno to check regno [PR109092] gcc/ChangeLog: PR target/109092 * config/riscv/riscv.md: Fix subreg bug.
[Bug target/105554] [10/11/12/13 Regression] ICE: in emit_block_move_hints, at expr.cc:1829 since r9-5509-g5928bc2ec06dd4e7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554 Jakub Jelinek changed: What|Removed |Added Attachment #54689|0 |1 is obsolete|| --- Comment #20 from Jakub Jelinek --- Created attachment 54691 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54691&action=edit gcc13-pr105554.patch Another working version.
[Bug c++/109164] wrong code with thread_local reference, loops and -ftree-pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109164
Richard Biener changed:
What|Removed |Added
Component|tree-optimization |c++
CC||jason at gcc dot gnu.org
--- Comment #4 from Richard Biener ---
So we have
;; Function Struct& _ZTW16thread_local_ref() (null)
;; enabled by -tree-original
if (_ZTH16thread_local_ref != 0B)
{
<;
}
return = thread_local_ref;
which is eventually inlined. But 'thread_local_ref' is TREE_READONLY and
thus may_be_aliased is false and the readonly-global exception triggers:
/* If the reference is based on a decl that is not aliased the call
cannot possibly clobber it. */
if (DECL_P (base)
&& !may_be_aliased (base)
/* But local non-readonly statics can be modified through recursion
or the call may implement a threading barrier which we must
treat as may-def. */
&& (TREE_READONLY (base)
|| !is_global_var (base)))
return false;
I think it's a mistake for the frontend to set TREE_READONLY on the
decl if it requires initialization (we've been there for other runtime
initialized globals).
Thus -> C++ FE bug.
[Bug tree-optimization/109170] New glibc warning: open_catalog.c:86:16: error: pointer ‘old_buf’ may be used after ‘realloc’ [-Werror=use-after-free] since r13-6707-g0a07bfad12530bca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109170 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Last reconfirmed||2023-03-17 --- Comment #1 from Richard Biener --- I will have a look.
[Bug tree-optimization/109170] New glibc warning: open_catalog.c:86:16: error: pointer ‘old_buf’ may be used after ‘realloc’ [-Werror=use-after-free] since r13-6707-g0a07bfad12530bca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109170
--- Comment #2 from Martin Liška ---
Reduced test-case:
$ cat open_catalog.i
unsigned long bufmax = 0;
unsigned long __open_catalog_bufmax;
void *realloc();
void free();
void __open_catalog(char *buf) {
char *old_buf = buf;
buf = realloc (buf, bufmax);
if (__builtin_expect ((buf == ((void *)0)), 0))
free (old_buf);
}
[Bug libstdc++/109165] std::hash>::operator() should be const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109165 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Target Milestone|--- |12.3 Last reconfirmed||2023-03-17 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jonathan Wakely --- Oops.
[Bug c++/109172] New: g++ calls a private destructor with the keyword throw after the try-block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109172 Bug ID: 109172 Summary: g++ calls a private destructor with the keyword throw after the try-block Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: MikeSmith32564 at mail dot com Target Milestone: --- Created attachment 54692 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54692&action=edit Bug example In the attached example an instance of class Demo is constructed in-place in a buffer by following the natural alignment of Demo and then this instance is passed to throw. Note that Demo has a private destructor. The expected behavior when building is that g++ should return a compilation error because a private destructor cannot be called outisde of the class Demo or outside of friend declarations. The actual behavior is that the example builds successfully when g++ -std=c++11 ./main.cpp -o ./main is used, producing the following output: Demo(), id = 1 Demo(const Demo&) called, this->id = 2, other.id = 1 in catch, e.id = 2 ~Demo(), id = 2 main ends here If the destructor is instead declared as deleted the example fails to compile as expected: main.cpp: In function 'int main()': main.cpp:69:10: error: use of deleted function 'Demo::~Demo()' throw *d; ^ main.cpp:61:2: note: declared here ~Demo() = delete; ^
[Bug c/109173] New: incorrect intrinsic signature for _mm_srai_epi64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109173
Bug ID: 109173
Summary: incorrect intrinsic signature for _mm_srai_epi64
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: malat at debian dot org
Target Milestone: ---
gcc-13 currently rejects the following:
% /usr/lib/gcc-snapshot/bin/gcc -c -Wsign-conversion -Werror -mavx512vl -O2
tu.c
tu.c: In function 'foo':
tu.c:7:30: error: conversion to 'int' from 'unsigned int' may change the sign
of the result [-Werror=sign-conversion]
7 | return _mm_srai_epi64(a, bar());
| ^
cc1: all warnings being treated as errors
with:
% cat tu.c
#include
extern unsigned int bar();
__m128i foo(__m128i a)
{
return _mm_srai_epi64(a, bar());
}
intel documentation declares it as unsigned int
*
https://www.intel.com/content/www/us/en/docs/cpp-compiler/developer-guide-reference/2021-8/intrinsics-for-shift-operations.html
[...]
__m128i _mm_srai_epi64(__m128i a, unsigned int imm)
[...]
% /usr/lib/gcc-snapshot/bin/gcc --version
gcc (Debian 20230315-1) 13.0.1 20230315 (experimental) [master
r13-6680-ga9ae16db8cb]
[Bug c++/109172] g++ calls a private destructor with the keyword throw after the try-block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109172
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-03-17
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Keywords||accepts-invalid
--- Comment #1 from Jonathan Wakely ---
The attached example has the deleted destructor, so fails as expected.
Reduced version of the actual problem:
struct Demo
{
private:
~Demo()
{
__builtin_abort();
}
};
int main() {
try
{
throw *new Demo;
}
catch(const Demo& e)
{
}
}
[Bug c/109173] incorrect intrinsic signature for _mm_srai_epi64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109173 Jakub Jelinek changed: What|Removed |Added CC||hjl.tools at gmail dot com, ||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- This is a bogus assumption IMHO.
[Bug c++/109172] [10/11/12/13 Regression] g++ calls a private destructor with the keyword throw after the try-block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109172 Jonathan Wakely changed: What|Removed |Added Known to fail||13.0, 4.4.7 Known to work||4.1.2, 4.3.0 Summary|g++ calls a private |[10/11/12/13 Regression] |destructor with the keyword |g++ calls a private |throw after the try-block |destructor with the keyword ||throw after the try-block --- Comment #2 from Jonathan Wakely --- This is a regression that started after r156840 and no later than r156854 Maybe r156841 or r156842
[Bug c++/109164] wrong code with thread_local reference, loops and -ftree-pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109164 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 54693 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54693&action=edit gcc13-pr109164.patch Untested fix.
[Bug c/109173] incorrect intrinsic signature for _mm_srai_epi64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109173 --- Comment #2 from Jakub Jelinek --- To expand on it further, nothing guarantees that the intrinsic is actually an inline function, it can be also macro etc., so relying on such details as exact operand type is impossible.
[Bug c/109173] incorrect intrinsic signature for _mm_srai_epi64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109173 --- Comment #3 from Mathieu Malaterre --- In a previous episode: > ICC is our gold standard as far as intrinsics are concerned. So, unless there > is > a real issue with some specific builtin, I think we should follow ICC. * https://gcc.gnu.org/bugzilla//show_bug.cgi?id=87674#c4
[Bug c/109174] New: incorrect intrinsic signature for AVX-512 srai*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109174
Bug ID: 109174
Summary: incorrect intrinsic signature for AVX-512 srai*
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: malat at debian dot org
Target Milestone: ---
gcc-13 currently rejects the following:
% /usr/lib/gcc-snapshot/bin/gcc -c -Wsign-conversion -Werror -mavx512bw -O2
tu2.c
tu2.c: In function 'foo':
tu2.c:7:24: error: conversion to 'int' from 'unsigned int' may change the sign
of the result [-Werror=sign-conversion]
7 | _mm512_slli_epi16(a, bar());
|^
tu2.c:8:24: error: conversion to 'int' from 'unsigned int' may change the sign
of the result [-Werror=sign-conversion]
8 | _mm512_srai_epi16(a, bar());
|^
tu2.c:9:24: error: conversion to 'int' from 'unsigned int' may change the sign
of the result [-Werror=sign-conversion]
9 | _mm512_srli_epi16(a, bar());
|^
cc1: all warnings being treated as errors
with
% cat tu2.c
#include
extern unsigned int bar();
void foo(__m512i a)
{
_mm512_slli_epi16(a, bar());
_mm512_srai_epi16(a, bar());
_mm512_srli_epi16(a, bar());
}
intel documentation declares it as unsigned int
https://www.intel.com/content/www/us/en/docs/cpp-compiler/developer-guide-reference/2021-8/intrinsics-for-shift-operations.html
[...]
__m512i _mm512_slli_epi16(__m512i a, unsigned int imm)
[...]
% /usr/lib/gcc-snapshot/bin/gcc --version
gcc (Debian 20230315-1) 13.0.1 20230315 (experimental) [master
r13-6680-ga9ae16db8cb]
[Bug c/109173] incorrect intrinsic signature for _mm_srai_epi64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109173 --- Comment #4 from Jakub Jelinek --- Except that ICC changes it over time...
[Bug tree-optimization/109170] New glibc warning: open_catalog.c:86:16: error: pointer ‘old_buf’ may be used after ‘realloc’ [-Werror=use-after-free] since r13-6707-g0a07bfad12530bca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109170 --- Comment #3 from Richard Biener --- The issue is that we have : old_buf_7 = buf_6(D); bufmax.0_1 = bufmax; buf_10 = realloc (buf_6(D), bufmax.0_1); _2 = buf_10 == 0B; _3 = (long int) _2; _4 = __builtin_expect (_3, 0); if (_4 != 0) goto ; [INV] else goto ; [INV] : free (old_buf_7); but ranger lacks a range-op for __builtin_constant_p. Testing a fix.
[Bug c++/109172] [10/11/12/13 Regression] g++ calls a private destructor with the keyword throw after the try-block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109172 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.5
[Bug tree-optimization/109170] New glibc warning: open_catalog.c:86:16: error: pointer ‘old_buf’ may be used after ‘realloc’ [-Werror=use-after-free] since r13-6707-g0a07bfad12530bca
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109170 --- Comment #4 from Martin Liška --- > but ranger lacks a range-op for __builtin_constant_p. Testing a fix. you likely mean __builtin_expect, right? Sure, that's a simple optimization ranger should understand..
[Bug modula2/109102] Wrong quotes in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109102 --- Comment #1 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:daf20b4b83615d61bf1793e8edcd64681275e598 commit r13-6735-gdaf20b4b83615d61bf1793e8edcd64681275e598 Author: Gaius Mulley Date: Fri Mar 17 12:47:06 2023 + PR modula2/109102 Wrong quotes in diagnostic The backtick and single quote should be replaced with %< and %> or %qs. gcc/m2/ChangeLog: PR modula2/109102 * gm2-gcc/m2builtins.cc (ASSERT): Change format specifier to use %qs rather than quotes. Signed-off-by: Gaius Mulley
[Bug modula2/109102] Wrong quotes in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109102 Gaius Mulley changed: What|Removed |Added Last reconfirmed||2023-03-17 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Gaius Mulley --- Many thanks for reporting the bug.
[Bug modula2/109102] Wrong quotes in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109102 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Gaius Mulley --- Closing as the patch has been applied.
[Bug rtl-optimization/109052] Unnecessary reload with -mfpmath=both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052 --- Comment #3 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:57688950b9328cbb4a9c21eb3199f9132b5119d3 commit r13-6736-g57688950b9328cbb4a9c21eb3199f9132b5119d3 Author: Vladimir N. Makarov Date: Fri Mar 17 08:58:58 2023 -0400 LRA: Implement combining secondary memory reload and original insn LRA creates secondary memory reload insns but do not try to combine it with the original insn. This patch implements a simple insn combining for such cases in LRA. PR rtl-optimization/109052 gcc/ChangeLog: * lra-constraints.cc: Include hooks.h. (combine_reload_insn): New function. (lra_constraints): Call it. gcc/testsuite/ChangeLog: * gcc.target/i386/pr109052.c: New.
[Bug rtl-optimization/109052] Unnecessary reload with -mfpmath=both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052 --- Comment #4 from Vladimir Makarov --- The complete solution would be running combine pass also after LRA. I am not sure how frequently the 2nd pass will improve the code. Also probably it might create some troubles the fix of which will require another LRA pass. The most generalized solution would be an approach of combined optimizations (integrated insn scheduling, RA, and code selection) but in practice it makes the integrated optimization too complicated. Less complicated solution could be implementation of combining secondary memory reload insns in postreload pass but implementing this in LRA is better because we increase possibility to assign hard regs to other pseudos as we don't need to allocate hard register to a pseudo which goes away. So I think the current patch is probably an adequate solution.
[Bug c++/69410] [10/11/12/13 Regression] friend declarations in local classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69410 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug rtl-optimization/109052] Unnecessary reload with -mfpmath=both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052
--- Comment #5 from Uroš Bizjak ---
(In reply to Vladimir Makarov from comment #4)
> So I think the current patch is probably an adequate solution.
Perhaps the compiler should also try to swap input operands to fit the combined
insn when commutative operands are allowed. This would solve the testcase from
Comment #2:
double foo (double a, double b)
{
double z = __builtin_fmod (a, 3.14);
return z * b;
}
gcc -O2 -mfpmath=both -mavx:
Failed combined insn:
24: r90:DF=r96:DF*r85:DF
REG_DEAD r85:DF
REG_DEAD r82:DF
Restoring insn after failed combining:
(^^^ shouldn't there be a memory operand mentioned in the above RTX dump?)
...
(insn 42 41 24 6 (set (reg/v:DF 23 xmm3 [orig:82 z ] [82])
(mem/c:DF (plus:DI (reg/f:DI 7 sp)
(const_int 8 [0x8])) [1 %sfp+-24 S8 A64])) "fmod.c":4:12 145
{*movdf_internal}
(nil))
(insn 24 42 30 6 (set (reg:DF 20 xmm0 [90])
(mult:DF (reg/v:DF 23 xmm3 [orig:82 z ] [82])
(reg/v:DF 22 xmm2 [orig:85 b ] [85]))) "fmod.c":4:12 1189
{*fop_df_comm}
(nil))
...
As can be seen in the above dump, swapped input operands would fit alternative
(v,v,vm) in the insn pattern:
[(set (match_operand:MODEF 0 "register_operand" "=f,x,v")
(match_operator:MODEF 3 "binary_fp_operator"
[(match_operand:MODEF 1 "nonimmediate_operand" "%0,0,v")
(match_operand:MODEF 2 "nonimmediate_operand" "fm,xm,vm")]))]
[Bug c++/109160] [Valid code] Constraint on deduced NTTP from method call causes ICE/Segfault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109160 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-03-17 Blocks||67491 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #1 from Patrick Palka --- Confirmed, this never worked properly. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 [Bug 67491] [meta-bug] concepts issues
[Bug testsuite/105959] new test case c-c++-common/diagnostic-format-sarif-file-4.c from r13-967-g6cf276ddf22066 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959 --- Comment #11 from David Malcolm --- (In reply to Hans-Peter Nilsson from comment #10) > (I see an identifier using ideographs? > Wouldn't want to review that code... Might as well use Linear A -which you > indeed can in UTF-8- - it's all greek to me!) FWIW the identifier "文字化け" is the word "mojibake", which is the Japanese word for snafu with character encodings: https://en.wikipedia.org/wiki/Mojibake
[Bug target/109173] incorrect intrinsic signature for _mm_srai_epi64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109173 --- Comment #5 from Jan Wassenberg --- Thanks, Mathieu, for raising this. Note that clang has changed their intrinsic to require an unsigned arg: https://github.com/google/highway/commit/45b1fac0b1c404e6573c2f182b36c245af6503e0 I understand that some implementations may be using a macro, and that's fine, but certain GCC and clang have non-macro intrinsics that are mutually incompatible, and users including us are forced to use #if to compile without warnings. My understanding is that icc is being replaced with clang. Wouldn't it be better then to follow the Intel intrinsics documentation?
[Bug modula2/109032] message 'compiler checks to force' is too complicated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109032 --- Comment #7 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:6bfb5eae96b65894da1301e966568fdf32bf64d0 commit r13-6737-g6bfb5eae96b65894da1301e966568fdf32bf64d0 Author: Gaius Mulley Date: Fri Mar 17 14:32:22 2023 + PR modula2/109032 - message 'compiler checks to force' is too complicated Correct typos and improve the descriptions of command line options. Improve comments in gm2-gcc/m2expr.cc. gcc/m2/ChangeLog: PR modula2/109032 * gm2-gcc/m2expr.cc: Correct ? : order in comments. (m2expr_BuildDivM2): Improve comment. * lang.opt: Improve option descriptions. Signed-off-by: Gaius Mulley
[Bug modula2/109032] message 'compiler checks to force' is too complicated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109032 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Gaius Mulley --- Thanks for reporting - now closing as the patch has been applied.
[Bug rtl-optimization/109052] Unnecessary reload with -mfpmath=both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052 --- Comment #6 from Vladimir Makarov --- (In reply to Uroš Bizjak from comment #5) > (In reply to Vladimir Makarov from comment #4) > > > So I think the current patch is probably an adequate solution. > > Perhaps the compiler should also try to swap input operands to fit the > combined insn when commutative operands are allowed. This would solve the > testcase from Comment #2: > Yes. I am agree. The base code can be improved further. Another improvement could be combining secondary memory reload for output. I'd like to watch what the effect of the current patch would be first. Although I tested the patch on many targets as usually for LRA the patch might result in some troubles on some targets. But I hope nothing bad will happen.
[Bug c++/109175] New: error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109175 Bug ID: 109175 Summary: error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=] Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: malat at debian dot org Target Milestone: --- A new warning is appearing in the highway compilation logs on aarch64: [...] FAILED: CMakeFiles/convert_test.dir/hwy/tests/convert_test.cc.o /usr/lib/gcc-snapshot/bin/g++ -DHWY_SHARED_DEFINE -I"/<>" -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -DHWY_BROKEN_EMU128=0 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE -fvisibility=hidden -fvisibility-inlines-hidden -Wno-builtin-macro-redefined -D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\" -fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion -Wvla -Wnon-virtual-dtor -fmath-errno -fno-exceptions -Werror -DHWY_IS_TEST=1 -DGTEST_HAS_PTHREAD=1 -MD -MT CMakeFiles/convert_test.dir/hwy/tests/convert_test.cc.o -MF CMakeFiles/convert_test.dir/hwy/tests/convert_test.cc.o.d -o CMakeFiles/convert_test.dir/hwy/tests/convert_test.cc.o -c '/<>/hwy/tests/convert_test.cc' In file included from /<>/hwy/foreach_target.h:114, from /<>/hwy/tests/convert_test.cc:26: In function 'hwy::AlignedFreeUniquePtr hwy::N_SVE2::F16TestCases(D, size_t&) [with D = Simd]', inlined from 'void hwy::N_SVE2::TestF16::operator()(TF32, DF32) [with TF32 = float; DF32 = hwy::N_SVE2::Simd]' at /<>/hwy/tests/convert_test.cc:300:10: /<>/hwy/tests/convert_test.cc:288:11: error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=] 288 | in[i] = 0.0f; In function 'void hwy::N_SVE2::TestF16::operator()(TF32, DF32) [with TF32 = float; DF32 = hwy::N_SVE2::Simd]': cc1plus: note: destination object is likely at address zero In file included from /<>/hwy/foreach_target.h:103: In function 'hwy::AlignedFreeUniquePtr hwy::N_SVE::F16TestCases(D, size_t&) [with D = Simd]', inlined from 'void hwy::N_SVE::TestF16::operator()(TF32, DF32) [with TF32 = float; DF32 = hwy::N_SVE::Simd]' at /<>/hwy/tests/convert_test.cc:300:10: /<>/hwy/tests/convert_test.cc:288:11: error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=] 288 | in[i] = 0.0f; In function 'void hwy::N_SVE::TestF16::operator()(TF32, DF32) [with TF32 = float; DF32 = hwy::N_SVE::Simd]': cc1plus: note: destination object is likely at address zero cc1plus: all warnings being treated as errors [...] ref: * https://buildd.debian.org/status/fetch.php?pkg=highway&arch=arm64&ver=1.0.4%7Egit20230308.a1d7764-1&stamp=1679052435&raw=0
[Bug c++/109175] error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109175 --- Comment #1 from Mathieu Malaterre --- Created attachment 54694 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54694&action=edit Preprocessed source gcc-13 % /usr/lib/gcc-snapshot/bin/g++ -save-temps=obj -DHWY_SHARED_DEFINE -I"/home/malat/highway-1.0.4~git20230308.a1d7764" -g -O2 -ffile-prefix-map=/home/malat/highway-1.0.4~git20230308.a1d7764=. -fstack-protector-strong -Wformat -Werror=format-security -DHWY_BROKEN_EMU128=0 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE -fvisibility=hidden -fvisibility-inlines-hidden -Wno-builtin-macro-redefined -D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\" -fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion -Wvla -Wnon-virtual-dtor -fmath-errno -fno-exceptions -Werror -DHWY_IS_TEST=1 -DGTEST_HAS_PTHREAD=1 -MD -MT CMakeFiles/convert_test.dir/hwy/tests/convert_test.cc.o -MF CMakeFiles/convert_test.dir/hwy/tests/convert_test.cc.o.d -o CMakeFiles/convert_test.dir/hwy/tests/convert_test.cc.o -c '/home/malat/highway-1.0.4~git20230308.a1d7764/hwy/tests/convert_test.cc'
[Bug c++/109175] error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109175 --- Comment #2 from Mathieu Malaterre --- Created attachment 54695 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54695&action=edit Preprocessed source gcc-12 g++ -save-temps=obj -DHWY_SHARED_DEFINE -I"/home/malat/highway-1.0.4~git20230308.a1d7764" -g -O2 -ffile-prefix-map=/home/malat/highway-1.0.4~git20230308.a1d7764=. -fstack-protector-strong -Wformat -Werror=format-security -DHWY_BROKEN_EMU128=0 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE -fvisibility=hidden -fvisibility-inlines-hidden -Wno-builtin-macro-redefined -D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\" -fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion -Wvla -Wnon-virtual-dtor -fmath-errno -fno-exceptions -Werror -DHWY_IS_TEST=1 -DGTEST_HAS_PTHREAD=1 -MD -MT CMakeFiles/convert_test.dir/hwy/tests/convert_test.cc.o -MF CMakeFiles/convert_test.dir/hwy/tests/convert_test.cc.o.d -o CMakeFiles/convert_test.dir/hwy/tests/convert_test.cc.o -c '/home/malat/highway-1.0.4~git20230308.a1d7764/hwy/tests/convert_test.cc'
[Bug c++/109175] error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109175 --- Comment #3 from Mathieu Malaterre --- Compiling the preprocessed source: % /usr/lib/gcc-snapshot/bin/g++ --verbose -g -fstack-protector-strong -Wformat -Werror=format-security -DHWY_BROKEN_EMU128=0 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE -fvisibility=hidden -fvisibility-inlines-hid den -Wno-builtin-macro-redefined -fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion -Wvla -Wnon-virtual-dtor -fmath-errno -fno-exceptions -Werror -DHWY_IS_TEST=1 -O2 -c 13/convert_test.cc.ii Using built-in specs. COLLECT_GCC=/usr/lib/gcc-snapshot/bin/g++ Target: aarch64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20230315-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr/lib/gcc-snapshot --with-gcc-major-version-only --program-prefix= --enable-shared --enable-linker-build-id --disable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=yes,extra,rtl --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu --with-build-config=bootstrap-lto-lean --enable-link-serialization=2 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.1 20230315 (experimental) [master r13-6680-ga9ae16db8cb] (Debian 20230315-1) COLLECT_GCC_OPTIONS='-v' '-g' '-fstack-protector-strong' '-Wformat=1' '-Werror=format-security' '-D' 'HWY_BROKEN_EMU128=0' '-Wdate-time' '-D' '_FORTIFY_SOURCE=2' '-fPIE' '-fvisibility=hidden' '-fvisibility-inlines-hidden' '-Wno-builtin-macro-redefined' '-fmerge-all-constants' '-Wall' '-Wextra' '-Wconversion' '-Wsign-conversion' '-Wvla' '-Wnon-virtual-dtor' '-fmath-errno' '-fno-exceptions' '-Werror' '-D' 'HWY_IS_TEST=1' '-O2' '-c' '-shared-libgcc' '-mlittle-endian' '-mabi=lp64' /usr/lib/gcc-snapshot/libexec/gcc/aarch64-linux-gnu/13/cc1plus -fpreprocessed 13/convert_test.cc.ii -quiet -dumpbase convert_test.cc.ii -dumpbase-ext .ii -mlittle-endian -mabi=lp64 -g -O2 -Wformat=1 -Werror=format-security -Wdate-time -Wno-builtin-macro-redefined -Wall -Wextra -Wconversion -Wsign-conversion -Wvla -Wnon-virtual-dtor -Werror -version -fstack-protector-strong -fPIE -fvisibility=hidden -fvisibility-inlines-hidden -fmerge-all-constants -fmath-errno -fno-exceptions -o /tmp/ccjFMyE5.s GNU C++17 (Debian 20230315-1) version 13.0.1 20230315 (experimental) [master r13-6680-ga9ae16db8cb] (aarch64-linux-gnu) compiled by GNU C version 13.0.1 20230315 (experimental) [master r13-6680-ga9ae16db8cb], GMP version 6.2.1, MPFR version 4.2.0, MPC version 1.3.1, isl version isl-0.25-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 4bc54a683351612d262139a66d85dce2 In file included from /home/malat/highway-1.0.4~git20230308.a1d7764/hwy/foreach_target.h:114, from /home/malat/highway-1.0.4~git20230308.a1d7764/hwy/tests/convert_test.cc:26: In function 'hwy::AlignedFreeUniquePtr hwy::N_SVE2::F16TestCases(D, size_t&) [with D = Simd]', inlined from 'void hwy::N_SVE2::TestF16::operator()(TF32, DF32) [with TF32 = float; DF32 = hwy::N_SVE2::Simd]' at /home/malat/highway-1.0.4~git20230308.a1d7764/hwy/tests/convert_test.cc:300:10: /home/malat/highway-1.0.4~git20230308.a1d7764/hwy/tests/convert_test.cc:288:11: error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=] 288 | in[i] = 0.0f; In function 'void hwy::N_SVE2::TestF16::operator()(TF32, DF32) [with TF32 = float; DF32 = hwy::N_SVE2::Simd]': cc1plus: note: destination object is likely at address zero In file included from /home/malat/highway-1.0.4~git20230308.a1d7764/hwy/foreach_target.h:103: In function 'hwy::AlignedFreeUniquePtr hwy::N_SVE::F16TestCases(D, size_t&) [with D = Simd]', inlined from 'void hwy::N_SVE::TestF16::operator()(TF32, DF32) [with TF32 = float; DF32 = hwy::N_SVE::Simd]' at /home/malat/highway-1.0.4~git20230308.a1d7764/hwy/tests/convert_test.cc:300:10: /home/malat/highway-1.0.4~git20230308.a1d7764/hwy/tests/convert_test.cc:288:11: error: 'void* __builtin_memset(void*, int, long unsigned int)' writing 4 or more bytes into a region of size 0 overflows the destination [-Werror=stringop-overflow=] 288 | in[i] = 0.0f; In function 'void hwy::N_SVE::TestF16::operator()(TF32, DF32) [with TF32 = float; DF32 = hwy::N_SVE::Simd]': cc1plus: note: destination object is likely at address zero
[Bug c++/109172] [10/11/12/13 Regression] g++ calls a private destructor with the keyword throw after the try-block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109172 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Given that the class is empty, my bet from those two would be on r156842. Anyway, if I add int d; before private: in #c1, it started to be accepted only in r159428 aka DR475 I think (r159421 still rejects, r159430 accepts).
[Bug c++/109168] bogus error: 'X' is not a valid template argument of type 'Y' because 'X' is not a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109168 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Last reconfirmed||2023-03-17 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Marek Polacek --- Not a regression.
[Bug c/109151] UBsan misses a divide-by-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109151 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:103d423f6ce72ccb03d55b7b1dfa2dabd5854371 commit r13-6738-g103d423f6ce72ccb03d55b7b1dfa2dabd5854371 Author: Jakub Jelinek Date: Fri Mar 17 16:10:14 2023 +0100 c, ubsan: Instrument even shortened divisions [PR109151] On the following testcase, the C FE decides to shorten the division because it has a guarantee that INT_MIN / -1 division won't be encountered, the first operand is widened from narrower unsigned and/or the second operand is a constant other than all ones (in this case both are true). The problem is that the narrower type in this case is _Bool and ubsan_instrument_division only instruments it if op0's type is INTEGER_TYPE or REAL_TYPE. Strangely this doesn't happen in C++ FE. Anyway, we only shorten divisions if the INT_MIN / -1 case is impossible, so I think we should be fine even with -fstrict-enums in C++ in case it shortened to ENUMERAL_TYPEs. The following patch just instruments those on the ubsan_instrument_division side. Perhaps only the first hunk and testcase might be needed because we shouldn't shorten if the other case could be triggered. 2023-03-17 Jakub Jelinek PR c/109151 * c-ubsan.cc (ubsan_instrument_division): Handle all scalar integral types rather than just INTEGER_TYPE. * c-c++-common/ubsan/div-by-zero-8.c: New test.
[Bug c++/109169] Feature request: Allow omitted template prompts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109169
--- Comment #6 from steve02081504 ---
Created attachment 54696
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54696&action=edit
temp.cpp
(In reply to Andrew Pinski from comment #4)
> You provide a full example of what you want?
> Because right now your example your provided does not even compile with msvc.
Strangely enough, when I tried to reproduce this requirement, I found that the
sample code I had written would compile.
```c++
#include
template
struct A {
template
static constexpr bool a = ::std::is_base_of_v;
};
template
A a{};
int main() {
return a.a;
}
```
I had no choice but to attach the files I couldn't get to compile and pass in
the attachment.
I didn't understand whether gcc could compile such things or not..
[Bug c++/109169] Feature request: Allow omitted template prompts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109169 steve02081504 changed: What|Removed |Added Version|unknown |12.2.0 --- Comment #7 from steve02081504 --- (error&version info) ```text C:\Users\steve02081504\Documents\workstation\ELC_workdirs\ELC>x86_64-w64-mingw32-g++ -v Using built-in specs. COLLECT_GCC=E:\msys\mingw64\bin\x86_64-w64-mingw32-g++.exe COLLECT_LTO_WRAPPER=E:/msys/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/12.2.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../gcc-12.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/include --libexecdir=/mingw64/lib --enable-bootstrap --enable-checking=release --with-arch=nocona --with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-filesystem-ts --enable-libstdcxx-time --disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-multilib --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev10, Built by MSYS2 project' --with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as --with-gnu-ld --disable-libstdcxx-debug --with-boot-ldflags=-static-libstdc++ --with-stage1-ldflags=-static-libstdc++ Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (Rev10, Built by MSYS2 project) C:\Users\steve02081504\Documents\workstation\ELC_workdirs\ELC>x86_64-w64-mingw32-g++ -x c++ -std=c++23 temp.cpp In file included from .\parts\header_file\files\elc\_files/base_defs/base_defs/_body.hpp:54, from .\parts\header_file\files\elc\_files/base_defs/_body.hpp:53, from .\parts\header_file\files\elc\base_defs:50, from .\parts\header_file\files\elc\random:33: .\parts\header_file\files\elc\_files/base_defs/base_defs/hash.hpp:47:91: error: expected primary-expression before '>' token 47 | concept is_unstable_hash = type_info.can_convert_to; | ^ .\parts\header_file\files\elc\_files/base_defs/base_defs/hash.hpp:47:92: error: expected primary-expression before ';' token 47 | concept is_unstable_hash = type_info.can_convert_to; | ^ In file included from .\parts\header_file\files\elc\_files/base_defs/base_defs/_body.hpp:55: .\parts\header_file\files\elc\_files/base_defs/base_defs/range.hpp:50:74: error: expected primary-expression before '>' token 50 | template requires(type_info.can_convert_to) | ```
[Bug testsuite/105959] new test case c-c++-common/diagnostic-format-sarif-file-4.c from r13-967-g6cf276ddf22066 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959
--- Comment #12 from David Malcolm ---
Thanks for the ideas. If I hack in the following into dg-scan (to force the
scanned file to be treated as UTF-8 as it is read), then the existing case
works with both:
LC_ALL=C
LC_ALL=en_US.UTF-8
so perhaps I can do this just for scan-sarif-file
diff --git a/gcc/testsuite/lib/scanasm.exp b/gcc/testsuite/lib/scanasm.exp
index 4b018abcf3d..828002bf6e1 100644
--- a/gcc/testsuite/lib/scanasm.exp
+++ b/gcc/testsuite/lib/scanasm.exp
@@ -59,6 +59,7 @@ proc dg-scan { name positive testcase output_file orig_args }
{
return
}
set fd [open $output_file r]
+fconfigure $fd -encoding utf-8
set text [read $fd]
close $fd
[Bug c++/109176] New: internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109176
Bug ID: 109176
Summary: internal compiler error: in to_constant, at
poly-int.h:504
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: malat at debian dot org
Target Milestone: ---
I cannot compile highway on arm64 with gcc-13 anymore.
Compilation fais with:
/home/malat/h/highway/hwy/tests/mask_test.cc:230:21: internal compiler error:
in to_constant, at poly-int.h:504
230 | HWY_NOINLINE void operator()(T /*unused*/, D d) {
| ^~~~
0x6a06eb poly_int_pod<2u, unsigned long>::to_constant() const [clone .part.0]
[clone .lto_priv.0]
../../src/gcc/poly-int.h:504
0xf5057b poly_int_pod<2u, unsigned long>::to_constant() const
../../src/gcc/poly-int.h:502
0x9451c3 nunits_for_known_piecewise_op
../../src/gcc/tree-vect-generic.cc:92
0x1e1b803 expand_vector_condition
../../src/gcc/tree-vect-generic.cc:1120
0x1a4b67b expand_vector_operations_1
../../src/gcc/tree-vect-generic.cc:2122
0x1a4b67b expand_vector_operations
../../src/gcc/tree-vect-generic.cc:2382
0x1a4b67b execute
../../src/gcc/tree-vect-generic.cc:2479
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
ref:
*
https://buildd.debian.org/status/fetch.php?pkg=highway&arch=arm64&ver=1.0.4%7Egit20230317.8681eb8-1&stamp=1679067803&raw=0
[Bug c++/109169] Feature request: Allow omitted template prompts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109169 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #8 from Andrew Pinski --- Yes we are not going to add a feature where template keyword can be omitted. The reason is type_info.can_convert_to; Cis being parsed thinking < here is less than which is correct.
[Bug c++/109177] New: Call to C++ function marked unavailable gets diagnosed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109177
Bug ID: 109177
Summary: Call to C++ function marked unavailable gets diagnosed
twice
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
Reproducer:
$ cat t.cc
void f() __attribute__((unavailable));
void g() { f(); }
$ gcc/xgcc -B gcc -c t.cc
t.cc: In function ‘void g()’:
t.cc:2:13: error: ‘void f()’ is unavailable
2 | void g() { f(); }
|~^~
t.cc:1:6: note: declared here
1 | void f() __attribute__((unavailable));
| ^
t.cc:2:13: error: ‘void f()’ is unavailable
2 | void g() { f(); }
|~^~
t.cc:1:6: note: declared here
1 | void f() __attribute__((unavailable));
| ^
This only seems to happen in C++ mode, C diagnoses this once as expected.
[Bug c++/109176] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109176 --- Comment #1 from Mathieu Malaterre --- Created attachment 54697 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54697&action=edit Preprocessed source gcc-13 % /usr/lib/gcc-snapshot/bin/g++ -freport-bug -DHWY_STATIC_DEFINE -I/home/malat/h/highway -O2 -g -DNDEBUG -fPIE -fvisibility=hidden -fvisibility-inlines-hidden -Wno-builtin-macro-redefined -D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\" -fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion -Wvla -Wnon-virtual-dtor -fmath-errno -fno-exceptions -DHWY_IS_TEST=1 -DGTEST_HAS_PTHREAD=1 -MD -MT CMakeFiles/mask_test.dir/hwy/tests/mask_test.cc.o -MF CMakeFiles/mask_test.dir/hwy/tests/mask_test.cc.o.d -o CMakeFiles/mask_test.dir/hwy/tests/mask_test.cc.o -c /home/malat/h/highway/hwy/tests/mask_test.cc
[Bug tree-optimization/108419] [13 Regression] Dead Code Elimination Regression at -O2 since r13-440-g98e475a8f58
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108419
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Slightly cleaned up testcase:
static int b = 6, c;
long d;
short h, i, j;
signed char k;
void foo (void);
short baz (int, int, int, int, int, int, int);
short qux (unsigned short, int, char, long);
short
bar (short l, short m)
{
return l + m;
}
static signed char
corge (void)
{
unsigned n;
for (n = -10U; n >= 14; n = bar (n, 8))
{
i = qux (b, 0, c, b);
j = baz (i, b, d < j, 5, 7, 9, 5);
k = 200 + n;
h = k % 5;
if (!h)
foo ();
}
return n;
}
int
main ()
{
b || corge ();
b = 1;
}
The loop iterates twice, with n -10U and -2U, in third iteration 6U fails the
6U >= 14 condition.
In GCC 12 as well as in r13-439 and r13-440 the loop IV is
# ivtmp.30_42 = PHI
and loop condition is
ivtmp.30_34 = ivtmp.30_42 + 8;
if (ivtmp.30_34 != 206)
while trunk has 2 IVs:
# RANGE [irange] unsigned int [38, 32767][4294934528, +INF] NONZERO
0xfffe
# n_32 = PHI
# RANGE [irange] unsigned int [1, +INF]
# ivtmp_2 = PHI
and
# RANGE [irange] unsigned short [30, +INF] NONZERO 0xfffe
l.0_27 = (unsigned short) n_32;
# RANGE [irange] unsigned short [0, 7][38, +INF] NONZERO 0xfffe
_28 = l.0_27 + 8;
# RANGE [irange] short int [-INF, 7][38, +INF] NONZERO 0xfffe
_29 = (short int) _28;
# RANGE [irange] unsigned int [0, 7][38, 32767][4294934528, +INF] NONZERO
0xfffe
n_30 = (unsigned int) _29;
ivtmp_43 = ivtmp_2 - 1;
if (ivtmp_43 != 0)
The r13-440 regression is in vrp2, previously we were able to determine that
because ivtmp.30_42 is [190, 190][198, 198]
then (signed char) of that is [-66, -66][-58, -58] and that % 5 is [-3, -3][-1,
-1].
Folding statement: _24 = (signed char) ivtmp.30_42;
- Loops range found for ivtmp.30_42: unsigned char [190, 198] and calculated
range :unsigned char [190, 190][198, 205]
-Global Exported: _24 = signed char [-66, -58] ... irange was : signed char
[-66, -66][-58, -58]
+Global Exported: _24 = signed char [-66, -58]
Not folded
Folding statement: k = _24;
Not folded
Folding statement: _25 = _24 % 5;
-Global Exported: _25 = signed char [-3, -1] ... irange was : signed char [-3,
-3][-1, -1]
+Global Exported: _25 = signed char [-4, 0]
is the first difference in the vrp2 dump between r13-439 and r13-440.
The other major change is starting with r13-3486-g4c5b1160776382772 when ivopts
uses the 2 IVs rather than one
and the convoluted increment by 8. It is actually only a normal increment by 8
if n_32 is in [0, 32759][-32777U, -1U]
but that is actually the case here.
I think the ranger doesn't iterate, right? So is there any way that it would
figure out the exact range for the IV?
[Bug tree-optimization/109176] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109176 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||ktkachov at gcc dot gnu.org Target Milestone|--- |13.0 Ever confirmed|0 |1 Last reconfirmed||2023-03-17 --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed. Running reduction
[Bug c++/109168] bogus error: 'X' is not a valid template argument of type 'Y' because 'X' is not a variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109168 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 97700. *** This bug has been marked as a duplicate of bug 97700 ***
[Bug c++/97700] Bogus error when a class containing a function pointer is used as a non-type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97700 Andrew Pinski changed: What|Removed |Added CC||waffl3x at protonmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 109168 has been marked as a duplicate of this bug. ***
[Bug target/105554] [10/11/12/13 Regression] ICE: in emit_block_move_hints, at expr.cc:1829 since r9-5509-g5928bc2ec06dd4e7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554
--- Comment #21 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:24c06560a7fa39049911eeb8777325d112e0deb9
commit r13-6739-g24c06560a7fa39049911eeb8777325d112e0deb9
Author: Jakub Jelinek
Date: Fri Mar 17 18:59:56 2023 +0100
tree-inline: Fix up multiversioning with vector arguments [PR105554]
The following testcase ICEs, because we call tree_function_versioning from
old_decl which has target attributes not supporting V4DImode and so
DECL_MODE of DECL_ARGUMENTS is BLKmode, while new_decl supports those.
tree_function_versioning initially copies DECL_RESULT and DECL_ARGUMENTS
from old_decl to new_decl, then calls initialize_cfun to create cfun
and only when the cfun is created it can later actually remap_decl
DECL_RESULT and DECL_ARGUMENTS etc.
The problem is that initialize_cfun -> push_struct_function ->
allocate_struct_function calls relayout_decl on DECL_RESULT and
DECL_ARGUMENTS, which clobbers DECL_MODE of old_decl and we then ICE
because
of it.
In particular, allocate_struct_function does:
if (!abstract_p)
{
/* Now that we have activated any function-specific attributes
that might affect layout, particularly vector modes, relayout
each of the parameters and the result. */
relayout_decl (result);
for (tree parm = DECL_ARGUMENTS (fndecl); parm;
parm = DECL_CHAIN (parm))
relayout_decl (parm);
/* Similarly relayout the function decl. */
targetm.target_option.relayout_function (fndecl);
}
if (!abstract_p && aggregate_value_p (result, fndecl))
{
#ifdef PCC_STATIC_STRUCT_RETURN
cfun->returns_pcc_struct = 1;
#endif
cfun->returns_struct = 1;
}
Now, in the case of tree_function_versioning, I believe all that we need
from these is possibly the
targetm.target_option.relayout_function (fndecl);
call (arm only), we will remap DECL_RESULT and DECL_ARGUMENTS later on
and copy_decl_for_dup_finish in that case will handle all we need:
/* For vector typed decls make sure to update DECL_MODE according
to the new function context. */
if (VECTOR_TYPE_P (TREE_TYPE (copy)))
SET_DECL_MODE (copy, TYPE_MODE (TREE_TYPE (copy)));
We don't need the cfun->returns_*struct either, because we override it
in initialize_cfun a few lines later:
/* Copy items we preserve during cloning. */
...
cfun->returns_struct = src_cfun->returns_struct;
cfun->returns_pcc_struct = src_cfun->returns_pcc_struct;
So, to avoid the clobbering of DECL_RESULT/DECL_ARGUMENTS of old_decl,
the following patch arranges allocate_struct_function to be called with
abstract_p true and calls targetm.target_option.relayout_function (fndecl);
by hand.
The removal of DECL_RESULT/DECL_ARGUMENTS copying at the start of
initialize_cfun is removed because the only caller -
tree_function_versioning, does that unconditionally before.
2023-03-17 Jakub Jelinek
PR target/105554
* function.h (push_struct_function): Add ABSTRACT_P argument
defaulted
to false.
* function.cc (push_struct_function): Add ABSTRACT_P argument, pass
it
to allocate_struct_function instead of false.
* tree-inline.cc (initialize_cfun): Don't copy DECL_ARGUMENTS
nor DECL_RESULT here. Pass true as ABSTRACT_P to
push_struct_function. Call targetm.target_option.relayout_function
after it.
(tree_function_versioning): Formatting fix.
* gcc.target/i386/pr105554.c: New test.
[Bug target/105554] [10/11/12 Regression] ICE: in emit_block_move_hints, at expr.cc:1829 since r9-5509-g5928bc2ec06dd4e7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105554 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED Summary|[10/11/12/13 Regression]|[10/11/12 Regression] ICE: |ICE: in |in emit_block_move_hints, |emit_block_move_hints, at |at expr.cc:1829 since |expr.cc:1829 since |r9-5509-g5928bc2ec06dd4e7 |r9-5509-g5928bc2ec06dd4e7 | --- Comment #22 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/108419] [13 Regression] Dead Code Elimination Regression at -O2 since r13-440-g98e475a8f58
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108419 --- Comment #4 from Andrew Macleod --- Not easily. I have started working on a phi analyzer for ranger to assist with various issues like this. It will analyze phi patterns to weed out the ssa-names that are just copies, and then allow the few remaining ssa-names that actually change the values in the phi seqeuence to be looked at more easily. It will help develop better initial ranges. So cases where the non-phi names are starting value and an increment or decrement can start with something better than VARYING. This will help with cases like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107986 It can help identify cases where values will have restricted smallish ranges, such as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107822. Cases like this one with the second IV are trickier as there isnt a relation to dicover between the two IVs... at leats not easily. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107639 is a case like that too I think. When there are 2 IVs I dont suppose there is any way to indicate there is a connection? then if we can end up counting one, we might be able to do something with the other.
[Bug target/109178] New: ICE using __builtin_vec_xst_trunc built-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109178
Bug ID: 109178
Summary: ICE using __builtin_vec_xst_trunc built-in
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
We ICE on the following simple test case. This ICEs on trunk and GCC 12 and
works on GCC 11 and earlier.
bergner@ltcden2-lp1:~$ cat bug.c
#include
void
foo (signed int *dst, vector signed __int128 src)
{
__builtin_vec_xst_trunc(src, 0, dst);
}
bergner@ltcden2-lp1:~$ gcc -S -O2 -mcpu=power10 bug.c
bug.c: In function ‘foo’:
bug.c:7:1: error: unrecognizable insn:
7 | }
| ^
(insn 9 8 0 2 (set (mem:DI (reg:DI 119) [0 S8 A8])
(truncate:SI (reg:TI 120))) "bug4.c":6:3 -1
(nil))
during RTL pass: vregs
bug.c:7:1: internal compiler error: in extract_insn, at recog.cc:2791
The above should be mem:SI and is caused by a typo in the rs6000 built-in
rewrite in GCC 12. I have a patch I'm testing.
[Bug target/109178] ICE using __builtin_vec_xst_trunc built-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109178 Peter Bergner changed: What|Removed |Added CC||chip.kerchner at ibm dot com, ||segher at gcc dot gnu.org Target Milestone|--- |13.0 Last reconfirmed||2023-03-17 Keywords||ice-on-valid-code Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Target||powerpc*-*-* Assignee|unassigned at gcc dot gnu.org |bergner at gcc dot gnu.org --- Comment #1 from Peter Bergner --- Mine.
[Bug testsuite/105959] new test case c-c++-common/diagnostic-format-sarif-file-4.c from r13-967-g6cf276ddf22066 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105959 --- Comment #13 from David Malcolm --- Created attachment 54698 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54698&action=edit Patch that I'm about to put through full testing
[Bug target/109178] ICE using __builtin_vec_xst_trunc built-in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109178 Peter Bergner changed: What|Removed |Added Known to work|10.0, 11.0 | --- Comment #2 from Peter Bergner --- (In reply to Peter Bergner from comment #0) > This ICEs on trunk and GCC 12 and works on GCC 11 and earlier. My bad. The built-in is new in GCC 12, so not a regression.
[Bug c++/69410] [10/11/12/13 Regression] friend declarations in local classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69410 --- Comment #11 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ae7190e345a8d80310835cb83b3b41ef2aeb0d37 commit r13-6740-gae7190e345a8d80310835cb83b3b41ef2aeb0d37 Author: Jason Merrill Date: Fri Mar 17 09:43:48 2023 -0400 c++: namespace-scoped friend in local class [PR69410] do_friend was only considering class-qualified identifiers for the qualified-id case, but we also need to skip local scope when there's an explicit namespace scope. PR c++/69410 gcc/cp/ChangeLog: * friend.cc (do_friend): Handle namespace as scope argument. * decl.cc (grokdeclarator): Pass down in_namespace. gcc/testsuite/ChangeLog: * g++.dg/lookup/friend24.C: New test.
[Bug c++/69410] [10/11/12 Regression] friend declarations in local classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69410 --- Comment #12 from Jason Merrill --- (In reply to Zopolis0 from comment #8) Thanks for your work on this bug!
[Bug c++/109172] [10/11/12/13 Regression] g++ calls a private destructor with the keyword throw after the try-block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109172 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug target/109179] New: addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 Bug ID: 109179 Summary: addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0' Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bergner at gcc dot gnu.org Target Milestone: --- A new bootstrap ICE on trunk. Setting component to target until I narrow down the change that caused it. during RTL pass: reload addkf3-sw.c: In function ‘__addkf3_sw’: addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0' (rtx note) in PATTERN, at rtl.h:1509 51 | } | ^ 0x1148c663 rtl_check_failed_type2(rtx_def const*, int, int, int, char const*, int, char const*) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/rtl.cc:907 0x10a0a207 PATTERN(rtx_def*) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/rtl.h:1509 0x1278c12b insn_extract(rtx_insn*) /home/bergner/gcc/build/gcc-fsf-mainline-chip-ice-base-regtest/gcc/insn-extract.cc:23 0x1118c9e7 lra_set_insn_recog_data(rtx_insn*) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/lra.cc:1059 0x11194f23 lra_get_insn_recog_data(rtx_insn*) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/lra-int.h:493 0x111b8de7 combine_reload_insn /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/lra-constraints.cc:5017 0x111b9e4b lra_constraints(bool) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/lra-constraints.cc:5231 0x111942a3 lra(_IO_FILE*) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/lra.cc:2375 0x110fdd77 do_reload /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/ira.cc:5963 0x110fe5df execute /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/ira.cc:6149
[Bug target/109179] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 Peter Bergner changed: What|Removed |Added Last reconfirmed||2023-03-17 Keywords||ice-checking Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target||powerpc64le-linux Target Milestone|--- |13.0
[Bug target/109179] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #1 from Peter Bergner --- Vlad's recent commit looks like a promising candidate though: commit 57688950b9328cbb4a9c21eb3199f9132b5119d3 Author: Vladimir N. Makarov AuthorDate: Fri Mar 17 08:58:58 2023 -0400 Commit: Vladimir N. Makarov CommitDate: Fri Mar 17 09:07:20 2023 -0400 LRA: Implement combining secondary memory reload and original insn LRA creates secondary memory reload insns but do not try to combine it with the original insn. This patch implements a simple insn combining for such cases in LRA. PR rtl-optimization/109052 gcc/ChangeLog: * lra-constraints.cc: Include hooks.h. (combine_reload_insn): New function. (lra_constraints): Call it. gcc/testsuite/ChangeLog: * gcc.target/i386/pr109052.c: New. I'm building with the commit before this to see whether we succeed or not.
[Bug rtl-optimization/109052] Unnecessary reload with -mfpmath=both
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109052 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #7 from Peter Bergner --- (In reply to Vladimir Makarov from comment #6) > I'd like to watch what the effect of the current patch would be first. > Although I tested the patch on many targets as usually for LRA the patch > might result in some troubles on some targets. But I hope nothing bad will > happen. I hit a bootstrap issue on powerpc64le-linux and it looks (still confirming) that this is probably the patch that caused it, since we're ICEing in your new combine_reload_insn() function. I opened PR109179 for the ICE. during RTL pass: reload addkf3-sw.c: In function ‘__addkf3_sw’: addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0' (rtx note) in PATTERN, at rtl.h:1509 51 | } | ^ 0x1148c663 rtl_check_failed_type2(rtx_def const*, int, int, int, char const*, int, char const*) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/rtl.cc:907 0x10a0a207 PATTERN(rtx_def*) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/rtl.h:1509 0x1278c12b insn_extract(rtx_insn*) /home/bergner/gcc/build/gcc-fsf-mainline-chip-ice-base-regtest/gcc/insn-extract.cc:23 0x1118c9e7 lra_set_insn_recog_data(rtx_insn*) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/lra.cc:1059 0x11194f23 lra_get_insn_recog_data(rtx_insn*) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/lra-int.h:493 0x111b8de7 combine_reload_insn /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/lra-constraints.cc:5017 0x111b9e4b lra_constraints(bool) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/lra-constraints.cc:5231 0x111942a3 lra(_IO_FILE*) /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/lra.cc:2375 0x110fdd77 do_reload /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/ira.cc:5963 0x110fe5df execute /home/bergner/gcc/gcc-fsf-mainline-chip-ice-base/gcc/ira.cc:6149
[Bug target/109179] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #2 from Peter Bergner --- (In reply to Peter Bergner from comment #1) > Vlad's recent commit looks like a promising candidate though: [snip] > I'm building with the commit before this to see whether we succeed or not. Bootstrap is into stage3 and we died in stage1 before, so I'm confident it is Vlad's commit.
[Bug target/109179] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #3 from Peter Bergner --- The ICE is occurring with: Breakpoint 2, internal_error (gmsgid=0x1351b738 "RTL check: expected elt %d type '%c' or '%c', have '%c' (rtx %s) in %s, at %s:%d") at /home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/diagnostic.cc:2152 2152 auto_diagnostic_group d; (gdb) bt #0 internal_error (gmsgid=0x1351b738 "RTL check: expected elt %d type '%c' or '%c', have '%c' (rtx %s) in %s, at %s:%d") at /home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/diagnostic.cc:2152 #1 0x114dbcd4 in rtl_check_failed_type2 (r=0x75770340, n=3, c1=101, c2=117, file=0x134813c0 "/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/rtl.h", line=1509, func=0x13481f80 "PATTERN") at /home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/rtl.cc:907 #2 0x10a18f70 in PATTERN (insn=0x75770340) at /home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/rtl.h:1509 #3 0x12853b2c in insn_extract (insn=0x75770340) at insn-extract.cc:23 #4 0x111c54c4 in lra_set_insn_recog_data (insn=0x75770340) at /home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/lra.cc:1059 #5 0x111ce070 in lra_get_insn_recog_data (insn=0x75770340) at /home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/lra-int.h:493 #6 0x111f2e64 in combine_reload_insn (from=0x75770500, to=0x75770340) at /home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/lra-constraints.cc:5017 ... (gdb) frame 3 #3 0x12853b2c in insn_extract (insn=0x75770340) at insn-extract.cc:23 23rtx pat = PATTERN (insn); (gdb) pr insn (note 9 19 13 2 NOTE_INSN_DELETED)
[Bug target/109179] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179
--- Comment #4 from Peter Bergner ---
...on the following minimal test case:
bergner@ltcden2-lp1:PR109179$ cat bug.i
__int128 var;
__int128
foo (void)
{
return var;
}
bergner@ltcden2-lp1:PR109179$
/home/bergner/gcc/build/gcc-fsf-mainline-chip-ice-debug/./gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-chip-ice-debug/./gcc/ -S -O0
-mcpu=power8 bug.i
during RTL pass: reload
bug.i: In function ‘foo’:
bug.i:6:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u',
have '0' (rtx note) in PATTERN, at rtl.h:1509
6 | }
| ^
0x114dbcd3 rtl_check_failed_type2(rtx_def const*, int, int, int, char const*,
int, char const*)
/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/rtl.cc:907
0x10a18f6f PATTERN(rtx_def*)
/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/rtl.h:1509
0x12853b2b insn_extract(rtx_insn*)
/home/bergner/gcc/build/gcc-fsf-mainline-chip-ice-debug/gcc/insn-extract.cc:23
0x111c54c3 lra_set_insn_recog_data(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/lra.cc:1059
0x111ce06f lra_get_insn_recog_data(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/lra-int.h:493
0x111f2e63 combine_reload_insn
/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/lra-constraints.cc:5017
[Bug rtl-optimization/109179] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179
--- Comment #5 from Peter Bergner ---
The "from" and "to" arguments to combine_reload_insn() are:
(gdb) pr from
(insn 19 17 9 2 (parallel [
(set (reg:TI 118 [ ])
(unspec:TI [
(reg:TI 117 [ _2 ])
] UNSPEC_P8V_RELOAD_FROM_VSX))
(clobber (reg:TI 123))
]) "bug.i":5:10 discrim 1 669 {reload_gpr_from_vsxti}
(nil))
(gdb) pr to
(note 9 19 13 2 NOTE_INSN_DELETED)
[Bug rtl-optimization/109179] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #6 from Vladimir Makarov --- Peter, thank you for reporting. I'll try to fix it today or revert it.
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 Andrew Pinski changed: What|Removed |Added Severity|normal |blocker Keywords||build, ice-on-valid-code Summary|addkf3-sw.c:51:1: internal |[13 Regression] |compiler error: RTL check: |addkf3-sw.c:51:1: internal |expected elt 3 type 'e' or |compiler error: RTL check: |'u', have '0' |expected elt 3 type 'e' or ||'u', have '0'
[Bug libstdc++/109165] std::hash>::operator() should be const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109165 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c48be8298c27143c1a684c0cb9689c88d16f4b49 commit r13-6741-gc48be8298c27143c1a684c0cb9689c88d16f4b49 Author: Jonathan Wakely Date: Fri Mar 17 11:39:55 2023 + libstdc++: Add const to hash>::operator() [PR109165] libstdc++-v3/ChangeLog: PR libstdc++/109165 * include/std/coroutine (hash<>::operator()): Add const. * testsuite/18_support/coroutines/hash.cc: New test.
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #7 from Jakub Jelinek --- So perhaps: --- gcc/lra-constraints.cc.jj 2023-03-17 16:09:09.162136438 +0100 +++ gcc/lra-constraints.cc 2023-03-17 21:37:04.799285670 +0100 @@ -5020,7 +5020,9 @@ combine_reload_insn (rtx_insn *from, rtx /* Check conditions for second memory reload and original insn: */ if ((targetm.secondary_memory_needed == hook_bool_mode_reg_class_t_reg_class_t_false) - || NEXT_INSN (from) != to || CALL_P (to) + || NEXT_INSN (from) != to + || !NONDEBUG_INSN_P (to) + || CALL_P (to) || id->used_insn_alternative == LRA_UNKNOWN_ALT || (set = single_set (from)) == NULL_RTX) return false; ?
[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 Last reconfirmed||2023-03-17 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||wrong-code --- Comment #2 from anlauf at gcc dot gnu.org --- Confirmed. I also have the gut feeling that there is a duplicate. It appears that we do not initialize the pointer. Consider: program boom use, intrinsic :: iso_c_binding, only: c_loc implicit none complex, save, target :: a(4) = [(1.,0.), (2.,0.), (3.,0.), (4.,0.)] real, pointer :: p(:) => a(1:3:2)%re real, pointer :: q(:) q => a(1:3:2)%re print *, "size (p) =", size (p) print *, "size (q) =", size (q) print *, "c_loc(p(1)), c_loc(p(2)) =", c_loc(p(1)), c_loc(p(2)) print *, "c_loc(q(1)), c_loc(q(2)) =", c_loc(q(1)), c_loc(q(2)) ! print *, p ! this segfaults print *, q end program boom This prints e.g. size (p) = 1 size (q) = 2 c_loc(p(1)), c_loc(p(2)) =00 c_loc(q(1)), c_loc(q(2)) = 4202592 4202608 1. 3. Crayftn 14.0 (the only compiler that I found to work here): size (p) = 2 size (q) = 2 c_loc(p(1)), c_loc(p(2)) = 4210816, 4210832 c_loc(q(1)), c_loc(q(2)) = 4210816, 4210832 1., 3.
[Bug fortran/104332] [10/11/12/13 Regression] ICE in resolve_symbol, at fortran/resolve.cc:15815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104332 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:7ce83edf8ebbbc21b20aeed3a3ab06bb2e9e02cb commit r11-10583-g7ce83edf8ebbbc21b20aeed3a3ab06bb2e9e02cb Author: Harald Anlauf Date: Thu Mar 9 18:59:08 2023 +0100 Fortran: fix ICE with bind(c) in block data [PR104332] gcc/fortran/ChangeLog: PR fortran/104332 * resolve.c (resolve_symbol): Avoid NULL pointer dereference while checking a symbol with the BIND(C) attribute. gcc/testsuite/ChangeLog: PR fortran/104332 * gfortran.dg/bind_c_usage_34.f90: New test. (cherry picked from commit e20e5d9dc11b64e8eabce6803c91cb5768207083)
[Bug fortran/104332] [10/11/12/13 Regression] ICE in resolve_symbol, at fortran/resolve.cc:15815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104332 --- Comment #12 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c5cb9d8819eb9551d23f77e63cb3399115f0aab8 commit r10-11255-gc5cb9d8819eb9551d23f77e63cb3399115f0aab8 Author: Harald Anlauf Date: Thu Mar 9 18:59:08 2023 +0100 Fortran: fix ICE with bind(c) in block data [PR104332] gcc/fortran/ChangeLog: PR fortran/104332 * resolve.c (resolve_symbol): Avoid NULL pointer dereference while checking a symbol with the BIND(C) attribute. gcc/testsuite/ChangeLog: PR fortran/104332 * gfortran.dg/bind_c_usage_34.f90: New test. (cherry picked from commit e20e5d9dc11b64e8eabce6803c91cb5768207083)
[Bug fortran/106945] [10/11/12/13 Regression] ICE: 'verify_gimple' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106945 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f68f0e69d988ca999c09953811f3cc722f114677 commit r11-10584-gf68f0e69d988ca999c09953811f3cc722f114677 Author: Harald Anlauf Date: Sat Mar 11 15:37:37 2023 +0100 Fortran: fix bounds check for copying of class expressions [PR106945] In the bounds check for copying of class expressions, the number of elements determined from a descriptor, returned as type gfc_array_index_type (i.e. a signed type), should be converted to the type of the passed element count, which is of type size_type_node (i.e. unsigned), for use in comparisons. gcc/fortran/ChangeLog: PR fortran/106945 * trans-expr.c (gfc_copy_class_to_class): Convert element counts in bounds check to common type for comparison. gcc/testsuite/ChangeLog: PR fortran/106945 * gfortran.dg/pr106945.f90: New test. (cherry picked from commit 2cf5f485e0351bb1faf46196a99e524688f3966e)
[Bug fortran/106945] [10/11/12/13 Regression] ICE: 'verify_gimple' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106945 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:3cca6b5fa51fd271644082761de85e89fd56d69c commit r10-11256-g3cca6b5fa51fd271644082761de85e89fd56d69c Author: Harald Anlauf Date: Sat Mar 11 15:37:37 2023 +0100 Fortran: fix bounds check for copying of class expressions [PR106945] In the bounds check for copying of class expressions, the number of elements determined from a descriptor, returned as type gfc_array_index_type (i.e. a signed type), should be converted to the type of the passed element count, which is of type size_type_node (i.e. unsigned), for use in comparisons. gcc/fortran/ChangeLog: PR fortran/106945 * trans-expr.c (gfc_copy_class_to_class): Convert element counts in bounds check to common type for comparison. gcc/testsuite/ChangeLog: PR fortran/106945 * gfortran.dg/pr106945.f90: New test. (cherry picked from commit 2cf5f485e0351bb1faf46196a99e524688f3966e)
[Bug fortran/104332] [10/11/12/13 Regression] ICE in resolve_symbol, at fortran/resolve.cc:15815
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104332 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/106945] [10/11/12/13 Regression] ICE: 'verify_gimple' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106945 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179
--- Comment #8 from Peter Bergner ---
Here's another creduced test case, this one with -O2 optimization:
bergner@ltcden2-lp1:PR109179$ cat bug2.i
union u
{
_Float128 flt;
long sign;
};
_Float128
foo (long src)
{
union u var;
var.sign = src;
return var.flt;
}
bergner@ltcden2-lp1:PR109179$ gcc -S -O2 -mcpu=power8 bug2.i
during RTL pass: reload
bug2.i: In function ‘foo’:
bug2.i:13:1: internal compiler error: RTL check: expected elt 3 type 'e' or
'u', have '0' (rtx note) in PATTERN, at rtl.h:1509
13 | }
| ^
0x1148c663 rtl_check_failed_type2(rtx_def const*, int, int, int, char const*,
int, char const*)
/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/rtl.cc:907
0x10a0a207 PATTERN(rtx_def*)
/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/rtl.h:1509
0x1278c123 insn_extract(rtx_insn*)
/home/bergner/gcc/build/gcc-fsf-mainline-chip-ice-regtest/gcc/insn-extract.cc:23
0x1118c9e7 lra_set_insn_recog_data(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/lra.cc:1059
0x11194f23 lra_get_insn_recog_data(rtx_insn*)
/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/lra-int.h:493
0x111b8de7 combine_reload_insn
/home/bergner/gcc/gcc-fsf-mainline-chip-ice/gcc/lra-constraints.cc:5017
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #9 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #7) > So perhaps: > --- gcc/lra-constraints.cc.jj 2023-03-17 16:09:09.162136438 +0100 > +++ gcc/lra-constraints.cc2023-03-17 21:37:04.799285670 +0100 > @@ -5020,7 +5020,9 @@ combine_reload_insn (rtx_insn *from, rtx >/* Check conditions for second memory reload and original insn: */ >if ((targetm.secondary_memory_needed > == hook_bool_mode_reg_class_t_reg_class_t_false) > - || NEXT_INSN (from) != to || CALL_P (to) > + || NEXT_INSN (from) != to > + || !NONDEBUG_INSN_P (to) > + || CALL_P (to) >|| id->used_insn_alternative == LRA_UNKNOWN_ALT >|| (set = single_set (from)) == NULL_RTX) > return false; > ? Yes, that is what I am trying to do. For me only question why is LRA works there on notes. LRA pushes only real insns to work stack.
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #10 from Peter Bergner --- (In reply to Jakub Jelinek from comment #7) > So perhaps: > --- gcc/lra-constraints.cc.jj 2023-03-17 16:09:09.162136438 +0100 > +++ gcc/lra-constraints.cc2023-03-17 21:37:04.799285670 +0100 > @@ -5020,7 +5020,9 @@ combine_reload_insn (rtx_insn *from, rtx >/* Check conditions for second memory reload and original insn: */ >if ((targetm.secondary_memory_needed > == hook_bool_mode_reg_class_t_reg_class_t_false) > - || NEXT_INSN (from) != to || CALL_P (to) > + || NEXT_INSN (from) != to > + || !NONDEBUG_INSN_P (to) > + || CALL_P (to) >|| id->used_insn_alternative == LRA_UNKNOWN_ALT >|| (set = single_set (from)) == NULL_RTX) > return false; > ? I can give this try. Although it would be good to know from Vlad whether it's invalid to ever pass a debug insn to combine_reload_insn() or not.
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek --- But in this case it has been removed in between: #0 set_insn_deleted (insn=0x7fffea13a340) at ../../gcc/emit-rtl.cc:4257 #1 0x00ac7d3e in lra_set_insn_deleted (insn=0x7fffea13a340) at ../../gcc/lra.cc:263 #2 0x00ad8de8 in check_and_process_move (change_p=0x7fffd26f, sec_mem_p=0x7fffd26e) at ../../gcc/lra-constraints.cc:1400 #3 0x00ae0034 in curr_insn_transform (check_only_p=false) at ../../gcc/lra-constraints.cc:4130 #4 0x00ae41d3 in lra_constraints (first_p=true) at ../../gcc/lra-constraints.cc:5314
[Bug other/109163] SARIF (and other JSON) output files are non-deterministic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109163 David Malcolm changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-March/6 ||14165.html Keywords||patch Status|ASSIGNED|WAITING --- Comment #3 from David Malcolm --- Patch posted for review: [PATCH] json: preserve key-insertion order [PR109163] https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614165.html
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #12 from Peter Bergner --- (In reply to Jakub Jelinek from comment #7) > So perhaps: > --- gcc/lra-constraints.cc.jj 2023-03-17 16:09:09.162136438 +0100 > +++ gcc/lra-constraints.cc2023-03-17 21:37:04.799285670 +0100 > @@ -5020,7 +5020,9 @@ combine_reload_insn (rtx_insn *from, rtx >/* Check conditions for second memory reload and original insn: */ >if ((targetm.secondary_memory_needed > == hook_bool_mode_reg_class_t_reg_class_t_false) > - || NEXT_INSN (from) != to || CALL_P (to) > + || NEXT_INSN (from) != to > + || !NONDEBUG_INSN_P (to) > + || CALL_P (to) >|| id->used_insn_alternative == LRA_UNKNOWN_ALT >|| (set = single_set (from)) == NULL_RTX) > return false; > ? This doesn't work as is, since the ICE is occurring on code before we get here in the function. Specifically here: lra_insn_recog_data_t id = lra_get_insn_recog_data (to); I'll try moving the test up earlier and testing with that.
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #13 from Peter Bergner --- (In reply to Peter Bergner from comment #12) > I'll try moving the test up earlier and testing with that. So this fixes the ICEs on the two test cases above. I'll try a full bootstrap with it. --- a/gcc/lra-constraints.cc +++ b/gcc/lra-constraints.cc @@ -5014,6 +5014,10 @@ combine_reload_insn (rtx_insn *from, rtx_insn *to) enum reg_class to_class, from_class; int n, nop; signed char changed_nops[MAX_RECOG_OPERANDS + 1]; + + if (!NONDEBUG_INSN_P (to)) +return false; + lra_insn_recog_data_t id = lra_get_insn_recog_data (to); struct lra_static_insn_data *static_id = id->insn_static_data;
[Bug rtl-optimization/109179] [13 Regression] addkf3-sw.c:51:1: internal compiler error: RTL check: expected elt 3 type 'e' or 'u', have '0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109179 --- Comment #14 from Vladimir Makarov --- (In reply to Peter Bergner from comment #13) > (In reply to Peter Bergner from comment #12) > > I'll try moving the test up earlier and testing with that. > > So this fixes the ICEs on the two test cases above. I'll try a full > bootstrap with it. > > --- a/gcc/lra-constraints.cc > +++ b/gcc/lra-constraints.cc > @@ -5014,6 +5014,10 @@ combine_reload_insn (rtx_insn *from, rtx_insn *to) >enum reg_class to_class, from_class; >int n, nop; >signed char changed_nops[MAX_RECOG_OPERANDS + 1]; > + > + if (!NONDEBUG_INSN_P (to)) > +return false; > + >lra_insn_recog_data_t id = lra_get_insn_recog_data (to); >struct lra_static_insn_data *static_id = id->insn_static_data; Peter, sorry for troubles and thank you for working on it. The patch is ok for me. Could you commit the patch if the bootstrap is ok.
