[Bug bootstrap/53902] make install fails on SunOS 5.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53902 --- Comment #8 from Andrew Pinski --- https://www.illumos.org/issues/3800
[Bug bootstrap/53902] make install fails on SunOS 5.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53902 Andrew Pinski changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED --- Comment #9 from Andrew Pinski --- Looks like this was a binutils issue which was fixed by: From: Rainer Orth Newsgroups: gmane.comp.gnu.binutils Subject: PATCH: Make .eh_frame sections read-only on 64-bit Solaris/x86 Date: Mon, 18 Jan 2010 19:44:27 +0100 Which is https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=53e5c8fee65d80d63b464ec455cce4f24f27dbd4
[Bug c++/93931] ICE using lambda capture in openMP parallel for reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93931 Andrew Pinski changed: What|Removed |Added Known to fail||8.4.0, 9.3.0 Target Milestone|--- |8.5 Known to work||10.1.0, 8.5.0, 9.4.0
[Bug c++/95028] ICE in g++ (Arch Linux 9.3.0-1) 9.3.0 with captured OMP reduce clause in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95028 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 93931. *** This bug has been marked as a duplicate of bug 93931 ***
[Bug c++/93931] ICE using lambda capture in openMP parallel for reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93931 Andrew Pinski changed: What|Removed |Added CC||fytch at protonmail dot com --- Comment #8 from Andrew Pinski --- *** Bug 95028 has been marked as a duplicate of this bug. ***
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 95028, which changed state. Bug 95028 Summary: ICE in g++ (Arch Linux 9.3.0-1) 9.3.0 with captured OMP reduce clause in lambda https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95028 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/98715] ICE in make_decl_rtl with double variable length array (VLA)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98715 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 58646. *** This bug has been marked as a duplicate of bug 58646 ***
[Bug c++/58646] [9/10/11/12 Regression] ICE on a multidimensional VLA with an empty initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58646 Andrew Pinski changed: What|Removed |Added CC||alserkli at inbox dot ru --- Comment #14 from Andrew Pinski --- *** Bug 98715 has been marked as a duplicate of this bug. ***
[Bug c++/16994] [meta-bug] VLA and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16994 Bug 16994 depends on bug 98715, which changed state. Bug 98715 Summary: ICE in make_decl_rtl with double variable length array (VLA) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98715 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/102551] New: Failing compile-time comparison of std::type_info addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102551
Bug ID: 102551
Summary: Failing compile-time comparison of std::type_info
addresses
Product: gcc
Version: 12.0
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 valid code is rejected by GCC:
```
#include
int main() {
constexpr auto v1 = &typeid(int);
constexpr auto v2 = &typeid(char);
static_assert( v1 != v2 );
}
```
Demo: https://gcc.godbolt.org/z/eexj7vcPG
[Bug c++/102551] Failing compile-time comparison of std::type_info addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102551 Andrew Pinski changed: What|Removed |Added Keywords||rejects-valid, wrong-code Known to fail||4.6.4 --- Comment #1 from Andrew Pinski --- It has always been broken since C++11 support was added: #include static_assert( &typeid(int) != &typeid(char) ,"");
[Bug c++/102551] Failing compile-time comparison of std::type_info addresses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102551 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-10-01
[Bug c++/102496] [11/12 regression] extern __thread and thread_local declaration in function scope produces a non-TLS reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102496 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:701075864ac4d1c6cec936d10f9cfc2aeb8c1699 commit r12-4032-g701075864ac4d1c6cec936d10f9cfc2aeb8c1699 Author: Jakub Jelinek Date: Fri Oct 1 10:30:16 2021 +0200 c++: Fix handling of __thread/thread_local extern vars declared at function scope [PR102496] The introduction of push_local_extern_decl_alias in r11-3699-g4e62aca0e0520e4ed2532f2d8153581190621c1a broke tls vars, while the decl they are created for has the tls model set properly, nothing sets it for the alias that is actually used, so accesses to it are done as if they were normal variables. This is then diagnosed at link time if the definition of the extern vars is __thread/thread_local. 2021-10-01 Jakub Jelinek PR c++/102496 * name-lookup.c (push_local_extern_decl_alias): Return early even for tls vars with non-dependent type when processing_template_decl. For CP_DECL_THREAD_LOCAL_P vars call set_decl_tls_model on alias. * g++.dg/tls/pr102496-1.C: New test. * g++.dg/tls/pr102496-2.C: New test.
[Bug c++/102548] [9/10/11/12 Regression] ICE with cdecl attribute on a builtin function since r7-4737-g48330c9355e32a41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102548 Martin Liška changed: What|Removed |Added CC||edlinger at gcc dot gnu.org, ||marxin at gcc dot gnu.org Summary|[9/10/11/12 Regression] ICE |[9/10/11/12 Regression] ICE |with cdecl attribute on a |with cdecl attribute on a |builtin function|builtin function since ||r7-4737-g48330c9355e32a41 --- Comment #5 from Martin Liška --- Then it started with r7-4737-g48330c9355e32a41.
[Bug c++/64697] C++11 thread_local: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for N::ptd'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697 --- Comment #25 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:021ad8e5cf9ab66e1a0a41dce3a54586facb86e0 commit r12-4036-g021ad8e5cf9ab66e1a0a41dce3a54586facb86e0 Author: Eric Botcazou Date: Fri Oct 1 10:49:34 2021 +0200 Fix PR c++/64697 at -O1 or above The BFD fix eliminates the link failure and working code is generated at -O0, but _not_ when optimization is enabled because the optimizer changes: movq.refptr._ZTH1s(%rip), %rax testq %rax, %rax je .L2 call_ZTH1s into: leaq_ZTH1s(%rip), %rax testq %rax, %rax je .L2 call_ZTH1s and the leaq now also gets the relocation overflow. So the fix is to teach legitimate_pic_address_disp_p to reject the transformation when the symbol is an external weak function, which yields: cmpq$0, .refptr._ZTH1s(%rip) je .L2 call_ZTH1s and the cmpq keeps a relocation that does not overflow. gcc/ PR c++/64697 * config/i386/i386.c (legitimate_pic_address_disp_p): For PE-COFF do not return true for external weak function symbols in medium model.
[Bug c++/64697] C++11 thread_local: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for N::ptd'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697 --- Comment #26 from CVS Commits --- The releases/gcc-11 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:618b7cb3b3fb4d2d92434d31ea8b6746ffef2572 commit r11-9049-g618b7cb3b3fb4d2d92434d31ea8b6746ffef2572 Author: Eric Botcazou Date: Fri Oct 1 10:49:34 2021 +0200 Fix PR c++/64697 at -O1 or above The BFD fix eliminates the link failure and working code is generated at -O0, but _not_ when optimization is enabled because the optimizer changes: movq.refptr._ZTH1s(%rip), %rax testq %rax, %rax je .L2 call_ZTH1s into: leaq_ZTH1s(%rip), %rax testq %rax, %rax je .L2 call_ZTH1s and the leaq now also gets the relocation overflow. So the fix is to teach legitimate_pic_address_disp_p to reject the transformation when the symbol is an external weak function, which yields: cmpq$0, .refptr._ZTH1s(%rip) je .L2 call_ZTH1s and the cmpq keeps a relocation that does not overflow. gcc/ PR c++/64697 * config/i386/i386.c (legitimate_pic_address_disp_p): For PE-COFF do not return true for external weak function symbols in medium model.
[Bug c++/64697] C++11 thread_local: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for N::ptd'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697 --- Comment #27 from CVS Commits --- The releases/gcc-10 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:48e24ff39b16c072cd58bdad1a5668794453af5f commit r10-10158-g48e24ff39b16c072cd58bdad1a5668794453af5f Author: Eric Botcazou Date: Fri Oct 1 10:49:34 2021 +0200 Fix PR c++/64697 at -O1 or above The BFD fix eliminates the link failure and working code is generated at -O0, but _not_ when optimization is enabled because the optimizer changes: movq.refptr._ZTH1s(%rip), %rax testq %rax, %rax je .L2 call_ZTH1s into: leaq_ZTH1s(%rip), %rax testq %rax, %rax je .L2 call_ZTH1s and the leaq now also gets the relocation overflow. So the fix is to teach legitimate_pic_address_disp_p to reject the transformation when the symbol is an external weak function, which yields: cmpq$0, .refptr._ZTH1s(%rip) je .L2 call_ZTH1s and the cmpq keeps a relocation that does not overflow. gcc/ PR c++/64697 * config/i386/i386.c (legitimate_pic_address_disp_p): For PE-COFF do not return true for external weak function symbols in medium model.
[Bug c++/64697] C++11 thread_local: relocation truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init function for N::ptd'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |10.4 CC||ebotcazou at gcc dot gnu.org --- Comment #28 from Eric Botcazou --- The binutils bug has been fixed in 2.36 or later: https://sourceware.org/bugzilla/show_bug.cgi?id=26659 The optimization bug will be fixed in upcoming 10.x, 11.x and 12.x releases.
[Bug tree-optimization/102546] [12 Regregression] Missed Dead Code Elimination regression (trunk vs 11.2.0) at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546 Aldy Hernandez changed: What|Removed |Added Last reconfirmed||2021-10-01 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org --- Comment #5 from Aldy Hernandez --- (In reply to Richard Biener from comment #4) > (In reply to Aldy Hernandez from comment #2) > > By VRP1 we seem to be calculating the following: > > > > (f_8 << f_8) && (f_8 == 0) > > > > This would fold to false, which would elide the foo(): > > > > [local count: 59055800]: > > b = 0; > > _3 = f_8 << f_8; > > _4 = (char) _3; > > _5 = (int) _4; > > if (_4 > 0) > > goto ; [64.06%] > > else > > goto ; [35.94%] > > > >[local count: 34842922]: > > if (f_8 == 0) > > goto ; [71.10%] > > else > > goto ; [28.90%] > > > >[local count: 12809203]: > > foo (); > > I think it's similar to in the other PR, with old EVRP when visiting BB 8 > we pushed [1, +INF] as the global range for _4, then supposedly ranger > manages to evaluate f_8 == 0 with its backward infering somehow. > > We no longer do this "path sensitive" adjustment of (global) ranges since > you removed the EVRP DOM walk algorithm. The hybrid threader does path sensitive ranges and relationals. What's missing is the range-op entry for the following relation: ~[0,0] = x << x In this case, we know that X cannot be 0. Fixing this, causes all the right things to happen. However, I see that the none of the op1_range entries are being called with a relation. Presumably this was an oversight on Andrew's part, but can easily be fixed. Interestingly on this case, the VRP threader shouldn't even need to step up here. VRP1 should have folded the conditional in BB8. The new evrp can though. If I tweak range-ops, and call execute_early_vrp() from VRP1, evrp folds the conditional and there's no need to thread. Now before Andrew asks why evrp doesn't clean this up earlier (with the range-ops tweak), it's because the IL is different. See my question about the "a" present in earlier passes. ;-) So...mine. I'll address all the issues pointed out.
[Bug tree-optimization/102546] [12 Regregression] Missed Dead Code Elimination regression (trunk vs 11.2.0) at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546 --- Comment #6 from Aldy Hernandez --- (In reply to Richard Biener from comment #4) > I think it's similar to in the other PR, with old EVRP when visiting BB 8 BTW, which is this other PR, so I may see if my work for this PR fixes that one?
[Bug tree-optimization/102546] [12 Regregression] Missed Dead Code Elimination regression (trunk vs 11.2.0) at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546 --- Comment #7 from Zhendong Su --- (In reply to Aldy Hernandez from comment #6) > (In reply to Richard Biener from comment #4) > > I think it's similar to in the other PR, with old EVRP when visiting BB 8 > > BTW, which is this other PR, so I may see if my work for this PR fixes that > one? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102540
[Bug fortran/102460] fortran internal compile error in coverage.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102460 --- Comment #7 from Martin Liška --- Thanks! So it's really a Fortran issue (gdb) p startloc.line $8 = 7 (gdb) p end_line $9 = 6 Can please anybody from Fortran FE guys help me here?
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285
Eric Gallager changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org,
||egallager at gcc dot gnu.org,
||rguenth at gcc dot gnu.org,
||vries at gcc dot gnu.org
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=82421
--- Comment #14 from Eric Gallager ---
(In reply to David Binderman from comment #11)
> (In reply to qinzhao from comment #10)
>
> > 2734 /* The heuristic of fold_builtin_alloca_with_align differs
>
> git blame says:
>
>
> 13e49da934e9 (Tom de Vries 2011-10-07 12:49:49 + 2732)
> /* The heuristic of fold_builtin_alloca_with_align differs before and
> 13e49da934e9 (Tom de Vries 2011-10-07 12:49:49 + 2733)
> after inlining, so we don't require the arg to be changed into a
> 13e49da934e9 (Tom de Vries 2011-10-07 12:49:49 + 2734)
> constant for folding, but just to be constant. */
> 9e878cf1bae7 (Eric Botcazou 2017-10-19 15:58:05 + 2735)
> if (gimple_call_builtin_p (stmt, BUILT_IN_ALLOCA_WITH_ALIGN)
> 9e878cf1bae7 (Eric Botcazou 2017-10-19 15:58:05 + 2736)
> || gimple_call_builtin_p (stmt, BUILT_IN_ALLOCA_WITH_ALIGN_AND_MAX))
> 1fed1006552c (Tom de Vries 2011-08-31 07:04:25 + 2737)
> {
> 13e49da934e9 (Tom de Vries 2011-10-07 12:49:49 + 2738)
> tree new_rhs = fold_builtin_alloca_with_align (stmt);
> 5d882cc1dafe (Richard Guenther 2011-09-02 11:53:55 + 2739)
> if (new_rhs)
> 5d882cc1dafe (Richard Guenther 2011-09-02 11:53:55 + 2740)
> {
> 52a5515ed661 (Richard Biener 2021-04-14 13:40:58 +0200 2741)
> gimplify_and_update_call_from_tree (gsi, new_rhs);
> 2f31f742a693 (Tom de Vries 2011-12-17 11:39:43 + 2742)
> tree var = TREE_OPERAND (TREE_OPERAND (new_rhs, 0),0);
> 2f31f742a693 (Tom de Vries 2011-12-17 11:39:43 + 2743)
> insert_clobbers_for_var (*gsi, var);
> 5d882cc1dafe (Richard Guenther 2011-09-02 11:53:55 + 2744)
> return true;
> 5d882cc1dafe (Richard Guenther 2011-09-02 11:53:55 + 2745)
> }
> 1fed1006552c (Tom de Vries 2011-08-31 07:04:25 + 2746)
> }
>
> so at least Tom, Eric and Richard have been in there.
cc-ing them
[Bug c++/85146] ICE with __direct_bases for declared but not defined struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85146 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.0
[Bug c++/77869] ICE on a code piece
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77869 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.0
[Bug c++/67164] ICE: tree check: expected class ‘expression’, have ‘exceptional’ (argument_pack_select) in tree_operand_check, at tree.h:3356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67164 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0
[Bug c++/91538] ICE with generic lambda.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91538 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=93140 --- Comment #3 from Andrew Pinski --- Fixed in GCC 8.4.0, GCC 9.3.0 and GCC 10+ by the patch which fixed PR 93140.
[Bug c++/83138] ICE: Segfault expanding function parameter pack in subsequent sibling pack declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83138 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |8.0
[Bug c++/97050] ICE with segfault in lambda overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97050 Andrew Pinski changed: What|Removed |Added Known to fail||10.3.0 Known to work||11.1.0 --- Comment #3 from Andrew Pinski --- Looks fixed in GCC 11.
[Bug c++/97468] gcc crashes when using __may_alias__ attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97468 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 89867. *** This bug has been marked as a duplicate of bug 89867 ***
[Bug c++/89867] internal compiler error: in layout_type, at stor-layout.c:2578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89867 Andrew Pinski changed: What|Removed |Added CC||tangyixuan at mail dot dlut.edu.cn --- Comment #4 from Andrew Pinski --- *** Bug 97468 has been marked as a duplicate of this bug. ***
[Bug c++/63578] ICE with may_alias and auto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63578 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 89867. *** This bug has been marked as a duplicate of bug 89867 ***
[Bug c++/89867] internal compiler error: in layout_type, at stor-layout.c:2578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89867 Andrew Pinski changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #5 from Andrew Pinski --- *** Bug 63578 has been marked as a duplicate of this bug. ***
[Bug target/94437] Internal compiler error in avr-g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94437 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #8 from Andrew Pinski --- Dup of bug 97377. *** This bug has been marked as a duplicate of bug 97377 ***
[Bug c++/97377] Segmentation fault while compiling Marlin code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97377 Andrew Pinski changed: What|Removed |Added CC||gatk555 at gmail dot com --- Comment #2 from Andrew Pinski --- *** Bug 94437 has been marked as a duplicate of this bug. ***
[Bug sanitizer/102515] UBSAN misses signed division instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102515 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-10-01 --- Comment #4 from Richard Biener --- I have a patch.
[Bug c++/99] Bug in template type in error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||egallager at gcc dot gnu.org --- Comment #24 from Eric Gallager --- (In reply to Manuel López-Ibáñez from comment #22) > Perhaps the only solution is to not pretty-print the candidates, which is > exactly what clang does: > > pr99.cc:8:10: error: call to 'f' is ambiguous > return f(X(), X()); > ^ > pr99.cc:4:26: note: candidate function [with Q = int] > template int f(X, X); > ^ > pr99.cc:5:26: note: candidate function [with B = int] > template int f(X, X); > ^ > > Dodji, as the diagnostics maintainer, would that be an acceptable fix? While Dodji is still technically listed as a diagnostics maintainer, David Malcolm has been more active as such lately, so I'm cc-ing him, too, to ask him...
[Bug c++/71740] [9/10 Regression] ICE when defining a pointer to the `memcpy()` function with namespace scope using `auto` targeting i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71740 Andrew Pinski changed: What|Removed |Added Known to fail||6.1.0 Target Milestone|--- |9.5 Keywords||needs-bisection Known to work||5.5.0 Summary|ICE when defining a pointer |[9/10 Regression] ICE when |to the `memcpy()` function |defining a pointer to the |with namespace scope using |`memcpy()` function with |`auto` targeting i686 |namespace scope using ||`auto` targeting i686 --- Comment #3 from Andrew Pinski --- Though this is a regression. It is related to PR 102548.
[Bug c++/71740] [9/10 Regression] ICE when defining a pointer to the `memcpy()` function with namespace scope using `auto` targeting i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71740 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-10-01 Status|UNCONFIRMED |NEW
[Bug sanitizer/102515] UBSAN misses signed division instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102515
--- Comment #5 from Jakub Jelinek ---
Created attachment 51529
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51529&action=edit
gcc12-pr102515.patch
I have one too, even bootstrapped/regtested overnight, just didn't get to
writing new testcases that would cover the cases that need testing (i.e. that
-f{,no-}sanitize-recover=float-divide-by-zero rather than
-f{,no-}sanitize-recover=integer-divide-by-zero decides on *_abort for float
division and the behavior for -fsanitize=undefined
-fno-sanitize-recover=integer-divide-by-zero or -fsanitize=undefined
-fno-sanitize-recover=signed-integer-overflow (i.e. when integer-divide-by-zero
and signed-integer-overflow differ in the recover method).
[Bug c++/101914] internal compiler error: in tsubst, at cp/pt.c:15553
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101914 --- Comment #2 from Andrew Pinski --- GCC 6 rejected the code.
[Bug c++/86661] [9 Regression] g++ ICE:tree check: expected tree that contains ‘decl minimal’ structure, have ‘overload’ in note_name_declared_in_class, at cp/class.c:8288
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86661 Andrew Pinski changed: What|Removed |Added Target Milestone|9.5 |9.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Summary|g++ ICE:tree check: |[9 Regression] g++ ICE:tree |expected tree that contains |check: expected tree that |‘decl minimal’ structure, |contains ‘decl minimal’ |have ‘overload’ in |structure, have ‘overload’ |note_name_declared_in_class |in |, at cp/class.c:8288|note_name_declared_in_class ||, at cp/class.c:8288 --- Comment #10 from Andrew Pinski --- Fixed.
[Bug sanitizer/102515] UBSAN misses signed division instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102515
--- Comment #6 from Richard Biener ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 51529 [details]
> gcc12-pr102515.patch
>
> I have one too, even bootstrapped/regtested overnight, just didn't get to
> writing new testcases that would cover the cases that need testing (i.e. that
> -f{,no-}sanitize-recover=float-divide-by-zero rather than
> -f{,no-}sanitize-recover=integer-divide-by-zero decides on *_abort for float
> division and the behavior for -fsanitize=undefined
> -fno-sanitize-recover=integer-divide-by-zero or -fsanitize=undefined
> -fno-sanitize-recover=signed-integer-overflow (i.e. when
> integer-divide-by-zero and signed-integer-overflow differ in the recover
> method).
OK, so yours looks mostly identical to mine, even handling one minor case
better and erring on the side to not preserve divide overflow with
divide-by-zero (which I think is reasonable).
I've yet only added c-c++-common/ubsan/overflow-div-1.c as
/* { dg-do run } */
/* { dg-options "-fsanitize=signed-integer-overflow" } */
/* { dg-shouldfail "ubsan" } */
int __attribute__((noipa))
foo (int a, int b)
{
return a / b;
}
int
main ()
{
return foo (-__INT_MAX__ - 1, -1);
}
/* { dg-output "cannot be represented" } */
and did not add testcases for the fixed float-divide recovery (which I also
noticed and fixed).
Note I simply track whether _all_ of the used instrumentations have
recovery enabled and if not then go the abort path.
[Bug sanitizer/102515] UBSAN misses signed division instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102515 --- Comment #7 from Richard Biener --- Created attachment 51530 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51530&action=edit patch For reference, this is my patch.
[Bug c++/12277] eliminate and warn on dynamic casts with known NULL results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12277 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #12 from Eric Gallager --- Would this warning go under an existing flag, or a new one?
[Bug c++/101043] ICE in check_noexcept_r for lambda conditional noexcept via requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101043 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2021-06-14 00:00:00 |2021-10-1 --- Comment #2 from Andrew Pinski --- The ICE moved in GCC 11+: : In instantiation of 'void intersect(const set&, const set&) [with T = int]': :19:12: required from here :9:12: internal compiler error: in strip_typedefs_expr, at cp/tree.c:1864
[Bug libstdc++/102447] std::regex incorrectly accepts invalid bracket expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102447 Jonathan Wakely changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|NEW --- Comment #4 from Jonathan Wakely --- Reopening. JavaScript engines in web browsers accept invalid regexes for legacy support: https://262.ecma-international.org/#sec-additional-ecmascript-features-for-web-browsers If we're not implementing a browser engine, then it should be a syntax error: NonemptyClassRanges :: ClassAtom - ClassAtom ClassRanges It is a Syntax Error if IsCharacterClass of the first ClassAtom is true or IsCharacterClass of the second ClassAtom is true. It is a Syntax Error if IsCharacterClass of the first ClassAtom is false and IsCharacterClass of the second ClassAtom is false and the CharacterValue of the first ClassAtom is larger than the CharacterValue of the second ClassAtom.
[Bug libstdc++/102445] [meta-bug] std::regex issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445 Bug 102445 depends on bug 102447, which changed state. Bug 102447 Summary: std::regex incorrectly accepts invalid bracket expression https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102447 What|Removed |Added Status|RESOLVED|NEW Resolution|INVALID |---
[Bug c++/101043] ICE in check_noexcept_r for lambda conditional noexcept via requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101043 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98333 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > The ICE moved in GCC 11+: > : In instantiation of 'void intersect(const set&, const set&) > [with T = int]': > :19:12: required from here > :9:12: internal compiler error: in strip_typedefs_expr, at > cp/tree.c:1864 Maybe the patch for PR 98333 changed where the ICE is ...
[Bug c++/101239] "Internal compiler error: Error reporting routines re-entered." in size_in_bytes_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101239 Andrew Pinski changed: What|Removed |Added Depends on||24663 --- Comment #3 from Andrew Pinski --- I suspect the real issue is with zero sized arrays which we had problems with before; PR 24663 . Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24663 [Bug 24663] Template instantiation generating a zero-sized array doesn't fail
[Bug c++/101343] ICE in tsubst_copy, at cp/pt.c:15732
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101343
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW |RESOLVED
--- Comment #4 from Andrew Pinski ---
Yes this is a dup of bug 95317:
enum { Size };
QStaticStringData qstring_literal;
Gives the hint there.
*** This bug has been marked as a duplicate of bug 95317 ***
[Bug c++/95317] [9/10 Regression] ICE on valid C++14 code, in tsubst_copy, at cp/pt.c:15649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95317 Andrew Pinski changed: What|Removed |Added CC||tim at ngus dot net --- Comment #8 from Andrew Pinski --- *** Bug 101343 has been marked as a duplicate of this bug. ***
[Bug target/102544] GCN offloading not working for 'amdgcn-amd-amdhsa--gfx906:sramecc+:xnack-'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102544
--- Comment #3 from Andrew Stubbs ---
That output shows that we have the correct libgomp and rocm is installed and
working. Libgomp initialized the GCN plugin, but did not attempt to initialize
the device (the next message in the output should have been "Selected kernel
arguments memory region", or at least a GCN error message).
Instead we have a target-independent libgomp error. Presumably the kernel
metadata is malformed, somehow?
I think we need a testcase to debug this further, preferably reduced to be as
simple as possible.
Perhaps it would be a good idea to start with a minimal toy example and see if
that works on the device.
#include
#include
int main ()
{
int v = 1;
#pragma acc parallel copy(v)
{
if (acc_on_device(acc_device_host))
v = -1; // error
else {
v = 2; // success
}
}
printf ("v is %d\n", v);
return v;
}
[Bug tree-optimization/102542] [12 Regression] ICE Segmentation fault since r12-3876-g4a960d548b7d7d94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102542 Aldy Hernandez changed: What|Removed |Added CC||jeffreyalaw at gmail dot com --- Comment #5 from Aldy Hernandez --- (In reply to rguent...@suse.de from comment #4) > On Thu, 30 Sep 2021, aldyh at gcc dot gnu.org wrote: Thanks for the loop explanation. It's quite helpful. > So the threading at hand rotates the loop (which is only so-so OK), > that might be problematic in case it creates a non-do-while loop > after loop header copying. > > In this process it might also lose track of the loop, causing it to > be re-discovered as separate entity which has problems of its own. > > IMHO we should avoid threadings through a loop header if the path > ends in the loop itself, even if it doesn't introduce a new entry but > just re-directs the existing one. It looks like Jeff and you have stumbled on various corner cases we must address in cancel_invalid_paths(). Could I inconvenience you to tweak this function with your insight? It's a tiny function, and it seems you're much more qualified to add the restriction code. If not, I'm sure I can stumble around it and send it for review. Orthogonal to this, it does look like the extra thread is causing an ICE in slp which must be addressed?? Thanks.
[Bug target/102552] New: i386 failing tests after r12-4038-g6de9f0c13b27c34336587da19d03200f8cc6bcd5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102552
Bug ID: 102552
Summary: i386 failing tests after
r12-4038-g6de9f0c13b27c34336587da19d03200f8cc6bcd5
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
The following 2 tests do fail after my revision:
FAIL: gcc.target/i386/avx512fp16-reduce-op-2.c scan-tree-dump-times optimized
".REDUC_MAX" 3
FAIL: gcc.target/i386/avx512fp16-reduce-op-2.c scan-tree-dump-times optimized
".REDUC_MIN" 3
FAIL: gcc.target/i386/avx512fp16-reduce-op-2.c scan-tree-dump-times optimized
".REDUC_PLUS" 3
FAIL: gcc.target/i386/intrinsics_4.c (test for excess errors)
Apparently, it does not happen on all x86_64 systems, strange:
$ cat reduc.c
_Float16
__attribute__((noipa, target("avx512fp16,avx512vl"), optimize("Ofast")))
reduc_add_128 (_Float16* p)
{
_Float16 sum = 0;
for (int i = 0; i != 8; i++)
sum += p[i];
return sum;
}
$ ./xgcc -B. reduc.c -Ofast -fdump-tree-optimized=/dev/stdout
;; Function reduc_add_128 (reduc_add_128, funcdef_no=0, decl_uid=1978,
cgraph_uid=1, symbol_order=0)
__attribute__((optimize ("Ofast"), target ("avx512fp16,avx512vl"), noipa,
noinline, noclone, no_icf))
_Float16 reduc_add_128 (_Float16 * p)
{
vector(8) _Float16 vect__4.6;
_Float16 _24;
[local count: 119292720]:
vect__4.6_5 = MEM [(_Float16 *)p_9(D)];
_24 = .REDUC_PLUS (vect__4.6_5); [tail call]
return _24;
}
while on a different box it does:
$ ./xgcc -B. reduc.c -Ofast -fdump-tree-optimized=/dev/stdout
;; Function reduc_add_128 (reduc_add_128, funcdef_no=0, decl_uid=1978,
cgraph_uid=1, symbol_order=0)
__attribute__((optimize ("Ofast"), target ("avx512fp16,avx512vl"), noipa,
noinline, noclone, no_icf))
_Float16 reduc_add_128 (_Float16 * p)
{
_Float16 sum;
_Float16 _4;
_Float16 _5;
_Float16 _6;
_Float16 _7;
_Float16 _12;
_Float16 _13;
_Float16 _22;
_Float16 _23;
_Float16 _30;
_Float16 _40;
_Float16 _50;
_Float16 _60;
_Float16 _70;
_Float16 _80;
[local count: 119292720]:
_6 = *p_9(D);
_30 = MEM[(_Float16 *)p_9(D) + 2B];
_40 = MEM[(_Float16 *)p_9(D) + 4B];
_13 = _30 + _40;
_50 = MEM[(_Float16 *)p_9(D) + 6B];
_60 = MEM[(_Float16 *)p_9(D) + 8B];
_12 = _50 + _60;
_22 = _12 + _13;
_70 = MEM[(_Float16 *)p_9(D) + 10B];
_80 = MEM[(_Float16 *)p_9(D) + 12B];
_7 = _70 + _80;
_4 = MEM[(_Float16 *)p_9(D) + 14B];
_5 = _4 + _6;
_23 = _5 + _7;
sum_10 = _22 + _23;
return sum_10;
}
[Bug target/102552] i386 failing tests after r12-4038-g6de9f0c13b27c34336587da19d03200f8cc6bcd5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102552 --- Comment #1 from Andrew Pinski --- Maybe binutils version difference?
[Bug tree-optimization/102542] [12 Regression] ICE Segmentation fault since r12-3876-g4a960d548b7d7d94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102542
--- Comment #6 from Richard Biener ---
(In reply to Aldy Hernandez from comment #5)
> (In reply to rguent...@suse.de from comment #4)
> > On Thu, 30 Sep 2021, aldyh at gcc dot gnu.org wrote:
>
> Thanks for the loop explanation. It's quite helpful.
>
> > So the threading at hand rotates the loop (which is only so-so OK),
> > that might be problematic in case it creates a non-do-while loop
> > after loop header copying.
> >
> > In this process it might also lose track of the loop, causing it to
> > be re-discovered as separate entity which has problems of its own.
> >
> > IMHO we should avoid threadings through a loop header if the path
> > ends in the loop itself, even if it doesn't introduce a new entry but
> > just re-directs the existing one.
>
> It looks like Jeff and you have stumbled on various corner cases we must
> address in cancel_invalid_paths().
>
> Could I inconvenience you to tweak this function with your insight? It's a
> tiny function, and it seems you're much more qualified to add the
> restriction code. If not, I'm sure I can stumble around it and send it for
> review.
Something like
diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c
index dcabfdb30d2..b1b77e91176 100644
--- a/gcc/tree-ssa-threadupdate.c
+++ b/gcc/tree-ssa-threadupdate.c
@@ -2811,6 +2811,14 @@ jt_path_registry::cancel_invalid_paths
(vec &path)
cancel_thread (&path, "Path crosses loops");
return true;
}
+ edge entry = path[0]->e;
+ edge exit = path[path.length () - 1]->e;
+ if (entry->src->loop_father != exit->dest->loop_father
+ && !flow_loop_nested_p (exit->src->loop_father,
entry->dest->loop_father))
+{
+ cancel_thread (&path, "Path rotates loop");
+ return true;
+}
return false;
}
that is, the path should either start & end in the same loop or overall
exit the loop it starts in but never enter a loop (the above also catches
creating irreducible loops, not only rotation).
I find the
// The first entry represents the block with an outgoing edge
// that we will redirect to the jump threading path. Thus we
// don't care about that block's loop father.
if ((i > 0 && e->src->loop_father != loop)
|| e->dest->loop_father != loop)
path_crosses_loops = true;
mildly confusing and don't really understand what it is about. What's
not present yet is avoiding to thread through the loop header. For that
I'd add in the loop
if (e->dest->loop_father->header == e->dest
&& !flow_loop_nested_p (exit->dest->loop_father,
e->dest->loop_father)
cancel_thread ("Path crosses loop header but does not exit it");
such threadings tend to create sub-loops which _might_ be OK, not sure.
This is stricter than the above suggestion since it also covers paths
that remain in the same loop but it should cover the above cases as well.
Note it's difficult to tell whether the created sub-loop is irreducible.
This check should also prevent us from creating multiple latches.
> Orthogonal to this, it does look like the extra thread is causing an ICE in
> slp which must be addressed??
Yes, we have duplicates for this crash which is caused by some changes
Richard Sandiford did.
[Bug sanitizer/102515] UBSAN misses signed division instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102515
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9c1a633d96926357155d4702b66f8a0ec856a81f
commit r12-4042-g9c1a633d96926357155d4702b66f8a0ec856a81f
Author: Jakub Jelinek
Date: Fri Oct 1 14:27:32 2021 +0200
ubsan: Move INT_MIN / -1 instrumentation from
-fsanitize=integer-divide-by-zero to -fsanitize=signed-integer-overflow
[PR102515]
As noted by Richi, in clang INT_MIN / -1 is instrumented under
-fsanitize=signed-integer-overflow rather than
-fsanitize=integer-divide-by-zero as we did and doing it in the former
makes more sense, as it is overflow during division rather than division
by zero.
I've verified on godbolt that clang behaved that way since 3.2-ish times or
so when sanitizers were added.
Furthermore, we've been using
-f{,no-}sanitize-recover=integer-divide-by-zero to decide on the float
-fsanitize=float-divide-by-zero instrumentation _abort suffix.
The case where INT_MIN / -1 is instrumented by one sanitizer and
x / 0 by another one when both are enabled is slightly harder if
the
-f{,no-}sanitize-recover={integer-divide-by-zero,signed-integer-overflow}
flags differ, then we need to emit both __ubsan_handle_divrem_overflow
and __ubsan_handle_divrem_overflow_abort calls guarded by their respective
checks rather than one guarded by check1 || check2.
2021-10-01 Jakub Jelinek
Richard Biener
PR sanitizer/102515
gcc/
* doc/invoke.texi (-fsanitize=integer-divide-by-zero): Remove
INT_MIN / -1 division detection from here ...
(-fsanitize=signed-integer-overflow): ... and add it here.
gcc/c-family/
* c-ubsan.c (ubsan_instrument_division): Check the right
flag_sanitize_recover bit, depending on which sanitization
is done. Sanitize INT_MIN / -1 under SANITIZE_SI_OVERFLOW
rather than SANITIZE_DIVIDE. If both SANITIZE_SI_OVERFLOW
and SANITIZE_DIVIDE is enabled, neither check is known
to be false and flag_sanitize_recover bits for those two
aren't the same, emit both __ubsan_handle_divrem_overflow
and __ubsan_handle_divrem_overflow_abort calls.
gcc/c/
* c-typeck.c (build_binary_op): Call ubsan_instrument_division
for division even for SANITIZE_SI_OVERFLOW.
gcc/cp/
* typeck.c (cp_build_binary_op): Call ubsan_instrument_division
for division even for SANITIZE_SI_OVERFLOW.
gcc/testsuite/
* c-c++-common/ubsan/div-by-zero-3.c: Use
-fsanitize=signed-integer-overflow instead of
-fsanitize=integer-divide-by-zero.
* c-c++-common/ubsan/div-by-zero-5.c: Likewise.
* c-c++-common/ubsan/div-by-zero-4.c: Likewise. Add
-fsanitize-undefined-trap-on-error.
* c-c++-common/ubsan/float-div-by-zero-2.c: New test.
* c-c++-common/ubsan/overflow-div-1.c: New test.
* c-c++-common/ubsan/overflow-div-2.c: New test.
* c-c++-common/ubsan/overflow-div-3.c: New test.
[Bug c++/102496] [11 regression] extern __thread and thread_local declaration in function scope produces a non-TLS reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102496 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 regression] extern |[11 regression] extern |__thread and thread_local |__thread and thread_local |declaration in function |declaration in function |scope produces a non-TLS|scope produces a non-TLS |reference |reference --- Comment #6 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/102504] [12 Regression] ICE in build_outer_var_ref, at omp-low.c:746
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102504 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/102546] [12 Regregression] Missed Dead Code Elimination regression (trunk vs 11.2.0) at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546 --- Comment #8 from Andrew Macleod --- On 10/1/21 5:18 AM, aldyh at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102546 > > Aldy Hernandez changed: > > What|Removed |Added > > Last reconfirmed||2021-10-01 > Status|UNCONFIRMED |NEW > Ever confirmed|0 |1 > Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot > gnu.org > > --- Comment #5 from Aldy Hernandez --- > (In reply to Richard Biener from comment #4) >> (In reply to Aldy Hernandez from comment #2) >>> By VRP1 we seem to be calculating the following: >>> >>> (f_8 << f_8) && (f_8 == 0) >>> >>> This would fold to false, which would elide the foo(): >>> >>>[local count: 59055800]: >>>b = 0; >>>_3 = f_8 << f_8; >>>_4 = (char) _3; >>>_5 = (int) _4; >>>if (_4 > 0) >>> goto ; [64.06%] >>>else >>> goto ; [35.94%] >>> >>> [local count: 34842922]: >>>if (f_8 == 0) >>> goto ; [71.10%] >>>else >>> goto ; [28.90%] >>> >>> [local count: 12809203]: >>>foo (); >> I think it's similar to in the other PR, with old EVRP when visiting BB 8 >> we pushed [1, +INF] as the global range for _4, then supposedly ranger >> manages to evaluate f_8 == 0 with its backward infering somehow. >> >> We no longer do this "path sensitive" adjustment of (global) ranges since >> you removed the EVRP DOM walk algorithm. > The hybrid threader does path sensitive ranges and relationals. What's > missing > is the range-op entry for the following relation: > >~[0,0] = x << x > > In this case, we know that X cannot be 0. Fixing this, causes all the right > things to happen. > > However, I see that the none of the op1_range entries are being called with a > relation. Presumably this was an oversight on Andrew's part, but can easily > be > fixed. Not an oversight. I believe I added the infrastructure to pass relations to GORI when I introduce relations to range-ops for folding, but there has not been time to flush out actually utilizing them yet. I can maybe take a look at that next week. maybe. It also opens up some possibilities for solving unsigned overflow questions: c_1 = a_2 + 2 if (c_1 < a_2) // check overflow condition On the true edge, solving [1,1] = c_1 < a_2... would propagate c_1 < a_2 to the defining insn as: [varying] = a_2 + 2, (LHS < a_2). op1_range for PLUS can use that relation to determine that a_2 must be fully contained in [INF - 1, INF] on the TRUE side, and therefore c_1 is [0,1]. The false side would then also calculate a_2 = [0, INF - 2] and c_1 as [2, INF] > Interestingly on this case, the VRP threader shouldn't even need to step up > here. VRP1 should have folded the conditional in BB8. The new evrp can > though. If I tweak range-ops, and call execute_early_vrp() from VRP1, evrp > folds the conditional and there's no need to thread. > > Now before Andrew asks why evrp doesn't clean this up earlier (with the > range-ops tweak), it's because the IL is different. See my question about the > "a" present in earlier passes. ;-) > > So...mine. I'll address all the issues pointed out. >
[Bug c++/102538] [11/12 Regression] Wrong narrowing conversion checking for initializer with union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102538
--- Comment #3 from Jakub Jelinek ---
Testcase for the wrong-code:
struct X { union { char r8[8]; int r32[2]; }; };
struct Y { X v[1]; };
Y x = { { { .r32 = { 5, 6 } } } };
int
main ()
{
if (x.v[0].r32[0] != 5 || x.v[0].r32[1] != 6)
__builtin_abort ();
}
[Bug target/102552] i386 failing tests after r12-4038-g6de9f0c13b27c34336587da19d03200f8cc6bcd5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102552
--- Comment #2 from Martin Liška ---
No, it's related to fact that:
bool
parse_optimize_options (tree args, bool attr_p)
{
...
/* Build up argv vector. Just in case the string is stored away, use garbage
collected strings. */
vec_safe_truncate (optimize_args, 0);
vec_safe_push (optimize_args, (const char *) NULL);
As seen we push NULL pointer as the first vector element. Why do we do that?
[Bug target/102552] i386 failing tests after r12-4038-g6de9f0c13b27c34336587da19d03200f8cc6bcd5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102552 --- Comment #3 from Martin Liška --- Oh, it's because it calls eventually decode_cmdline_options_to_array that skips the first argument (program name).
[Bug target/102552] i386 failing tests after r12-4038-g6de9f0c13b27c34336587da19d03200f8cc6bcd5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102552 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:5051fad8582fcbdd0844232b5a8c4e856be5e5a4 commit r12-4045-g5051fad8582fcbdd0844232b5a8c4e856be5e5a4 Author: Martin Liska Date: Fri Oct 1 15:37:59 2021 +0200 options: fix concat of options. PR target/102552 gcc/c-family/ChangeLog: * c-common.c (parse_optimize_options): decoded_options[0] is used for program name, so merged_decoded_options should also respect that.
[Bug target/102552] i386 failing tests after r12-4038-g6de9f0c13b27c34336587da19d03200f8cc6bcd5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102552 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška --- Fixed now.
[Bug c++/102553] New: internal compiler error: Segmentation fault for struct based parameter of template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102553 Bug ID: 102553 Summary: internal compiler error: Segmentation fault for struct based parameter of template Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- Created attachment 51531 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51531&action=edit Linux Preprocessor file x86_64-ubuntu-linux-gnu-g++ -c a.cc -I../../include -Ofast -std=c++20 -ffreestanding= In file included from ../../include/fast_io_core_impl/integers/integer.h:5, from ../../include/fast_io_core.h:63, from a.cc:1: ../../include/fast_io_core_impl/integers/impl.h: In substitution of 'template using scalar_manip_precision_t = fast_io::manipulators::scalar_manip_t<((const fast_io::manipulators::scalar_flags)flags), fast_io::manipulators::precision_holder > [with fast_io::manipulators::scalar_flags flags = dcmfloat_mani_flags_cache; T = __float128]': ../../include/fast_io_core_impl/integers/impl.h:418:148: required from here ../../include/fast_io_core_impl/integers/impl.h:108:49: internal compiler error: Segmentation fault 108 | using scalar_manip_precision_t = scalar_manip_t>; Problem exists on other platforms too. You can just test preprocessor file since it is freestanding.
[Bug c++/102553] internal compiler error: Segmentation fault for struct based parameter of template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102553 cqwrteur changed: What|Removed |Added CC||unlvsur at live dot com --- Comment #1 from cqwrteur --- Created attachment 51532 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51532&action=edit windows preprocessor file
[Bug c++/102553] internal compiler error: Segmentation fault for struct based parameter of template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102553 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-10-01 Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Confirmed, I'm reducing that right now.
[Bug debug/102507] ICE in btf_finalize when compiling with -gbtf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102507 Indu Bhagat changed: What|Removed |Added CC||ibhagat at gcc dot gnu.org --- Comment #3 from Indu Bhagat --- (In reply to Martin Liška from comment #2) > Is it fixed now? I would like to compile another application before I close this one (should be doable coming monday, the remote machine I need for this has been taken down for maintenance :/).
[Bug c++/102553] internal compiler error: Segmentation fault for struct based parameter of template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102553 Martin Liška changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from Martin Liška --- Can you compile it with clang?
[Bug tree-optimization/102542] [12 Regression] ICE Segmentation fault since r12-3876-g4a960d548b7d7d94
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102542 --- Comment #7 from Aldy Hernandez --- On Fri, Oct 1, 2021 at 1:46 PM rguenth at gcc dot gnu.org wrote: > > Could I inconvenience you to tweak this function with your insight? It's a > > tiny function, and it seems you're much more qualified to add the > > restriction code. If not, I'm sure I can stumble around it and send it for > > review. > > Something like > > diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c > index dcabfdb30d2..b1b77e91176 100644 Thanks so much for this. I will test it, and incorporate it with some ideas Jeff had suggested. Then I'll post it upstream for review/discussion. BTW, it seems that the code restricting paths should actually live in the loop world...since it's the loop experts who know what is allowed and what is problematic ;-).
[Bug c++/102538] [11/12 Regression] Wrong narrowing conversion checking for initializer with union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102538
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #4 from Patrick Palka ---
Analogous constexpr testcase:
struct X { union { char r8[8]; int r32[2]; }; };
struct Y { X v; };
constexpr Y x = { { .r32 = { 5, 6 } } };
static_assert(x.v.r32[0] == 5 && x.v.r32[1] == 6);
The error is perhaps insightful:
:4:31: error: non-constant condition for static assertion
:4:31: error: accessing ‘Xr32’ member instead of
initialized ‘Xr8’ member in constant expression
[Bug c++/102538] [11/12 Regression] Wrong narrowing conversion checking for initializer with union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102538 --- Comment #5 from Jakub Jelinek --- Yeah, the above mentioned reshape* change results in the r32 index of d->cur being ignored when recursing into the anonymous union.
[Bug c++/102553] internal compiler error: Segmentation fault for struct based parameter of template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102553 --- Comment #4 from cqwrteur --- (In reply to Martin Liška from comment #3) > Can you compile it with clang? yes I can
[Bug c++/102553] internal compiler error: Segmentation fault for struct based parameter of template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102553 --- Comment #5 from cqwrteur --- (In reply to Martin Liška from comment #3) > Can you compile it with clang? msvc, clang they all work.
[Bug c++/101783] unnecessary error when top level cv qualifier is dropped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101783 --- Comment #10 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:7c99923f8c544ec07109e8333acb2c2388c38a1b commit r12-4051-g7c99923f8c544ec07109e8333acb2c2388c38a1b Author: qingzhe huang Date: Fri Oct 1 10:46:35 2021 -0400 c++: cv-qualified ref introduced by typedef [PR101783] The root cause of this bug is that it considers reference with cv-qualifiers as an error by generating value for variable "bad_quals". However, this is not correct for case of typedef. Here I quote spec [dcl.ref]/1 : "Cv-qualified references are ill-formed except when the cv-qualifiers are introduced through the use of a typedef-name ([dcl.typedef], [temp.param]) or decltype-specifier ([dcl.type.decltype]), in which case the cv-qualifiers are ignored." 2021-09-30 qingzhe huang gcc/cp/ChangeLog: PR c++/101783 * tree.c (cp_build_qualified_type_real): Exclude typedef from error. gcc/testsuite/ChangeLog: PR c++/101783 * g++.dg/parse/pr101783.C: New test.
[Bug ipa/102554] New: [ 10/11/12 Regresion ] Inlining missed at -O3 with non-default --param=early-inlining-insns and pragma optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102554
Bug ID: 102554
Summary: [ 10/11/12 Regresion ] Inlining missed at -O3 with
non-default --param=early-inlining-insns and pragma
optimize
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: jschoen4 at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
GNU C++14 (GCC) version 10.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 10.2.0, GMP version 6.0.0, MPFR version
3.1.1, MPC version 1.0.1, isl version isl-0.16.1-GMP
Target: x86_64-pc-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC)
===
=TEST CODE=
===
cat test.cpp
#pragma GCC push_options
#pragma GCC optimize ("no-lifetime-dse")
class TestClass
{
public:
static inline int should_inline() {
return 10;
}
};
#pragma GCC pop_options
int main() {
return TestClass::should_inline() + 1;
}
===
=cmd =
===
gcc-10 test.cpp -S --param=early-inlining-insns=30 -O3 -fno-lifetime-dse -Wall
-Wextra
===
=BAD ASM =
===
cat test.s
.file "test.cpp"
.text
.section
.text._ZN9TestClass13should_inlineEv,"axG",@progbits,_ZN9TestClass13should_inlineEv,comdat
.p2align 4
.weak _ZN9TestClass13should_inlineEv
.type _ZN9TestClass13should_inlineEv, @function
_ZN9TestClass13should_inlineEv:
.LFB0:
.cfi_startproc
movl$10, %eax
ret
.cfi_endproc
.LFE0:
.size _ZN9TestClass13should_inlineEv,
.-_ZN9TestClass13should_inlineEv
.section.text.startup,"ax",@progbits
.p2align 4
.globl main
.type main, @function
main:
.LFB1:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
call_ZN9TestClass13should_inlineEv
addq$8, %rsp
.cfi_def_cfa_offset 8
addl$1, %eax
ret
.cfi_endproc
.LFE1:
.size main, .-main
.ident "GCC: (GNU) 10.2.0"
.section.note.GNU-stack,"",@progbits
===
=info =
===
cat test.cpp.079i.inline
...
Deciding on inlining of small functions. Starting with size 9.
Enqueueing calls in int main()/1.
test.cpp:13:34: missed: not inlinable: int main()/1 -> static int
TestClass::should_inline()/0, optimization level attribute mismatch
param_early_inlining_insns (0x1e/0xe)
Enqueueing calls in static int TestClass::should_inline()/0.
node context cache: 0 hits, 0 misses, 1 initializations
...
===
=GOOD ASM =
===
gcc-10 test.cpp -S --param=early-inlining-insns=14 -O3 -fno-lifetime-dse -Wall
-Wextra
.file "test.cpp"
.text
.section.text.startup,"ax",@progbits
.p2align 4
.globl main
.type main, @function
main:
.LFB1:
.cfi_startproc
movl$11, %eax
ret
.cfi_endproc
.LFE1:
.size main, .-main
.ident "GCC: (GNU) 10.2.0"
.section.note.GNU-stack,"",@progbits
==
=notes=
==
Starting with gcc 10+ (gcc9 works correctly), the use of
--param=early-inlining-insns=30 and -O3 on the command line combined with using
a "#pragma GCC optimize" in source code, even one that does not change the
effective optimization attributes, causes "optimization level attribute
mismatch" to occur in the inliner.
In the example I placed both -fno-lifetime-dse on the command line and in the
pragma gcc optimize ("no-lifetime-dse"), so it has no impact at all to the
effective optimization attributes.
The issue is not specific to using just pragma GCC optimize "no-lifetime-dse",
any pragma gcc optimize line will have this effect. Even "unrecognized" ones.
i.e.
#pragma GCC optimize ("fake_attribute")
Any value OTHER THAN --param=early-inlining-insns=14 on the command line when
used with -O3 and pragma optimize will trigger this.
.. i.e.
==
=optimize correctly =
==
gcc-10 test.cpp -S --param=early-inlining-insns=14 -O3 -fno-lifetime-dse -Wall
-Wextra
gcc-10 test.cpp -S --param=early-inlining-insns=30 -O2 -fno-lifetime-dse -Wall
-Wextra
gcc-9 test.cpp -S --param=early-inlining-insns=30 -O3 -fno-lifetime-dse -Wall
-Wextra
==
=missed optimize =
==
gcc-10 test.cpp -S --param=early-inlining-insns=12 -O3 -fno-lifetime-dse -Wall
-Wextra
gcc-10 test.cpp -S --param=early-inlining-insns=17 -O3 -fno-lifetime-dse -Wall
-Wextra
etc.
gcc-11 test.cpp -S --param=early-inlining-insns=30 -O3 -fno-lifetime-dse -Wall
-Wextra
gcc-12 test.cpp -S --param=early-inlining-insns=30 -O3 -fno-lifetime-dse -Wall
-Wextra
gcc-trunk test.cpp -S --param=early-inlining-insns=30 -O3 -fno-l
[Bug target/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968 Maxim Kuvyrkov changed: What|Removed |Added CC||mkuvyrkov at gcc dot gnu.org Assignee|thomas.preudhomme at celest dot fr |unassigned at gcc dot gnu.org --- Comment #16 from Maxim Kuvyrkov --- AFAIK, Thomas isn't working on this.
[Bug target/86968] Unaligned big-endian (scalar_storage_order) access on armv7-a yields 4 ldrb instructions rather than ldr+rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86968 Maxim Kuvyrkov changed: What|Removed |Added Status|ASSIGNED|UNCONFIRMED Ever confirmed|1 |0
[Bug rtl-optimization/90378] [9/10/11/12 regression] -Os -flto miscompiles 454.calculix after r266385 on Arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90378 Maxim Kuvyrkov changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #13 from Maxim Kuvyrkov --- This problem has not been occurring since we have moved aarch32 benchmarking to a machine with newer kernel. Closing.
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 90378, which changed state. Bug 90378 Summary: [9/10/11/12 regression] -Os -flto miscompiles 454.calculix after r266385 on Arm https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90378 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME
[Bug c/102555] New: missing -Waddress comparing &p[0] to zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102555
Bug ID: 102555
Summary: missing -Waddress comparing &p[0] to zero
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Event with the patch for pr102103 applied, only the first of the two equality
expressions gets a warning, even though ideally both should. This is tracked
(and xfailed) in gcc/testsuite/c-c++-common/Waddress-4.c.
$ cat z.c && gcc -S -Wall -fdump-tree-original=/dev/stdout z.c
int f (int *p, int i)
{
return &p[i] == 0;
}
int g (int *p)
{
return &p[0] == 0;
}
z.c: In function ‘f’:
z.c:3:16: warning: the comparison will always evaluate as ‘false’ for the
pointer operand in ‘p + (sizetype)((long unsigned int)i * 4)’ must not be NULL
[-Waddress]
3 | return &p[i] == 0;
|^~
;; Function f (null)
;; enabled by -tree-original
{
return p + (sizetype) ((long unsigned int) i * 4) == 0B;
}
;; Function g (null)
;; enabled by -tree-original
{
return p == 0B;
}
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 --- Comment #15 from qinzhao at gcc dot gnu.org --- (In reply to Richard Biener from comment #13) > Because the variable doesn't need to be addressable. > > OK, so the issue is likely that we're probing the lhs with EXPAND_WRITE but > when we expand the memset we end up with using expand_expr_addr_expr_1 > with EXPAND_NORMAL. then can we change the probing to use EXPAND_NORMAL?
[Bug tree-optimization/102556] New: equality comparison of a [static N] parameter to null not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102556
Bug ID: 102556
Summary: equality comparison of a [static N] parameter to null
not folded
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The C99 [static N] array notation in a function parameter indicates that the
caller must provide as an argument an array with at least N element.
Therefore, in the body of the function, the parameter may be assumed to be
nonnull, the same way as if it had been declared with attribute nonnull.
The test case below shows that GCC fails to take advantage of this to fold
pointless comparisons of such parameters to null, even though it does make use
of the equivalent guarantee provided by the attribute.
In contrast, Clang folds the expression in both functions to false.
$ cat z.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout z.c
__attribute__ ((nonnull)) int f (int *a)
{
return a == 0; // folded to false with a warning (good)
}
int g (int a[static 1])
{
return a == 0; // not folded, missing warning
}
z.c: In function ‘f’:
z.c:3:12: warning: ‘nonnull’ argument ‘a’ compared to NULL [-Wnonnull-compare]
3 | return a == 0; // folded to false with a warning (good)
| ~~^~~~
;; Function f (f, funcdef_no=0, decl_uid=1978, cgraph_uid=1, symbol_order=0)
__attribute__((nonnull))
int f (int * a)
{
[local count: 1073741824]:
return 0;
}
;; Function g (g, funcdef_no=1, decl_uid=1981, cgraph_uid=2, symbol_order=1)
__attribute__((access ("^0[s1]", )))
int g (int * a)
{
_Bool _1;
int _3;
[local count: 1073741824]:
_1 = a_2(D) == 0B;
_3 = (int) _1;
return _3;
}
[Bug ipa/102557] New: [12 Regression] ICE: Segmentation fault signal terminated program cc1plus (indefinite recursion in modref_ref_node::insert_access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102557 Bug ID: 102557 Summary: [12 Regression] ICE: Segmentation fault signal terminated program cc1plus (indefinite recursion in modref_ref_node::insert_access) Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com CC: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 51533 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51533&action=edit Testcase g++-12.0.0-alpha20210926 snapshot (g:fe2771b291c2c7c0ac37b75ec5b160937524b60c) ICEs when compiling the attached testcase, reduced from libstdc++-v3/testsuite/22_locale/time_get/get_monthname/char/6.cc, w/ -O3 --param max-inline-insns-single=2 --param modref-max-accesses=2: % g++-12.0.0 -O3 --param max-inline-insns-single=2 --param modref-max-accesses=2 -c xv7snbwu.cc g++-12.0.0: internal compiler error: Segmentation fault signal terminated program cc1plus (gdb) where #0 0x00f345c7 in modref_access_node::merge (this=this@entry=0x777533f8, a=..., record_adjustments=record_adjustments@entry=false) at /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210926/work/gcc-12-20210926/gcc/ipa-modref-tree.h:204 #1 0x00f35235 in modref_access_node::forced_merge (this=0x777533f8, a=..., record_adjustments=) at /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210926/work/gcc-12-20210926/gcc/ipa-modref-tree.h:351 #2 0x00f39654 in modref_ref_node::insert_access (this=this@entry=0x77732f00, a=..., max_accesses=max_accesses@entry=2, record_adjustments=record_adjustments@entry=false) at /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210926/work/gcc-12-20210926/gcc/ipa-modref-tree.h:575 #3 0x00f397de in modref_ref_node::insert_access (this=this@entry=0x77732f00, a=..., max_accesses=max_accesses@entry=2, record_adjustments=record_adjustments@entry=false) at /var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210926/work/gcc-12-20210926/gcc/ipa-modref-tree.h:596
[Bug c/102558] New: missing warning comparing T[static N] to null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102558
Bug ID: 102558
Summary: missing warning comparing T[static N] to null
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
This is the diagnostic part of pr102556:
The C99 [static N] array notation in a function parameter indicates that the
caller must provide as an argument an array with at least N element.
Therefore, in the body of the function, the parameter may be assumed to be
nonnull, the same way as if it had been declared with attribute nonnull.
The test case below shows that GCC fails to issue a warning for the pointless
equality expression in g(), equivalent to the one in f() (although -Waddress
might be more suitable than than -Wnonnull-compare).
$ cat z.c && gcc -O2 -S -Wall z.c
__attribute__ ((nonnull)) int f (int *a)
{
return a == 0; // warning (good, folded to false)
}
int g (int a[static 1])
{
return a == 0; // missing warning (not folded)
}
z.c: In function ‘f’:
z.c:3:12: warning: ‘nonnull’ argument ‘a’ compared to NULL [-Wnonnull-compare]
3 | return a == 0; // warning (good, folded to false)
| ~~^~~~
[Bug middle-end/102285] New flag -ftrivial-auto-var-init=zero causes crash in pr82421.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 --- Comment #16 from Qing Zhao --- > On Oct 1, 2021, at 1:51 AM, rguenth at gcc dot gnu.org > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102285 > > --- Comment #13 from Richard Biener --- > Because the variable doesn't need to be addressable. One question: For the following statement in the routine “fold_builtin_alloca_with_align” in tree-ssa-ccp.c: /* Fold alloca to the address of the array. */ return fold_convert (TREE_TYPE (lhs), build_fold_addr_expr (var)); Clearly, we build a add_expr for “var”, but why not “mark_addressable” for “var” since its address is taken?
[Bug ipa/102557] [12 Regression] ICE: Segmentation fault signal terminated program cc1plus (indefinite recursion in modref_ref_node::insert_access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102557
--- Comment #1 from Arseny Solokha ---
Semi-reduced testcase for the reference:
#include
void
test01 (char *mname)
{
std::istringstream iss;
iss.str (mname);
iss.str (mname);
}
% g++-12.0.0 -std=c++20 -O3 -fopenacc --param max-inline-insns-single=2 --param
modref-max-accesses=2 --param uninlined-function-time=98 -c ujd9xqvr.cc
g++-12.0.0: internal compiler error: Segmentation fault signal terminated
program cc1plus
[Bug c/102559] New: missing warning comparing result of a nonnull function to null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102559
Bug ID: 102559
Summary: missing warning comparing result of a nonnull function
to null
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC folds equality comparisons of nonnull function and null to zero but it
fails to issue any warning for doing so. In contrast, comparing the value of a
pointer parameter and null in a nonnull function triggers a -Wnonnull-compare.
Clang is more consistent and issues warnings for all such (likely) misues.
$ cat z.c && gcc -O -S -Wall -fdump-tree-optimized=/dev/stdout z.c
__attribute__ ((returns_nonnull)) void* f (void);
int g (void)
{
return f () == 0; // missing warning (return folded to zero)
}
int h (void *p, const void *q, int n)
{
return !__builtin_memcpy (p, q, n); // missing warning (folded to zero)
}
;; Function g (g, funcdef_no=0, decl_uid=1980, cgraph_uid=1, symbol_order=0)
int g ()
{
[local count: 1073741824]:
f ();
return 0;
}
;; Function h (h, funcdef_no=1, decl_uid=1985, cgraph_uid=2, symbol_order=1)
int h (void * p, const void * q, int n)
{
long unsigned int _1;
[local count: 1073741824]:
_1 = (long unsigned int) n_4(D);
__builtin_memcpy (p_6(D), q_7(D), _1);
return 0;
}
[Bug target/102544] GCN offloading not working for 'amdgcn-amd-amdhsa--gfx906:sramecc+:xnack-'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102544 --- Comment #4 from miko at predsci dot com --- The result is: v is -1
[Bug target/100734] [12 Regression] /test/gnu/gcc/objdir/gcc/include-fixed/stdlib.h:291:8: internal compiler error: in from_mode_char, at attribs.h:304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100734 --- Comment #15 from CVS Commits --- The releases/gcc-11 branch has been updated by John David Anglin : https://gcc.gnu.org/g:356390c14aa70a95c15845512f2381b627cf9a96 commit r11-9051-g356390c14aa70a95c15845512f2381b627cf9a96 Author: John David Anglin Date: Fri Oct 1 17:18:32 2021 + Use libiberty snprintf and vsnprintf on hppa*-*-hpux*. libiberty/ChangeLog: PR target/100734 * configure.ac: Use libiberty snprintf and vsnprintf on hppa*-*-hpux*. * configure: Regenerate.
[Bug target/102544] GCN offloading not working for 'amdgcn-amd-amdhsa--gfx906:sramecc+:xnack-'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102544 --- Comment #5 from Andrew Stubbs --- Sorry, I should have said to compile with -fopenacc. If you did do that, please post the GCN_DEBUG output.
[Bug c++/102283] Inconsistent/wrong overload resolution when using an initializer list and a defaulted template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102283 --- Comment #5 from Giuseppe D'Angelo --- (Sorry for the delay) Thank you for the analysis. I'm now not really sure if GCC is doing something wrong (vs Clang/MSVC). Feel free to close/suspend this task if you strongly believe GCC is right here.
[Bug debug/102373] Segmentation fault in dwarf2out.c, line 32744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102373 --- Comment #6 from CVS Commits --- The master branch has been updated by John David Anglin : https://gcc.gnu.org/g:f1710910087fb1f4a7706e9ce838163ffcbc50b4 commit r12-4058-gf1710910087fb1f4a7706e9ce838163ffcbc50b4 Author: John David Anglin Date: Fri Oct 1 17:34:09 2021 + Default to dwarf version 4 on hppa64-hpux 2021-10-01 John David Anglin gcc/ChangeLog: PR debug/102373 * config/pa/pa.c (pa_option_override): Default to dwarf version 4 on hppa64-hpux.
[Bug debug/102373] Segmentation fault in dwarf2out.c, line 32744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102373 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by John David Anglin : https://gcc.gnu.org/g:aac3b6a7e3a7b810005343e62e6822338fcb85d4 commit r11-9052-gaac3b6a7e3a7b810005343e62e6822338fcb85d4 Author: John David Anglin Date: Fri Oct 1 17:35:45 2021 + Default to dwarf version 4 on hppa64-hpux 2021-10-01 John David Anglin gcc/ChangeLog: PR debug/102373 * config/pa/pa.c (pa_option_override): Default to dwarf version 4 on hppa64-hpux.
[Bug debug/102373] Segmentation fault in dwarf2out.c, line 32744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102373 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from John David Anglin --- Fixed. Problem was I didn't set dwarf_strict to 1 in change to limit dwarf version.
[Bug c/102103] missing warning comparing array address to null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102103 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:4dc7ce6fb3917958d1a6036d8acf2953b9c1b868 commit r12-4059-g4dc7ce6fb3917958d1a6036d8acf2953b9c1b868 Author: Martin Sebor Date: Fri Oct 1 11:50:25 2021 -0600 Enhance -Waddress to detect more suspicious expressions [PR102103]. Resolves: PR c/102103 - missing warning comparing array address to null gcc/ChangeLog: PR c/102103 * doc/invoke.texi (-Waddress): Update. * gengtype.c (write_types): Avoid -Waddress. * poly-int.h (POLY_SET_COEFF): Avoid using null. gcc/c-family/ChangeLog: PR c/102103 * c-common.c (decl_with_nonnull_addr_p): Handle members. Check and perform warning suppression. (c_common_truthvalue_conversion): Enhance warning suppression. gcc/c/ChangeLog: PR c/102103 * c-typeck.c (maybe_warn_for_null_address): New function. (build_binary_op): Call it. gcc/cp/ChangeLog: PR c/102103 * typeck.c (warn_for_null_address): Enhance. (cp_build_binary_op): Call it also for member pointers. gcc/fortran/ChangeLog: PR c/102103 * array.c: Remove an unnecessary test. * trans-array.c: Same. gcc/testsuite/ChangeLog: PR c/102103 * g++.dg/cpp0x/constexpr-array-ptr10.C: Suppress a valid warning. * g++.dg/warn/Wreturn-local-addr-6.C: Correct a cast. * gcc.dg/Waddress.c: Expect a warning. * c-c++-common/Waddress-3.c: New test. * c-c++-common/Waddress-4.c: New test. * g++.dg/warn/Waddress-5.C: New test. * g++.dg/warn/Waddress-6.C: New test. * g++.dg/warn/pr101219.C: Expect a warning. * gcc.dg/Waddress-3.c: New test.
[Bug c/102103] missing warning comparing array address to null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102103 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 --- Comment #4 from Martin Sebor --- Done for GCC 12.
[Bug c++/33925] gcc -Waddress lost some useful warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33925 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org CC||msebor at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #8 from Martin Sebor --- With pr102103 resolved, let me handle this.
