[Bug c++/109529] the r-value volatile object is not accepted by the l-value volatile constant argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109529 --- Comment #2 from Andrew Pinski --- Since `static_cast(x)` is considered rvalue and `int volatile const &` needs to be bound, it will not be bound to a temporary (rvalue) which is produced by the rvalue reference. In the non-volatile case, well it is a const reference which can be bound to a temporary value (rvalue) and that temp in this case will end its lifetime after the end of the statement (after the ;).
[Bug c++/109529] the r-value volatile object is not accepted by the l-value volatile constant argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109529
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Andrew Pinski ---
only const references can be bound to temporaries. const volatile references
cannot be bound to a temporary.
That is even this is invalid code:
```
int main(){
const volatile int & a = 1;
}
```
[Bug c++/109529] New: the r-value volatile object is not accepted by the l-value volatile constant argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109529
Bug ID: 109529
Summary: the r-value volatile object is not accepted by the
l-value volatile constant argument.
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lisp2d at rambler dot ru
Target Milestone: ---
void funy(int const &){}
void fun(int volatile const &){}
int main(){
int y ;
funy(y); // good
funy(static_cast(y)); // good
funy(static_cast(y)); // good
int volatile x ;
fun(x); // good
fun(static_cast(x)); // error
fun(static_cast(x)); // error
}
[Bug middle-end/109528] function with _Noreturn triggers infinite recursion warning while using the attribute does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109528 --- Comment #4 from Stavros Avramidis --- The warning makes a bit more sense now, I was thinking gcc was getting confused about function ending after calling the internal exits(). Anyways, I can confirm that it works with `[[gnu::noreturn]]`
[Bug target/109478] FAIL: g++.dg/other/pr104989.C -std=gnu++14 (internal compiler error: Segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109478 --- Comment #5 from Sam James --- (In reply to John David Anglin from comment #4) > Fixed by commit 4f1c5e54d782b26304b0095ffb3ceb4c92c3c78d. i.e. r13-7194-g4f1c5e54d782b26304b0095ffb3ceb4c92c3c78d for the nice link
[Bug rtl-optimization/104989] [10/11 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.cc:2797 (error: flow control insn inside a basic block)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104989 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #8 from Sam James --- (In reply to CVS Commits from comment #7) > The master branch has been updated by John David Anglin > : > > https://gcc.gnu.org/g:4f1c5e54d782b26304b0095ffb3ceb4c92c3c78d > > commit r13-7194-g4f1c5e54d782b26304b0095ffb3ceb4c92c3c78d > Author: John David Anglin > Date: Sat Apr 15 17:02:44 2023 + > > Fix handling of large arguments passed by value. > > 2023-04-15 John David Anglin > > gcc/ChangeLog: > > PR target/104989 > [...] This was for PR109478 instead.
[Bug c/21038] report unmatched brace as a note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21038 Eric Gallager changed: What|Removed |Added Component|c++ |c CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=109356 --- Comment #7 from Eric Gallager --- (In reply to Xi Ruoyao from comment #6) > Can we close this or reset Component field? Component field reset.
[Bug middle-end/109505] (t | 15) & svcntb() causes an OOM/ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109505 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #7) > Fails even in GCC 11.1.0. > It is due to match.pd's > > /* (x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2) */ > (simplify > (bit_and (bit_ior @0 CONSTANT_CLASS_P@1) CONSTANT_CLASS_P@2) > (bit_ior (bit_and @0 @2) (bit_and @1 @2))) > > POLY_INT_CST is a CONSTANT_CLASS but does not simplify on the bit_and. > So maybe it should include a ! on the (bit_and @1 @2) . Which then will go into a loop with: (A | B) & (A | C) into A | (B & C)
[Bug tree-optimization/109524] [13 Regression] ICE: SIGSEGV in remove_unreachable::remove_and_update_globals (tree-vrp.cc:136) with -O3 -fno-tree-forwprop -fnon-call-exceptions -fno-tree-ccp -fno-tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109524 --- Comment #8 from Jakub Jelinek --- Perhaps add to substitute_and_fold another callback before the dead eh edges etc. are removed and perform this m_unreachable.remove_and_update_globals in there rather than after substitute_and_fold returns?
[Bug tree-optimization/109524] [13 Regression] ICE: SIGSEGV in remove_unreachable::remove_and_update_globals (tree-vrp.cc:136) with -O3 -fno-tree-forwprop -fnon-call-exceptions -fno-tree-ccp -fno-tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109524 --- Comment #7 from Jakub Jelinek --- The edge in question has been removed in #2 0x025b0e32 in free_edge (fn=0x7fffea2ed7e8, e=) at ../../gcc/cfg.cc:93 #3 0x025b1631 in remove_edge_raw (e=) at ../../gcc/cfg.cc:367 #4 0x009e447c in remove_edge (e=) at ../../gcc/cfghooks.cc:464 #5 0x009e49b5 in delete_basic_block (bb=) at ../../gcc/cfghooks.cc:636 #6 0x0112b193 in remove_edge_and_dominated_blocks (e= 6)>) at ../../gcc/tree-cfg.cc:8958 #7 0x0112b34f in gimple_purge_dead_eh_edges (bb=) at ../../gcc/tree-cfg.cc:9002 #8 0x0112b412 in gimple_purge_all_dead_eh_edges (blocks=0x39d0cb8) at ../../gcc/tree-cfg.cc:9029 #9 0x0131281a in substitute_and_fold_engine::substitute_and_fold (this=0x7fffd960, block=) at ../../gcc/tree-ssa-propagate.cc:998 #10 0x0145ef6b in execute_ranger_vrp (fun=0x7fffea2ed7e8, warn_array_bounds_p=true, final_p=false) at ../../gcc/tree-vrp.cc:1102 and #0 0x009d9c1b in bb_seq_addr (bb=) at ../../gcc/gimple.h:1820 #1 0x009f7325 in gsi_last_bb (bb=) at ../../gcc/gimple-iterator.h:160 #2 0x00c7fe17 in gsi_last_nondebug_bb (bb=) at ../../gcc/gimple-iterator.h:321 #3 0x0265dca9 in gimple_outgoing_range_stmt_p (bb=) at ../../gcc/gimple-range-edge.cc:42 #4 0x0145b54d in remove_unreachable::remove_and_update_globals (this=0x7fffd970, final_p=false) at ../../gcc/tree-vrp.cc:136 #5 0x0145ef87 in execute_ranger_vrp (fun=0x7fffea2ed7e8, warn_array_bounds_p=true, final_p=false) at ../../gcc/tree-vrp.cc:1104 then tries to access the already freed edge which was kept in some list of edges across the gimple_purge_all_dead_eh_edges.
[Bug target/109494] inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 Andrew Pinski changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0
[Bug target/109494] inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 --- Comment #11 from Andrew Pinski --- (In reply to Oliver Rosten from comment #10) > Can do, but I don't have sufficient understanding to understand why! Can you > kindly explain? Because that is where you got the GCC you are using from. It is listed in the configure line: "--with-bugurl=https://github.com/Homebrew/homebrew-core/issues";
[Bug target/109494] inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 --- Comment #10 from Oliver Rosten --- Can do, but I don't have sufficient understanding to understand why! Can you kindly explain?
[Bug target/109494] inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 --- Comment #9 from Andrew Pinski --- You most likely should report this to Homebrew too: https://github.com/Homebrew/homebrew-core/issues
[Bug target/109494] inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 --- Comment #8 from Oliver Rosten --- Created attachment 54870 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54870&action=edit Output from gcc -v
[Bug target/109494] inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 --- Comment #7 from Andrew Pinski --- You still didn't provide the full output.
[Bug target/109494] inline const variables interfere with source_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494 --- Comment #6 from Oliver Rosten --- I've added a simple makefile to the project: https://github.com/ojrosten/SourceLoc
[Bug tree-optimization/109524] [13 Regression] ICE: SIGSEGV in remove_unreachable::remove_and_update_globals (tree-vrp.cc:136) with -O3 -fno-tree-forwprop -fnon-call-exceptions -fno-tree-ccp -fno-tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109524 --- Comment #6 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #5) > That only moves it by a single revision back - r13-3595-g7b1cdca6d6d594a Which actually makes sense as the most reduced testcase has __builtin_unreachable in it. I am not sure if the original non-reduced testcase (which was not attached here had a function which returned without a return value or not).
[Bug tree-optimization/109524] [13 Regression] ICE: SIGSEGV in remove_unreachable::remove_and_update_globals (tree-vrp.cc:136) with -O3 -fno-tree-forwprop -fnon-call-exceptions -fno-tree-ccp -fno-tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109524 --- Comment #5 from Jakub Jelinek --- That only moves it by a single revision back - r13-3595-g7b1cdca6d6d594a
[Bug tree-optimization/109524] [13 Regression] ICE: SIGSEGV in remove_unreachable::remove_and_update_globals (tree-vrp.cc:136) with -O3 -fno-tree-forwprop -fnon-call-exceptions -fno-tree-ccp -fno-tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109524 --- Comment #4 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #3) > Started with r13-3596-ge7310e24b1c0ca67b1bb You might want to add -param=vrp1-mode=ranger when bisecting.
[Bug tree-optimization/109524] [13 Regression] ICE: SIGSEGV in remove_unreachable::remove_and_update_globals (tree-vrp.cc:136) with -O3 -fno-tree-forwprop -fnon-call-exceptions -fno-tree-ccp -fno-tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109524 Jakub Jelinek changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com, ||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Started with r13-3596-ge7310e24b1c0ca67b1bb
[Bug tree-optimization/109524] [13 Regression] ICE: SIGSEGV in remove_unreachable::remove_and_update_globals (tree-vrp.cc:136) with -O3 -fno-tree-forwprop -fnon-call-exceptions -fno-tree-ccp -fno-tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109524 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-04-15 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/109524] [13 Regression] ICE: SIGSEGV in remove_unreachable::remove_and_update_globals (tree-vrp.cc:136) with -O3 -fno-tree-forwprop -fnon-call-exceptions -fno-tree-ccp -fno-tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109524 --- Comment #1 from Andrew Pinski --- Created attachment 54869 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54869&action=edit Further reduced
[Bug tree-optimization/109524] [13 Regression] ICE: SIGSEGV in remove_unreachable::remove_and_update_globals (tree-vrp.cc:136) with -O3 -fno-tree-forwprop -fnon-call-exceptions -fno-tree-ccp -fno-tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109524 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug target/109527] redundant register assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109527
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed||2023-04-15
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Take:
```
short test(int t, short* a)
{
*a = 1;
return *a;
}
```
This produces decent code for aarch64:
```
mov w0, 1
strhw0, [x1]
ret
```
Note I suspect this is really does not show up that often either and only
happens with return values.
[Bug c/109526] Broken type name for anonymous struct containing a VLA member in diagnostic message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109526 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-04-15 --- Comment #1 from Andrew Pinski --- Confirmed. If it was not a VLA type inside the struct we get: :7:12: warning: initialization of 'struct *' from incompatible pointer type 'char *' [-Wincompatible-pointer-types] 7 | } *p = x; |^ Which seems better.
[Bug middle-end/109528] function with _Noreturn triggers infinite recursion warning while using the attribute does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109528
Andrew Pinski changed:
What|Removed |Added
Component|c |middle-end
--- Comment #3 from Andrew Pinski ---
/* Avoid diagnosing an apparently infinitely recursive function that
doesn't return where the infinite recursion might be avoided by
a call to another noreturn function. */
noreturn_p = lookup_attribute ("noreturn", DECL_ATTRIBUTES (m_func->decl));
This is the wrong check. It should use "flags_from_decl_or_type (m_func->decl)
& ECF_NOTHROW" instead or even just TREE_THIS_VOLATILE here.
[Bug c/109528] function with _Noreturn triggers infinite recursion warning while using the attribute does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109528
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|Calling exit() at the end |function with _Noreturn
|of function triggers|triggers infinite recursion
|infinite recursion warning |warning while using the
||attribute does not
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-04-15
--- Comment #2 from Andrew Pinski ---
Reduced testcase:
```
#if 1
#define noreturn _Noreturn
#else
#define noreturn [[gnu::noreturn]]
#endif
struct tree_node {
unsigned nr_children;
char name[16];
struct tree_node *children;
};
noreturn void fork_my_tree(const struct tree_node* pRoot)
{
for (unsigned i = 0u; i < pRoot->nr_children; i++)
fork_my_tree(pRoot->children + i);
__builtin_exit(0);
}
```
Changing `#if 1` to `#if 0` fixes the warning.
[Bug c/109528] Calling exit() at the end of function triggers infinite recursion warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109528 Andrew Pinski changed: What|Removed |Added Component|analyzer|c Keywords||diagnostic --- Comment #1 from Andrew Pinski --- Actually it looks more like _Noreturn is not take effect on the declaration. If I use __attribute__((noreturn)) or [[gnu::noreturn]] (or on the trunk [[noreturn]] which is part of C23) instead, it just works.
[Bug bootstrap/109510] [13 Regression] bootstrap with Ada broken on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109510 --- Comment #15 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:2e2b6ec156e3035297bd76edfd462d68d1f87314 commit r13-7195-g2e2b6ec156e3035297bd76edfd462d68d1f87314 Author: Eric Botcazou Date: Sat Apr 15 19:35:02 2023 +0200 Fix fallout of previous change on x86/Linux gcc/ada/ PR bootstrap/109510 * gcc-interface/decl.cc (gnat_to_gnu_entity) : Do not reset align to zero in any case. Set TYPE_USER_ALIGN on the type only if it is an aggregate type, or else a type whose default alignment is specifically capped on selected platforms.
[Bug c++/109514] [13 regression] -Werror=dangling-pointer false positive nn fheroes-1.0.3 (lambdas)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109514 --- Comment #4 from Sergei Trofimovich --- Thank you, Jason! I tested the original code from fheroes2-1.0.3. It also compiles without warnings.
[Bug target/109478] FAIL: g++.dg/other/pr104989.C -std=gnu++14 (internal compiler error: Segmentation fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109478 John David Anglin changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from John David Anglin --- Fixed by commit 4f1c5e54d782b26304b0095ffb3ceb4c92c3c78d.
[Bug c/109528] New: Calling exit() at the end of function triggers infinite recursion warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109528 Bug ID: 109528 Summary: Calling exit() at the end of function triggers infinite recursion warning Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: stavros9899 at gmail dot com Target Milestone: --- Created attachment 54868 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54868&action=edit code that triggers the warning Hello, this codem falsy -imo- triggers infinite-recursion warning. The interesting thing is that the error goes away when the last exit(), at the near end of the function gets removed.
[Bug rtl-optimization/104989] [10/11 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.cc:2797 (error: flow control insn inside a basic block)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104989 --- Comment #7 from CVS Commits --- The master branch has been updated by John David Anglin : https://gcc.gnu.org/g:4f1c5e54d782b26304b0095ffb3ceb4c92c3c78d commit r13-7194-g4f1c5e54d782b26304b0095ffb3ceb4c92c3c78d Author: John David Anglin Date: Sat Apr 15 17:02:44 2023 + Fix handling of large arguments passed by value. 2023-04-15 John David Anglin gcc/ChangeLog: PR target/104989 * config/pa/pa-protos.h (pa_function_arg_size): Update prototype. * config/pa/pa.cc (pa_function_arg): Return NULL_RTX if argument size is zero. (pa_arg_partial_bytes): Don't call pa_function_arg_size twice. (pa_function_arg_size): Change return type to int. Return zero for arguments larger than 1 GB. Update comments.
[Bug c++/109357] [12/13 Regression] internal compiler error in cp/constexpr.cc:1685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109357 --- Comment #2 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:13669741e673fa6a7b7c8d68f992e58ecd393160 commit r13-7193-g13669741e673fa6a7b7c8d68f992e58ecd393160 Author: Jason Merrill Date: Fri Apr 14 22:40:43 2023 -0400 c++: constexpr aggregate destruction [PR109357] We were assuming that the result of evaluation of TARGET_EXPR_INITIAL would always be the new value of the temporary, but that's not necessarily true when the initializer is complex (i.e. target_expr_needs_replace). In that case evaluating the initializer initializes the temporary as a side-effect. PR c++/109357 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_constant_expression) [TARGET_EXPR]: Check for complex initializer. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/constexpr-dtor15.C: New test.
[Bug rtl-optimization/109527] New: redundant register assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109527
Bug ID: 109527
Summary: redundant register assignment
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: vanyacpp at gmail dot com
Target Milestone: ---
On this function
short test(short* a)
{
*a = 1;
return *a;
}
latest gcc -O2 generates:
test(short*):
mov eax, 1
mov WORD PTR [rdi], ax
mov eax, 1
ret
I believe the second assignment to eax is redundant and can be removed:
test(short*):
mov eax, 1
mov WORD PTR [rdi], ax
ret
[Bug c/109526] New: Broken type name for anonymous struct containing a VLA member in diagnostic message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109526
Bug ID: 109526
Summary: Broken type name for anonymous struct containing a VLA
member in diagnostic message
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: xry111 at gcc dot gnu.org
Target Milestone: ---
void test(__SIZE_TYPE__ len, char *x)
{
struct
{
char data[len];
} *p = x;
}
The diagnostic message is:
: In function 'test':
:6:12: warning: initialization of ' *' from incompatible pointer
type 'char *' [-Wincompatible-pointer-types]
6 | } *p = x;
|^
"" does not make any sense to me.
[Bug target/54816] [avr] shift is better than widening mul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54816 --- Comment #3 from Wilhelm M --- (In reply to Roger Sayle from comment #2) > The original problem looks to be fixed on mainline. Can you confirm this > Wilhelm? If so we can close this PR. > > With -Os -mmcu=atmega8, we currently generate (the desired): > wmul: lsl r22 > lsl r22 > lsl r22 > muls r22,r24 > movw r24,r0 > clr __zero_reg__ > ret Yes, this seems to be fixed in mainline.
[Bug libstdc++/109525] typo in views::as_const::operator()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109525 --- Comment #1 from 康桓瑋 --- testcase: #include #include std::vector v; std::same_as>> auto r = std::views::as_const(v);
[Bug libstdc++/109525] New: typo in views::as_const::operator()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109525 Bug ID: 109525 Summary: typo in views::as_const::operator() Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- ranges#L9027: else if constexpr (is_lvalue_reference_v<_Range> && constant_range<_Tp> && !view<_Tp>) return ref_view(static_cast(__r)); According to [range.as.const.overview-2.5], the second condition should be constant_range, I think?
[Bug fortran/109511] incorrectly rejects set_exponent with constant negative exponent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109511 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:64efeac03cb9fa2603bb6628712f3a2541aef1cb commit r12-9402-g64efeac03cb9fa2603bb6628712f3a2541aef1cb Author: Harald Anlauf Date: Fri Apr 14 20:45:19 2023 +0200 Fortran: fix compile-time simplification of SET_EXPONENT [PR109511] gcc/fortran/ChangeLog: PR fortran/109511 * simplify.cc (gfc_simplify_set_exponent): Fix implementation of compile-time simplification of intrinsic SET_EXPONENT for argument X < 1 and for I < 0. gcc/testsuite/ChangeLog: PR fortran/109511 * gfortran.dg/set_exponent_1.f90: New test. (cherry picked from commit fa4cb42870df60debdbd51e2ddc6d6ab9e6a)
[Bug target/109519] aarch64: wrong code with NEON intrinsics on gcc-10 and later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109519 --- Comment #5 from Sebastian Pop --- Thanks Andrew for the patch, it fixes the issue.
[Bug target/54816] [avr] shift is better than widening mul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54816 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com --- Comment #2 from Roger Sayle --- The original problem looks to be fixed on mainline. Can you confirm this Wilhelm? If so we can close this PR. With -Os -mmcu=atmega8, we currently generate (the desired): wmul: lsl r22 lsl r22 lsl r22 muls r22,r24 movw r24,r0 clr __zero_reg__ ret
[Bug c++/21038] report unmatched brace as a note
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21038
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #6 from Xi Ruoyao ---
With latest GCC, it works for C++:
LANG= g++ t.c
t.c: In function 'void foo()':
t.c:4:11: error: expected '}' at end of input
4 | int k;
| ^
t.c:1:12: note: to match this '{'
1 | void foo() {
|^
But it's sometimes indeed completely misleading (PR109356).
Still does not work for C:
LANG= cc t.c
t.c: In function 'foo':
t.c:4:5: error: expected declaration or statement at end of input
4 | int k;
| ^~~
Can we close this or reset Component field?
[Bug target/108807] [11/12 regression] gcc.target/powerpc/vsx-builtin-10d.c fails after r11-6857-gb29225597584b6 on power 9 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108807 --- Comment #7 from Jeffrey A. Law --- Once you've committed to the active release branches where this bug is active (11/12 in this case), you can just close the bug as resolved/fixed. No need to update the summary/title in that case. Thanks, Jeff
[Bug c++/109521] [11/12/13 Regression] Checking ICE with canonical types differ for identical types ‘UBYTE [7]’ {aka ‘unsigned char [7]’} and ‘unsigned char [7]’ since r11-6508-gabb1b6058c09a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109521
Sam James changed:
What|Removed |Added
Summary|[11/12/13 Regression] |[11/12/13 Regression]
|Checking ICE with canonical |Checking ICE with canonical
|types differ for identical |types differ for identical
|types ‘UBYTE [7]’ {aka |types ‘UBYTE [7]’ {aka
|‘unsigned char [7]’} and|‘unsigned char [7]’} and
|‘unsigned char [7]’ |‘unsigned char [7]’ since
||r11-6508-gabb1b6058c09a7
CC||msebor at gcc dot gnu.org
--- Comment #3 from Sam James ---
Bisect says:
abb1b6058c09a7c0430d9bf019466ada07ca7b40 is the first bad commit
commit abb1b6058c09a7c0430d9bf019466ada07ca7b40
Author: Martin Sebor
Date: Wed Jan 6 13:44:27 2021 -0700
PR c++/95768 - pretty-printer ICE on -Wuninitialized with allocated storage
i.e. r11-6508-gabb1b6058c09a7.
[Bug other/109522] Spurious "cc1: error: no include path in which to search for stdc-predef.h" building a cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109522 Xi Ruoyao changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-April/6 ||15791.html --- Comment #3 from Xi Ruoyao --- Posted the patch adding -nostdinc for review.
[Bug other/109522] Spurious "cc1: error: no include path in which to search for stdc-predef.h" building a cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109522 --- Comment #2 from Xi Ruoyao --- (In reply to Jakub Jelinek from comment #1) > I bet we really don't need the macros from stdc-predef.h, so perhaps we > could use -nostdinc. > stdc-predef.h currently (sometimes) predefines > __STDC_IEC_559__ > __STDC_IEC_60559_BFP__ > __STDC_IEC_559_COMPLEX__ > __STDC_IEC_60559_COMPLEX__ > __STDC_ISO_10646__ > and grep doesn't find any STDC_IEC nor STDC_ISO occurrences in fixincl. Yes, these macros are some sort of "modern" (stdc-predef.h was firstly added to Glibc in 2012), and it's unlikely anyone has ever used them in a broken way (without "__").
[Bug tree-optimization/109524] New: [13 Regression] ICE: SIGSEGV in remove_unreachable::remove_and_update_globals (tree-vrp.cc:136) with -O3 -fno-tree-forwprop -fnon-call-exceptions -fno-tree-ccp -fno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109524
Bug ID: 109524
Summary: [13 Regression] ICE: SIGSEGV in
remove_unreachable::remove_and_update_globals
(tree-vrp.cc:136) with -O3 -fno-tree-forwprop
-fnon-call-exceptions -fno-tree-ccp -fno-tree-fre
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 54867
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54867&action=edit
auto-reduced testcase
Compiler output:
$ x86_64-pc-linux-gnu-gcc -O3 -fno-tree-forwprop -fnon-call-exceptions
-fno-tree-ccp -fno-tree-fre testcase.C -w -wrapper
valgrind,-q,--track-origins=yes
==2129== Invalid read of size 8
==2129==at 0x197A872: remove_unreachable::remove_and_update_globals(bool)
[clone .part.0] (tree-vrp.cc:136)
==2129==by 0x197CC3D: remove_and_update_globals (tree-vrp.cc:1106)
==2129==by 0x197CC3D: execute_ranger_vrp(function*, bool, bool)
(tree-vrp.cc:1104)
==2129==by 0x15B4E8A: execute_one_pass(opt_pass*) (passes.cc:2651)
==2129==by 0x15B577F: execute_pass_list_1(opt_pass*) (passes.cc:2760)
==2129==by 0x15B5791: execute_pass_list_1(opt_pass*) (passes.cc:2761)
==2129==by 0x15B57B8: execute_pass_list(function*, opt_pass*)
(passes.cc:2771)
==2129==by 0x11E5605: expand (cgraphunit.cc:1841)
==2129==by 0x11E5605: cgraph_node::expand() (cgraphunit.cc:1794)
==2129==by 0x11E694A: expand_all_functions (cgraphunit.cc:2024)
==2129==by 0x11E694A: symbol_table::compile() [clone .part.0]
(cgraphunit.cc:2398)
==2129==by 0x11E94A7: compile (cgraphunit.cc:2311)
==2129==by 0x11E94A7: symbol_table::finalize_compilation_unit()
(cgraphunit.cc:2583)
==2129==by 0x16B5541: compile_file() (toplev.cc:471)
==2129==by 0xE11068: do_compile (toplev.cc:2125)
==2129==by 0xE11068: toplev::main(int, char**) (toplev.cc:2277)
==2129==by 0xE12D0A: main (main.cc:39)
==2129== Address 0x55a4840 is in a rw- anonymous segment
==2129==
==2129== Invalid read of size 1
==2129==at 0x197A876: remove_unreachable::remove_and_update_globals(bool)
[clone .part.0] (tree-vrp.cc:136)
==2129==by 0x58E1A47: ???
==2129==by 0x197CC3D: remove_and_update_globals (tree-vrp.cc:1106)
==2129==by 0x197CC3D: execute_ranger_vrp(function*, bool, bool)
(tree-vrp.cc:1104)
==2129==by 0x15B4E8A: execute_one_pass(opt_pass*) (passes.cc:2651)
==2129==by 0x15B577F: execute_pass_list_1(opt_pass*) (passes.cc:2760)
==2129==by 0x15B5791: execute_pass_list_1(opt_pass*) (passes.cc:2761)
==2129==by 0x15B57B8: execute_pass_list(function*, opt_pass*)
(passes.cc:2771)
==2129==by 0x11E5605: expand (cgraphunit.cc:1841)
==2129==by 0x11E5605: cgraph_node::expand() (cgraphunit.cc:1794)
==2129==by 0x11E694A: expand_all_functions (cgraphunit.cc:2024)
==2129==by 0x11E694A: symbol_table::compile() [clone .part.0]
(cgraphunit.cc:2398)
==2129==by 0x11E94A7: compile (cgraphunit.cc:2311)
==2129==by 0x11E94A7: symbol_table::finalize_compilation_unit()
(cgraphunit.cc:2583)
==2129==by 0x16B5541: compile_file() (toplev.cc:471)
==2129==by 0xE11068: do_compile (toplev.cc:2125)
==2129==by 0xE11068: toplev::main(int, char**) (toplev.cc:2277)
==2129== Address 0xa5a5a5a5a5a5a5f6 is not stack'd, malloc'd or (recently)
free'd
==2129==
during GIMPLE pass: vrp
testcase.C: In function 'void AddGRFTextToList()':
testcase.C:30:6: internal compiler error: Segmentation fault
30 | void AddGRFTextToList() {
| ^~~~
0x16b507f crash_signal
/repo/gcc-trunk/gcc/toplev.cc:314
0x197a876 remove_unreachable::remove_and_update_globals(bool)
/repo/gcc-trunk/gcc/tree-vrp.cc:136
...
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-7181-20230414111512-gb0e85485fbf-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-7181-20230414111512-gb0e85485fbf-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230414 (experimental) (GCC)
[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #52 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:de0ee9d14165eebb3d31c84e98260c05c3b33acb
commit r13-7192-gde0ee9d14165eebb3d31c84e98260c05c3b33acb
Author: Jakub Jelinek
Date: Sat Apr 15 12:08:45 2023 +0200
if-conv: Small improvement for expansion of complex PHIs [PR109154]
The following patch is just a dumb improvement, gets rid of 2 unnecessary
instructions on both the PR's original testcase and on the two reduced
ones,
both on -mcpu=neoverse-v1 and -mavx512f.
The thing is, if we have args_len (args_len >= 2) unique PHI arguments,
we need only args_len - 1 COND_EXPRs to expand the PHI, because first
COND_EXPR can merge 2 unique arguments and all the following ones merge
another unique argument with the previously merged arguments,
while the code for mysterious reasons was always emitting args_len
COND_EXPRs, where the first COND_EXPR merged the first and second unique
arguments, the second COND_EXPR merged the second unique argument with
result of merging the first and second unique arguments and the rest was
already expectable, nth COND_EXPR for n > 2 merged the nth unique argument
with result of merging the previous unique arguments.
Now, in my understanding, the bb_predicate for bb's predecessor need to
form a disjunct set which together creates the successor's bb_predicate,
so I don't see why we'd need to check all the bb_predicates, if we check
all but one then when all those other ones are false the last bb_predicate
is necessarily true. Given that the code attempts to sort argument with
most occurrences (so likely most complex combined predicate) last, I chose
not to test that last argument's predicate.
So e.g. on the testcase from comment 47 in the PR:
void
foo (int *f, int d, int e)
{
for (int i = 0; i < 1024; i++)
{
int a = f[i];
int t;
if (a < 0)
t = 1;
else if (a < e)
t = 1 - a * d;
else
t = 0;
f[i] = t;
}
}
we used to emit:
_7 = a_10 < 0;
_21 = a_10 >= 0;
_22 = a_10 < e_11(D);
_23 = _21 & _22;
_26 = a_10 >= e_11(D);
_27 = _21 & _26;
_ifc__42 = _7 ? 1 : t_13;
_ifc__43 = _23 ? t_13 : _ifc__42;
t_6 = _27 ? 0 : _ifc__43;
while the following patch changes it to:
_7 = a_10 < 0;
_21 = a_10 >= 0;
_22 = a_10 < e_11(D);
_23 = _21 & _22;
_ifc__42 = _23 ? t_13 : 0;
t_6 = _7 ? 1 : _ifc__42;
which I believe should be sufficient for a PHI <1, t_13, 0>.
I've gathered some statistics and on x86_64-linux and i686-linux
bootstraps/regtests, this code triggers:
92 4 4
112 2 4
141 3 4
4046 3 3
(where 2nd number is args_len and 3rd argument EDGE_COUNT (bb->preds)
and first argument count of those from sort | uniq -c | sort -n).
In all these cases the patch should squeze one extra COND_EXPR and
its associated predicate (the latter only if it wasn't used elsewhere).
Incrementally, I think we should try to perform some analysis on which
predicates depend on inverses of other predicates and if possible try
to sort the arguments better and omit testing unnecessary predicates.
So essentially for the above testcase deconstruct it back to:
_7 = a_10 < 0;
_22 = a_10 < e_11(D);
_ifc__42 = _22 ? t_13 : 0;
t_6 = _7 ? 1 : _ifc__42;
which is like what this patch produces, but with the & a_10 >= 0 part
removed, because the last predicate is a_10 < 0 and so testing a_10 >= 0
on what appears on the false branch doesn't make sense.
But I'm afraid that will take more work than is doable in stage4 right now.
2023-04-15 Jakub Jelinek
PR tree-optimization/109154
* tree-if-conv.cc (predicate_scalar_phi): For complex PHIs, emit
just
args_len - 1 COND_EXPRs rather than args_len. Formatting fix.
[Bug target/108807] [11/12 regression] gcc.target/powerpc/vsx-builtin-10d.c fails after r11-6857-gb29225597584b6 on power 9 BE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108807 --- Comment #6 from Kewen Lin --- (In reply to Jeffrey A. Law from comment #5) > Kewen, is this BZ fixed on the trunk? If so we should update the title by > dropping the "/13" so that's not flagged as a gcc-13 regression. Yes, thanks for reminding and tips! I didn't know this rule before, I had a related question that I'm going to backport the commit to gcc-11/gcc-12 soon, once it's done excepting for marking the status to resolved, should I also drop the remaining "[11/12 regression]"? Or for a bug in resolved status, not dropping it would be fine?
[Bug c++/109521] [11/12/13 Regression] Checking ICE with canonical types differ for identical types ‘UBYTE [7]’ {aka ‘unsigned char [7]’} and ‘unsigned char [7]’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109521 --- Comment #2 from Sam James --- Created attachment 54866 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54866&action=edit reduced.ii Yours is better formed, I think, but let me attach the results of cvise which just finished for the hell of it.
[Bug c++/83264] std::initializer_list with a single element selects the wrong overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83264 --- Comment #13 from Andrew Pinski --- *** Bug 109523 has been marked as a duplicate of this bug. ***
[Bug c++/109523] List-initializing constructor of std::vector is selected erroneously
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109523 --- Comment #2 from Andrew Pinski --- Actually it is a dup of bug 83264. *** This bug has been marked as a duplicate of bug 83264 ***
[Bug c++/85577] list-initialization chooses initializer-list constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85577 Andrew Pinski changed: What|Removed |Added CC||fchelnokov at gmail dot com --- Comment #11 from Andrew Pinski --- *** Bug 109523 has been marked as a duplicate of this bug. ***
[Bug c++/109523] List-initializing constructor of std::vector is selected erroneously
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109523 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Nope, GCC is actually the only compiler that implements this correctly in this case. Duplicate of bug 85577. https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2137 *** This bug has been marked as a duplicate of bug 85577 ***
[Bug c++/109521] [11/12/13 Regression] Checking ICE with canonical types differ for identical types ‘UBYTE [7]’ {aka ‘unsigned char [7]’} and ‘unsigned char [7]’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109521
Andrew Pinski changed:
What|Removed |Added
Known to fail|11.3.1, 12.2.1, 13.0|11.1.0
Known to work|10.4.1 |10.4.0
Target Milestone|--- |11.4
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Keywords||ice-checking,
||ice-on-valid-code,
||needs-bisection
Summary|[11/12/13 regression] |[11/12/13 Regression]
|Checking ICE with canonical |Checking ICE with canonical
|types differ for identical |types differ for identical
|types ‘UBYTE [7]’ {aka |types ‘UBYTE [7]’ {aka
|‘unsigned char [7]’} and|‘unsigned char [7]’} and
|‘unsigned char [7]’ |‘unsigned char [7]’
Last reconfirmed||2023-04-15
--- Comment #1 from Andrew Pinski ---
Reduced:
```
struct vector
{
vector& operator=(vector&& __x)
{
return *this;
}
};
struct tree_node {
vector childs;
unsigned char pad[7];
tree_node(){}
};
tree_node mcts_root;
void find_Horner_MCTS_expand_tree () {
mcts_root = tree_node();
}
```
Compile at -O2 -Wall is enough to reproduce the failure.
Note using unsigned short or unsigned int instead of unsigned char allows it to
work.
[Bug c++/109523] New: List-initializing constructor of std::vector is selected erroneously
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109523
Bug ID: 109523
Summary: List-initializing constructor of std::vector is
selected erroneously
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
The following program
#include
struct C {
int a;
constexpr C() : a(0) {}
constexpr C(int a) : a(a) {}
};
static_assert( std::vector({5}).size() == 5 );
is accepted in Clang and MSVC. But in GCC static assertion fails, because it
constructs a vector of single element 5. Online demo:
https://gcc.godbolt.org/z/j4b3z5xxP
Related discussion with explanation:
https://stackoverflow.com/q/76013629/7325599
[Bug target/99708] __SIZEOF_FLOAT128__ not defined on powerpc64le-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0
[Bug target/99708] __SIZEOF_FLOAT128__ not defined on powerpc64le-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99708 --- Comment #38 from Jonathan Wakely --- (In reply to Peter Bergner from comment #36) > Is this fixed now? Yes, I think the macros are defined consistently with the types now. Let's close it.
[Bug other/109522] Spurious "cc1: error: no include path in which to search for stdc-predef.h" building a cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109522 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I bet we really don't need the macros from stdc-predef.h, so perhaps we could use -nostdinc. stdc-predef.h currently (sometimes) predefines __STDC_IEC_559__ __STDC_IEC_60559_BFP__ __STDC_IEC_559_COMPLEX__ __STDC_IEC_60559_COMPLEX__ __STDC_ISO_10646__ and grep doesn't find any STDC_IEC nor STDC_ISO occurrences in fixincl.
[Bug other/109522] New: Spurious "cc1: error: no include path in which to search for stdc-predef.h" building a cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109522 Bug ID: 109522 Summary: Spurious "cc1: error: no include path in which to search for stdc-predef.h" building a cross compiler Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at gcc dot gnu.org Target Milestone: --- Build a cross compiler (with target libc not installed yet): ../gcc/configure --target=loongarch64-linux-gnu --disable-multilib --with-system-zlib && make gcc Then a spurious message is outputted for macro_list: echo | /home/xry111/git-repos/gcc-la/./gcc/xgcc -B/home/xry111/git-repos/gcc-la/./gcc/ -E -dM - | \ sed -n -e 's/^#define \([^_][a-zA-Z0-9_]*\).*/\1/p' \ -e 's/^#define \(_[^_A-Z][a-zA-Z0-9_]*\).*/\1/p' | \ sort -u > tmp-macro_list cc1: error: no include path in which to search for stdc-predef.h /bin/sh ../../gcc/gcc/../move-if-change tmp-macro_list macro_list Though the macro_list file is created successfully, the message can lead people to think something is wrong.
[Bug c/109521] New: Checking ICE (canonical types differ for identical types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109521
Bug ID: 109521
Summary: Checking ICE (canonical types differ for identical
types)
Product: gcc
Version: 13.0
URL: https://bugs.gentoo.org/904339
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Build: x86_64-pc-linux-gnu
Created attachment 54865
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54865&action=edit
optimise.ii.orig.xz
Had this when building form-4.3.0. Originally reported downstream in Gentoo at
https://bugs.gentoo.org/904339.
To trigger this, I had to use -U_GLIBCXX_ASSERTIONS as I have it enabled by
default for my GCC (Gentoo has it enabled by default for hardened, but not all
setups). Obviously this doesn't matter once preprocessed though.
Needs a checking build.
```
$ g++ -DHAVE_CONFIG_H -I. -I.. -O2 -Wall -Wextra -Wpadded
-Wno-misleading-indentation -Wno-stringop-overflow -U_GLIBCXX_ASSERTIONS -c
sources/optimize.cc
‘
during GIMPLE pass: uninit
In function ‘void find_Horner_MCTS()’:
canonical types differ for identical types ‘UBYTE [7]’ {aka ‘unsigned char
[7]’} and ‘unsigned char [7]’
2208 | void find_Horner_MCTS () {
| ^~~~
0x68ea0a comptypes(tree_node*, tree_node*, int)
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/cp/typeck.cc:1710
0x22768b9 cxx_types_compatible_p(tree_node*, tree_node*)
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/cp/cp-objcp-common.cc:130
0x11ed84a c_fold_indirect_ref_for_warn
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/c-family/c-pretty-print.cc:1851
0x11edf79 c_fold_indirect_ref_for_warn
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/c-family/c-pretty-print.cc:1918
0x11ee249 print_mem_ref
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/c-family/c-pretty-print.cc:1981
0x7b8b72 expr_to_string(tree_node*)
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/cp/error.cc:3315
0x21adbb0 cp_printer
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/cp/error.cc:4484
0x1a71e85 pp_format(pretty_printer*, text_info*)
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/pretty-print.cc:1475
0x1a710c3 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/diagnostic.cc:1592
0x1aef8c9 diagnostic_impl
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/diagnostic.cc:1756
0x1aef8c9 warning_at(unsigned int, int, char const*, ...)
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/diagnostic.cc:1893
0x9eda7e maybe_warn_operand
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/tree-ssa-uninit.cc:731
0x1d83413 warn_uninitialized_vars
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/tree-ssa-uninit.cc:1098
0x22271fa execute_late_warn_uninitialized
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/tree-ssa-uninit.cc:1406
0x22271fa execute
/usr/src/debug/sys-devel/gcc-13.0.1_pre20230409-r4/gcc-13-20230409/gcc/tree-ssa-uninit.cc:1451
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
