[Bug analyzer/108028] New: --Wanalyzer-null-dereference false posiative with *q = 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108028
Bug ID: 108028
Summary: --Wanalyzer-null-dereference false posiative with *q =
1
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: mengli.ming at outlook dot com
Target Milestone: ---
I got a false positive error when compiling the following program with
gcc(trunk) -fanalyzer -O2 in https://godbolt.org/z/W37MzrPqd. The
`__analyzer_eval()` statement is added at some suitable places in the code in
order to keep track of the information already available to the analyzer at
some point in the static analysis of the program. After that, I found that
under -O0, for this program (https://godbolt.org/z/Y1GMEMaG9),
`__analyzer_eval(p && (0 == q))`, `__analyzer_eval(p)`, `__analyzer_eval(0 ==
q)` give the same result at the same program point as -O2 without generating
the NPD warning. The following is the result of the analysis obtained using
-O2, please take a look, thank you.
```
#include "stdio.h"
int f(int, int *);
int f(int p, int *q)
{
__analyzer_eval(p && (0 == q));
if (p && (0 == q))
{
__analyzer_eval(p && (0 == q));
__analyzer_eval(p);
__analyzer_eval(0 == p);
__analyzer_eval(q);
__analyzer_eval(0 == q);
*q = 1;
}
printf("NPD_FLAG\n");
}
int main()
{
int a = 0;
int *b = (void*)0;
f(a, b);
}
```
```
: In function 'f':
:6:5: warning: FALSE
6 | __analyzer_eval(p && (0 == q));
| ^~
:6:5: warning: UNKNOWN
:9:9: warning: TRUE
9 | __analyzer_eval(p && (0 == q));
| ^~
:10:9: warning: TRUE
10 | __analyzer_eval(p);
| ^~
:11:9: warning: FALSE
11 | __analyzer_eval(0 == p);
| ^~~
:12:9: warning: UNKNOWN
12 | __analyzer_eval(q);
| ^~
:13:9: warning: TRUE
13 | __analyzer_eval(0 == q);
| ^~~
:14:12: warning: dereference of NULL '0' [CWE-476]
[-Wanalyzer-null-dereference]
14 | *q = 1;
| ~~~^~~
'f': events 1-3
|
|7 | if (p && (0 == q))
| |^
| ||
| |(1) following 'true' branch...
|8 | {
|9 | __analyzer_eval(p && (0 == q));
| | ~~~
| | |
| | (2) ...to here
|..
| 14 | *q = 1;
| | ~~
| ||
| |(3) dereference of NULL '0'
```
In the analysis under -O2 above, lines 12 and 13 are somewhat contradictory, as
`__analyzer_eval(q)` results in UNKNOWN while `__analyzer_eval(0 == q)` results
in TRUE.
[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027 --- Comment #5 from cqwrteur --- built toolchain demo. (this is canadian compilation. What I showed was cross one.) https://github.com/trcrsired/x86_64-w64-mingw32-with-mcf-thread-model-native-toolchain
[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027 --- Comment #4 from cqwrteur --- (In reply to cqwrteur from comment #3) > (In reply to cqwrteur from comment #2) > > (In reply to LIU Hao from comment #1) > > > I need some information about this though: > > > > > > > > > When multilib is enabled, does GCC still link programs with `-lmsvcrt`? > > > There seems to be only reference to msvcrt: > > > > > > gcc/config/i386/mingw32.h:187: -lmoldname -lmingwex -lmsvcrt > > > -lkernel32 > > > " MCFGTHREAD_SPEC > > > > > > which is followed by `MCFGTHREAD_SPEC`. > > > > > > > > > If GCC links against libmcfgthread in both m32 and m64, then I suspect > > > there > > > is only one issue: You forgot to install mcfgthread. I don't know whether > > > libtool has builtin macros for multilib builds; by default libraries are > > > installed into `/lib` and you have to copy them into > > > `/lib32` and `/lib64`, respectively. > > > > I do install mcfgthread. Yes. I do both of them. The problem is that libtool > > will incorrectly link to lib/libmcfgthread.la even lib32/libmcfgthread.la > > and lib/32/libmcfgthread.la exist. > > Can you just remove the .la file? > > It finally gets to work by manually replacing all lib/libmcfgthread.la to > lib32/libmcfgthread.la in 32 multilibs. > > I do not even think you ever tried how to build multilibs. If you want > details, you can join QQ group 801441303 I do not think it is the problem of libstdc++ itself. It is probably your code has issues.
[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027 --- Comment #3 from cqwrteur --- (In reply to cqwrteur from comment #2) > (In reply to LIU Hao from comment #1) > > I need some information about this though: > > > > > > When multilib is enabled, does GCC still link programs with `-lmsvcrt`? > > There seems to be only reference to msvcrt: > > > > gcc/config/i386/mingw32.h:187: -lmoldname -lmingwex -lmsvcrt -lkernel32 > > " MCFGTHREAD_SPEC > > > > which is followed by `MCFGTHREAD_SPEC`. > > > > > > If GCC links against libmcfgthread in both m32 and m64, then I suspect there > > is only one issue: You forgot to install mcfgthread. I don't know whether > > libtool has builtin macros for multilib builds; by default libraries are > > installed into `/lib` and you have to copy them into > > `/lib32` and `/lib64`, respectively. > > I do install mcfgthread. Yes. I do both of them. The problem is that libtool > will incorrectly link to lib/libmcfgthread.la even lib32/libmcfgthread.la > and lib/32/libmcfgthread.la exist. > Can you just remove the .la file? It finally gets to work by manually replacing all lib/libmcfgthread.la to lib32/libmcfgthread.la in 32 multilibs. I do not even think you ever tried how to build multilibs. If you want details, you can join QQ group 801441303
[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027 --- Comment #2 from cqwrteur --- (In reply to LIU Hao from comment #1) > I need some information about this though: > > > When multilib is enabled, does GCC still link programs with `-lmsvcrt`? > There seems to be only reference to msvcrt: > > gcc/config/i386/mingw32.h:187: -lmoldname -lmingwex -lmsvcrt -lkernel32 > " MCFGTHREAD_SPEC > > which is followed by `MCFGTHREAD_SPEC`. > > > If GCC links against libmcfgthread in both m32 and m64, then I suspect there > is only one issue: You forgot to install mcfgthread. I don't know whether > libtool has builtin macros for multilib builds; by default libraries are > installed into `/lib` and you have to copy them into > `/lib32` and `/lib64`, respectively. I do install mcfgthread. Yes. I do both of them. The problem is that libtool will incorrectly link to lib/libmcfgthread.la even lib32/libmcfgthread.la and lib/32/libmcfgthread.la exist. Can you just remove the .la file?
[Bug libstdc++/108027] mcf thread model causes build issues for multilibs of x86_64-w64-mingw32 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027 --- Comment #1 from LIU Hao --- I need some information about this though: When multilib is enabled, does GCC still link programs with `-lmsvcrt`? There seems to be only reference to msvcrt: gcc/config/i386/mingw32.h:187: -lmoldname -lmingwex -lmsvcrt -lkernel32 " MCFGTHREAD_SPEC which is followed by `MCFGTHREAD_SPEC`. If GCC links against libmcfgthread in both m32 and m64, then I suspect there is only one issue: You forgot to install mcfgthread. I don't know whether libtool has builtin macros for multilib builds; by default libraries are installed into `/lib` and you have to copy them into `/lib32` and `/lib64`, respectively.
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615
--- Comment #11 from Steve Kargl ---
On Fri, Dec 09, 2022 at 01:50:56AM +, barrowes at alum dot mit.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615
>
> --- Comment #10 from Ben Barrowes ---
> The reason the stdout redirection doesn't work for me is because
> I want to save these preprocessed files during a "make" session.
> When I make, thousands of fotran files are preprocessed and compiled.
> How do I save the stdout from each one into its own directory?
>
% cat > a1.f90
subroutine foo
end subroutine foo
% cp a1.f90 b1.f90
% cp a1.f90 c1.f90
% cp a1.f90 d1.f90
% cat Makefile
FC = gfortran11
FF = -cpp -E
IN = f90
OUT = txt
NAMES = a1 b1 c1 d1
all:
.for i in ${NAMES}
${FC} ${FF} $i.${IN} > $i.${OUT}
.endfor
% make
gfortran11 -cpp -E a1.f90 > a1.txt
gfortran11 -cpp -E b1.f90 > b1.txt
gfortran11 -cpp -E c1.f90 > c1.txt
gfortran11 -cpp -E d1.f90 > d1.txt
% ls
Makefilea1.txt b1.txt c1.txt d1.txt
a1.f90 b1.f90 c1.f90 d1.f90
The preprocessed files appear in the same directory with its source
source file. It's trivial matter to have preprocess stuffed into
its own directory.
PS: Having to preprocess thousands of Fortran files into individual
directories seems to be poor software design.
[Bug libstdc++/108027] New: mcf thread model causes build issues for x86_64-w64-mingw32 multilibs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108027 Bug ID: 108027 Summary: mcf thread model causes build issues for x86_64-w64-mingw32 multilibs Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- Created attachment 54051 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54051=edit config.log and build logs undefined reference to `__MCF_cxa_thread_atexit' collect2: error: ld returned 1 exit status make[9]: *** [Makefile:751: libstdc++.la] Error 1 make[8]: *** [Makefile:784: all-recursive] Error 1 make[7]: *** [Makefile:576: all-recursive] Error 1 make[6]: *** [Makefile:501: all] Error 2 make[5]: *** [Makefile:870: multi-do] Error 1 make[4]: *** [Makefile:840: all-multi] Error 2 make[3]: *** [Makefile:576: all-recursive] Error 1 make[2]: *** [Makefile:501: all] Error 2 make[1]: *** [Makefile:13906: all-target-libstdc++-v3] Error 2 make: *** [Makefile:1029: all] Error 2
[Bug analyzer/108003] [13 Regression] ICE in bitmap_check_index, at sbitmap.h:105
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108003 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from David Malcolm --- Should be fixed by the above patch.
[Bug analyzer/108003] [13 Regression] ICE in bitmap_check_index, at sbitmap.h:105
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108003 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:7dc0ecafe60b224b3343667f55eaaa501f390925 commit r13-4578-g7dc0ecafe60b224b3343667f55eaaa501f390925 Author: David Malcolm Date: Thu Dec 8 21:19:23 2022 -0500 analyzer: fix ICE on region creation during get_referenced_base_regions [PR108003] gcc/analyzer/ChangeLog: PR analyzer/108003 * call-summary.cc (call_summary_replay::convert_region_from_summary_1): Convert heap_regs_in_use from auto_sbitmap to auto_bitmap. * region-model-manager.cc (region_model_manager::get_or_create_region_for_heap_alloc): Convert from sbitmap to bitmap. * region-model-manager.h: Likewise. * region-model.cc (region_model::get_or_create_region_for_heap_alloc): Convert from auto_sbitmap to auto_bitmap. (region_model::get_referenced_base_regions): Likewise. * region-model.h: Include "bitmap.h" rather than "sbitmap.h". (region_model::get_referenced_base_regions): Convert from auto_sbitmap to auto_bitmap. gcc/testsuite/ChangeLog: PR analyzer/108003 * g++.dg/analyzer/pr108003.C: New test. Signed-off-by: David Malcolm
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615 --- Comment #10 from Ben Barrowes --- The reason the stdout redirection doesn't work for me is because I want to save these preprocessed files during a "make" session. When I make, thousands of fotran files are preprocessed and compiled. How do I save the stdout from each one into its own directory?
[Bug c++/108026] New: Confusing pedwarn with template lambda with -std=c++11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108026
Bug ID: 108026
Summary: Confusing pedwarn with template lambda with -std=c++11
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take:
```
auto a = []() {};
```
Compile with `-std=c++11 -pedantic`, we get currently:
```
:1:12: warning: lambda templates are only available with '-std=c++14'
or '-std=gnu++14' [-Wc++14-extensions]
1 | auto a = []() {};
|^
```
But change it to -std=c++14 we get:
```
:1:12: warning: lambda templates are only available with '-std=c++20'
or '-std=gnu++20' [-Wc++20-extensions]
1 | auto a = []() {};
|^
```
I am confused based on the warning/error message which is it?
So I looked into the history of this code and pedwarn message and found that
lamdba templates were proposed as part of the original paper about expanding
lamdba for C++14, N3418 but they were removed by before the approval of C++14,
N3559. And then finally in C++20 they were added back.
Anyways the pedwarn message is just confusing and should be fixed.
[Bug c++/77914] Wrong lambda definition accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77914 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.0
[Bug libstdc++/108024] std::format_string's constructor has the wrong constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108024 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-12-09 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |13.0 Status|UNCONFIRMED |ASSIGNED
[Bug libstdc++/108015] [13 Regression] 17_intro/headers/c++2011/stdc++_multiple_inclusion.cc failure on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108015 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Should be fixed now.
[Bug libstdc++/108015] [13 Regression] 17_intro/headers/c++2011/stdc++_multiple_inclusion.cc failure on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108015 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:d61c0357ebc771166d5d48743f80aa339b4183dc commit r13-4574-gd61c0357ebc771166d5d48743f80aa339b4183dc Author: Jonathan Wakely Date: Thu Dec 8 11:55:31 2022 + libstdc++: Remove digit separators [PR108015] These are not valid in C++11 and cause a warning when preprocessing, even though they're inside a skipped group. chrono:2436: warning: missing terminating ' character libstdc++-v3/ChangeLog: PR libstdc++/108015 * include/std/chrono (hh_mm_ss): Remove digit separators.
[Bug middle-end/104296] MIN should simplify to unsigned != 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104296 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-12-09 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Andrew Pinski --- Mine. Actually this should only be done in expand ... And we should do: _1 = a_2(D) != 0; _3 = (unsigned intD.9) _1; Into: _3 = MIN_EXPR; Instead.
[Bug c++/108020] Add fix-it hint for iostream operators declared in-class without 'friend'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108020 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-12-08 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/107879] [13 Regression] ffmpeg-4 test suite fails on FPU arithmetics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107879
--- Comment #12 from Sergei Trofimovich ---
(In reply to Jakub Jelinek from comment #5)
> It is the foperator_mult::op{1,2}_range and can be seen even on:
> double
> foo (double x, double y)
> {
> double z = x * y;
> if (z == 0.0)
> return x;
> return 42.0;
> }
> testcase.
> 2->3 (T) x_2(D) : [frange] double [-0.0 (-0x0.0p+0), 0.0 (0x0.0p+0)]
> 2->3 (T) y_3(D) : [frange] double [-0.0 (-0x0.0p+0), 0.0 (0x0.0p+0)]
> 2->3 (T) z_4 : [frange] double [-0.0 (-0x0.0p+0), 0.0 (0x0.0p+0)]
> On the true edge of z == 0.0, we have [-0., 0.] range for z_4, that is
For my curiosity fow did you get such a detailed [frange] output for the
expressions? I tried -fdump-tree-all-all and best I get is a one-liner around
PHI nodes:
# RANGE [frange] double [0.0 (0x0.0p+0), +Inf]
# iftmp.5_6 = PHI
# .MEM_23 = PHI <.MEM_19(3), .MEM_19(4), .MEM_15(6)>
# VUSE <.MEM_23>
return iftmp.5_6;
Is there a magic gcc flag to dump more range details? Or you had to patch a bit
of gcc code?
[Bug tree-optimization/89317] Ineffective code from std::copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> Better one:
> struct b { int data[16]; };
>
> int foo (struct b *x)
> {
> int *a = x->data;
> int *b = ((int*)x) + 4;
> return b - a;
> }
Note we can handle address of a variable case already; that is:
```
struct b { int data[16]; };
int foo (struct b x)
{
int *a = x.data;
int *b = ((int*)) + 4;
return b - a;
}
```
is optimized during ccp1.
[Bug tree-optimization/89317] Ineffective code from std::copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> Reduced testcase for that issue:
> struct { int data[16]; } *x;
> int foo (int n1)
> {
> int *a = x->data;
> int *b = ((int*)x) + 4;
> return b - a;
> }
Better one:
struct b { int data[16]; };
int foo (struct b *x)
{
int *a = x->data;
int *b = ((int*)x) + 4;
return b - a;
}
[Bug tree-optimization/89317] Ineffective code from std::copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89317
Andrew Pinski changed:
What|Removed |Added
Keywords||TREE
--- Comment #5 from Andrew Pinski ---
Note on the trunk, these two functions now produce the same code. BUT we are
still missing a gimple level optimization.
The RTL level can figure out:
_1 = this_6(D) + 16;
_2 = _6(D)->data1;
_19 = _1 - _2;
__n_20 = _19 /[ex] 2;
if (_19 > 0)
goto ; [89.00%]
else
goto ; [11.00%]
That _19 is 16 and the condition is always true.
Reduced testcase for that issue:
struct { int data[16]; } *x;
int foo (int n1)
{
int *a = x->data;
int *b = ((int*)x) + 4;
return b - a;
}
[Bug c++/107768] Bogus -Wzero-as-null-pointer-constant in coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107768 --- Comment #6 from Andrew Pinski --- This should fix the issue (just like what was done in PR 51045): diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc index 01a3e831ee5..96875425ba6 100644 --- a/gcc/cp/coroutines.cc +++ b/gcc/cp/coroutines.cc @@ -4131,7 +4131,7 @@ coro_rewrite_function_body (location_t fn_start, tree fnbody, tree orig, /* We will need to be able to set the resume function pointer to nullptr to signal that the coroutine is 'done'. */ tree zero_resume -= build1 (CONVERT_EXPR, resume_fn_ptr_type, integer_zero_node); += build1 (CONVERT_EXPR, resume_fn_ptr_type, nullptr_node); /* The pointer to the destroy function. */ tree var = coro_build_artificial_var (fn_start, coro_destroy_fn_id, @@ -4518,7 +4518,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree *destroyer) tree ramp_body = push_stmt_list (); tree zeroinit = build1_loc (fn_start, CONVERT_EXPR, - coro_frame_ptr, integer_zero_node); + coro_frame_ptr, nullptr_node); tree coro_fp = coro_build_artificial_var (fn_start, "_Coro_frameptr", coro_frame_ptr, orig, zeroinit); tree varlist = coro_fp; @@ -4753,7 +4753,7 @@ morph_fn_to_coro (tree orig, tree *resumer, tree *destroyer) gcc_checking_assert (same_type_p (fn_return_type, TREE_TYPE (grooaf))); tree if_stmt = begin_if_stmt (); - tree cond = build1 (CONVERT_EXPR, coro_frame_ptr, integer_zero_node); + tree cond = build1 (CONVERT_EXPR, coro_frame_ptr, nullptr_node); cond = build2 (EQ_EXPR, boolean_type_node, coro_fp, cond); finish_if_stmt_cond (cond, if_stmt); if (VOID_TYPE_P (fn_return_type))
[Bug c++/107768] Bogus -Wzero-as-null-pointer-constant in coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107768 --- Comment #5 from Andrew Pinski --- (gdb) p debug_tree(decl) unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x76c24e70 fields context full-name "struct resuming_on_new_thread()::_Z22resuming_on_new_threadv.Frame" needs-constructor X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown pointer_to_this chain > unsigned DI size unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x76c24f18> unsigned read DI t.cc:15:6 size unit-size align:64 warn_if_not_align:0 context initial chain >
[Bug c++/107768] Bogus -Wzero-as-null-pointer-constant in coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107768
--- Comment #4 from Andrew Pinski ---
Oh I was printing the backtrace of the wrong one :)
Breakpoint 5, warning_at (location=21406144, opt=860, gmsgid=0x36bec84 "zero as
null pointer constant") at
/home/apinski/src/upstream-gcc/gcc/gcc/diagnostic.cc:1875
1875{
1: expand_location( location) = {file = 0x4c16150 "t.cc", line = 24, column =
1, data = 0x0, sysp = false}
(gdb) bt
#0 warning_at (location=21406144, opt=860, gmsgid=0x36bec84 "zero as null
pointer constant") at /home/apinski/src/upstream-gcc/gcc/gcc/diagnostic.cc:1875
#1 0x0106a451 in maybe_warn_zero_as_null_pointer_constant
(expr=, loc=21406144) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/tree.cc:6247
#2 0x00d29f62 in cp_convert_to_pointer (type=, expr=, dofold=true, complain=3) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/cvt.cc:213
#3 0x00d2d1dc in ocp_convert (type=,
expr=, convtype=79, flags=17, complain=3) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/cvt.cc:887
#4 0x00d2fc39 in convert (type=,
expr=) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/cvt.cc:1688
#5 0x00d1d930 in cp_fold (x=) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/cp-gimplify.cc:2515
#6 0x00d1601b in cp_fold_r (stmt_p=0x76c277a0,
walk_subtrees=0x7fffd3e0, data_=0x7fffd540) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/cp-gimplify.cc:1017
#7 0x01dd730d in walk_tree_1 (tp=0x76c277a0, func=0xd157dc
, data=0x7fffd540, pset=0x0, lh=0x1065f71
>*)>)
at /home/apinski/src/upstream-gcc/gcc/gcc/tree.cc:11257
#8 0x01dd78ab in walk_tree_1 (tp=0x76c210c0, func=0xd157dc
, data=0x7fffd540, pset=0x0, lh=0x1065f71
>*)>)
at /home/apinski/src/upstream-gcc/gcc/gcc/tree.cc:11361
#9 0x00d1690a in cp_fold_function (fndecl=) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/cp-gimplify.cc:1133
#10 0x00d9f747 in finish_function (inline_p=false) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/decl.cc:18210
#11 0x00f1300a in cp_parser_function_definition_after_declarator
(parser=0x77274be0, inline_p=false) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:31905
#12 0x00f12e10 in
cp_parser_function_definition_from_specifiers_and_declarator
(parser=0x77274be0, decl_specifiers=0x7fffd9b0, attributes=,
declarator=0x4c16320) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:31819
#13 0x00efebc5 in cp_parser_init_declarator (parser=0x77274be0,
flags=0, decl_specifiers=0x7fffd9b0, checks=0x0,
function_definition_allowed_p=true, member_p=false, declares_class_or_enum=0,
function_definition_p=0x7fffd939, maybe_range_for_decl=0x0,
init_loc=0x7fffd940,
auto_result=0x7fffd948) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22693
#14 0x00eefdd6 in cp_parser_simple_declaration (parser=0x77274be0,
function_definition_allowed_p=true, maybe_range_for_decl=0x0) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:15341
#15 0x00eef8cf in cp_parser_block_declaration (parser=0x77274be0,
statement_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:15161
#16 0x00eef51d in cp_parser_declaration (parser=0x77274be0,
prefix_attrs=) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:15027
#17 0x00eef5e9 in cp_parser_toplevel_declaration
(parser=0x77274be0) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:15048
#18 0x00ed74fc in cp_parser_translation_unit (parser=0x77274be0) at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:5090
#19 0x00f4e06b in c_parse_file () at
/home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:49349
#20 0x0115200a in c_common_parse_file () at
/home/apinski/src/upstream-gcc/gcc/gcc/c-family/c-opts.cc:1248
#21 0x0197da00 in compile_file () at
/home/apinski/src/upstream-gcc/gcc/gcc/toplev.cc:444
#22 0x01980acd in do_compile (no_backend=false) at
/home/apinski/src/upstream-gcc/gcc/gcc/toplev.cc:2125
#23 0x01980eb5 in toplev::main (this=0x7fffdd62, argc=5,
argv=0x7fffde68) at /home/apinski/src/upstream-gcc/gcc/gcc/toplev.cc:2277
#24 0x03293c49 in main (argc=5, argv=0x7fffde68) at
/home/apinski/src/upstream-gcc/gcc/gcc/main.cc:39
[Bug fortran/108025] Duplicate CONTIGUOUS attribute should be diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108025 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |13.0 --- Comment #3 from anlauf at gcc dot gnu.org --- Fixed.
[Bug fortran/108025] Duplicate CONTIGUOUS attribute should be diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108025 --- Comment #2 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:3a9f6d5a8ee490adf9a18f93feaf86542642be7d commit r13-4568-g3a9f6d5a8ee490adf9a18f93feaf86542642be7d Author: Harald Anlauf Date: Thu Dec 8 22:50:45 2022 +0100 Fortran: diagnose and reject duplicate CONTIGUOUS attribute [PR108025] gcc/fortran/ChangeLog: PR fortran/108025 * symbol.cc (gfc_add_contiguous): Diagnose and reject duplicate CONTIGUOUS attribute. gcc/testsuite/ChangeLog: PR fortran/108025 * gfortran.dg/contiguous_12.f90: New test.
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #9 from kargl at gcc dot gnu.org --- (In reply to Ben Barrowes from comment #8) > Maybe *.fpp ? We already have too many extensions for Fortran. How about simply redirecting stdout gfortran -cpp -E file.f90 > preprocessed.f90
[Bug fortran/108025] Duplicate CONTIGUOUS attribute should be diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108025 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2022-12-08 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Ever confirmed|0 |1 Keywords||diagnostic, patch --- Comment #1 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-December/058597.html
[Bug fortran/108025] New: Duplicate CONTIGUOUS attribute should be diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108025
Bug ID: 108025
Summary: Duplicate CONTIGUOUS attribute should be diagnosed
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gcc dot gnu.org
Target Milestone: ---
The following code should be rejected as indicated:
subroutine foo (x)
real, contiguous :: x(:)
contiguous :: x! { dg-error "Duplicate CONTIGUOUS attribute" }
end
Detected by NAG and Intel.
[Bug c++/107768] Bogus -Wzero-as-null-pointer-constant in coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107768 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-12-08 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- unit-size align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x76ded1f8 fields public abstract external in_system_header autoinline decl_3 decl_8 QI /home/apinski/upstream-gcc/include/c++/13.0.0/compare:61:9 align:16 warn_if_not_align:0 context full-name "constexpr std::partial_ordering::~partial_ordering() noexcept ()" not-really-extern chain > context full-name "class std::partial_ordering" needs-constructor X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown pointer_to_this reference_to_this chain > public arg:0 addressable used read QI /home/apinski/upstream-gcc/include/c++/13.0.0/compare:358:26 size unit-size align:8 warn_if_not_align:0 context arg-type > /home/apinski/upstream-gcc/include/c++/13.0.0/compare:359:12 start: /home/apinski/upstream-gcc/include/c++/13.0.0/compare:359:12 finish: /home/apinski/upstream-gcc/include/c++/13.0.0/compare:359:16> Is looking exactly like PR 95242 ...
[Bug c++/107768] Bogus -Wzero-as-null-pointer-constant in coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107768 --- Comment #2 from Andrew Pinski --- #1 0x0106a451 in maybe_warn_zero_as_null_pointer_constant (expr=, loc=16802880) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/tree.cc:6247 #2 0x00c5b243 in conversion_null_warnings (totype=, expr=, fn=, argnum=0) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/call.cc:8013 #3 0x00c5c0df in convert_like_internal (convs=0x4c264b0, expr=, fn=, argnum=0, issue_conversion_warnings=true, c_cast_p=false, nested_p=false, complain=3) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/call.cc:8234 #4 0x00c5e811 in convert_like (convs=0x4c264b0, expr=, fn=, argnum=0, issue_conversion_warnings=true, c_cast_p=false, nested_p=false, complain=3) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/call.cc:8762 #5 0x00c5e8cc in convert_like_with_context (convs=0x4c264b0, expr=, fn=, argnum=0, complain=3) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/call.cc:8788 #6 0x00c6375f in build_over_call (cand=0x4c264e0, flags=17, complain=3) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/call.cc:9936 #7 0x00c5c7b5 in convert_like_internal (convs=0x4c26610, expr=, fn=, argnum=1, issue_conversion_warnings=true, c_cast_p=false, nested_p=false, complain=3) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/call.cc:8302 #8 0x00c5e811 in convert_like (convs=0x4c26610, expr=, fn=, argnum=1, issue_conversion_warnings=true, c_cast_p=false, nested_p=false, complain=3) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/call.cc:8762 #9 0x00c5e8cc in convert_like_with_context (convs=0x4c26610, expr=, fn=, argnum=1, complain=3) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/call.cc:8788 #10 0x00c6375f in build_over_call (cand=0x4c26640, flags=1, complain=3) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/call.cc:9936 #11 0x00c5737f in build_new_op (loc=..., code=EQ_EXPR, flags=1, arg1=, arg2=, arg3=, lookups=, overload=0x7fffcf18, complain=3) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/call.cc:6986 #12 0x0108fc84 in build_x_binary_op (loc=..., code=EQ_EXPR, arg1=, arg1_code=ERROR_MARK, arg2=, arg2_code=ERROR_MARK, lookups=, overload_p=0x7fffcfb8, complain=3) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/typeck.cc:4722 #13 0x00ee2dde in cp_parser_binary_expression (parser=0x77274be0, cast_p=false, no_toplevel_fold_p=false, decltype_p=false, prec=PREC_NOT_OPERATOR, pidk=0x0) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:10280 #14 0x00ee337a in cp_parser_assignment_expression (parser=0x77274be0, pidk=0x0, cast_p=false, decltype_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:10441 #15 0x00ee3704 in cp_parser_expression (parser=0x77274be0, pidk=0x0, cast_p=false, decltype_p=false, warn_comma_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:10611 #16 0x00eedaea in cp_parser_jump_statement (parser=0x77274be0) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:14356 #17 0x00ee8970 in cp_parser_statement (parser=0x77274be0, in_statement_expr=, in_compound=true, if_p=0x0, chain=0x0, loc_after_labels=0x0) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:12332 #18 0x00ee9c92 in cp_parser_statement_seq_opt (parser=0x77274be0, in_statement_expr=) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:12906 #19 0x00ee9b74 in cp_parser_compound_statement (parser=0x77274be0, in_statement_expr=, bcs_flags=0, function_body=true) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:12858 #20 0x00f0464c in cp_parser_function_body (parser=0x77274be0, in_function_try_block=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:25241 #21 0x00f04970 in cp_parser_ctor_initializer_opt_and_function_body (parser=0x77274be0, in_function_try_block=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:25292 #22 0x00f12fff in cp_parser_function_definition_after_declarator (parser=0x77274be0, inline_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:31902 #23 0x00f12e10 in cp_parser_function_definition_from_specifiers_and_declarator (parser=0x77274be0, decl_specifiers=0x7fffd7f0, attributes=, declarator=0x4c16450) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:31819 #24 0x00efebc5 in cp_parser_init_declarator (parser=0x77274be0, flags=0, decl_specifiers=0x7fffd7f0, checks=0x0, function_definition_allowed_p=true, member_p=false, declares_class_or_enum=0, function_definition_p=0x7fffd779, maybe_range_for_decl=0x0, init_loc=0x7fffd780, auto_result=0x7fffd788) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22693 #25 0x00eefdd6 in cp_parser_simple_declaration (parser=0x77274be0, function_definition_allowed_p=true, maybe_range_for_decl=0x0) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:15341 #26 0x00eef8cf in
[Bug tree-optimization/108023] Incorrect line number in ASAN's report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108023 Andrew Pinski changed: What|Removed |Added Component|sanitizer |tree-optimization Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-12-08 --- Comment #1 from Andrew Pinski --- LIM loses the line #. We go from: [local count: 955630225]: # b.1_46 = PHI <_16(6), [/app/example.cpp:16:17 discrim 1] 0(5)> [/app/example.cpp:17:7] # DEBUG BEGIN_STMT [/app/example.cpp:17:17] _9 = *j_1; [/app/example.cpp:17:19] _11 = (long unsigned int) h_45; [/app/example.cpp:17:20] _12 = _11 * 4; [/app/example.cpp:17:20] _13 = _9 + _12; [/app/example.cpp:17:20] _14 = *_13; [/app/example.cpp:17:12] MEM[(int *)k_8 + 12B] = _14; [/app/example.cpp:16:5 discrim 3] # DEBUG BEGIN_STMT [/app/example.cpp:16:5 discrim 3] _16 = b.1_46 + 1; [/app/example.cpp:16:5 discrim 3] b = _16; [/app/example.cpp:16:17 discrim 1] # DEBUG BEGIN_STMT [/app/example.cpp:16:17 discrim 1] if (_16 <= 2) goto ; [89.00%] else goto ; [11.00%] To: [local count: 955630225]: # b.1_46 = PHI <_16(10), [/app/example.cpp:16:17 discrim 1] 0(5)> [/app/example.cpp:17:7] # DEBUG BEGIN_STMT [/app/example.cpp:17:12] k__lsm.10_48 = _14; [/app/example.cpp:16:5 discrim 3] # DEBUG BEGIN_STMT [/app/example.cpp:16:5 discrim 3] _16 = b.1_46 + 1; [/app/example.cpp:16:5 discrim 3] b_lsm.11_26 = _16; [/app/example.cpp:16:17 discrim 1] # DEBUG BEGIN_STMT [/app/example.cpp:16:17 discrim 1] if (_16 <= 2) goto ; [89.00%] else goto ; [11.00%] [local count: 850510901]: goto ; [100.00%] [local count: 118111600]: # b_lsm.11_36 = PHI # k__lsm.10_6 = PHI MEM[(int *)k_8 + 12B] = k__lsm.10_6; b = b_lsm.11_36; Seems like LIM could in theory copy the line # but that might even confuse people while debugging I don't know what the best appoarch here really. Just use -Og instead?
[Bug c++/105397] C++ modules vs -fvisibility option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105397 --- Comment #2 from Ben Boeckel --- > Perhaps the best option is to default the visibility of the implicit > functions to the widest visibility of any function or object in module > purview exposed by the TU. What to do about `extern "C"` APIs made available by a module? Is that even allowed? Imagine a library providing some C API by implementing in C++ modules; should the module initializer be public API too?
[Bug c++/107768] Bogus -Wzero-as-null-pointer-constant in coroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107768 --- Comment #1 from Andrew Pinski --- Created attachment 54050 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54050=edit Reduced testcase This reduces the testcase to the bare min to reproduce the wrong warning.
[Bug libstdc++/107761] Implement C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107761 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-12-08 --- Comment #1 from Andrew Pinski --- .
[Bug libstdc++/107760] Implement C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107760 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-12-08 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- .
[Bug libstdc++/107759] Implement C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107759 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-12-08 --- Comment #1 from Andrew Pinski --- .
[Bug libstdc++/107758] Implement C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107758 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-12-08 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- .
[Bug ipa/108000] Assert during ipa-cp with AutoFDO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108000 --- Comment #4 from CVS Commits --- The master branch has been updated by Eugene Rozenfeld : https://gcc.gnu.org/g:7410032a772a9e77b620b091c2b551b68113a179 commit r13-4567-g7410032a772a9e77b620b091c2b551b68113a179 Author: Eugene Rozenfeld Date: Tue Dec 6 17:05:18 2022 -0800 Fix count comparison in ipa-cp The existing comparison was incorrect for non-PRECISE counts (e.g., AFDO): we could end up with a 0 base_count, which could lead to asserts, e.g., in good_cloning_opportunity_p. Tested on x86_64-pc-linux-gnu. gcc/ChangeLog: PR ipa/108000 * ipa-cp.cc (ipcp_propagate_stage): Fix profile count comparison gcc/testsuite * gcc.dg/tree-prof/pr108000.c: Regression test
[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997 --- Comment #8 from Jakub Jelinek --- Indeed, and it started with r10-5288-g52dc9c32311e8ea4833b8865c0d3121cad03937d but guess it has been latent before.
[Bug analyzer/108003] [13 Regression] ICE in bitmap_check_index, at sbitmap.h:105
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108003 David Malcolm changed: What|Removed |Added Last reconfirmed||2022-12-08 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Thanks for filing this. Confirmed; am testing a fix.
[Bug sanitizer/108021] sanitizer used with qemu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108021 --- Comment #2 from Andrew Pinski --- I have not tried the trunk with these patches though. The patches I did were for GCC 10.
[Bug sanitizer/108021] sanitizer used with qemu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108021 --- Comment #1 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gcc-patches/2020-February/540024.html
[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997 Andrew Pinski changed: What|Removed |Added Known to fail||10.1.0, 11.1.0, 12.2.0 Known to work||9.1.0 Keywords||ice-checking Target|powerpc64-linux |x86_64-linux-gnu ||powerpc64-linux Summary|[13 Regression] |[10/11/12/13 Regression] |r13-4389-gfd8dd6c0384969|r13-4389-gfd8dd6c0384969 |probably uncovered an issue |probably uncovered an issue |building the Linux kernel |building the Linux kernel Target Milestone|13.0|10.5 --- Comment #7 from Andrew Pinski --- With the reduced testcase in comment #5 (with a `;` add after `l2:` to allow compiling with older gcc), the ICE is there for GCC 10+ (with -fchecking). GCC 9 didn't ICE nor did it place gimple after the `asm goto`.
[Bug tree-optimization/107997] [13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997
--- Comment #6 from Jakub Jelinek ---
create_new_iv is called with cand->pos being IP_END, where the last stmt of the
body is asm goto.
__asm__ __volatile__ goto("" : : : : "l2" l2);
;;succ: 13
;; basic block 13, loop depth 1
;;pred: 9
;;12
# x_4 = PHI
l2:
As the label is in the same bb as fallthrough, the bb which ends with asm goto
has just a single succ edge, but in order to insert something at the end of the
latch bb,
we would need to create a new bb, move the label to it and insert the iv there.
I guess gsi_insert_on_edge_immediate should be able to handle that case, or
perhaps just detect when gsi_last_bb (ip_end_pos (data->current_loop))
is GIMPLE_ASM or better yet stmt_ends_bb_p and split_edge in that case?
[Bug tree-optimization/107997] [13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2022-12-08
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #5 from Jakub Jelinek ---
Cleaned up, just -Os is needed:
int a, b;
void bar (int);
int baz (void);
void *
foo (int x, void *y)
{
asm goto ("" : : "r" (x || !a) : : l);
l:
if (y)
return 0;
bar (b ? b : x);
while (x--)
{
if (!baz ())
baz ();
asm goto ("" : : : : l2);
l2:
}
return y;
}
[Bug tree-optimization/107997] [13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997 --- Comment #3 from Jan-Benedict Glaw --- Created attachment 54048 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54048=edit Original preprocessed source
[Bug tree-optimization/107997] [13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997 --- Comment #4 from Jan-Benedict Glaw --- Created attachment 54049 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54049=edit Reduced testcase (cvise)
[Bug c++/105838] [10/11/12/13 Regression] g++ 12.1.0 runs out of memory or time when building const std::vector of std::strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838 --- Comment #19 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:bd0485f20f4794f9787237706a6308473a8e9415 commit r13-4565-gbd0485f20f4794f9787237706a6308473a8e9415 Author: Jason Merrill Date: Tue Dec 6 18:10:48 2022 -0500 c++: build initializer_list in a loop [PR105838] The previous patch avoided building an initializer_list at all when building a vector, but in situations where that isn't possible, we could still build the initializer_list with a loop over a constant array. This is represented using a VEC_INIT_EXPR, which required adjusting a couple of places that expected the initializer array to have the same type as the target array and fixing build_vec_init not to undo our efforts. PR c++/105838 gcc/cp/ChangeLog: * call.cc (convert_like_internal) [ck_list]: Use maybe_init_list_as_array. * constexpr.cc (cxx_eval_vec_init_1): Init might have a different type. * tree.cc (build_vec_init_elt): Likewise. * init.cc (build_vec_init): Handle from_array from a TARGET_EXPR. Retain TARGET_EXPR of a different type. gcc/testsuite/ChangeLog: * g++.dg/tree-ssa/initlist-opt2.C: New test.
[Bug c++/105838] [10/11/12/13 Regression] g++ 12.1.0 runs out of memory or time when building const std::vector of std::strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838
--- Comment #18 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:d081807d8d70e3e87eae41e1560e54d503f4d465
commit r13-4564-gd081807d8d70e3e87eae41e1560e54d503f4d465
Author: Jason Merrill
Date: Tue Dec 6 09:51:51 2022 -0500
c++: avoid initializer_list [PR105838]
When constructing a vector from { "strings" }, first is built an
initializer_list, which is then copied into the strings in the
vector. But this is inefficient: better would be treat the { "strings" }
as a range and construct the strings in the vector directly from the
string-literals. We can do this transformation for standard library
classes because we know the design patterns they follow.
PR c++/105838
gcc/cp/ChangeLog:
* call.cc (list_ctor_element_type): New.
(braced_init_element_type): New.
(has_non_trivial_temporaries): New.
(maybe_init_list_as_array): New.
(maybe_init_list_as_range): New.
(build_user_type_conversion_1): Use maybe_init_list_as_range.
* parser.cc (cp_parser_braced_list): Call
recompute_constructor_flags.
* cp-tree.h (find_temps_r): Declare.
gcc/testsuite/ChangeLog:
* g++.dg/tree-ssa/initlist-opt1.C: New test.
[Bug c++/105838] [10/11/12/13 Regression] g++ 12.1.0 runs out of memory or time when building const std::vector of std::strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838 --- Comment #17 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:1e1847612d7f169f82c985b0b3a5e3301d6fe999 commit r13-4563-g1e1847612d7f169f82c985b0b3a5e3301d6fe999 Author: Jason Merrill Date: Mon Dec 5 15:19:27 2022 -0500 c++: fewer allocator temps [PR105838] In this PR, initializing the array of std::string to pass to the vector initializer_list constructor gets very confusing to the optimizers as the number of elements increases, primarily because of all the std::allocator temporaries passed to all the string constructors. Instead of creating one for each string, let's share an allocator between all the strings; we can do this safely because we know that std::allocator is stateless and that string doesn't care about the object identity of its allocator parameter. PR c++/105838 gcc/cp/ChangeLog: * cp-tree.h (is_std_allocator): Declare. * constexpr.cc (is_std_allocator): Split out from... (is_std_allocator_allocate): ...here. * init.cc (find_temps_r): New. (find_allocator_temp): New. (build_vec_init): Use it. gcc/testsuite/ChangeLog: * g++.dg/tree-ssa/allocator-opt1.C: New test.
[Bug tree-optimization/107997] [13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997 --- Comment #2 from Jan-Benedict Glaw --- (In reply to Jakub Jelinek from comment #1) > (In reply to Jan-Benedict Glaw from comment #0) > > I'll add the preprocessed sources. > > Could you please? Without it there isn't much that can be done. At it right now, throwing it at cvise.
[Bug tree-optimization/107985] [13 Regression] ICE in as_a, at value-range.h:393
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107985 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Assuming this is fixed.
[Bug middle-end/107991] [10/11/12/13 Regression] Extra mov instructions with ternary on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107991 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||marxin at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- 2 mov insns in foo/bar instead of 1 started with r8-1519-ge59a1c22fb249388e82b4fd004f33615abe36d2e PR79489 fix. And 3 mov insns in all 3 instead of 2 started with the r10-3679-g9b0365879b3c4917f5a2485a1fca8bb678484bfe change.
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615 --- Comment #8 from Ben Barrowes --- Maybe *.fpp ?
[Bug tree-optimization/107997] [13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107997 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- (In reply to Jan-Benedict Glaw from comment #0) > I'll add the preprocessed sources. Could you please? Without it there isn't much that can be done.
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615 --- Comment #7 from Jakub Jelinek --- *.i would be definitely wrong, that is for preprocessed C (*.ii is for preprocessed C++, *.mi for preprocessed ObjC, etc.).
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615 --- Comment #6 from Ben Barrowes --- There are many cases where people do not use a capital "F", but still have preprocessor directives in the code. In these cases, no proprocessed file is written out right now, AFAIK. So perhaps as you suggest we could add a new suffix to the old filename. Then test1.f would become test.f.i and test1.f90 would also become test1.f.i, etc. Having this one rule would be a concise solution and have a guaranteed output in all cases.
[Bug libstdc++/108024] New: std::format_string's constructor has the wrong constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108024
Bug ID: 108024
Summary: std::format_string's constructor has the wrong
constraint
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: ---
format#L3628:
template
template> _Tp>
consteval
basic_format_string<_CharT, _Args...>::
basic_format_string(const _Tp& __s)
: _M_str(__s)
>From [format.fmt.string]: "Constraints: const T& models
convertible_to>." We should use the requires-clause
to constrain const _Tp instead of _Tp. Testcase:
#include
struct Str {
consteval operator std::string_view() const { return ""; }
operator std::string_view() = delete;
};
int main() {
return std::format(Str{}).size();
}
https://godbolt.org/z/xjq5K9YGo
[Bug tree-optimization/106912] [13 Regression] ICE in vect_transform_loops, at tree-vectorizer.cc:1032 since r13-1575-gcf3a120084e94614
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106912 --- Comment #6 from Jakub Jelinek --- Sure, the FUNCTION_TYPE can be shared, so shouldn't be overwritten in place, but can be copied with TREE_READONLY cleared on the copy. So, if we for whatever reason need to clear const flag on some functions, after clearing TREE_READONLY on the node->decl we'd also need to update the TREE_TYPE to a version without TREE_READONLY set (so that say if new calls are created they don't get wrong fntype) and then walk all call edges to that function, updating gimple_call_fntype to the updated type if it was equal to the old TREE_TYPE, or to a copy with TREE_READONLY cleared if it has TREE_READONLY set on the FUNCTION/METHOD_TYPE).
[Bug debug/98776] DW_AT_low_pc is inconsistent with function entry address, when enabling -fpatchable-function-entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98776 --- Comment #11 from CVS Commits --- The master branch has been updated by Sebastian Pop : https://gcc.gnu.org/g:09c91caeb84e7c3609a12a53b57e5219a1dd2b15 commit r13-4561-g09c91caeb84e7c3609a12a53b57e5219a1dd2b15 Author: Sebastian Pop Date: Wed Nov 30 19:45:24 2022 + AArch64: Add UNSPECV_PATCHABLE_AREA [PR98776] Currently patchable area is at the wrong place on AArch64. It is placed immediately after function label, before .cfi_startproc. This patch adds UNSPECV_PATCHABLE_AREA for pseudo patchable area instruction and modifies aarch64_print_patchable_function_entry to avoid placing patchable area before .cfi_startproc. gcc/ PR target/98776 * config/aarch64/aarch64-protos.h (aarch64_output_patchable_area): Declared. * config/aarch64/aarch64.cc (aarch64_print_patchable_function_entry): Emit an UNSPECV_PATCHABLE_AREA pseudo instruction. (aarch64_output_patchable_area): New. * config/aarch64/aarch64.md (UNSPECV_PATCHABLE_AREA): New. (patchable_area): Define. gcc/testsuite/ PR target/98776 * gcc.target/aarch64/pr98776.c: New. * gcc.target/aarch64/pr92424-2.c: Adjust pattern. * gcc.target/aarch64/pr92424-3.c: Adjust pattern.
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- If you use test.F90 extension, -save-temps will produce test.f90 with preprocessed source, that is how it should behave. Now, for *.F or *.F08 etc. extensions it still creates *.f90, I'd say it should create *.f, *.f08 etc. instead. And finally for the -cpp case where the source contains an extension that is meant for files that don't need preprocessing, either we could use a temporary filename, or say append suffix to the filename instead of removing its suffix and appending a new extension.
[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569 --- Comment #42 from Jakub Jelinek --- On #c0 foo, this was previously optimized in dom2 which optimized _4 = ABS_EXPR ; _3 = _4 u> 1.79769313486231570814527423731704356798070567525844996599e+308; _5 = ~_3; if (_4 u> 1.79769313486231570814527423731704356798070567525844996599e+308) goto ; [0.00%] else goto ; [100.00%] [count: 0]: __builtin_unreachable (); [local count: 1073741824]: return _5; without any frange related stuff as: - if (_4 u> 1.79769313486231570814527423731704356798070567525844996599e+308) + if (_3 != 0) and - return _5; + return 1; But because __builtin_unreachable () is now removed earlier (vrp1 already; without providing useful global range though), we don't do that anymore.
[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569 --- Comment #41 from Jakub Jelinek --- As for #c1, with trunk -O3 -march=skylake it is: vmovsd 8(%rdi), %xmm1 vmovsd (%rdi), %xmm0 vmulsd %xmm1, %xmm1, %xmm1 vfmadd132sd %xmm0, %xmm1, %xmm0 vsqrtsd %xmm0, %xmm0, %xmm0 which is I think what we want.
[Bug tree-optimization/107569] [13 Regression] Failure to optimize std::isfinite since r13-3596
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107569 --- Comment #40 from Jakub Jelinek --- The current state of #c0 testcase is that bar is actually optimized into return 1; Folding statement: .ASSUME (_Z3bard._assume.0, x_1(D)); _Z3bard._assume.0 assume inferred range of x_1(D) (param x) = [frange] double [-1.79769313486231570814527423731704356798070567525844996599e+308 (-0x0.f8p+1024), 1.7976931 3486231570814527423731704356798070567525844996599e+308 (0x0.f8p+1024)] during vrp1 and Folding statement: _4 = _3 u> 1.79769313486231570814527423731704356798070567525844996599e+308; Queued stmt for removal. Folds to: 0 It is correct to optimize the comparison even with -ftrapping-math - comparisons only emit exceptions on NaNs, the quiet ones like u> even just on sNaNs, and the range proves that the non-constant operand is never a NAN and the other isn't either (it is constant). On the other side, foo isn't optimized. # RANGE [frange] double [0.0 (0x0.0p+0), +Inf] +NAN _6 = ABS_EXPR ; _4 = _6 u> 1.79769313486231570814527423731704356798070567525844996599e+308; _8 = ~_4; if (_6 u> 1.79769313486231570814527423731704356798070567525844996599e+308) goto ; [INV] else goto ; [INV] : __builtin_unreachable (); : # RANGE [frange] double [0.0 (0x0.0p+0), +Inf] +NAN _9 = ABS_EXPR ; _10 = _9 u> 1.79769313486231570814527423731704356798070567525844996599e+308; _11 = ~_10; return _11; is turned by fre1 into: _6 = ABS_EXPR ; _4 = _6 u> 1.79769313486231570814527423731704356798070567525844996599e+308; _8 = ~_4; if (_6 u> 1.79769313486231570814527423731704356798070567525844996599e+308) goto ; [INV] else goto ; [INV] : __builtin_unreachable (); : return _8; and while e.g. evrp figures correctly out that 2->3 (T) _6 : [frange] double [+Inf, +Inf] +NAN 2->4 (F) x_3(D) : [frange] double [-1.79769313486231570814527423731704356798070567525844996599e+308 (-0x0.f8p+1024), 1.797693134862315708145274237317043567980705675 25844996599e+308 (0x0.f8p+1024)] 2->4 (F) _4 : [irange] bool [0, 0] NONZERO 0x0 2->4 (F) _6 : [frange] double [0.0 (0x0.0p+0), 1.79769313486231570814527423731704356798070567525844996599e+308 (0x0.f8p+1024)] it doesn't do the extra step of figuring out that when _4 on the 2->4 edge must be 0, then _8 on that edge must be 1. And, the finite range say for _6 or x_3(D) isn't stored into global state (if there would be say some possibly not returning call between _6 definition and uses or for x_3(D) between start of function and the uses, we obviously couldn't store it as a global range; in this case we could if we proved that isn't possible, i.e. that if the function is reached then return _8; is reached too). And then during vrp1 the same problem and __builtin_unreachable () is removed with nothing noted anywhere. Andrew, any thoughts?
[Bug target/106585] RISC-V: Mis-optimized code gen for zbs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585 --- Comment #10 from palmer at gcc dot gnu.org --- (In reply to Andrew Waterman from comment #9) > On Wed, Dec 7, 2022 at 7:02 PM palmer at gcc dot gnu.org via Gcc-bugs > wrote: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106585 > > > > palmer at gcc dot gnu.org changed: > > > >What|Removed |Added > > > > CC||palmer at gcc dot gnu.org > > > > --- Comment #8 from palmer at gcc dot gnu.org --- > > (In reply to Jeffrey A. Law from comment #7) > > > Raphael and I are poking at this a bit. I can't convince myself that it's > > > actually safe to use GPR for the bit manipulation patterns. > > > > > > For rv64 I'm pretty sure the b* instructions are operating on 64bit > > > quantities only. Meaning they might twiddle the SI sign bit without > > > extending. If we were to change these patterns to use GPR and the result > > > then fed an addw (for example) then we would have inconsistent register > > > state as operand twiddled by the prior b* pattern wouldn't have been sign > > > extended. > > > > > > To be clear, I think this is a limitation imposed by the ISA docs, not GCC > > > where this will be reasonably well defined. > > > > So you're worried about addw (and the various other OP-32 instructions) > > needing > > signed extended high parts in registers in order to function as expected? > > I've > > never gotten that from the ISA manual, there might be some vestigial > > MIPS-isms > > floating around the RISC-V port that indicate that though (as we've got > > similar > > constraints for the comparisons). > > > > That said, I'v gone and actually read the ISA manual here and it's not at > > all > > specific. I'm seeing > > > > ADDW and SUBW are RV64I-only instructions that are defined analogously > > to ADD and SUB but operate on 32-bit values and produce signed 32-bit > > results. Overflows are ignored, and the low 32-bits of the result is > > sign-extended to 64-bits and written to the destination register. > > > > which doesn't explicitly say the high 32-bits of the inputs are ignored. As > > far as I can tell "32-bit values" isn't defined anywhere, so that's not so > > useful. > > > > Do you know if there's any hardware that needs extended values for addw and > > friends? That'd almost certainly break a lot of binaries, but I could > > certainly buy an argument saying it's to the spec (and the actual words in > > the > > spec, not just this "anything goes" compatibility stuff). > > The spec explicitly says that the upper 32 bits of the inputs are > ignored; you just need to read a few paragraphs up. > https://github.com/riscv/riscv-isa-manual/blob/ > b7080e0d18765730ff4f3d07b866b4884a8be401/src/rv64.tex#L18-L21 Ah, sorry I missed that. So I think we're fine from the ISA side of things, it's just the SW constraints to worry about. > > > > > > With that in mind I think the only path forward is new patterns that > > > (sadly) > > > use explicit subregs for sources, but still set a DImode destination. > > > > > > I'm the newbie here, so if I've misinterpreted the ISA docs incorrectly, > > > don't hesitate to let me know. > > > > Kind of just a related FYI: the comparison instructions and various bits of > > the > > ABI do require values in canonical forms (the ABI stuff isn't exactly sign > > extended, but there's a rule). That's all a big fragile.
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615 --- Comment #4 from Ben Barrowes --- It has been a while. Is there any way to save the temporary preprocessed files in gfortran?
[Bug target/107920] [13 Regression] ICE in execute_todo, at passes.cc:2140
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107920 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #16 from Jakub Jelinek --- Assuming this is now fixed.
[Bug ada/107440] GCC error: in gnat_to_gnu_entity, at ada/gcc-interface/decl.cc:610
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107440 --- Comment #3 from Eric Botcazou --- > Q: „How to have less bugs“ > A: „Make bug reporting so complicated and cumbersome that no one reports > bugs any more“ Yet most other people abide by these instructions...
[Bug sanitizer/108023] New: Incorrect line number in ASAN's report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108023
Bug ID: 108023
Summary: Incorrect line number in ASAN's report
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
For the following code, GCC's ASAN at -O1 and above produce incorrect line
numbers in the final reports (Line 15 v.s. Line 8).
Compiler explorer: https://godbolt.org/z/4953EPr78
% cat a.c
int a, b, c, g, f;
static long d(int);
long d(int h) {
int **j = (int**)malloc(sizeof(int *) * sizeof(int));
for (int i = 0; i < sizeof(int); i++)
j[i] = malloc(sizeof(f));
int *k = malloc(sizeof(int) * sizeof(g));
for (h=0; h <= 2; h++) {
free(k);
for (b=0; b <= 2; b++)
k[3] = j[0][h];
}
return k[a];
}
void e() {
c = d(0);
}
int main() {
e();
return c;
}
%
% gcc-tk -O0 -fsanitize=address -w -g a.c && ./a.out
=
==3175968==ERROR: AddressSanitizer: heap-use-after-free on address
0x6020009c at pc 0x0040130f bp 0x7ffd47fc9fd0 sp 0x7ffd47fc9fc8
WRITE of size 4 at 0x6020009c thread T0
#0 0x40130e in d /a.c:15
#1 0x4013a3 in e /a.c:21
#2 0x4013ba in main /a.c:25
...
%
% gcc-tk -O2 -fsanitize=address -w -g a.c && ./a.out
==3254785==ERROR: AddressSanitizer: heap-use-after-free on address
0x6020009c at pc 0x00401354 bp 0x7ffce8fa2e80 sp 0x7ffce8fa2e78
WRITE of size 4 at 0x6020009c thread T0
#0 0x401353 in d /a.c:8
#1 0x4010e8 in e /a.c:21
#2 0x4010e8 in main /a.c:25
...
%
[Bug ada/107440] GCC error: in gnat_to_gnu_entity, at ada/gcc-interface/decl.cc:610
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107440
--- Comment #2 from Martin Krischik ---
Q: „How to have less bugs“
A: „Make bug reporting so complicated and cumbersome that no one reports bugs
any more“
—
>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/Users/martin/.config/alire/cache/dependencies/gnat_native_12.1.2_587b912f/bin/../libexec/gcc/x86_64-apple-darwin19.6.0/12.1.0/lto-wrapper
Target: x86_64-apple-darwin19.6.0
Configured with: ../src/configure
--prefix=/Users/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-darwin/gcc/install
--enable-languages=c,ada,c++ --enable-libstdcxx --enable-libstdcxx-threads
--enable-libada --disable-nls --without-libiconv-prefix --disable-libstdcxx-pch
--enable-lto --disable-multilib --disable-libcilkrts --without-build-config
--with-build-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
--with-specs='%{!sysroot=*:--sysroot=%:if-exists-else(/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk)}'
--with-mpfr=/Users/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-darwin/mpfr/install
--with-gmp=/Users/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-darwin/gmp/install
--with-mpc=/Users/runner/work/GNAT-FSF-builds/GNAT-FSF-builds/sbx/x86_64-darwin/mpc/install
--build=x86_64-apple-darwin19.6.0
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.1.0 (GCC)
—
x86_64-apple-darwin19.6.0
—
I'm using Alire — I don't know which options are passed to GCC.
—
I'm using Alire — I don't know how the GCC was build.
—
I'm using Alire — I don't even know which parameter where passed to gnatmake.
—
I already liked the source to the code. With Alire additional libraries will be
pulled in automatically.
—
Code compiles with or without a syntax error.
—
See above. Code compiles with an error box.
[Bug driver/108022] [11/12/13 regression] -frecord-gcc-switches doesn't record preprocessor macros since r11-5739-g7caa49706316e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108022 David Seifert changed: What|Removed |Added CC||soap at gentoo dot org --- Comment #4 from David Seifert --- (In reply to Jakub Jelinek from comment #3) > -frecord-gcc-switches is a totally useless option btw, just forget it exists > and use -grecord-gcc-switches instead. The problem is, the UX isn't exactly helpful. The only way I managed to extract the macro definition was gcc -ggdb3 -grecord-gcc-switches -D_TEST_SAVE_CPPFLAGS test.c -o ~/test && objdump -s -j .debug_str test | grep SAVE which doesn't make our use case any easier really (since it requires heavy debug flags).
[Bug tree-optimization/105043] Documentation for __builtin_object_size and other Object Size checking builtin functions should mention - D_FORTIFY_SOURCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105043 Siddhesh Poyarekar changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot gnu.org See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=28998 --- Comment #8 from Siddhesh Poyarekar --- I'm working on some documentation in glibc. I agree the last part of the Object Size Checking documentation can be rephrased in the context of _FORTIFY_SOURCE, let me take a shot at that.
[Bug driver/108022] [11/12/13 regression] -frecord-gcc-switches doesn't record preprocessor macros since r11-5739-g7caa49706316e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108022 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- -frecord-gcc-switches is a totally useless option btw, just forget it exists and use -grecord-gcc-switches instead.
[Bug driver/108022] [11/12/13 regression] -frecord-gcc-switches doesn't record preprocessor macros since r11-5739-g7caa49706316e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108022 Martin Liška changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #2 from Martin Liška --- Yes, the change was intentional as we merged what we produce for both -frecord-gcc-switches and -grecord-gcc-switches.
[Bug debug/106719] [10/11/12 Regression] '-fcompare-debug' failure w/ -O2 since r10-6038-ge5e07b68187b9a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106719 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11/12 Regression] |'-fcompare-debug' failure |'-fcompare-debug' failure |w/ -O2 since|w/ -O2 since |r10-6038-ge5e07b68187b9a|r10-6038-ge5e07b68187b9a --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug web/107749] onlinedocs: gdc docs got removed during sphinx revert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107749 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Iain Buclaw --- They've been re-added.
[Bug debug/106719] [10/11/12/13 Regression] '-fcompare-debug' failure w/ -O2 since r10-6038-ge5e07b68187b9a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106719
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d9f9d5d30feb33c359955d7030cc6be50ef6dc0a
commit r13-4559-gd9f9d5d30feb33c359955d7030cc6be50ef6dc0a
Author: Jakub Jelinek
Date: Thu Dec 8 14:57:22 2022 +0100
cfgbuild: Fix DEBUG_INSN handling in find_bb_boundaries [PR106719]
The following testcase FAILs on aarch64-linux. We have some atomic
instruction followed by 2 DEBUG_INSNs (if -g only of course) followed
by NOTE_INSN_EPILOGUE_BEG followed by some USE insn.
Now, split3 pass replaces the atomic instruction with a code sequence
which ends with a conditional jump and the split3 pass calls
find_many_sub_basic_blocks.
For -g0, find_bb_boundaries sees the flow_transfer_insn (the new
conditional
jump), then NOTE_INSN_EPILOGUE_BEG which can live in between basic blocks
and then the USE insn, so splits block after the NOTE_INSN_EPILOGUE_BEG
and puts the NOTE in between the blocks.
For -g, if sees a DEBUG_INSN after the flow_transfer_insn, so sets
debug_insn to it, then walks over another DEBUG_INSN,
NOTE_INSN_EPILOGUE_BEG
until it finally sees the USE insn, and triggers the:
rtx_insn *prev = PREV_INSN (insn);
/* If the first non-debug inside_basic_block_p insn after a
control
flow transfer is not a label, split the block before the debug
insn instead of before the non-debug insn, so that the debug
insns are not lost. */
if (debug_insn && code != CODE_LABEL && code != BARRIER)
prev = PREV_INSN (debug_insn);
code I've added for PR81325. If there are only DEBUG_INSNs, that is
the right thing to do, but if in between debug_insn and insn there are
notes which can stay in between basic blocks or simnilarly JUMP_TABLE_DATA
or their associated CODE_LABELs, it causes -fcompare-debug differences.
The following patch fixes it by clearing debug_insn if JUMP_TABLE_DATA
or associated CODE_LABEL is seen (I'm afraid there is no good answer
what to do with DEBUG_INSNs before those; the code then removes them:
/* Clean up the bb field for the insns between the blocks.
*/
for (x = NEXT_INSN (flow_transfer_insn);
x != BB_HEAD (fallthru->dest);
x = next)
{
next = NEXT_INSN (x);
/* Debug insns should not be in between basic blocks,
drop them on the floor. */
if (DEBUG_INSN_P (x))
delete_insn (x);
else if (!BARRIER_P (x))
set_block_for_insn (x, NULL);
}
but if there are NOTEs, the patch just reorders the NOTEs and DEBUG_INSNs,
such that the NOTEs come first (so that they stay in between basic blocks
like with -g0) and DEBUG_INSNs after those (so that bb is split before
them, so they will be in the basic block after NOTE_INSN_BASIC_BLOCK).
2022-12-08 Jakub Jelinek
PR debug/106719
* cfgbuild.cc (find_bb_boundaries): If there are NOTEs in between
debug_insn (seen after flow_transfer_insn) and insn, move NOTEs
before all the DEBUG_INSNs and split after NOTEs. If there are
other insns like jump table data, clear debug_insn.
* gcc.dg/pr106719.c: New test.
[Bug target/107627] [13 Regression] int128_t shift generates extra xor/or.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107627
--- Comment #11 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:1dc49df4eeaec311f19638861c64e90d7ec696e5
commit r13-4558-g1dc49df4eeaec311f19638861c64e90d7ec696e5
Author: Jakub Jelinek
Date: Thu Dec 8 14:55:46 2022 +0100
i386: Add *concat3_{5,6,7} patterns [PR107627]
On Thu, Dec 01, 2022 at 09:09:51AM +0100, Jakub Jelinek via Gcc-patches
wrote:
> BTW, I wonder if we couldn't add additional patterns which would catch
> the case where one of the operands is constant.
The following patch does add those.
The difference with the patch on the 2 testcases is:
baz:
- movq8(%rsi), %rax
+ movq8(%rsi), %rsi
+ movq%rdi, %r8
movl%edx, %ecx
- xorl%r8d, %r8d
- xorl%edx, %edx
- movabsq $-2401053089206453570, %r9
- orq %r8, %rax
- orq %r9, %rdx
- shrdq %rdx, %rax
- movq%rax, (%rdi)
+ movabsq $-2401053089206453570, %rdi
+ movq%rsi, %rax
+ shrdq %rdi, %rax
+ movq%rax, (%r8)
qux:
- movq(%rsi), %rax
+ movq%rdi, %r8
+ movq(%rsi), %rdi
movl%edx, %ecx
- xorl%r9d, %r9d
- movabsq $-2401053089206453570, %r8
- movq%rax, %rdx
- xorl%eax, %eax
- orq %r8, %rax
- orq %r9, %rdx
- shrdq %rdx, %rax
- movq%rax, (%rdi)
+ movabsq $-2401053089206453570, %rsi
+ movq%rsi, %rax
+ shrdq %rdi, %rax
+ movq%rax, (%r8)
and
garply:
pushl %esi
- xorl%edx, %edx
+ movl$-559038737, %esi
pushl %ebx
movl16(%esp), %eax
- orl $-559038737, %edx
movl20(%esp), %ecx
- movl4(%eax), %eax
- shrdl %edx, %eax
movl12(%esp), %edx
+ movl4(%eax), %ebx
+ movl%ebx, %eax
+ shrdl %esi, %eax
fred:
...
movl16(%esp), %eax
+ movl$-889275714, %ebx
movl20(%esp), %ecx
- movl(%eax), %eax
- movl%eax, %edx
- movl$0, %eax
- orl $-889275714, %eax
- shrdl %edx, %eax
movl12(%esp), %edx
+ movl(%eax), %esi
+ movl%ebx, %eax
+ shrdl %esi, %eax
2022-12-08 Jakub Jelinek
PR target/107627
* config/i386/i386.md (HALF, half): New mode attributes.
(*concat3_5, *concat3_6,
*concat3_7): New define_insn_and_split patterns.
* gcc.target/i386/pr107627-3.c: New test.
* gcc.target/i386/pr107627-4.c: New test.
[Bug tree-optimization/107985] [13 Regression] ICE in as_a, at value-range.h:393
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107985 --- Comment #6 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:0ef9991d8767932f51fa97753c16058d17b29b18 commit r13-4557-g0ef9991d8767932f51fa97753c16058d17b29b18 Author: Andrew MacLeod Date: Tue Dec 6 10:41:29 2022 -0500 Ensure arguments to range-op handler are supported. PR tree-optimization/107985 gcc/ * gimple-range-op.cc (gimple_range_op_handler::gimple_range_op_handler): Check if type of the operands is supported. * gimple-range.cc (gimple_ranger::prefill_stmt_dependencies): Do not assert if here is no range-op handler. gcc/testsuite/ * g++.dg/pr107985.C: New.
[Bug driver/108022] [11/12/13 regression] -frecord-gcc-switches doesn't record preprocessor macros since r11-5739-g7caa49706316e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108022 Sam James changed: What|Removed |Added Summary|[11/12/13 regression] |[11/12/13 regression] |-frecord-gcc-switches |-frecord-gcc-switches |doesn't record preprocessor |doesn't record preprocessor |macros since|macros since |7caa49706316e650fb67719e1a1 |r11-5739-g7caa49706316e6 |bf3a35054b685 | --- Comment #1 from Sam James --- (it's r11-5739-g7caa49706316e6).
[Bug driver/108022] New: [11/12/13 regression] -frecord-gcc-switches doesn't record preprocessor macros since 7caa49706316e650fb67719e1a1bf3a35054b685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108022
Bug ID: 108022
Summary: [11/12/13 regression] -frecord-gcc-switches doesn't
record preprocessor macros since
7caa49706316e650fb67719e1a1bf3a35054b685
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: sam at gentoo dot org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
-frecord-gcc-switches seems to have stopped recording preprocessor flags passed
on the command line between GCC 10 and GCC 11.
```
$ cat test.c
#include
int main(void) {
printf("%s", "hi\n");
}
$ gcc-10 -frecord-gcc-switches -D_TEST_SAVE_CPPFLAGS test.c -o ~/test &&
objdump -s test | grep -i TEST_SAVE
2d44205f 54455354 5f534156 455f4350 -D _TEST_SAVE_CP
$ gcc-11 -frecord-gcc-switches -D_TEST_SAVE_CPPFLAGS test.c -o ~/test &&
objdump -s test | grep -i TEST_SAVE
```
10.4.1 (20221201) is fine
11.3.1 (20221202) is not
gcc 12 and gcc 13 also have the same regression from gcc 10 (they don't work).
Manually inspecting 'objdump -s test' doesn't show -DD_TEST_SAVE_CPPFLAGS
either (it's not an issue with how the string is chunked).
I ran a bisect overnight and it looks like the culprit is:
```
7caa49706316e650fb67719e1a1bf3a35054b685 is the first bad commit
commit 7caa49706316e650fb67719e1a1bf3a35054b685
Author: Martin Liska
Date: Mon Nov 23 13:40:04 2020 +0100
Refactor -frecord-gcc-switches.
gcc/ChangeLog:
* doc/tm.texi: Change argument of the record_gcc_switches
hook and remove SWITCH_TYPE_* enum values.
* dwarf2out.c (gen_producer_string): Move to opts.c and remove
handling of the dwarf_record_gcc_switches option.
(dwarf2out_early_finish): Use moved gen_producer_string
function.
* opts.c (gen_producer_string): New.
* opts.h (gen_producer_string): New.
* target.def: Change type of record_gcc_switches.
* target.h (enum print_switch_type): Remove.
(elf_record_gcc_switches): Change first argument.
* toplev.c (MAX_LINE): Remove.
(print_to_asm_out_file): Likewise.
(print_to_stderr): Likewise.
(print_single_switch): Likewise.
(print_switch_values): Likewise.
(init_asm_output): Use new gen_producer_string function.
(process_options): Likewise.
* varasm.c (elf_record_gcc_switches): Just save the string argument
to the ELF container.
gcc/doc/tm.texi | 38 +---
gcc/dwarf2out.c | 118 +++--
gcc/opts.c | 119 ++
gcc/opts.h | 6 ++
gcc/target.def | 38 +---
gcc/target.h| 14 +
gcc/toplev.c| 176 ++--
gcc/varasm.c| 48
8 files changed, 166 insertions(+), 391 deletions(-)
```
I haven't tried reverting it yet as it doesn't revert cleanly on master.
[Bug sanitizer/108021] New: sanitizer used with qemu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108021
Bug ID: 108021
Summary: sanitizer used with qemu
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: laurent.alfonsi at linaro dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
Hi,
I m running gcc testsuite with qemu, and I am facing an issue in sanitizer.
Before (12.x), the asan was incompatible with ptrace.
$ cat emtpy.c
int main(void) { return 0; }
$ aarch64-linux-gnu-gcc emtpy.c -fsanitize=address
$ qemu-aarch64 -L ./sysroot-with-libasan-from-release ./a.out
==135765==LeakSanitizer has encountered a fatal error.
==135765==HINT: For debugging, try setting environment variable
LSAN_OPTIONS=verbosity=1:log_threads=1
==135765==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)
# fiishes quickly : return status=1
Now (13.x),
$ qemu-aarch64 -L ./sysroot-with-libasan-from-master-branch ./a.out
# RAM memory grows exponentially without message
It happens of course on most asan-dg.exp tests
Either, it has been changed and not incompatible anymore with ptrace, or the
error message was removed by error.
It happens of course on most asan-dg.exp tests.
Is this supposed to work now ?
[Bug preprocessor/62661] digit separator warning in if'ed out code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62661 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- I think it is PR14634 that actually changed this. The question is if we can avoid the pedwarn in system headers, or if it should be kind of pedwarn that isn't emitted as a warning without -pedantic/-Wpedantic.
[Bug preprocessor/62661] digit separator warning in if'ed out code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62661 --- Comment #6 from Jonathan Wakely --- What's really fun is that you can't even do: #if __cpp_digit_separators int i = 1'000; #else int i = 1000; #endif
[Bug libstdc++/108015] [13 Regression] 17_intro/headers/c++2011/stdc++_multiple_inclusion.cc failure on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108015 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Jonathan Wakely --- Warning about this is stupid. We tokenized it successfully, complaining that we couldn't is unhelpful. Clang and EDG do not warn.
[Bug tree-optimization/107699] [12/13 Regression] False positive -Warray-bounds, non-existent offset reported by GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699 --- Comment #10 from Richard Biener --- The change fixed the missing _2 = _M_elems + _1; if (_M_elems != _2) goto ; [53.47%] else goto ; [46.53%] optimization only, the diagnostic is still there.
[Bug tree-optimization/107699] [12/13 Regression] False positive -Warray-bounds, non-existent offset reported by GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107699 --- Comment #9 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:892e8c520be37d0a0f14e2ae375103c5303ed549 commit r13-4555-g892e8c520be37d0a0f14e2ae375103c5303ed549 Author: Richard Biener Date: Thu Dec 8 09:07:36 2022 +0100 tree-optimization/107699 - missed _M_elems + _1 != _M_elems folding The following addresses a missed folding noticed in PR107699 that can be fixed amending the existing + a != + b pattern to also handle the case of only one side having a pointer plus. I'm moving the patterns next to related simpifications showing there'd be an existing pattern matching this if it were not gated with an explicit single_use constraint. Note the new pattern also handles + a != , but this hints at some unification / generalization opportunities here. PR tree-optimization/107699 * match.pd ( !=/== + c -> ( - ) !=/== c): New pattern variant. * gcc.dg/tree-ssa/pr107699.c: New testcase.
[Bug tree-optimization/102706] [12 regression] -O2 vectorization causes regression in Warray-bounds-48.c on many targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102706 --- Comment #6 from CVS Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:4505270128ef70538ea345f292e3eb85a5369eaf commit r13-4554-g4505270128ef70538ea345f292e3eb85a5369eaf Author: Alexandre Oliva Date: Thu Dec 8 07:50:33 2022 -0300 [PR102706] [testsuite] -Wno-stringop-overflow vs Warray-bounds The bogus Wstringop-overflow warnings conditionally issued for Warray-bounds-48.c and -Wzero-length-array-bounds-2.c are expected under conditions that depend on the availability of certain vector patterns, but that don't seem to model the conditions under which the warnings are expected. On riscv64-elf and arm-eabi/-mcpu=cortex-r5, for example, though the Warray-bounds-48.c condition passes, we don't issue warnings. On riscv64-elf, we decide not to vectorize the assignments; on cortex-r5, we do vectorize pairs of assignments, but that doesn't yield the expected warning, even though assignments that should trigger the bogus warning are vectorized and associated with the earlier line where the bogus warning would be expected. On riscv64, for Wzero-length-array-bounds-2.c, we issue the expected warning in test_C_global_buf, but we also issue a warning for test_C_local_buf under the same conditions, that would be expected on other platforms but that is not issued on them. On arm-eabi/-mcpu=cortex-r5, the condition passes so we'd expect the warning in both functions, but we don't warn on either. Instead of further extending the effective target tests, introduced to temporarily tolerate these expected bogus warnings, so as to capture the vectorizer analyses that lead to the mismatched decisions, I'm disabling the undesired warnings for these two tests. for gcc/testsuite/ChangeLog PR tree-optimization/102706 * gcc.dg/Warray-bounds-48.c: Disable -Wstringop-overflow. * gcc.dg/Wzero-length-array-bounds-2.c: Likewise.
[Bug tree-optimization/99919] [10/11/12/13 Regression] bogus -Wmaybe-uninitialized with a _Bool bit-field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919 --- Comment #7 from Richard Biener --- Created attachment 54047 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54047=edit patch I also have a patch - this disables optimize_bit_field_compare for bitfield vs. constant compares which is the source of most premature obfuscation and avoids missing the optimization of multiple bitfield extracts as if more aggressively removing this code.
[Bug c/108019] [ARM] D16 float register was used but not saved in integer-dominated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108019 Richard Earnshaw changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #6 from Richard Earnshaw --- d16 is a call-clobbered register in the ABI. There is no need for the compiler to save it before use.
[Bug tree-optimization/107409] Perf loss ~5% on 519.lbm_r SPEC cpu2017 benchmark with r10-5090-ga9a4edf0e71bba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107409 --- Comment #11 from Rama Malladi --- (In reply to Martin Liška from comment #10) > @Honza ? Just checking if this can be fixed/ implemented. Thanks.
[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107967 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Jakub Jelinek --- The rest is I believe dup of PR107608.
[Bug c++/108020] New: Add fix-it hint for iostream operators declared in-class without 'friend'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108020
Bug ID: 108020
Summary: Add fix-it hint for iostream operators declared
in-class without 'friend'
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
#include
#include
struct S
{
std::istream& operator>>(std::istream&, S&);
std::ostream& operator<<(std::ostream&, S&);
};
streamop.cc:5:17: error: ‘std::istream& S::operator>>(std::istream&, S&)’ must
have exactly one argument
5 | std::istream& operator>>(std::istream&, S&);
| ^~~~
streamop.cc:6:17: error: ‘std::ostream& S::operator<<(std::ostream&, S&)’ must
have exactly one argument
6 | std::ostream& operator<<(std::ostream&, S&);
| ^~~~
The user probably meant to declare these with 'friend'. We could suggest that
in a fix-it hint.
The fix-it should only be given when the first argument is a specialization of
std::basic_[io]stream. The error is fine for shift operators, although those
are probably defined less often than stream operators. The fix-it could be
added if the signature of a member function matches either of these, for any C
and T:
std::basic_ostream& operator<<(std::basic_ostream&, const X&);
std::basic_istream& operator>>(std::basic_istream&, X&);
[Bug libstdc++/108015] [13 Regression] 17_intro/headers/c++2011/stdc++_multiple_inclusion.cc failure on i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108015 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-12-08 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug ipa/108007] [10/11/12/13 Regression] wrong code at -Os and above with "-fno-dce -fno-tree-dce" on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108007 Martin Liška changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #5 from Martin Liška --- (In reply to Andrew Pinski from comment #4) > Most likely due to r10-3311-gff6686d2e5f797 (the new IPA-SRA). Yes, it's since the revision.
[Bug target/87832] AMD pipeline models are very costly size-wise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87832 --- Comment #12 from Martin Liška --- Nice work Alexander!
[Bug middle-end/107976] ICE: SIGSEGV (stack overflow) in emit_case_dispatch_table (stmt.cc:783) with large --param=jump-table-max-growth-ratio-for-speed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107976 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-12-08 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #3 from Martin Liška --- Yeah, I think we should limit the params to a reasonable limit.
[Bug tree-optimization/107828] tree-inlining would generate SSA with incorrect def stmt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107828 Martin Liška changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #3 from Martin Liška --- I tend to close this as Martin provided an answer.
