[Bug other/108644] Format string warnings related to longs under MigW-W64/MSYS2 on Windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644 --- Comment #3 from Richard Biener --- (In reply to Andrew Pinski from comment #1) > The lto-plugin warnings are not a GCC issue really. > ../../../gcc/lto-plugin/lto-plugin.c:501:19: warning: 'I' flag used with > '%x' gnu_printf format [-Wformat=] > > > Those are done correctly and using the right arguments and all. The issue is > rather how PRI_LL is defined but fprintf specifies gnu_printf rather than > win32_printf format > Where is PRI_LL definition coming from? Please provide the preprocessed > source (and add -g3 to keep the #define's in there). > I suspect there is a bug in mingw's stdint.h in some cases ... /* We need to use I64 instead of ll width-specifier on native Windows. The reason for this is that older MS-runtimes don't support the ll. */ #ifdef __MINGW32__ #define PRI_LL "I64" #else #define PRI_LL "ll" #endif
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 Richard Biener changed: What|Removed |Added Last reconfirmed||2023-02-03 Status|UNCONFIRMED |NEW Priority|P3 |P1 Ever confirmed|0 |1 CC||amacleod at redhat dot com --- Comment #1 from Richard Biener --- Confirmed. We have VR_UNDEFINED as other_op in #4 0x030c3df4 in gori_compute::refine_using_relation (this=0x490b310, op1=, op1_range=..., op2=, op2_range=..., src=..., k=VREL_LT) at /home/rguenther/src/trunk/gcc/gimple-range-gori.cc:1034 1034 if (!op_handler.op2_range (new_result, type, (gdb) l 1029 src.get_operand (other_op, def_op1); 1030 1031 // Using op1_range as the LHS, and relation REL, evaluate op2. 1032 tree type = TREE_TYPE (def_op2); 1033 Value_Range new_result (type); 1034 if (!op_handler.op2_range (new_result, type, 1035 op1_def_p ? op1_range : op2_range, 1036 other_op, relation_trio::lhs_op2 (k))) must be a quite recent regression.
[Bug tree-optimization/108601] [13 Regression] vector peeling ICEs with VLA in gcc_r in SPEC2017 since g:c13223b790bbc5e4a3f5605e057eac59b61b2c85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #16 from Richard Biener --- Fixed.
[Bug tree-optimization/108653] New: SRA compile-time hog with large copy chain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108653
Bug ID: 108653
Summary: SRA compile-time hog with large copy chain
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
PR108500 shows that propagate_all_subaccesses is quadratic in the length of a
copy chain. A simplified testcase looks like the following where adding
'THOUSAND's will increase the number of items worked on in its processing loop
quadratically.
struct s2 {
int id;
char a[20];
};
static inline __attribute__((always_inline)) struct s2
f(struct s2 s)
{
return s;
}
volatile struct s2 x;
int main(void)
{
struct s2 s2 = {0};
#define TEN \
s2 = f(s2); \
s2 = f(s2); \
s2 = f(s2); \
s2 = f(s2); \
s2 = f(s2); \
s2 = f(s2); \
s2 = f(s2); \
s2 = f(s2); \
s2 = f(s2); \
s2 = f(s2);
#define HUNDRED TEN TEN TEN TEN TEN TEN TEN TEN TEN TEN
#define THOUSAND HUNDRED HUNDRED HUNDRED HUNDRED HUNDRED HUNDRED HUNDRED
HUNDRED HUNDRED HUNDRED
THOUSAND THOUSAND
return 0;
}
with a dev build this shows
tree SRA : 0.52 ( 66%) 0.00 ( 0%) 0.53 ( 66%)
0 ( 0%)
[Bug c/108654] New: Incorrect codegen of RVV GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108654
Bug ID: 108654
Summary: Incorrect codegen of RVV GCC
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
#include "riscv_vector.h"
void foo5_3 (int32_t * restrict in, int32_t * restrict out, size_t n, int cond)
{
vint8m1_t v = *(vint8m1_t*)in;
*(vint8m1_t*)out = v;
vbool8_t v3 = *(vbool8_t*)in;
*(vbool8_t*)(out + 200) = v3;
vbool16_t v4 = *(vbool16_t *)in;
*(vbool16_t *)(out + 300) = v4;
}
ASM:
foo5_3:
csrrt0,vlenb
sllit1,t0,1
csrra5,vlenb
sub sp,sp,t1
sllia3,a5,1
vl1re8.vv24,0(a0)
add a3,a3,sp
vs1r.v v24,0(a1)
addia4,a1,800
sub a5,a3,a5
vsetvli a3,zero,e8,m1,ta,ma
vsm.v v24,0(a4)
vs1r.v v24,0(a5)
addia1,a1,1200
csrrt0,vlenb
sllit1,t0,1
vsetvli a5,zero,e8,mf2,ta,ma
vsm.v v24,0(a1)
add sp,sp,t1
jr ra
There are 2 issues here:
First, 2 vlm.v mask loads are missing which is incorrect code-gen.
Second, the code quality is bad which is the duplicate bug filed here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108185
[Bug tree-optimization/108500] [11/12 Regression] -O -finline-small-functions results in "internal compiler error: Segmentation fault" on a very large program (700k function calls)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500 --- Comment #19 from Richard Biener --- I have split out the SRA issue to PR108653.
[Bug tree-optimization/108639] [13 Regression] ICE on valid code at -O1 and above: in decompose, at wide-int.h:984 since r13-5578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639 --- Comment #12 from Aldy Hernandez --- Yeah, I've been mulling around the idea of removing the type from storage of both irange and frange. It seems we need it for setting a type (setting the endpoints for varying, querying HONOR_NANS, HONOR_INFINITIES,e tc), but not in the storage itself. Something to keep in mind when moving to wide_ints. It does seem we need to keep the sign and precision somewhere. The precision lives in the wide-int, but the sign bit still needs storage??
[Bug modula2/108551] gcc/m2/gm2-libs-pim/Termbase.mod:128:1: error: control reaches end of non-void function [-Werror=return-type]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108551 Gaius Mulley changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #12 from Gaius Mulley --- Closing after the git push and also PR108555 has been fixed.
[Bug modula2/108612] m2/gm2-libs-iso/ClientSocket.mod:229:1: error: control reaches end of non-void function [-Werror=return-type]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108612 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Gaius Mulley --- Closing now the patch has been applied.
[Bug c++/108655] New: ICE in execute_todo, at passes.cc:2134 since r13-1204-gd68d366425369649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108655
Bug ID: 108655
Summary: ICE in execute_todo, at passes.cc:2134 since
r13-1204-gd68d366425369649
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jason at redhat dot com
Target Milestone: ---
The following ICEs:
$ int
test_collapse() {
int i;
for (; i;)
;
for (; i < 6;)
for (int j = 0; j < 6; ++j)
i += j;
}
$ gcc simd.c -c -O1 -funreachable-traps
during GIMPLE pass: ivcanon
simd.c: In function ‘test_collapse’:
simd.c:2:1: internal compiler error: in execute_todo, at passes.cc:2140
2 | test_collapse() {
| ^
0x721e5f execute_todo
/home/marxin/Programming/gcc/gcc/passes.cc:2140
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c++/108655] ICE in execute_todo, at passes.cc:2134 since r13-1204-gd68d366425369649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108655 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-02-03 Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=106258
[Bug modula2/108551] gcc/m2/gm2-libs-pim/Termbase.mod:128:1: error: control reaches end of non-void function [-Werror=return-type]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108551 --- Comment #13 from Martin Liška --- Thanks, I can confirm it's fine now.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Summary|[13 Regression] ICE in |[13 Regression] ICE in |upper_bound, at |upper_bound, at |value-range.h:950 with -O3 |value-range.h:950 with -O3 ||since ||r13-2974-g67166c9ec35d58ef --- Comment #2 from Martin Liška --- Started with r13-2974-g67166c9ec35d58ef.
[Bug middle-end/106805] [13 Regression] Undue optimisation of floating-point comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106805 --- Comment #9 from Jakub Jelinek --- So, the current state is that this is now optimized away by dom2 using frange, like in PR107608 (which is closed with a workaround), but in this case the NaN vs. 1.0 or NaN vs. Inf >= and <= comparisons get a singleton integral range which dom2 then optimizes out. GCC 12 optimizes it out currently even earlier because #c5 change isn't backported there yet, but otherwise wouldn't suffer from the frange issue and would be miscompiled only during expansion. I'd say for now if you want such a function to raise exceptions even with constant arguments, don't make it inline and add noipa attribute to it instead. That case I think has been fixed on the trunk already.
[Bug c++/108646] nonnull attribute does not detect variables that are NULL being passed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108646 --- Comment #2 from Jonathan Wakely --- It already does detect it: n.c: In function ‘test’: n.c:6:2: warning: argument 1 null where non-null expected [-Wnonnull] 6 | mem2(dest); | ^~ n.c:2:8: note: in a call to function ‘mem2’ declared ‘nonnull’ 2 | void * mem2(void *dest) __attribute__((nonnull)); |^~~~ You need to enable optimization, otherwise there is no data flow analysis. Without optimization, it detects it with -fanalyzer n.c: In function ‘void test()’: n.c:6:6: warning: use of NULL ‘dest’ where non-null expected [CWE-476] [-Wanalyzer-null-argument] 6 | mem2(dest); | ^~ ‘void test()’: events 1-2 | |5 | char *dest = NULL; | |^~~~ | || | |(1) ‘dest’ is NULL |6 | mem2(dest); | | ~~ | | | | | (2) argument 1 (‘dest’) NULL where non-null expected | n.c:2:8: note: argument 1 of ‘void* mem2(void*)’ must be non-null 2 | void * mem2(void *dest) __attribute__((nonnull)); |^~~~ And it's also detected at runtime using -fsanitize=undefined: n.c:6:6: runtime error: null pointer passed as argument 1, which is declared to never be null
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 Jakub Jelinek changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- The ICE is when operator_lt::op2_range does: 976 case BRS_FALSE: 977 build_le (r, type, op1.upper_bound ()); 978 break; lhs is [irange] bool [0, 0] NONZERO 0x0 and rhs is [irange] UNDEFINED which is why op1.upper_bound () ICEs - it has no pairs. I wonder if operator_lt::op?_range and other operators shouldn't start with relop_early_resolve or at least empty_range_varying or something similar to deal with op?.undefined_p ().
[Bug libstdc++/108645] Change in behavior, std::accumulate doesn't always work as expected in C++20 builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108645
--- Comment #3 from Jonathan Wakely ---
(In reply to Evan Teran from comment #1)
> Which results in the same behavior, so it appears to be that the:
>
> ```
> basic_string operator+(basic_string &&, basic_string &&)
> ```
>
> Overload doesn't steal the guts of the rhs at all?
It does if:
- the allocators are equal,
- the LHS does not have sufficient capacity for the result, and
- the RHS does have sufficient capacity for the result.
In your example, all your strings fit in the SSO buffer inside the std::string
object, so the LHS has sufficient capacity for the result. And there's nothing
to steal from the RHS anyway, as it doesn't own any allocated memory.
The observed behaviour is not a bug, because as you say, leaving the RHS
non-empty is a valid state. The implementation is pretty clear:
{
#if _GLIBCXX_USE_CXX11_ABI
using _Alloc_traits = allocator_traits<_Alloc>;
bool __use_rhs = false;
if _GLIBCXX17_CONSTEXPR (typename _Alloc_traits::is_always_equal{})
__use_rhs = true;
else if (__lhs.get_allocator() == __rhs.get_allocator())
__use_rhs = true;
if (__use_rhs)
#endif
{
const auto __size = __lhs.size() + __rhs.size();
if (__size > __lhs.capacity() && __size <= __rhs.capacity())
return std::move(__rhs.insert(0, __lhs));
}
return std::move(__lhs.append(__rhs));
}
If the RHS object is used (because all the conditions above are true) then it
will be moved into the return value and so left empty.
If the LHS is used then the RHS is unchanged.
[Bug rtl-optimization/104054] [10/11/12/13 Regression] '-fcompare-debug' failure (length) w/ -Os -funroll-loops since r8-3946-gfe94440235cfaa57
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104054 --- Comment #11 from Uroš Bizjak --- The testcase now PASSes compare-debug with: gcc version 13.0.1 20230203 (experimental) [master r13-5678-g167b04b9b8a] (GCC) ... but passes due to different register allocation, where regrename is not triggered. The core of the problem (See Comment #8) remains unfixed, and it will require some deep surgery into regrename pass.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 --- Comment #4 from Jakub Jelinek --- Perhaps just adding if (op2.undefined_p ()) return false; above most of the switch (get_bool_state (r, lhs, type)) lines (in methods that refer to op2; and similarly for op1) for the comparison operators.
[Bug libstdc++/108645] Change in behavior, std::accumulate doesn't always work as expected in C++20 builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108645 --- Comment #4 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #3) > const auto __size = __lhs.size() + __rhs.size(); > if (__size > __lhs.capacity() && __size <= __rhs.capacity()) > return std::move(__rhs.insert(0, __lhs)); It would be possible to change that logic to: const auto __size = __lhs.size() + __rhs.size(); if (__size <= __rhs.capacity() && __rhs.capacity() > __lhs.capacity()) return std::move(__rhs.insert(0, __lhs)); That way if both strings have sufficient capacity, we would return the larger of the two capacities. In general, the returned string is more likely to be the one that gets reused, and this way it would be more likely to have additional spare capacity. In some usage patterns this would be a pessimization, because it would tend to coalesce all the larger capacities into one string, leaving smaller, less useful strings behind. Also, inserting into the beginning of the RHS takes more work than simply appending to the end of the LHS. So I don't think it's clear that this would be a definite improvement. It wouldn't change anything in your example anyway, because there is no dynamically allocated memory anywhere except the accumulator value, which is always the LHS.
[Bug libstdc++/108645] Change in behavior, std::accumulate doesn't always work as expected in C++20 builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108645 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #3) > In your example, all your strings fit in the SSO buffer inside the > std::string object, so the LHS has sufficient capacity for the result. Actually that's only true until the last step of the algorithm. On the last step (when appending "example" to "this_is_an_") neither the LHS nor the RHS has capacity for the result, so a reallocation is needed. But it's true that the RHS has nothing to steal at any step in the algorithm, so we append to the LHS and let that reallocate itself if needed. > And > there's nothing to steal from the RHS anyway, as it doesn't own any > allocated memory.
[Bug tree-optimization/108655] [13 Regression] ICE in execute_todo, at passes.cc:2134 since r13-1204-gd68d366425369649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108655 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Summary|ICE in execute_todo, at |[13 Regression] ICE in |passes.cc:2134 since|execute_todo, at |r13-1204-gd68d366425369649 |passes.cc:2134 since ||r13-1204-gd68d366425369649 CC||jakub at gcc dot gnu.org Priority|P3 |P1 Target Milestone|--- |13.0 Component|c++ |tree-optimization Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
[Bug tree-optimization/108655] [13 Regression] ICE in execute_todo, at passes.cc:2134 since r13-1204-gd68d366425369649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108655 --- Comment #1 from Jakub Jelinek --- Created attachment 54401 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54401&action=edit gcc13-pr108655.patch Untested fix.
[Bug debug/108656] New: [12/13 Regression] '-fcompare-debug' failure (length) w/ -O2 -fno-ipa-pure-const -fno-tree-dce --param early-inlining-insns=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108656
Bug ID: 108656
Summary: [12/13 Regression] '-fcompare-debug' failure (length)
w/ -O2 -fno-ipa-pure-const -fno-tree-dce --param
early-inlining-insns=0
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: compare-debug-failure
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++ 13.0.0 20220515 snapshot (g:18547874ee205d830acb31f1e3c1c89fc7725c14) fails
-fcompare-debug check when compiling the following testcase w/ -O2
-fno-ipa-pure-const -fno-tree-dce --param early-inlining-insns=0:
volatile int q;
int m, n;
int
quux (int x)
{
return x;
}
int
corge (int x, int y)
{
if (x < 0 || x > y)
return 1;
return 0;
}
int
baz (void)
{
return m ? q : 0;
}
__attribute__ ((pure, returns_twice)) int
bar (void)
{
(void) baz ();
return 0;
}
int
foo (void)
{
int a = quux (0);
int b = corge (bar (), n);
return 0;
}
% gcc-13 -O2 -fcompare-debug -fno-ipa-pure-const -fno-tree-dce --param
early-inlining-insns=0 -c c46sgk3m.c
gcc-13: error: c46sgk3m.c: '-fcompare-debug' failure (length)
gkd diff:
(note # 0 0 NOTE_INSN_DELETED)
Declarations used by foo, sorted by DECL_UID:
-1: static volatile int q;
-0: static int m;
+2: static volatile int q;
+1: static int m;
+0: static int n;
;; Function foo (foo, funcdef_no=4, cgraph_uid=5, symbol_order=7)
@@ -184,17 +185,17 @@
(jump_insn # 0 0 2 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
-(label_ref #)
+(label_ref:DI #)
(pc))) "c46sgk3m.c":22:16# {*jcc}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 536870916 (nil)))
- -> 12)
+ -> 13)
(note # 0 0 [bb 3] NOTE_INSN_BASIC_BLOCK)
-(insn:TI # 0 0 3 (set (reg:SI 0 ax [orig:83 iftmp.0_10 ] [83])
+(insn:TI # 0 0 3 (set (reg:SI 0 ax [orig:84 iftmp.0_10 ] [84])
(mem/v/c:SI (symbol_ref:DI ("q") [flags 0x2] ) [ q+0 S4
A32])) "c46sgk3m.c":22:16 discrim 1# {*movsi_internal}
- (expr_list:REG_UNUSED (reg:SI 0 ax [orig:83 iftmp.0_10 ] [83])
+ (expr_list:REG_UNUSED (reg:SI 0 ax [orig:84 iftmp.0_10 ] [84])
(nil)))
-(code_label # 0 0 4 12 (nil) [1 uses])
+(code_label # 0 0 4 13 (nil) [1 uses])
(note # 0 0 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn:TI # 0 0 4 (parallel [
(set (reg:DI 0 ax)
[Bug debug/108656] [12/13 Regression] '-fcompare-debug' failure (length) w/ -O2 -fno-ipa-pure-const -fno-tree-dce --param early-inlining-insns=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108656 --- Comment #1 from Arseny Solokha --- The snapshot date is of course wrong. It should read "gcc 13.0.1 20230119 snapshot (g:2e32a12c04c72f692a7bd119fd3e4e5b74392c9d)".
[Bug libstdc++/103934] std::atomic_flag: multiple C++20 functions missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103934 Jonathan Wakely changed: What|Removed |Added Keywords||patch --- Comment #1 from Jonathan Wakely --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588521.html
[Bug debug/108656] [12/13 Regression] '-fcompare-debug' failure (length) w/ -O2 -fno-ipa-pure-const -fno-tree-dce --param early-inlining-insns=0 since r12-5236
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108656 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Last reconfirmed||2023-02-03 CC||jakub at gcc dot gnu.org Summary|[12/13 Regression] |[12/13 Regression] |'-fcompare-debug' failure |'-fcompare-debug' failure |(length) w/ -O2 |(length) w/ -O2 |-fno-ipa-pure-const |-fno-ipa-pure-const |-fno-tree-dce --param |-fno-tree-dce --param |early-inlining-insns=0 |early-inlining-insns=0 ||since r12-5236 Target Milestone|--- |12.3 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Started with r12-5236-g5aa91072e24c1e16a5e .
[Bug c++/108646] nonnull attribute does not detect variables that are NULL being passed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108646 --- Comment #3 from Jonny Grant --- (In reply to Jonathan Wakely from comment #2) > It already does detect it: > > n.c: In function ‘test’: > n.c:6:2: warning: argument 1 null where non-null expected [-Wnonnull] > 6 | mem2(dest); > | ^~ > n.c:2:8: note: in a call to function ‘mem2’ declared ‘nonnull’ > 2 | void * mem2(void *dest) __attribute__((nonnull)); > |^~~~ > > You need to enable optimization, otherwise there is no data flow analysis. > > Without optimization, it detects it with -fanalyzer > > n.c: In function ‘void test()’: > n.c:6:6: warning: use of NULL ‘dest’ where non-null expected [CWE-476] > [-Wanalyzer-null-argument] > 6 | mem2(dest); > | ^~ > ‘void test()’: events 1-2 > | > |5 | char *dest = NULL; > | |^~~~ > | || > | |(1) ‘dest’ is NULL > |6 | mem2(dest); > | | ~~ > | | | > | | (2) argument 1 (‘dest’) NULL where non-null expected > | > n.c:2:8: note: argument 1 of ‘void* mem2(void*)’ must be non-null > 2 | void * mem2(void *dest) __attribute__((nonnull)); > |^~~~ > > > And it's also detected at runtime using -fsanitize=undefined: > > n.c:6:6: runtime error: null pointer passed as argument 1, which is declared > to never be null That's great it works with optimization, I should remember to always do that.(In reply to Jonathan Wakely from comment #2) > It already does detect it: > > n.c: In function ‘test’: > n.c:6:2: warning: argument 1 null where non-null expected [-Wnonnull] > 6 | mem2(dest); > | ^~ > n.c:2:8: note: in a call to function ‘mem2’ declared ‘nonnull’ > 2 | void * mem2(void *dest) __attribute__((nonnull)); > |^~~~ > > You need to enable optimization, otherwise there is no data flow analysis. > > Without optimization, it detects it with -fanalyzer > > n.c: In function ‘void test()’: > n.c:6:6: warning: use of NULL ‘dest’ where non-null expected [CWE-476] > [-Wanalyzer-null-argument] > 6 | mem2(dest); > | ^~ > ‘void test()’: events 1-2 > | > |5 | char *dest = NULL; > | |^~~~ > | || > | |(1) ‘dest’ is NULL > |6 | mem2(dest); > | | ~~ > | | | > | | (2) argument 1 (‘dest’) NULL where non-null expected > | > n.c:2:8: note: argument 1 of ‘void* mem2(void*)’ must be non-null > 2 | void * mem2(void *dest) __attribute__((nonnull)); > |^~~~ > > > And it's also detected at runtime using -fsanitize=undefined: > > n.c:6:6: runtime error: null pointer passed as argument 1, which is declared > to never be null That's great. I should have remembered to add -O2 Is it worth -Wnonnull emitting a warning message that it needs optimization to get the needed data flow analysis?
[Bug ipa/108384] [13 Regression] error: conversion of register to a different size in ‘view_convert_expr’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108384 --- Comment #14 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:e8109bd87766be88e83fe88a44433dae16358a02 commit r13-5681-ge8109bd87766be88e83fe88a44433dae16358a02 Author: Martin Jambor Date: Fri Feb 3 13:28:24 2023 +0100 ipa: Avoid invalid gimple when IPA-CP and IPA-SRA disagree on types (108384) When the compiled program contains type mismatches between callers and callees when it comes to a parameter, IPA-CP can try to propagate one constant from callers while IPA-SRA may try to split a parameter expecting a value of a different size on the same offset. This then currently leads to creation of a VIEW_CONVERT_EXPR with mismatching type sizes of LHS and RHS which is correctly flagged by the GIMPLE verifier as invalid. It seems that the best course of action is to try and avoid the situation altogether and so this patch adds a check to IPA-SRA that peeks into the result of IPA-CP and when it sees a value on the same offset but with a mismatching size, it just decides to leave that particular parameter be. gcc/ChangeLog: 2023-02-02 Martin Jambor PR ipa/108384 * ipa-sra.cc (push_param_adjustments_for_index): Remove a size check when comparing to an IPA-CP value. (dump_list_of_param_indices): New function. (adjust_parameter_descriptions): Check for mismatching IPA-CP values. Dump removed candidates using dump_list_of_param_indices. * ipa-param-manipulation.cc (ipa_param_body_adjustments::modify_expression): Add assert checking sizes of a VIEW_CONVERT_EXPR will match. (ipa_param_body_adjustments::modify_assignment): Likewise. gcc/testsuite/ChangeLog: 2023-02-02 Martin Jambor PR ipa/108384 * gcc.dg/ipa/pr108384.c: New test.
[Bug ipa/108384] [13 Regression] error: conversion of register to a different size in ‘view_convert_expr’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108384 Martin Jambor changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Martin Jambor --- Fixed, thanks for reporting.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 --- Comment #5 from Aldy Hernandez --- > Perhaps just adding if (op2.undefined_p ()) return false; above most of the > switch (get_bool_state (r, lhs, type)) lines (in methods that refer to op2; > and similarly for op1) for the comparison operators. This feels like the right approach. We also do something similar in some of the binary operators. For example, plus/minus_expr do: if (lhs.undefined_p ()) return false; For this testcase we have: [0,0] = UNDEFINED < op2 I don't think we can determine anything for op2 in this situation, so the right thing would be to return false, which amounts to returning VARYING. The binary operators would also have to handle operators of undefined, but those seem to all have gates on singleton_p() or go through the fold_range() routine for the inverse operation, so they'd be handled correctly. So yeah, it looks like just handling the op[12]_range operators above the get_bool_state would do the trick. Hmmm, it seems like there are 2 operators that have possible problematic handling of op2.undefined_p(): 1. operator_cast::op1_range (irange &r, tree type, The assert looks at the op2 type. That will ICE with an UNDEFINED. The truncating_cast_p path will also look at op2's type blindly. 2. operator_bitwise_xor::op1_range Imagine: [0,0] = x ^ UNDEFINED op1_range won't ICE, but it will do: case BRS_FALSE: r = op2; I don't think we know anything about x in this case. Though if, op2 is UNDEFINED, I guess it wouldn't hurt to assume op1 is also UNDEFINED. Also earlier in the function, for: UNDEFINED = x ^ op2 will return x = UNDEFINED for any op2. So at least #1 would also have to be handled because it could ICE. Also, range-op-float.cc needs the same treatment prior all the get_bool_state calls. As you mention, another alternative would be to always call empty_range_varying, as we're doing for abs::op[12]_range: if (empty_range_varying (r, type, lhs, op2)) return true; Thoughts? Andrew? Hmmm, I wonder why we haven't tripped over this scenario in past releases (LHS being defined, but op2 being UNDEFINED).
[Bug debug/108656] [12/13 Regression] '-fcompare-debug' failure (length) w/ -O2 -fno-ipa-pure-const -fno-tree-dce --param early-inlining-insns=0 since r12-5236
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108656 Jakub Jelinek changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- I think the problem is in the bogus combination of attributes, pure (or const) and returns_twice. For returns_twice we force the call to be the first statement in a bb (stmt_starts_bb_p returns true for it) with an AB edge to it and expect it to be the last one as well with an AB edge out of it. For normal returns_twice calls that is the case, the fact that there is returns_twice results in cfun->calls_setjmp and in that case call_can_make_abnormal_goto will be true (so among others the call is marked as ctrl altering and eventually stmt_ends_bb_p). But if returns_twice is mixed with const, pure or leaf attributes, this all falls apart. The exact reason for the -fcompare-debug failure is that we have the weird ;; basic block 4, loop depth 0, maybe hot ;;prev block 3, next block 5, flags: (NEW) ;;pred: 3 (FALLTHRU) ;;5 (ABNORMAL,DFS_BACK) # _5(ab) = PHI <_12(3), _6(ab)(5)> _2 = bar (); _14 = corge (_2, _5(ab)); goto ; [INV] ;;succ: 6 (FALLTHRU) ;;5 (ABNORMAL) pre-einline (note, corge isn't pure/const/leaf and so unlike bar is assumed to maybe doing abnormal goto), einline turns it into: ;; basic block 3, loop depth 0, maybe hot ;;prev block 2, next block 4, flags: (NEW, REACHABLE) ;;pred: 2 (FALLTHRU) ;;4 (ABNORMAL,DFS_BACK) # _5(ab) = PHI <_12(2), _6(ab)(4)> # DEBUG BEGIN_STMT baz (); # DEBUG BEGIN_STMT _19 = 0; _2 = _19; _14 = corge (_2, _5(ab)); goto ; [INV] ;;succ: 5 (FALLTHRU) ;;4 (ABNORMAL) (with the debug stmts missing for -g0), no returns_twice nor anything else actually needing abnormal stuff in the cfg, but bar wasn't the last stmt in bb, so no purging was done. Later on, expand_calL_inline is called on the bb which has just ;; basic block 3, loop depth 0, maybe hot ;;prev block 2, next block 4, flags: (NEW, REACHABLE) ;;pred: 2 (FALLTHRU) ;;4 (ABNORMAL,DFS_BACK) # _5(ab) = PHI <_12(2), _6(ab)(4)> # DEBUG BEGIN_STMT baz (); # DEBUG BEGIN_STMT goto ; [INV] ;;succ: 5 (FALLTHRU) ;;4 (ABNORMAL) and return_block is after splitting in one case just baz (); call and in another case baz () call + debug stmt. /* If the GIMPLE_CALL was in the last statement of BB, it may have been the source of abnormal edges. In this case, schedule the removal of dead abnormal edges. */ gsi = gsi_start_bb (return_block); gsi_next (&gsi); purge_dead_abnormal_edges = gsi_end_p (gsi); So, purge_dead_abnormal_edges is set for -g0 but not -g and as after inlining baz there is nothing that would need an abnormal edge, we drop .ABNORMAL_DISPATCHER in the former case and not the latter. I wonder if we shouldn't reject mixing const/pure/leaf attributes with returns_twice, like we already warn and ignore returns_twice attribute when mixed with noreturn. Or, I think we'd need to make sure returns_twice results in call_can_make_abnormal_goto true, and perhaps stmt_can_terminate_bb_p true too. Though, still I wonder what will happen if we DCE the returns_twice calls, wonder if we at least drop the abnormal successor edges then.
[Bug sanitizer/108637] ASAN at -O2 misses a stack-use-after-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108637 Martin Liška changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Martin Liška --- It's reported since r13-3856-g837be6c7cfb49e16.
[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
2023-02-03 Jakub Jelinek
PR fortran/108451
* trans-decl.cc (gfc_trans_use_stmts): Call clear_slot before
doing continue.
--- gcc/fortran/trans-decl.cc.jj2023-01-16 11:52:16.146733136 +0100
+++ gcc/fortran/trans-decl.cc 2023-02-03 14:41:40.503322954 +0100
@@ -5350,7 +5350,11 @@ gfc_trans_use_stmts (gfc_namespace * ns)
/* Sometimes, generic interfaces wind up being over-ruled by a
local symbol (see PR41062). */
if (!st->n.sym->attr.use_assoc)
- continue;
+ {
+ *slot = error_mark_node;
+ entry->decls->clear_slot (slot);
+ continue;
+ }
if (st->n.sym->backend_decl
&& DECL_P (st->n.sym->backend_decl)
fixes the regression (fairly obvious bug). Am not adding testcase because
given #c1 I'm really not sure if the testcase is valid or not. Anyway, GCC 12
accept z1 and z2 and reject z3, so IMHO this bug should be split into the
checking ICE which the above patch should fix and any possible accepts-invalid
which doesn't look like a regression.
[Bug middle-end/108435] [13 Regression] ICE in as_a, at is-a.h:242 since r13-142-g705bcedf6eae2d7c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108435 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug c/108657] New: csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657 Bug ID: 108657 Summary: csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 54402 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54402&action=edit C source code For the attached C code, derived from csmith output, I get: $ ~/gcc/results/bin/gcc -w bug880.c $ ./a.out checksum = F3A34B53 $ ~/gcc/results/bin/gcc -w -O2 bug880.c $ ./a.out checksum = F3A34B53 $ ~/gcc/results/bin/gcc -w -O2 -ftrivial-auto-var-init=zero bug880.c $ ./a.out checksum = F3A34B53 $ ~/gcc/results/bin/gcc -w -O3 -ftrivial-auto-var-init=zero bug880.c $ ./a.out checksum = BCC02729 $ ~/gcc/results/bin/gcc -w -O3 bug880.c $ ./a.out checksum = F3A34B53 $ Also, the possible bug seems to have first occurred sometime before 20230103 $ ~/gcc/results.20230103.asan.ubsan/bin/gcc -w -O3 -ftrivial-auto-var-init=zero bug880.c $ ./a.out checksum = BCC02729 $
[Bug fortran/89925] [10/11/12/13 Regression] Wrong array bounds from ALLOCATE with SOURCE or MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925 Vladimir Fuka changed: What|Removed |Added CC||vladimir.fuka at gmail dot com --- Comment #9 from Vladimir Fuka --- Was this bug fixed? It seems to work correctly in 12.2.1 but incorrectly in 11.3.0 (OpenSUSE builds). It is a major problem and the fix would very much be worth backporting to maintained versions.
[Bug fortran/89925] [10/11/12/13 Regression] Wrong array bounds from ALLOCATE with SOURCE or MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925 --- Comment #10 from Tobias Burnus --- I think that could be the commit r12-5767-g6262e3a22b3d86afc116480bc59a7bb30b0cfd40 "fortran: Fix setting of array lower bound for named arrays" but I have not checked more deeply.
[Bug c++/108579] [13 Regression] Requires-expression that checks constructor on non-template constructor of template class got rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108579 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:e7930c6750d03b28d922ebbbace20ba9d8622c6a commit r13-5682-ge7930c6750d03b28d922ebbbace20ba9d8622c6a Author: Patrick Palka Date: Fri Feb 3 09:12:31 2023 -0500 c++: excessive satisfaction in check_methods [PR108579] In check_methods we're unnecessarily checking satisfaction for all constructors and assignment operators, even those that don't look like copy/move special members. In the testcase below this manifests as an unstable satisfaction error because the satisfaction result is first determined to be false during check_methods (since A is incomplete at this point) and later true after completion of A. This patch fixes this simply by swapping the order of the constraint_satisfied_p and copy/move_fn_p tests. PR c++/108579 gcc/cp/ChangeLog: * class.cc (check_methods): Swap order of constraints_satisfied_p and copy/move_fn_p tests. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-pr108579.C: New test.
[Bug c++/96745] [concepts] internal compiler error: in type_memfn_rqual, at cp/typeck.c:10389
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96745 --- Comment #6 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:ed2b519e02eac99fadfa51adc7b11f8854c24575 commit r13-5683-ged2b519e02eac99fadfa51adc7b11f8854c24575 Author: Patrick Palka Date: Fri Feb 3 09:15:29 2023 -0500 c++: ICE on unviable/ambiguous constrained dtors [PR96745] Here we're crashing from check_bases_and_members due to CLASSTYPE_DESTRUCTOR being an OVERLOAD which, due to the pruning performed by add_method, should only happen if there is no viable destructor or the destructor is ambiguous because of unsatisfied or ambiguous constraints. This patch fixes this by making check_bases_and_members naturally handle CLASSTYPE_DESTRUCTOR being an OVERLOAD. It's then convenient to prune the OVERLOAD after effectively diagnosing the overload resolution failure in check_methods. PR c++/96745 gcc/cp/ChangeLog: * class.cc (check_methods): Diagnose an unviable OVERLOAD set for CLASSTYPE_DESTRUCTOR differently from an ambiguous one. Then prune the OVERLOAD to a single function. (check_bases_and_members): Handle CLASSTYPE_DESTRUCTOR being an OVERLOAD when calling deduce_noexcept_on_destructor. Document why it has to be called before check_methods. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-dtor1.C: New test.
[Bug c++/108579] [13 Regression] Requires-expression that checks constructor on non-template constructor of template class got rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108579 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Patrick Palka --- Fixed for GCC 13, thanks for the bug report.
[Bug c++/96745] [concepts] internal compiler error: in type_memfn_rqual, at cp/typeck.c:10389
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96745 Patrick Palka changed: What|Removed |Added Keywords||ice-on-invalid-code Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |13.0 --- Comment #7 from Patrick Palka --- Fixed for GCC 13, thanks for the bug report. This doesn't seem worth backporting since the ICE only happens on invalid code.
[Bug c++/96745] [concepts] internal compiler error: in type_memfn_rqual, at cp/typeck.c:10389
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96745 Patrick Palka changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #8 from Patrick Palka --- *** Bug 107150 has been marked as a duplicate of this bug. ***
[Bug c++/107150] ICE: tree check: expected function_type or method_type, have lang_type in deduce_noexcept_on_destructor, at cp/class.cc:5183
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107150 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=96745 | CC||ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- dup *** This bug has been marked as a duplicate of bug 96745 ***
[Bug c++/107461] [12/13 Regression] ambiguity error for friend with templated constexpr argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:59e0376f607805ef9b67fd7b0a4a3084ab3571a5 commit r13-5684-g59e0376f607805ef9b67fd7b0a4a3084ab3571a5 Author: Patrick Palka Date: Fri Feb 3 09:41:10 2023 -0500 c++: unexpected ADDR_EXPR after overload set pruning [PR107461] Here the ahead-of-time overload set pruning in finish_call_expr is unintentionally returning a CALL_EXPR whose (pruned) callee is wrapped in an ADDR_EXPR, despite the original callee not being wrapped in an ADDR_EXPR. This ends up causing a bogus declaration mismatch error in the below testcase because the call to min in #1 gets expressed as a CALL_EXPR of ADDR_EXPR of FUNCTION_DECL, whereas the level-lowered call to min in #2 gets expressed instead as a CALL_EXPR of FUNCTION_DECL. This patch fixes this by stripping the spurious ADDR_EXPR appropriately. Thus the first call to min now also gets expressed as a CALL_EXPR of FUNCTION_DECL, matching the behavior before r12-6075-g2decd2cabe5a4f. PR c++/107461 gcc/cp/ChangeLog: * semantics.cc (finish_call_expr): Strip ADDR_EXPR from the selected callee during overload set pruning. gcc/testsuite/ChangeLog: * g++.dg/template/call9.C: New test.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 --- Comment #6 from Andrew Macleod --- This is the first release that we process relations in GORI. Up until recently it was fairly ad-hoc what got passed in as a relation trio to the op?_range routines. A couple of days ago I fleshed it out fully. I am surprised that isn't what caused this. Anyway, the reason its tripping: if (_42 != 0) goto ; [50.00%] else goto ; [50.00%] bb6: _27 = *h_29(D); _53 = _27 < _42; if (_42 > _53) we start by trying to evaluate the outgoing edge for _42 on the true side: [1,1] = (_42 > _53) The problem is we have determined that _42 is bool [0, 0] at this point. Knowing _42 is [0, 0], the definition of _53 can never be true, so it is also bool [0,0] in order for _53 to be [0,0] AND _42 to be [0,0], the bool value for _27 is nonsensical..and thus its being calculated as undefined. This branch is eventually going to be removed since it can never be taken, but that hasnt happened at this point yet. we could fix it at the call site, but you do point out that the opX_range routines are not gracefully dealing with undefined values. We probably should audit them all to make sure we handled undefined gracefully before accessing a bound.
[Bug c++/107461] [12 Regression] ambiguity error for friend with templated constexpr argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:534aea1ca7e7538dc6af3eac3cd2ec6c7343fdee commit r12-9103-g534aea1ca7e7538dc6af3eac3cd2ec6c7343fdee Author: Patrick Palka Date: Fri Feb 3 09:41:10 2023 -0500 c++: unexpected ADDR_EXPR after overload set pruning [PR107461] Here the ahead-of-time overload set pruning in finish_call_expr is unintentionally returning a CALL_EXPR whose (pruned) callee is wrapped in an ADDR_EXPR, despite the original callee not being wrapped in an ADDR_EXPR. This ends up causing a bogus declaration mismatch error in the below testcase because the call to min in #1 gets expressed as a CALL_EXPR of ADDR_EXPR of FUNCTION_DECL, whereas the level-lowered call to min in #2 gets expressed instead as a CALL_EXPR of FUNCTION_DECL. This patch fixes this by stripping the spurious ADDR_EXPR appropriately. Thus the first call to min now also gets expressed as a CALL_EXPR of FUNCTION_DECL, matching the behavior before r12-6075-g2decd2cabe5a4f. PR c++/107461 gcc/cp/ChangeLog: * semantics.cc (finish_call_expr): Strip ADDR_EXPR from the selected callee during overload set pruning. gcc/testsuite/ChangeLog: * g++.dg/template/call9.C: New test. (cherry picked from commit 59e0376f607805ef9b67fd7b0a4a3084ab3571a5)
[Bug c++/107461] [12 Regression] ambiguity error for friend with templated constexpr argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107461 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Patrick Palka --- Fixed for GCC 12.3/13, thanks for the bug report.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #7 from Jakub Jelinek ---
So
--- gcc/range-op.cc.jj 2023-02-03 10:51:40.699003658 +0100
+++ gcc/range-op.cc 2023-02-03 16:04:39.264159294 +0100
@@ -642,7 +642,8 @@ operator_equal::op1_range (irange &r, tr
case BRS_FALSE:
// If the result is false, the only time we know anything is
// if OP2 is a constant.
- if (wi::eq_p (op2.lower_bound(), op2.upper_bound()))
+ if (!op2.undefined_p ()
+ && wi::eq_p (op2.lower_bound(), op2.upper_bound()))
{
r = op2;
r.invert ();
@@ -755,7 +756,8 @@ operator_not_equal::op1_range (irange &r
case BRS_TRUE:
// If the result is true, the only time we know anything is if
// OP2 is a constant.
- if (wi::eq_p (op2.lower_bound(), op2.upper_bound()))
+ if (!op2.undefined_p ()
+ && wi::eq_p (op2.lower_bound(), op2.upper_bound()))
{
r = op2;
r.invert ();
@@ -920,6 +922,9 @@ operator_lt::op1_range (irange &r, tree
const irange &op2,
relation_trio) const
{
+ if (op2.undefined_p ())
+return false;
+
switch (get_bool_state (r, lhs, type))
{
case BRS_TRUE:
@@ -942,6 +947,9 @@ operator_lt::op2_range (irange &r, tree
const irange &op1,
relation_trio) const
{
+ if (op1.undefined_p ())
+return false;
+
switch (get_bool_state (r, lhs, type))
{
case BRS_TRUE:
@@ -1031,6 +1039,9 @@ operator_le::op1_range (irange &r, tree
const irange &op2,
relation_trio) const
{
+ if (op2.undefined_p ())
+return false;
+
switch (get_bool_state (r, lhs, type))
{
case BRS_TRUE:
@@ -1053,6 +1064,9 @@ operator_le::op2_range (irange &r, tree
const irange &op1,
relation_trio) const
{
+ if (op1.undefined_p ())
+return false;
+
switch (get_bool_state (r, lhs, type))
{
case BRS_TRUE:
@@ -1141,6 +1155,9 @@ operator_gt::op1_range (irange &r, tree
const irange &lhs, const irange &op2,
relation_trio) const
{
+ if (op2.undefined_p ())
+return false;
+
switch (get_bool_state (r, lhs, type))
{
case BRS_TRUE:
@@ -1163,6 +1180,9 @@ operator_gt::op2_range (irange &r, tree
const irange &op1,
relation_trio) const
{
+ if (op1.undefined_p ())
+return false;
+
switch (get_bool_state (r, lhs, type))
{
case BRS_TRUE:
@@ -1252,6 +1272,9 @@ operator_ge::op1_range (irange &r, tree
const irange &op2,
relation_trio) const
{
+ if (op2.undefined_p ())
+return false;
+
switch (get_bool_state (r, lhs, type))
{
case BRS_TRUE:
@@ -1274,6 +1297,9 @@ operator_ge::op2_range (irange &r, tree
const irange &op1,
relation_trio) const
{
+ if (op1.undefined_p ())
+return false;
+
switch (get_bool_state (r, lhs, type))
{
case BRS_TRUE:
then plus testcase?
[Bug gcov-profile/108658] New: [GCOV] Function entry is not recorded in a function containing an infinite loop depending on the optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
Bug ID: 108658
Summary: [GCOV] Function entry is not recorded in a function
containing an infinite loop depending on the
optimization level
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Consider the following test code:
idle.c
void *idle(void *ignored)
{
while (1) {
/* Do nothing */
}
return 0;
}
main.c
#include
void *idle(void *ignored);
int main(void)
{
pthread_t th;
pthread_create(&th, NULL, idle, NULL);
sleep(1);
return 0;
}
This sequence of commands shows that the idle() function entry is not recorded
for -O2 and -Og:
gcc-12 -O2 --coverage -c main.c
rm -f *.gc??
gcc-12 -O2 --coverage -c idle.c
gcc-12 -pthread --coverage main.o idle.o
./a.out
gcov-12 idle.c
File 'idle.c'
Lines executed:0.00% of 1
Creating 'idle.c.gcov'
Lines executed:0.00% of 1
cat idle.c.gcov
-:0:Source:idle.c
-:0:Graph:idle.gcno
-:0:Data:idle.gcda
-:0:Runs:1
#:1:void *idle(void *ignored)
-:2:{
-:3: while (1) {
-:4:/* Do nothing */
-:5: }
-:6:
-:7: return 0;
-:8:}
rm -f *.gc??
gcc-12 -Og --coverage -c idle.c
gcc-12 -pthread --coverage main.o idle.o
./a.out
gcov-12 idle.c
File 'idle.c'
Lines executed:50.00% of 2
Creating 'idle.c.gcov'
Lines executed:50.00% of 2
cat idle.c.gcov
-:0:Source:idle.c
-:0:Graph:idle.gcno
-:0:Data:idle.gcda
-:0:Runs:1
#:1:void *idle(void *ignored)
-:2:{
472195650:3: while (1) {
-:4:/* Do nothing */
-:5: }
-:6:
-:7: return 0;
-:8:}
rm -f *.gc??
gcc-12 -O0 --coverage -c idle.c
gcc-12 -pthread --coverage main.o idle.o
./a.out
gcov-12 idle.c
File 'idle.c'
Lines executed:100.00% of 2
Creating 'idle.c.gcov'
Lines executed:100.00% of 2
cat idle.c.gcov
-:0:Source:idle.c
-:0:Graph:idle.gcno
-:0:Data:idle.gcda
-:0:Runs:1
472440920:1:void *idle(void *ignored)
-:2:{
472440920:3: while (1) {
-:4:/* Do nothing */
-:5: }
-:6:
-:7: return 0;
-:8:}
For -O0 the line count is also wrong from my point of view. Line 1 should have
a count of 1.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 --- Comment #8 from Jakub Jelinek --- Unfortunately that would mean for the non-equality cases that if lhs.undefined_p () we don't return undefined but false (aka VARYING). Another option is to add those if (op?.undefined_p ()) return false; to both case BRS_TRUE: and case BRS_FALSE:.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 --- Comment #9 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #8) > Unfortunately that would mean for the non-equality cases that if > lhs.undefined_p () we don't return undefined but false (aka VARYING). > Another option is to add those if (op?.undefined_p ()) return false; to both > case BRS_TRUE: and case BRS_FALSE:. Well, if the LHS is undefined, (or even one of the operands) we are typically in dead code or edge anyway.. I'm not sure it really matters? An alternate question as well is why is the threader even looking at this impossible path. It should know that the branch can never be true
[Bug gcov-profile/108658] [GCOV] Function entry is not recorded in a function containing an infinite loop depending on the optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658 --- Comment #1 from Andrew Pinski --- Try compiling with -pthread too? Otherwise the instrumentation code assumes it is single threaded.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 --- Comment #10 from Jakub Jelinek --- (In reply to Andrew Macleod from comment #9) > (In reply to Jakub Jelinek from comment #8) > > Unfortunately that would mean for the non-equality cases that if > > lhs.undefined_p () we don't return undefined but false (aka VARYING). > > Another option is to add those if (op?.undefined_p ()) return false; to both > > case BRS_TRUE: and case BRS_FALSE:. > > Well, if the LHS is undefined, (or even one of the operands) we are > typically in dead code or edge anyway.. I'm not sure it really matters? Ok, I'll test the patch then. > An alternate question as well is why is the threader even looking at this > impossible path. It should know that the branch can never be true I think range-op shouldn't assume nothing will call it with UNDEFINED ranges.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 --- Comment #11 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #10) > (In reply to Andrew Macleod from comment #9) > > (In reply to Jakub Jelinek from comment #8) > > > Unfortunately that would mean for the non-equality cases that if > > > lhs.undefined_p () we don't return undefined but false (aka VARYING). > > > Another option is to add those if (op?.undefined_p ()) return false; to > > > both > > > case BRS_TRUE: and case BRS_FALSE:. > > > > Well, if the LHS is undefined, (or even one of the operands) we are > > typically in dead code or edge anyway.. I'm not sure it really matters? > > Ok, I'll test the patch then. > > > An alternate question as well is why is the threader even looking at this > > impossible path. It should know that the branch can never be true > > I think range-op shouldn't assume nothing will call it with UNDEFINED ranges. Oh I wasn't suggesting otherwise,we should be bulletproof. Just wondering why the threader is spending any time evaluating ranges on a path it should know is impossible.
[Bug c++/108659] New: Suboptimal 128 bit atomics codegen on AArch64 and x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659 Bug ID: 108659 Summary: Suboptimal 128 bit atomics codegen on AArch64 and x64 Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: s_gccbugzilla at nedprod dot com Target Milestone: --- Related: - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649 - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 I got bitten by this again, latest GCC still does not emit single instruction 128 bit atomics, even when the -march is easily new enough. Here is a godbolt comparing latest MSVC, latest GCC and latest clang for the skylake-avx512 architecture, which unquestionably supports cmpxchg16b. Only clang emits the single instruction atomic: https://godbolt.org/z/EnbeeW4az I'm gathering from the issue comments and from the comments at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 that you're going to wait for AMD to guarantee atomicity of SSE instructions before changing the codegen here, which makes sense. However I also wanted to raise potentially suboptimal 128 bit atomic codegen by GCC for AArch64 as compared to clang: https://godbolt.org/z/oKv4o81nv GCC emits `dmb` to force a global memory fence, whereas clang does not. I think clang is in the right here, the seq_cst atomic semantics are not supposed to globally memory fence.
[Bug target/108659] Suboptimal 128 bit atomics codegen on AArch64 and x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- (In reply to Niall Douglas from comment #0) > I'm gathering from the issue comments and from the comments at > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 that you're going to > wait for AMD to guarantee atomicity of SSE instructions before changing the > codegen here, which makes sense. AMD has guaranteed it, but there is still VIA and Zhaoxin and while we have some statement from the latter, I'm not sure it is enough and we don't have anything from VIA. See PR104688 for details.
[Bug fortran/108651] Array Constructor with [type-spec:: fails to apply to all values, eg x = [integer(int64):: 1,2,3,4]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108651 --- Comment #3 from Scott Boyce --- No its not correct because the [integer(int64):: in INTEGER(INT64), dimension(2), parameter:: arr1 = [integer(int64):: -3300711175878204139, 8258803693257250632] is the initialization is indicating that all the numbers are int64 and not int32. Otherwise, what is the point of adding the type spec within the array initialization Second, otherwise you have to do something stupid like this to be compatible with gfortran: INTEGER(INT64), dimension(256), parameter:: exp_ipmf= [ & 9223372036854775806_int64, 1623796909450836942_int64, 2664290944894287536_int64, & 7387971354164062286_int64, 6515064486552725727_int64, 8840508362680705564_int64, & 6099647593382931854_int64, 7673130333659518959_int64, 6220332867583442119_int64, & 5045979640552799519_int64, 4075305837223961434_int64, 3258413672162528204_int64, & 2560664887087755460_int64, 1957224924672901793_int64, 1429800935350586317_int64, & 964606309710805398_int64, 551043923599587507_int64, 180827629096887271_int64, & -152619738120024135_int64, -454588624410297994_int64, -729385126147771550_int64, & -980551509819436091_int64, -1211029700667469343_int64, -1423284293868552853_int64, & -1619396356369054015_int64, -1801135830956208679_int64, -1970018048575620636_int64, & -2127348289059702419_int64, -2274257249303686369_int64, -2411729520096647511_int64, & -2540626634159186189_int64, -2661705860113411427_int64, -2775635634532452931_int64, & -2883008316030452685_int64, -2984350790383660344_int64, -308019198120492_int64, & -3170777096303094023_int64, -3256660348483807146_int64, -3338123885075143810_int64, & -3415475560473292784_int64, -3488994201966436213_int64, -3558932970354465681_int64, & -3625522261068040523_int64, -3688972217741992772_int64, -3749474917563780918_int64, & -3807206277531066033_int64, -3862327722496832777_int64, -3914987649156774371_int64, & -3965322714631868789_int64, -4013458973776904711_int64, -4059512885612775571_int64, & -4103592206186240140_int64, -4145796782586126309_int64, -4186219260694351160_int64, & -4224945717447272663_int64, -4262056226866286506_int64, -4297625367836515404_int64, & -4331722680528539029_int64, -4364413077437474043_int64, -4395757214229410182_int64, & -4425811824915126951_int64, -4454630025296931623_int64, -4482261588141301290_int64, & -4508753193105274668_int64, -4534148654077814519_int64, -4558489126279958535_int64, & -4581813295192218010_int64, -4604157549138257917_int64, -4625556137145252094_int64, & -4646041313519107008_int64, -4665643470413307024_int64, -4684391259530330202_int64, & -4702311703971758561_int64, -4719430301145093973_int64, -4735771117539952483_int64, & -4751356876102085678_int64, -4766209036859141945_int64, -4780347871386006289_int64, & -4793792531638886797_int64, -4806561113635134843_int64, -4818670716409303206_int64, & -4830137496634475108_int64, -4840976719260841080_int64, -4851202804490340302_int64, & -4860829371376465578_int64, -4869869278311660680_int64, -4878334660640769131_int64, & -4886236965617420889_int64, -4893586984900801361_int64, -4900394884772701206_int64, & -490667023423961_int64, -4912422031164499511_int64, -4917658726580128817_int64, & -4922388247283526639_int64, -4926618016851058129_int64, -4930354975163349944_int64, & -4933605596540647482_int64, -4936375906575298263_int64, -4938671497741363402_int64, & -4940497543854573923_int64, -4941858813449628344_int64, -4942759682136115973_int64, & -4943204143989096034_int64, -4943195822025520534_int64, -4942737977813217760_int64, & -4941833520255016417_int64, -4940485013586754412_int64, -4938694684624350782_int64, & -4936464429291796994_int64, -4933795818458819764_int64, -4930690103114058905_int64, & -4927148218896869823_int64, -4923170790008281939_int64, -4918758132519204034_int64, & -4913910257091649047_int64, -4908626871126539190_int64, -4902907380349533220_int64, & -4896750889844278395_int64, -4890156204540517421_int64, -4883121829162564021_int64, & -4875645967641788341_int64, -4867726521994914537_int64, -4859361090668117144_int64, & -4850546966345100146_int64, -4841281133215543008_int64, -4831560263698491528_int64, & -4821380714613448338_int64, -4810738522790068329_int64, -4799629400105478223_int64, & -4788048727936306618_int64, -4775991551010520594_int64, -4763452570642106428_int64, & -4750426137329493684_int64, -4736906242696391928_int64, -4722886510751374910_int64, & -4708360188440094804_int64, -46933201354614246
[Bug target/108659] Suboptimal 128 bit atomics codegen on AArch64 and x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- (In reply to Niall Douglas from comment #0) > Related: > - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80878 > - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94649 > - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 > > I got bitten by this again, latest GCC still does not emit single > instruction 128 bit atomics, even when the -march is easily new enough. Here > is a godbolt comparing latest MSVC, latest GCC and latest clang for the > skylake-avx512 architecture, which unquestionably supports cmpxchg16b. Only > clang emits the single instruction atomic: > > https://godbolt.org/z/EnbeeW4az > > I'm gathering from the issue comments and from the comments at > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688 that you're going to > wait for AMD to guarantee atomicity of SSE instructions before changing the > codegen here, which makes sense. However I also wanted to raise potentially > suboptimal 128 bit atomic codegen by GCC for AArch64 as compared to clang: > > https://godbolt.org/z/oKv4o81nv > > GCC emits `dmb` to force a global memory fence, whereas clang does not. > > I think clang is in the right here, the seq_cst atomic semantics are not > supposed to globally memory fence. FWIW, the GCC codegen for aarch64 is at https://godbolt.org/z/qvx9484nY (arm and aarch64 are different targets). It emits a call to libatomic, which for GCC 13 will use a lockless implementation when possible at runtime, see g:d1288d850944f69a795e4ff444a427eba3fec11b
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647
--- Comment #12 from Aldy Hernandez ---
(In reply to Jakub Jelinek from comment #7)
> So
> --- gcc/range-op.cc.jj2023-02-03 10:51:40.699003658 +0100
> +++ gcc/range-op.cc 2023-02-03 16:04:39.264159294 +0100
> @@ -642,7 +642,8 @@ operator_equal::op1_range (irange &r, tr
> case BRS_FALSE:
>// If the result is false, the only time we know anything is
>// if OP2 is a constant.
> - if (wi::eq_p (op2.lower_bound(), op2.upper_bound()))
> + if (!op2.undefined_p ()
> + && wi::eq_p (op2.lower_bound(), op2.upper_bound()))
> {
> r = op2;
> r.invert ();
> @@ -755,7 +756,8 @@ operator_not_equal::op1_range (irange &r
> case BRS_TRUE:
>// If the result is true, the only time we know anything is if
>// OP2 is a constant.
> - if (wi::eq_p (op2.lower_bound(), op2.upper_bound()))
> + if (!op2.undefined_p ()
> + && wi::eq_p (op2.lower_bound(), op2.upper_bound()))
> {
> r = op2;
> r.invert ();
> @@ -920,6 +922,9 @@ operator_lt::op1_range (irange &r, tree
> const irange &op2,
> relation_trio) const
> {
> + if (op2.undefined_p ())
> +return false;
> +
>switch (get_bool_state (r, lhs, type))
> {
> case BRS_TRUE:
> @@ -942,6 +947,9 @@ operator_lt::op2_range (irange &r, tree
> const irange &op1,
> relation_trio) const
> {
> + if (op1.undefined_p ())
> +return false;
> +
>switch (get_bool_state (r, lhs, type))
> {
> case BRS_TRUE:
> @@ -1031,6 +1039,9 @@ operator_le::op1_range (irange &r, tree
> const irange &op2,
> relation_trio) const
> {
> + if (op2.undefined_p ())
> +return false;
> +
>switch (get_bool_state (r, lhs, type))
> {
> case BRS_TRUE:
> @@ -1053,6 +1064,9 @@ operator_le::op2_range (irange &r, tree
> const irange &op1,
> relation_trio) const
> {
> + if (op1.undefined_p ())
> +return false;
> +
>switch (get_bool_state (r, lhs, type))
> {
> case BRS_TRUE:
> @@ -1141,6 +1155,9 @@ operator_gt::op1_range (irange &r, tree
> const irange &lhs, const irange &op2,
> relation_trio) const
> {
> + if (op2.undefined_p ())
> +return false;
> +
>switch (get_bool_state (r, lhs, type))
> {
> case BRS_TRUE:
> @@ -1163,6 +1180,9 @@ operator_gt::op2_range (irange &r, tree
> const irange &op1,
> relation_trio) const
> {
> + if (op1.undefined_p ())
> +return false;
> +
>switch (get_bool_state (r, lhs, type))
> {
> case BRS_TRUE:
> @@ -1252,6 +1272,9 @@ operator_ge::op1_range (irange &r, tree
> const irange &op2,
> relation_trio) const
> {
> + if (op2.undefined_p ())
> +return false;
> +
>switch (get_bool_state (r, lhs, type))
> {
> case BRS_TRUE:
> @@ -1274,6 +1297,9 @@ operator_ge::op2_range (irange &r, tree
> const irange &op1,
> relation_trio) const
> {
> + if (op1.undefined_p ())
> +return false;
> +
>switch (get_bool_state (r, lhs, type))
> {
> case BRS_TRUE:
> then plus testcase?
Looks good to me.
Do you mind adding this bit to your testing?
diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index 136b709385c..fdc0a6c05fd 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -2678,7 +2678,6 @@ operator_cast::op1_range (irange &r, tree type,
if (lhs.undefined_p ())
return false;
tree lhs_type = lhs.type ();
- gcc_checking_assert (types_compatible_p (op2.type(), type));
// If we are calculating a pointer, shortcut to what we really care about.
if (POINTER_TYPE_P (type))
@@ -2705,6 +2704,8 @@ operator_cast::op1_range (irange &r, tree type,
return true;
}
+ if (op2.undefined_p ())
+return false;
if (truncating_cast_p (op2, lhs))
{
if (lhs.varying_p ())
This catches the cast operator which will ICE in truncating_cast_p when op2 is
undefined.
I've removed the checking assert since any number of operations further down
will ICE if the types don't match.
[Bug fortran/108649] allocation segmentation fault for pointer derive type and ICE for final-binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649 --- Comment #7 from Scott Boyce --- (In reply to Jerry DeLisle from comment #6) Thanks that is excellent news about the finalization. There also is the issue with the ALLOCATION as well. Another set of test cases are my Batteries Included Fortran Library (its part of this project under the folder bif_lib). The full repository for BiF is located at https://code.usgs.gov/fortran/bif I was not sure if I should post that code on here as a separate issue (it has lots of allocation issues as well with gfortran).
[Bug fortran/108649] allocation segmentation fault for pointer derive type and ICE for final-binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649 --- Comment #8 from Scott Boyce --- Sorry for sending a second message, my test cases have a workaround already added to the code for the Finalization, but the code posted has issues with ALLOCATION of derived types.
[Bug target/108642] ACLE function __arm_wsr missing for AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108642 --- Comment #6 from David Spickett --- Thanks for the link, we'll try to use those when we detect g++.
[Bug c/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657 --- Comment #1 from David Binderman --- Created attachment 54403 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54403&action=edit C source code After 90 minutes reduction, about 12% of the original is left.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 --- Comment #13 from Aldy Hernandez --- Created attachment 54404 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54404&action=edit frange changes These are the analogous changes to range-op-float.cc. Patch in testing.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #14 from Jakub Jelinek --- Created attachment 54405 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54405&action=edit gcc13-pr108647.patch Here is what I'm about to test momentarily, though I must say I don't understand those operator_cast changes at all. I thought casts are unary operators and so I don't understand what kind of range would be op2 in that case.
[Bug tree-optimization/108647] [13 Regression] ICE in upper_bound, at value-range.h:950 with -O3 since r13-2974-g67166c9ec35d58ef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108647 --- Comment #15 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #14) > Created attachment 54405 [details] > gcc13-pr108647.patch > > Here is what I'm about to test momentarily, though I must say I don't > understand those operator_cast changes at all. I thought casts are unary > operators and so I don't understand what kind of range would be op2 in that > case. Oh poop, sorry. Unary operators always have the resulting type passed as VARYING in op2. It would never be undefined. Sorry for the noise; you can disregard the cast changes.
[Bug gcov-profile/108658] [GCOV] Function entry is not recorded in a function containing an infinite loop depending on the optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Instrumentation-Options.html#index-fprofile-update > The GCC driver automatically selects ‘prefer-atomic’ when -pthread is present > in the command line. The default for -fprofile-update= is single.
[Bug fortran/108651] Array Constructor with [type-spec:: fails to apply to all values, eg x = [integer(int64):: 1,2,3,4]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108651 --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to Scott Boyce from comment #3) > No its not correct because the Yes, it is the correct behavior. Please see 18-007r1.pdf, p.57. 7.4.3.1 Integer type ... Any integer value can be represented as a signed-int-literal-constant. ... The optional kind type parameter following digit-string specifies the kind type parameter of the integer constant; if it does not appear, the constant is default integer. 8258803693257250632 has default integer kind when it is parsed. 8258803693257250632_int64 has the integer type of integer(int64). Now check Sec. 7.8 "Construction of array values". R773 ac-value is expr or ac-implied-do 8258803693257250632 is an expr. C7111 (R770) If type-spec specifies an intrinsic type, each ac-value expression in the array-constructor shall be of an intrinsic type that is in type conformance with a variable of type type-spec as specified in Table 10.8. 8258803693257250632 meets the requirements of type conformance. 18-007r1.pdf, p. 89. If type-spec appears, it specifies the declared type and type parameters of the array constructor. Each ac-value expression in the array-constructor shall be compatible with intrinsic assignment to a variable of this type and type parameters. Each value is converted to the type and type parameters of the array-constructor in accordance with the rules of intrinsic assignment (10.2.1.3). Now, read that last sentence again, and then go read 10.2.1.3. 8258803693257250632 is treated as the right-hand-side of an intrinsic assignment such as integer(int64) x x = 8258803693257250632 This won't work because mathematically 8258803693257250632 exceeds huge(1). You have shown the correct way to do the array constructor, and in that case the type-spec within the constructor is redundant.
[Bug fortran/108451] [13 Regression] ICE in check_complete_insertion, at hash-table.h:578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108451
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> 2023-02-03 Jakub Jelinek
>
> PR fortran/108451
> * trans-decl.cc (gfc_trans_use_stmts): Call clear_slot before
> doing continue.
>
> --- gcc/fortran/trans-decl.cc.jj 2023-01-16 11:52:16.146733136 +0100
> +++ gcc/fortran/trans-decl.cc 2023-02-03 14:41:40.503322954 +0100
> @@ -5350,7 +5350,11 @@ gfc_trans_use_stmts (gfc_namespace * ns)
> /* Sometimes, generic interfaces wind up being over-ruled by a
>local symbol (see PR41062). */
> if (!st->n.sym->attr.use_assoc)
> - continue;
> + {
> + *slot = error_mark_node;
> + entry->decls->clear_slot (slot);
> + continue;
> + }
>
> if (st->n.sym->backend_decl
> && DECL_P (st->n.sym->backend_decl)
>
> fixes the regression (fairly obvious bug). Am not adding testcase because
> given #c1 I'm really not sure if the testcase is valid or not. Anyway, GCC
> 12 accept z1 and z2 and reject z3, so IMHO this bug should be split into the
> checking ICE which the above patch should fix and any possible
> accepts-invalid which doesn't look like a regression.
The code is invalid Fortran. The module m does not contain
an entity named 'pdtt'. If I had to guess the 'pdt' portion
of the name means 'parameterized derived type' and the last
't' means type 't'. This is likely an internal symbol that
has escaped. gfortran's support for PDTs is broken.
I agree with you about committing your fix for the ICE and
opening a new PR about the PDT issue. Note there are already
several open PRs, so this might end up as a dup.
[Bug target/108659] Suboptimal 128 bit atomics codegen on AArch64 and x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659 --- Comment #3 from Niall Douglas --- > AMD has guaranteed it, but there is still VIA and Zhaoxin and while we have > some statement from the latter, I'm not sure it is enough and we don't have > anything from VIA. See PR104688 for details. I'm wondering if a compiler opt out flag like -no-msseatomic16 to turn off use of SSE for 128 bit atomics wouldn't be an idea? Given the small market share of those CPU vendors, seems a shame to hold up implementation. (Also, if you do turn it on by default and advertise that widely, I suspect those vendors will hurry up with their documentation) > FWIW, the GCC codegen for aarch64 is at https://godbolt.org/z/qvx9484nY (arm > and aarch64 are different targets). It emits a call to libatomic, which for > GCC 13 will use a lockless implementation when possible at runtime, see > g:d1288d850944f69a795e4ff444a427eba3fec11b Thanks for the catch, my mistake. It would seem the codegen is similarly inferior to the codegen from clang for both aarch64 and x64. You may be interested in reading https://reviews.llvm.org/D110069. It wanted to have LLVM generate a 128 bit AArch64 CAS for atomics. LLVM merged that change, it'll be in the next release.
[Bug other/108644] Format string warnings related to longs under MigW-W64/MSYS2 on Windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644 --- Comment #4 from Jan Dubiec --- Created attachment 54406 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54406&action=edit Preprocessed lto-plugin\lto-plugin.c
[Bug target/108659] Suboptimal 128 bit atomics codegen on AArch64 and x64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108659 --- Comment #4 from Andrew Pinski --- (In reply to Niall Douglas from comment #3) > You may be interested in reading https://reviews.llvm.org/D110069. It wanted > to have LLVM generate a 128 bit AArch64 CAS for atomics. LLVM merged that > change, it'll be in the next release. Using CAS for atomic load is not valid thing to do ... Because atomic load from constant rodata needs to work. LLVM breaks this case as they don't care about it. GCC does though.
[Bug other/108644] Format string warnings related to longs under MigW-W64/MSYS2 on Windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644 --- Comment #5 from Jan Dubiec --- Andrew, as per your wish, preprocessed lto-plugin\lto-plugin.c is in the attachment. It was produced using the following command: gcc -DHAVE_CONFIG_H -I. -I../../../gcc/lto-plugin -I../../../gcc/lto-plugin/../include -DHAVE_CONFIG_H -Wall -DBASE_VERSION=\"13.0.1\" -E -g3 -O2 ../../../gcc/lto-plugin/lto-plugin.c -DDLL_EXPORT -DPIC -o lto-plugin-preprocessed.c Regarding gcc/ira-conflicts.cc, I think you are probably right, parentheses should fix the issue. But I am not able to understand (without looking into docs) how without the parentheses the expressions are promoted to unsigned long long int instead of just long int. And why the warning does not appear on Linux. Regarding gcc/config/h8300/h8300.cc, I will file a separate report soon.
[Bug other/108644] Format string warnings related to longs under MigW-W64/MSYS2 on Windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644 --- Comment #6 from Andrew Pinski --- (In reply to Jan Dubiec from comment #5) > Regarding gcc/ira-conflicts.cc, I think you are probably right, parentheses > should fix the issue. But I am not able to understand (without looking into > docs) how without the parentheses the expressions are promoted to unsigned > long long int instead of just long int. And why the warning does not appear > on Linux. (long) allocated_words_num * sizeof (IRA_INT_TYPE) For Linux, it is (long) * (unsigned long) or (long) * (unsigned int) [first is LP64 and the second is ILP32], the first gives unsigned long while the second case gives long. While under LLP64LI32, you have (long) * (unsigned long long) so you get "unsigned long long" as the type. as sizeof returns size_t. Does that make sense now?
[Bug gcov-profile/108658] [GCOV] Function entry is not recorded in a function containing an infinite loop from another thread depending on the optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658 --- Comment #3 from Sebastian Huber --- Thanks for the hint, however, adding -pthread or -fprofile-update=atomic doesn't change anything.
[Bug other/108644] Format string warnings related to longs under MigW-W64/MSYS2 on Windows 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644 --- Comment #7 from Jan Dubiec --- (In reply to Andrew Pinski from comment #6) [...] > as sizeof returns size_t. > > Does that make sense now? Yep, thanks.
[Bug c++/108646] nonnull attribute does not detect variables that are NULL being passed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108646 --- Comment #4 from Jonathan Wakely --- (In reply to Jonny Grant from comment #3) > Is it worth -Wnonnull emitting a warning message that it needs optimization > to get the needed data flow analysis? No, there are dozens of warnings that work poorly, or not at all, unless optimization is enabled. It's in the manual. "The effectiveness of some warnings depends on optimizations also being enabled. For example -Wsuggest-final-types is more effective with link-time optimization and some instances of other warnings may not be issued at all unless optimization is enabled. While optimization in general improves the efficacy of control and data flow sensitive warnings, in some cases it may also cause false positives."
[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242
--- Comment #5 from Jakub Jelinek ---
Makes me wonder why finish_fname returns the IDENTIFIER_NODE rather than the
VAR_DECL when processing_template_decl, though if I comment that out it ICEs.
When DECL_INITIAL is __FUNCTION__ etc. IDENTIFIER_NODE, it is looked up using
lookup_name, which works fine if it is the template function in which
__FUNCTION__ has been referenced (ok e.g. when processing DECL_EXPR of
fun_name). But for some reason
we don't find that VAR_DECL as local specialization and trigger
/* This can happen for a variable used in a
late-specified return type of a local lambda, or for a
local static or constant. Building a new VAR_DECL
should be OK in all those cases. */
r = tsubst_decl (t, args, complain);
if (local_specializations)
/* Avoid infinite recursion (79640). */
register_local_specialization (r, t);
if (decl_maybe_constant_var_p (r))
{
/* We can't call cp_finish_decl, so handle the
initializer by hand. */
tree init = tsubst_init (DECL_INITIAL (t), r, args,
complain, in_decl);
which then doesn't work, either it finds a different __FUNCTION__ than it
should, e.g. for:
bool v;
template
void my_fun()
{
auto fun = [&](auto res) {
static constexpr char const* fun_name = __FUNCTION__;
struct
{
constexpr const char* operator()() const { return v ? __FUNCTION__
: fun_name; };
} t;
t();
};
fun(12);
}
or it doesn't find it at all.
[Bug c++/101071] [10/11/12/13 Regression] ICE in gimplify_init_constructor, at gimplify.c:5228
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101071 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #5 from Marek Polacek --- Fixed by r13-2978, which came without a test so I'll add a new one.
[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657 --- Comment #2 from Andrew Pinski --- If I initialize __trans_tmp_13 explictly to 0, the issue goes away
[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242 Marek Polacek changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=105809 CC||mpolacek at gcc dot gnu.org --- Comment #6 from Marek Polacek --- I was just looking into bug 105809 which looks like the same problem except with __PRETTY_FUNCTION__.
[Bug c/108660] New: Wrong location for first statement of for loop (-Wunused-value)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108660
Bug ID: 108660
Summary: Wrong location for first statement of for loop
(-Wunused-value)
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:
```
void t1(int t)
{
for (t; t < 10; t++)
;
}
```
This should warn about a statement with no effect and GCC does but the location
marker is incorrect. The C front-end underlines the for keyword rather than the
expression `t`.
```
: In function 't1':
:3:3: warning: statement with no effect [-Wunused-value]
3 | for (t; t < 10; t++)
| ^~~
```
Note the C++ front-end gets it correct:
```
: In function 'void t1(int)':
:3:8: warning: statement has no effect [-Wunused-value]
3 | for (t; t < 10; t++)
|^
```
[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242
--- Comment #7 from Jakub Jelinek ---
Sorry, above doesn't compile, but
template
void my_fun()
{
auto fun = [&](auto res) {
static constexpr char const* fun_name = __PRETTY_FUNCTION__;
struct
{
constexpr const char* operator()() const { constexpr char const*
fun_name2 = __PRETTY_FUNCTION__; return fun_name; };
} t;
t();
};
fun(12);
}
int main() {
my_fun();
}
ICEs and compiles fine with G++ 11.x.
[Bug analyzer/108661] New: -Wanalyzer-use-of-uninitialized-value false positive seen in haproxy's sink_rotate_file_backed_ring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108661
Bug ID: 108661
Summary: -Wanalyzer-use-of-uninitialized-value false positive
seen in haproxy's sink_rotate_file_backed_ring
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Consider:
#include
#include
#include
struct ring
{
char buf[1024];
};
int test (const char *name)
{
struct ring ring;
int fd;
int ret;
fd = open(name, O_RDONLY);
if (fd < 0)
return 0;
ret = read(fd, &ring, sizeof(ring));
close(fd);
if (ret != sizeof(ring))
return 1;
if (ring.buf[0] > 1)
return 2;
return 3;
}
Currently trunk emits this false positive:
: In function 'test':
:26:21: warning: use of uninitialized value 'ring.buf[0]' [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
26 | if (ring.buf[0] > 1)
| ^~~
'test': events 1-6
|
| 12 | struct ring ring;
| | ^~~~
| | |
| | (1) region created on stack here
|..
| 17 | if (fd < 0)
| |~
| ||
| |(2) following 'false' branch (when 'fd >= 0')...
|..
| 20 | ret = read(fd, &ring, sizeof(ring));
| | ~
| | |
| | (3) ...to here
|..
| 23 | if (ret != sizeof(ring))
| |~
| ||
| |(4) following 'false' branch (when 'ret == 1024')...
|..
| 26 | if (ring.buf[0] > 1)
| | ~~~
| | |
| | (5) ...to here
| | (6) use of uninitialized value 'ring.buf[0]'
here
|
Compiler returned: 0
https://godbolt.org/z/3sMhxej6P
Looks like the analyzer might not "know" that when "read" returns the input
size, that the buffer is fully populated.
[Bug analyzer/108661] [13 Regression] -Wanalyzer-use-of-uninitialized-value false positive seen in haproxy's sink_rotate_file_backed_ring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108661 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-02-03 Ever confirmed|0 |1 Summary|-Wanalyzer-use-of-uninitial |[13 Regression] |ized-value false positive |-Wanalyzer-use-of-uninitial |seen in haproxy's |ized-value false positive |sink_rotate_file_backed_rin |seen in haproxy's |g |sink_rotate_file_backed_rin ||g --- Comment #1 from David Malcolm --- Seems to be a regression relative to 12.2
[Bug gcov-profile/108658] [GCOV] Function entry is not recorded in a function containing an infinite loop from another thread depending on the optimization level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
Sebastian Huber changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED|UNCONFIRMED
--- Comment #4 from Sebastian Huber ---
What is interesting is that -g changes the behaviour. I guess there is an error
in the mapping of the profiling counter to the associated source code lines.
gcc-12 -O2 --coverage -c main.c -g
rm -f *.gc??
gcc-12 -pthread -fprofile-update=atomic -O2 --coverage -c idle.c -g
gcc-12 -pthread --coverage main.o idle.o
./a.out
gcov-12 idle.c
File 'idle.c'
Lines executed:66.67% of 3
Creating 'idle.c.gcov'
Lines executed:66.67% of 3
cat idle.c.gcov
-:0:Source:idle.c
-:0:Graph:idle.gcno
-:0:Data:idle.gcda
-:0:Runs:1
#:1:void *idle(void *ignored)
-:2:{
213413784:3: while (1) {
-:4:/* Do nothing */
213413784:5: }
-:6:
-:7: return 0;
-:8:}
rm -f *.gc??
gcc-12 -pthread -fprofile-update=atomic -Og --coverage -c idle.c -g
gcc-12 -pthread --coverage main.o idle.o
./a.out
gcov-12 idle.c
File 'idle.c'
Lines executed:66.67% of 3
Creating 'idle.c.gcov'
Lines executed:66.67% of 3
cat idle.c.gcov
-:0:Source:idle.c
-:0:Graph:idle.gcno
-:0:Data:idle.gcda
-:0:Runs:1
#:1:void *idle(void *ignored)
-:2:{
214569562:3: while (1) {
-:4:/* Do nothing */
214569562:5: }
-:6:
-:7: return 0;
-:8:}
rm -f *.gc??
gcc-12 -pthread -fprofile-update=atomic -O0 --coverage -c idle.c -g
gcc-12 -pthread --coverage main.o idle.o
./a.out
gcov-12 idle.c
File 'idle.c'
Lines executed:100.00% of 2
Creating 'idle.c.gcov'
Lines executed:100.00% of 2
cat idle.c.gcov
-:0:Source:idle.c
-:0:Graph:idle.gcno
-:0:Data:idle.gcda
-:0:Runs:1
214896204:1:void *idle(void *ignored)
-:2:{
214896204:3: while (1) {
-:4:/* Do nothing */
-:5: }
-:6:
-:7: return 0;
-:8:}
[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657 --- Comment #3 from David Binderman --- (In reply to Andrew Pinski from comment #2) > If I initialize __trans_tmp_13 explictly to 0, the issue goes away $ fgrep trans_tmp_13 bug880.c int64_t __trans_tmp_13; (g_452) ^= (__trans_tmp_13); $ This now looks like a bug in csmith.
[Bug fortran/108651] Array Constructor with [type-spec:: fails to apply to all values, eg x = [integer(int64):: 1,2,3,4]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108651 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #5 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #2) > 5 | INTEGER(INT64), dimension(2), parameter:: arr1 = [integer(int64):: > -3300711175878204139, 8258803693257250632] > | > 1 > Error: Integer too big for its kind at (1). This check can be disabled with > the option '-fno-range-check' > > This is the correct behavior. -3300711175878204139 and 8258803693257250632 > are default integer kind, which is 32 bit and both numbers are outside the > range of [-huge(1)-1:huge(1)]. Indeed, and this is confirmed by other compilers, which either give an error (e.g. Nvidia) or at least a warning (Intel) in standard conformance mode. This PR should have been closed as invalid.
[Bug middle-end/108657] csmith: possible wrong checksum with -O3 and -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657 --- Comment #4 from Andrew Pinski --- (In reply to David Binderman from comment #3) > (In reply to Andrew Pinski from comment #2) > > If I initialize __trans_tmp_13 explictly to 0, the issue goes away > > $ fgrep trans_tmp_13 bug880.c >int64_t __trans_tmp_13; >(g_452) ^= (__trans_tmp_13); > $ > > This now looks like a bug in csmith. It might be both. I have not looked into the IR differences with respect of initializing and not initializing it and using/not using -ftrivial-auto-var-init=zero yet. This was mostly to give a hint to the next person who looks into this issue to see if they understand why there is a difference happening. -ftrivial-auto-var-init=zero should produce the similar results to initializing that variable to 0 but it is not. There has been some bugs (in GCC) recently in the area of not executed pathes with uninitialized variables changing the behavior (incorrectly) so it might be related to one of those ...
[Bug c++/101071] [10/11/12/13 Regression] ICE in gimplify_init_constructor, at gimplify.c:5228
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101071 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:60fca1802a25034f49fa1e3769b3a5656f392e89 commit r13-5692-g60fca1802a25034f49fa1e3769b3a5656f392e89 Author: Marek Polacek Date: Fri Feb 3 13:45:10 2023 -0500 c++: Add fixed test [PR101071] As a happy accident, this was fixed by the recent r13-2978. PR c++/101071 gcc/testsuite/ChangeLog: * g++.dg/cpp0x/variadic-alias8.C: New test.
[Bug c++/101071] [10/11/12/13 Regression] ICE in gimplify_init_constructor, at gimplify.c:5228
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101071 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Marek Polacek --- Fixed. Doesn't look important to (try to) backport.
[Bug c++/108158] [11/12/13 Regression] modification of '...' is not a constant expression since r12-2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:27ac6a707e7438c3cec79c24f5d53de79493e2f8 commit r13-5693-g27ac6a707e7438c3cec79c24f5d53de79493e2f8 Author: Marek Polacek Date: Mon Jan 30 09:02:00 2023 -0500 c++: wrong error with constexpr array and value-init [PR108158] In this test case, we find ourselves evaluating 't' which is ((const struct carray *) this)->data_[VIEW_CONVERT_EXPR(index)] in cxx_eval_array_reference. ctx->object is non-null, a RESULT_DECL, so we replace it with 't': new_ctx.object = t; // result_decl replaced and then we go to cxx_eval_constant_expression to evaluate an AGGR_INIT_EXPR, where we end up evaluating an INIT_EXPR (which is in the body of the constructor for seed_or_index): ((struct seed_or_index *) this)->value_ = NON_LVALUE_EXPR <0> whereupon in cxx_eval_store_expression we go to the probe loop where the 'this' is evaluated to ze_set.tables_.first_table_.data_[0] so the 'object' is ze_set, but that isn't in ctx->global->get_value_ptr so we fail with a bogus error. ze_set is not there because it comes from a different constexpr context (it's not in cv_cache either). The problem started with r12-2304 where I added the new_ctx.object replacement. That was to prevent a type mismatch: the type of 't' and ctx.object were different. It seems clear that we shouldn't have replaced ctx.object here. The cxx_eval_array_reference I mentioned earlier is called from cxx_eval_store_expression: 6257 init = cxx_eval_constant_expression (&new_ctx, init, vc_prvalue, 6258non_constant_p, overflow_p); which already created a new context, whose .object we should be using unless, for instance, INIT contained a.b and we're evaluating the 'a' part, which I think was the case for r12-2304; in that case ctx.object has to be something different. It no longer seems necessary to replace new_ctx.object (likely due to changes in empty class handling). PR c++/108158 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_array_reference): Don't replace new_ctx.object. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/constexpr-108158.C: New test.
[Bug c++/108158] [11/12 Regression] modification of '...' is not a constant expression since r12-2304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158 Marek Polacek changed: What|Removed |Added Summary|[11/12/13 Regression] |[11/12 Regression] |modification of '...' is|modification of '...' is |not a constant expression |not a constant expression |since r12-2304 |since r12-2304 --- Comment #7 from Marek Polacek --- Fixed on trunk so far.
[Bug libstdc++/94810] std::cout segmentation fault in __attribute__((constructor)) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94810 --- Comment #9 from Murugesan Nagarajan --- I'll update my comment today(Sat 04-Feb-2023 IST) after 09:00 AM IST. Right now I'm facing network issue due to travelling.
[Bug tree-optimization/107570] [13 Regression] ICE: Segmentation fault (in instantiate_scev_name/gimple_bb) since r13-3595-g7b1cdca6d6d594a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107570 --- Comment #5 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:093e2e1b201c0f324e0d8bfe6487aa2d470a13e7 commit r13-5694-g093e2e1b201c0f324e0d8bfe6487aa2d470a13e7 Author: Andrew MacLeod Date: Wed Feb 1 11:46:18 2023 -0500 Reset SCEV before removing unreachable globals. SCEV should be reset in VRP before trying to remove unreachable globals to avoid triggering issues with it's cache. PR tree-optimization/107570 gcc/ * tree-vrp.cc (remove_and_update_globals): Reset SCEV. gcc/testsuite/ * gcc.dg/pr107570.c: New.
[Bug tree-optimization/107570] [13 Regression] ICE: Segmentation fault (in instantiate_scev_name/gimple_bb) since r13-3595-g7b1cdca6d6d594a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107570 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Andrew Macleod --- Fixed.
[Bug libstdc++/94810] std::cout segmentation fault in __attribute__((constructor)) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94810 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=39796, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=98108, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=44952 --- Comment #10 from Andrew Pinski --- Note in GCC 13+, this should work now after r13-3707-g4e4e3ffd10f53e .
[Bug libstdc++/62200] libstdc++ initialization priority
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62200 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 39796. *** This bug has been marked as a duplicate of bug 39796 ***
[Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796 Andrew Pinski changed: What|Removed |Added CC||vhaisman at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 62200 has been marked as a duplicate of this bug. ***
