[Bug target/111096] Frame pointer is not used even when -fomit-frame-pointer is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096 --- Comment #2 from Andrew Pinski --- See https://gcc.gnu.org/pipermail/gcc-patches/2016-September/456662.html I think this is by design of the ABI ...
[Bug target/111096] Frame pointer is not used even when -fomit-frame-pointer is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096
--- Comment #1 from Andrew Pinski ---
#define FIXED_REGISTERS \
{ \
0, 0, 0, 0, 0, 0, 0, 0, /* R0 - R7 */ \
0, 0, 0, 0, 0, 0, 0, 0, /* R8 - R15 */ \
0, 0, 0, 0, 0, 0, 0, 0, /* R16 - R23 */ \
0, 0, 0, 0, 0, 1, 0, 1, /* R24 - R30, SP */ \
It is specifically marked as a fixed register ...
[Bug tree-optimization/95924] Failure to optimize some bit magic to one of the operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95924
--- Comment #3 from Andrew Pinski ---
_4 = (int) a_11(D);
_5 = ~_4;
_6 = (int) b_10(D);
_7 = _5 & _6;
(simplify
(bit_and:c (bit_not zero_one_valued_p@0) zero_one_valued_p@1)
(bit_and @1 (bit_xor! @0 { build_one_cst (type); } )))
Might be enough.
_4 = ~_3;
# RANGE [irange] int [0, 1] MASK 0x1 VALUE 0x0
_5 = (intD.9) b_8(D);
# RANGE [irange] int [0, 1] MASK 0x1 VALUE 0x0
_6 = _4 & _5;
# RANGE [irange] int [0, 1]
_15 = _6 ^ 1;
Or even:
(simplify
(bit_xor (bit_and:c zero_one_valued_p@0 @1) integer_onep@2)
(bit_or (bit_xor @0 @2) (bit_not! @1)))
Or:
(simplify
(bit_xor (bit_and:c zero_one_valued_p@0 (bit_not @1)) integer_onep@2)
(bit_or (bit_xor @0 @2) @1))
All of the above will work just trying to figure out which one would be better
here ...
[Bug rtl-optimization/111096] New: Frame pointer is not used even when -fomit-frame-pointer is specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111096
Bug ID: 111096
Summary: Frame pointer is not used even when
-fomit-frame-pointer is specified
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tkoenig at gcc dot gnu.org
Target Milestone: ---
The code, by Kent Dickey posted to comp.arch
typedef unsigned int u32;
typedef unsigned long long u64;
u64 do_op(u64 out0, u64 in0, u64 in1, u32 opcode, int size);
void
calc_loop(u64 *optr, u64 *iptr0, u64 *iptr1, u32 opcode, int size, int len)
{
u64 o0, i0, i1, val, result;
int num, shift, pos;
int i, j;
// size is 0,1,2,3 representing 8,16,32,64 bytes
num = 8 >> size;// 8,4,2,1
shift = 8 << size; // 8,16,32,64
for(i = 0; i < len; i++) {
o0 = optr[i];
i0 = iptr0[i];
i1 = iptr1[i];
result = 0;
pos = 0;
for(j = 0; j < num; j++) {
val = do_op(o0, i0, i1, opcode, size);
result = result | (val << pos);
pos += shift;
if(shift < 64) {
o0 = o0 >> shift;
i0 = i0 >> shift;
i1 = i1 >> shift;
}
}
optr[i] = result;
}
}
compiled for aarch64 on godbolt with recent trunk and -O3 -fomit-frame-pointer
(see https://godbolt.org/z/5bKPeGWrK ) does not set up the frame pointer,
but it also does not use it for aoviding spill/restore pairs:
calc_loop:
stp x19, x20, [sp, -144]!
mov w6, 8
asr w19, w6, w4
stp x27, x28, [sp, 64]
lsl w27, w6, w4
str x30, [sp, 80]
stp x0, x1, [sp, 112]
str x2, [sp, 128]
cmp w5, 0
ble .L1
sbfiz x0, x5, 3, 32
stp x21, x22, [sp, 16]
mov w20, w4
stp x23, x24, [sp, 32]
mov w21, w3
stp x25, x26, [sp, 48]
str x0, [sp, 136]
cmp w27, 63
ble .L3
mov x25, 0
.L6:
ldr x0, [sp, 112]
ldr x23, [x0, x25]
ldr x0, [sp, 120]
ldr x0, [x0, x25]
str x0, [sp, 104]
ldr x0, [sp, 128]
ldr x24, [x0, x25]
cbz w19, .L10
mov w22, 0
mov w28, 0
mov x26, 0
.L5:
ldr x1, [sp, 104]
mov w4, w20
mov w3, w21
mov x2, x24
mov x0, x23
add w22, w22, 1
bl do_op
lsl x0, x0, x28
add w28, w28, w27
orr x26, x26, x0
cmp w19, w22
bne .L5
ldr x0, [sp, 112]
str x26, [x0, x25]
add x25, x25, 8
ldr x0, [sp, 136]
cmp x0, x25
bne .L6
.L17:
ldp x21, x22, [sp, 16]
ldp x23, x24, [sp, 32]
ldp x25, x26, [sp, 48]
.L1:
ldp x27, x28, [sp, 64]
ldr x30, [sp, 80]
ldp x19, x20, [sp], 144
ret
.L3:
str xzr, [sp, 104]
ldp x0, x1, [sp, 104]
ldr x24, [x1, x0]
ldr x1, [sp, 120]
ldr x25, [x1, x0]
ldr x1, [sp, 128]
ldr x22, [x1, x0]
cbz w19, .L11
.L20:
mov w26, 0
mov w28, 0
mov x23, 0
.L8:
mov x2, x22
mov x1, x25
mov x0, x24
mov w4, w20
mov w3, w21
add w26, w26, 1
bl do_op
lsr x24, x24, x27
lsl x0, x0, x28
add w28, w28, w27
orr x23, x23, x0
lsr x25, x25, x27
lsr x22, x22, x27
cmp w19, w26
bne .L8
ldp x0, x1, [sp, 104]
str x23, [x1, x0]
add x0, x0, 8
ldr x1, [sp, 136]
str x0, [sp, 104]
cmp x1, x0
beq .L17
.L19:
ldp x0, x1, [sp, 104]
ldr x24, [x1, x0]
ldr x1, [sp, 120]
ldr x25, [x1, x0]
ldr x1, [sp, 128]
ldr x22, [x1, x0]
cbnzw19, .L20
.L11:
ldp x0, x1, [sp, 104]
mov x23, 0
str x23, [x1, x0]
add x0, x0, 8
ldr x1, [sp, 136]
str x0, [sp, 104]
cmp x1, x0
bne .L19
b .L17
.L10:
ldr x0, [sp, 112]
mov x26, 0
str x26, [x0, x25]
add x25, x25, 8
ldr x0, [sp, 136]
cmp
[Bug middle-end/82153] missed optimization: double truncating
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82153 --- Comment #6 from Andrew Pinski --- convert_to_integer_1 in convert.cc has some optmiizations which are missing in match.pd . /* Convert e.g. (long)round(d) -> lround(d). */ /* Convert (int)logb(d) -> ilogb(d). */
[Bug target/80517] [missed optimization] constant propagation through Intel intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80517 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=24928 --- Comment #8 from Andrew Pinski --- status of this bug: comment #0 first testcase: Fixed since GCC 9 comment #0 second testcase: still needs improvement comment #3 is now basically PR 24928
[Bug rtl-optimization/43147] SSE shuffle merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43147
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|--- |13.0
Resolution|--- |FIXED
--- Comment #21 from Andrew Pinski ---
Constant folding part was fixed in GCC 12 but combining shuffles was fixed in
GCC 13.
That is for:
```
__m128 m;
int main()
{
m = _mm_shuffle_ps(m, m, 0xC9); // Those two shuffles together swap
pairs
m = _mm_shuffle_ps(m, m, 0x2D); // And could be optimized to 0x4E
printv(m);
return 0;
}
```
GCC 13+ Produces:
```
movaps m(%rip), %xmm0
shufps $78, %xmm0, %xmm0
movaps %xmm0, m(%rip)
call_Z6printvDv4_f
```
instead of what was there in GCC 12:
```
movaps m(%rip), %xmm0
shufps $201, %xmm0, %xmm0
shufps $45, %xmm0, %xmm0
movaps %xmm0, m(%rip)
```
So closing as fixed in GCC 13.
[Bug modula2/108143] LONGREAL and powerpc64le-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108143 --- Comment #9 from Gaius Mulley --- Almost certainly m2builtin.cc is failing to detect that the targettm does not have log10l builtin as the result for log10l is always 0.0 on the ppc64le.
[Bug analyzer/110529] -Wanalyzer-null-dereference false nagetive with `*arr[0] = 10086`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110529 --- Comment #2 from mengli ming --- Um, would you be available to take a look at this case? Your insights would be greatly appreciated!
[Bug analyzer/111095] New: -Wanalyzer-out-of-bounds false negative with `return l_1322[9];`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111095 Bug ID: 111095 Summary: -Wanalyzer-out-of-bounds false negative with `return l_1322[9];` Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dale.mengli.ming at proton dot me Target Milestone: --- Hi,in this case(https://godbolt.org/z/sKPxGrG8z), the array `l_1322` has a capacity of 7. However, in relation to the `return l_1322[9]` statement, it appears(with -O1, -O2, -O3) that the analyzer don't report any related warnings. Thanks for taking the time to look at this case, even though I'm not sure if it's helpful for improving the analyzer.
[Bug target/111064] 5-10% regression of parest on icelake between g:d073e2d75d9ed492de9a8dc6970e5b69fae20e5a (Aug 15 2023) and g:9ade70bb86c8744f4416a48bb69cf4705f00905a (Aug 16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111064 --- Comment #3 from Hongtao.liu --- I didn't find the any regression when testing the patch. Guess it's because my tester is full-copy run and the options are -march=native -Ofast -flto -funroll-loop. Let me verify it.
[Bug analyzer/105899] RFE: -fanalyzer could complain about misuses of standard C string APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105899 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:3b691e0190c6e7291f8a52e1e14d8293a28ff4ce commit r14-3376-g3b691e0190c6e7291f8a52e1e14d8293a28ff4ce Author: David Malcolm Date: Mon Aug 21 21:13:19 2023 -0400 analyzer: check format strings for null termination [PR105899] This patch extends -fanalyzer to check the format strings of calls to functions marked with '__attribute__ ((format...))'. The only checking done in this patch is to check that the format string is a valid null-terminated string; this patch doesn't attempt to check the content of the format string. gcc/analyzer/ChangeLog: PR analyzer/105899 * call-details.cc (call_details::call_details): New ctor. * call-details.h (call_details::call_details): New ctor decl. (struct call_arg_details): Move here from region-model.cc. * region-model.cc (region_model::check_call_format_attr): New. (region_model::check_call_args): Call it. (struct call_arg_details): Move it to call-details.h. * region-model.h (region_model::check_call_format_attr): New decl. gcc/testsuite/ChangeLog: PR analyzer/105899 * gcc.dg/analyzer/attr-format-1.c: New test. * gcc.dg/analyzer/sprintf-1.c: Update expected results for now-passing tests. Signed-off-by: David Malcolm
[Bug analyzer/105899] RFE: -fanalyzer could complain about misuses of standard C string APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105899 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:fe97f09a0caeff2a22cc41b26bf08692bff8686d commit r14-3374-gfe97f09a0caeff2a22cc41b26bf08692bff8686d Author: David Malcolm Date: Mon Aug 21 21:13:19 2023 -0400 analyzer: replace -Wanalyzer-unterminated-string with scan_for_null_terminator [PR105899] In r14-3169-g325f9e88802daa I added check_for_null_terminated_string_arg to -fanalyzer, calling it in various places, with a sole check for unterminated string constants, adding -Wanalyzer-unterminated-string for this case. This patch adds region_model::scan_for_null_terminator, which simulates scanning memory for a zero byte, complaining about uninitiliazed bytes and out-of-range accesses seen before any zero byte is seen. This more flexible approach catches the issues we saw before with -Wanalyzer-unterminated-string, and also catches uninitialized runs of bytes, and I believe will be a better way to build checking of C string operations in the analyzer. Given that the patch makes -Wanalyzer-unterminated-string redundant and that this option was only in trunk for 10 days and has no known users, the patch simply removes the option without a compatibility fallback. The patch uses custom events and notes to provide context on where the issues are coming from. For example, given: null-terminated-strings-1.c: In function âtest_partially_initializedâ: null-terminated-strings-1.c:71:3: warning: use of uninitialized value âbuf[1]â [CWE-457] [-Wanalyzer-use-of-uninitialized-value] 71 | __analyzer_get_strlen (buf); | ^~~ âtest_partially_initializedâ: events 1-3 | | 69 | char buf[16]; | |^~~ | || | |(1) region created on stack here | 70 | buf[0] = 'a'; | 71 | __analyzer_get_strlen (buf); | | ~~~ | | | | | (2) while looking for null terminator for argument 1 (ââ) of â__analyzer_get_strlenâ... | | (3) use of uninitialized value âbuf[1]â here | analyzer-decls.h:59:22: note: argument 1 of â__analyzer_get_strlenâ must be a pointer to a null-terminated string 59 | extern __SIZE_TYPE__ __analyzer_get_strlen (const char *ptr); | ^ gcc/analyzer/ChangeLog: PR analyzer/105899 * analyzer.opt (Wanalyzer-unterminated-string): Delete. * call-details.cc (call_details::check_for_null_terminated_string_arg): Convert return type from void to const svalue *. Add param "out_sval". * call-details.h (call_details::check_for_null_terminated_string_arg): Likewise. * kf-analyzer.cc (kf_analyzer_get_strlen::impl_call_pre): Wire up to result of check_for_null_terminated_string_arg. * region-model.cc (get_strlen): Delete. (class unterminated_string_arg): Delete. (struct fragment): New. (class iterable_cluster): New. (region_model::get_store_bytes): New. (get_tree_for_byte_offset): New. (region_model::scan_for_null_terminator): New. (region_model::check_for_null_terminated_string_arg): Convert return type from void to const svalue *. Add param "out_sval". Reimplement in terms of scan_for_null_terminator, dropping the special-case for -Wanalyzer-unterminated-string. * region-model.h (region_model::get_store_bytes): New decl. (region_model::scan_for_null_terminator): New decl. (region_model::check_for_null_terminated_string_arg): Convert return type from void to const svalue *. Add param "out_sval". * store.cc (concrete_binding::get_byte_range): New. * store.h (concrete_binding::get_byte_range): New decl. (store_manager::get_concrete_binding): New overload. gcc/ChangeLog: PR analyzer/105899 * doc/invoke.texi: Remove -Wanalyzer-unterminated-string. gcc/testsuite/ChangeLog: PR analyzer/105899 * gcc.dg/analyzer/error-1.c: Update expected results to reflect reimplementation of unterminated string detection. Add test coverage for uninitialized buffers. * gcc.dg/analyzer/null-terminated-strings-1.c: Likewise. * gcc.dg/analyzer/putenv-1.c: Likewise. * gcc.dg/analyzer/strchr-1.c: Likewise. * gcc.dg/analyzer/strcpy-1.c: Likewise. * gcc.dg/analyzer/strdup-1.c: Likewise. Signed-off-by: David Malcolm
[Bug modula2/108143] LONGREAL and powerpc64le-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108143 --- Comment #8 from Gaius Mulley --- On reflection I'll drill down to see why the modula-2 builtin log10l doesn't work.
[Bug tree-optimization/110080] [13/14 Regression] Missed Dead Code Elimination at -Os when using __builtin_unreachable since r13-6945-g429a7a88438
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110080 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-08-21 --- Comment #4 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/110080] [13/14 Regression] Missed Dead Code Elimination at -Os when using __builtin_unreachable since r13-6945-g429a7a88438
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110080 --- Comment #3 from Andrew Pinski --- a.0_1 = aD.2830; # RANGE [irange] unsigned int [0, 255] MASK 0xff VALUE 0x0 _2 = (unsigned intD.9) a.0_1; # RANGE [irange] unsigned char [0, 0][4, 4] MASK 0x4 VALUE 0x0 _6 = a.0_1 & 4; # RANGE [irange] int [0, 0][4, 4] MASK 0x4 VALUE 0x0 _3 = (intD.6) _6; Those ranges should have been: a.0_1 [131,131] _2 [131,131] _6 [0,0] _3 [0,0] Like we got from the (not) unreachable branch: === BB 4 Imports: a.0_1 _3 Exports: a.0_1 _3 _6 a.0_1 [irange] unsigned char [131, 131] _3 [irange] int [0, 0] MASK 0x4 VALUE 0x0 The store to e was not 131 because it was before the unreachable though: e = _3; if (a.0_1 != 131) goto ; [0.00%] else goto ; [100.00%] [count: 0]: __builtin_unreachable ();
[Bug modula2/108143] LONGREAL and powerpc64le-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108143 Gaius Mulley changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-08-21 Ever confirmed|0 |1 --- Comment #7 from Gaius Mulley --- Assigned.
[Bug modula2/108143] LONGREAL and powerpc64le-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108143 Gaius Mulley changed: What|Removed |Added CC||gaius at gcc dot gnu.org --- Comment #6 from Gaius Mulley --- Created attachment 55773 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55773=edit Proposed fix Here is a proposed fix which uses a local implementation of log10l (logl(r)/logl(10.0)) rather than the builtin log10l. The patch will be applied (if/once) the full bootstrap completes.
[Bug tree-optimization/109943] [13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-6834-g41ade3399bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109943 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-08-21 Status|UNCONFIRMED |NEW --- Comment #4 from Andrew Pinski --- For the testcase in comment #0, fre3 is able to optmize it away (in GCC 12.3.0): Applying pattern match.pd:636, gimple-match.cc:47124 Match-and-simplified _10 % _8 to 0 That is because we figure out that _10 is the same as _8 somehow. Confirmed.
[Bug fortran/102620] [12/13/14 Regression] ICE in gfc_get_array_span, at fortran/trans-array.c:865 since r12-1233-gd514626ee2566c68
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102620 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #7 from anlauf at gcc dot gnu.org --- Apparently fixed on mainline for gcc-14 by r14-2461-gf9182da3213aa5.
[Bug tree-optimization/110949] ((cast)cmp) - 1 should be tranformed into -(cast)cmp` where cmp` is the inverse of cmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110949 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-08-21 Severity|normal |enhancement Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #1 from Andrew Pinski --- Note the RTL level does this optimization: Trying 8 -> 9: 8: r99:SI=cc:CC==0 REG_DEAD cc:CC 9: r97:SI=r99:SI-0x1 REG_DEAD r99:SI Successfully matched this instruction: (set (reg:SI 97 [ _8D.4420 ]) (neg:SI (ne:SI (reg:CC 66 cc) (const_int 0 [0]
[Bug tree-optimization/110915] vector version of `x == MIN & x > y` is not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110915
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> These should work, I think, will try after finishing up the pointer:
This is better version, it replaces the current min_value/max_value even:
(match min_value
uniform_integer_cst_p
(with { tree int_cst = uniform_integer_cst_p (t); }
(if ((INTEGRAL_TYPE_P (TREE_TYPE (int_cst))
|| POINTER_TYPE_P (TREE_TYPE (int_cst)))
&& wi::eq_p (wi::to_wide (int_cst),
wi::min_value (TREE_TYPE (int_cst
)
)
(match max_value
uniform_integer_cst_p
(with { tree int_cst = uniform_integer_cst_p (t); }
(if ((INTEGRAL_TYPE_P (TREE_TYPE (int_cst))
|| POINTER_TYPE_P (TREE_TYPE (int_cst)))
&& wi::eq_p (wi::to_wide (int_cst),
wi::max_value (TREE_TYPE (int_cst
)
)
That is INTEGER_CST replace with uniform_integer_cst_p and type with TREE_TYPE
(int_cst) and t with int_cst.
[Bug tree-optimization/111094] Spurious Wuninitialized swapping underlying bytes of object representation in move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111094 Ed Catmur changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Ed Catmur --- Well, I feel like [basic.types.general] probably allows it. But regardless, yeah, this is an opt-in diagnostic so it's fine if gcc warns on things that are legal but dubious. We'll just have to be a bit smarter in how we write this code. Thanks again.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 111094, which changed state. Bug 111094 Summary: Spurious Wuninitialized swapping underlying bytes of object representation in move constructor https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111094 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug fortran/49588] DATA statement with vector sections rejected (ICE: TODO)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49588 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-August/059700.html
[Bug tree-optimization/111094] Spurious Wuninitialized swapping underlying bytes of object representation in move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111094 --- Comment #3 from Andrew Pinski --- Also I read 2.2 differently (https://eel.is/c++draft/basic.indet) . Since the object which you are reading from is of type S and even though you are using an `unsigned char` to read the value here, it will not just be an Indeterminate but also will be undefined.
[Bug tree-optimization/111094] Spurious Wuninitialized swapping underlying bytes of object representation in move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111094 --- Comment #2 from Andrew Pinski --- But that does not mean GCC should not warn about this. It just means it will NOT be undefined behavior ...
[Bug tree-optimization/111094] Spurious Wuninitialized swapping underlying bytes of object representation in move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111094
Andrew Pinski changed:
What|Removed |Added
Component|c++ |tree-optimization
--- Comment #1 from Andrew Pinski ---
This is what the IR looks like:
a ={v} {CLOBBER};
*b_2(D).b = 0;
vect__14.11_28 = MEM [(unsigned char *) + 2B];
MEM [(unsigned char *)b_2(D) + 2B] =
vect__14.11_28;
a ={v} {CLOBBER(eol)};
return b_2(D);
Which is copying the unitialized parts of a.S to b.S.
[Bug c++/111094] New: Spurious Wuninitialized swapping underlying bytes of object representation in move constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111094
Bug ID: 111094
Summary: Spurious Wuninitialized swapping underlying bytes of
object representation in move constructor
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ed at catmur dot uk
Target Milestone: ---
struct S { short x, y; };
struct A {
A() {}
A(A&& rhs) {
auto p = reinterpret_cast();
auto q = reinterpret_cast();
for (int i = 0; i != sizeof s; ++i) {
auto t = p[i];
p[i] = q[i];
q[i] = t;
}
}
bool b = false;
S s;
};
A f() {
A a;
A b = static_cast(a);
return b;
}
at -O3 -Wall:
In constructor 'A::A(A&&)',
inlined from 'A f()' at :18:29:
:9:23: warning: '*(__vector(4) unsigned char*)((char*) + offsetof(A,
A::s.S::x))' is used uninitialized [-Wuninitialized]
9 | p[i] = q[i];
|~~~^
: In function 'A f()':
:17:7: note: 'a' declared here
17 | A a;
| ^
I'm reasonably sure that this usage of swapping underlying bytes is OK by
[basic.indet]/2.3.
(Motivation is e.g. optional with empty-on-move behavior and optimization for
trivial types.)
[Bug libstdc++/111089] ODR violation warning in std::variant implementation when linking(LTO) C++20 and C++17 TUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111089
--- Comment #1 from Andrew Pinski ---
libstdc++'s c++20 version of _Uninitialized:
struct _Empty_byte { };
union {
_Empty_byte _M_empty;
_Type _M_storage;
};
c++17 version:
__gnu_cxx::__aligned_membuf<_Type> _M_storage;
That is techincally a ODR violation ...
How to reproduce using regular sources (rather than preprocessed sources).
main.cc:
```
#include
#include
#include
void test(std::variant id);
int main()
{
test("123");
}
```
t.cc:
```
#include
#include
#include
void test(std::variant id)
{
__builtin_printf("%d\n", (int)(id.index()));
}
```
$ ~/upstream-gcc/bin/g++ t.cc -std=gnu++20 -c -flto
$ ~/upstream-gcc/bin/g++ main.cc -std=gnu++17 -c -flto
$ ~/upstream-gcc/bin/g++ main.o t.o -flto
main.cc:5:6: warning: ‘test’ violates the C++ One Definition Rule [-Wodr]
5 | void test(std::variant id);
| ^
t.cc:6:6: note: type mismatch in parameter 1
6 | void test(std::variant id)
| ^
/home/apinski/upstream-gcc/include/c++/14.0.0/variant:1337:11: note: type
‘struct variant’ itself violates the C++ One Definition Rule
1337 | class variant
| ^
t.cc:6:6: note: ‘test’ was previously declared here
6 | void test(std::variant id)
| ^
[Bug target/111093] New: [nvptx] ICE (assert) when running "accel/nvptx-none/cc1 -E -dM < /dev/null"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111093 Bug ID: 111093 Summary: [nvptx] ICE (assert) when running "accel/nvptx-none/cc1 -E -dM < /dev/null" Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: tschwinge at gcc dot gnu.org, vries at gcc dot gnu.org Target Milestone: --- Running "accel/nvptx-none/cc1 -E -dM < /dev/null" to determine which #defines are available fails with: cc1: internal compiler error: in nvptx_option_override, at config/nvptx/nvptx.cc:339 0x125e31a nvptx_option_override The reason is: /* Via nvptx 'OPTION_DEFAULT_SPECS', '-misa' always appears on the command line. */ gcc_checking_assert (OPTION_SET_P (ptx_isa_option)); Expected: An error message that '-misa=' is required, given that OPTION_DEFAULT_SPECS is not used when invoking the compiler (e.g. cc1) directly and not via the driver (e.g. gcc), especially as the drivers of the accelerator targets are not installed in an offloading configuration.
[Bug tree-optimization/111048] [14 Regression] Wrong AVX2 code on highway-1.0.6 on -O2 and above since r14-3243-ga7dba4a1c05a76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111048 --- Comment #11 from Sergei Trofimovich --- I confirm highway-1.0.6 still passes the tests with Prathamesh's fix. Thank you!
[Bug c++/96868] C++20 designated initializer erroneous warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96868
roland at gnu dot org changed:
What|Removed |Added
CC||roland at gnu dot org
--- Comment #9 from roland at gnu dot org ---
IMHO there's a good case to be made for never warning for designated
initializers, even for fields that have uninitialized default-construction.
When using a designated initializer, `= {.a=value}` doesn't leave any field `b`
uninitialized, it initializes it as `= {}` would, i.e. safely zero for base
types, etc. When I write `= {.a=value}` that default-or-zero-initialization of
the other fields is exactly what I intended, and I know well that omitted
fields in an initializer are different from leaving the fields uninitialized.
Clearly opinions on this vary. It seems like it merits having separable option
configuration: `-Wmissing-field-initializers`,
`-Wmissing-designated-field-initializers`. If that flexibility is available,
then it's of less concern what the default state with just
`-Wmissing-field-initializers` or `-Wextra` is.
The separate question remains whether "missing initializer" vs "missing
(explicit) initialization" should also be distinguished differently in the
available warning states than what we have today. I don't have much opinion
about that one as long as there's a way for me to say that:
```
struct s { int a, b; };
s foo = {.a=1};
```
is acceptable without warning in C++, even if it requires a different option
state than to accept:
```
struct s { int a; int b = 0; };
s foo = {.a=1};
```
[Bug tree-optimization/111090] Bogus -Wuninitialized for trivial copy of nested struct with partially initialized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111090 Ed Catmur changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Ed Catmur --- (In reply to Andrew Pinski from comment #2) > I don't see how it is bogus as you admit it was only partially initialized > even. The act of copying is still an use IIRC. Sorry, my bad. I reduced it past the point of usefulness and got myself confused. Thanks.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 111090, which changed state. Bug 111090 Summary: Bogus -Wuninitialized for trivial copy of nested struct with partially initialized array https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111090 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug middle-end/111082] [14 Regression] ICE in expand_fn_using_insn, at internal-fn.cc:214 (AVX512 related)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111082 Andrew Pinski changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #8 from Andrew Pinski --- *** Bug 111092 has been marked as a duplicate of this bug. ***
[Bug c/111092] ice expand_fn_using_insn, at internal-fn.cc:214
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111092 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Fixed a few hours ago. *** This bug has been marked as a duplicate of bug 111082 ***
[Bug libstdc++/111091] Split view with double quoted string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111091 --- Comment #2 from Andrew Pinski --- Both libstdc++ and libc++ have the same behavior for Try1 ...
[Bug c/111092] New: ice expand_fn_using_insn, at internal-fn.cc:214
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111092
Bug ID: 111092
Summary: ice expand_fn_using_insn, at internal-fn.cc:214
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this C code:
typedef struct {
long r;
long c
} bool_mat_struct;
bool_mat_struct bool_mat_randtest_diagonal_mat;
bool_mat_randtest_diagonal_n;
bool_mat_randtest_diagonal() {
bool_mat_randtest_diagonal_n =
bool_mat_randtest_diagonal_mat.r > bool_mat_randtest_diagonal_mat.c
? bool_mat_randtest_diagonal_mat.c
: bool_mat_randtest_diagonal_mat.r;
}
compiled by recent gcc and compiler flags -O3 -march=znver2, does this:
$ /home/dcb38/gcc/results.20230817.asan.ubsan/bin/gcc -c -w -O3 -march=znver2
bug948B.c
$ /home/dcb38/gcc/results.20230818.asan.ubsan/bin/gcc -c -w -O3 -march=znver2
bug948B.c
during RTL pass: expand
bug948B.c: In function ‘bool_mat_randtest_diagonal’:
bug948B.c:7:1: internal compiler error: in expand_fn_using_insn, at
internal-fn.cc:214
7 | bool_mat_randtest_diagonal() {
| ^~
0xb33633 expand_fn_using_insn(gcall*, insn_code, unsigned int, unsigned int)
../../trunk.year/gcc/internal-fn.cc:214
0x8af481 expand_call_stmt(gcall*)
../../trunk.year/gcc/cfgexpand.cc:2737
Git range is g:93f803d53b5ccaab to g:68f7cb6cf9e8b9f2, some 39 commits.
[Bug c++/111091] Split view with double quoted string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111091 --- Comment #1 from KL --- The godbolt has the clang compiler set but it was just to compare the output (which has the same output given the same libstdc++). Sorry for this.
[Bug tree-optimization/111090] Bogus -Wuninitialized for trivial copy of nested struct with partially initialized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111090
--- Comment #3 from Andrew Pinski ---
Reduced to make it obvious what is going on:
```
struct A {
A() { buf[0] = 0; }
int buf[2];
};
A g()
{
A a;
A b = a;
return b;
}
```
[Bug c++/111091] New: Split view with double quoted string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111091
Bug ID: 111091
Summary: Split view with double quoted string
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: deco33000 at yandex dot com
Target Milestone: ---
Hi,
I have just been caught by an overlook using range split, but it may happen to
others.
The issue is the Try1 bypasses the delimiter (maybe because of a char
conversion?)
The other versions work fine though..
As usual, to ease your life: https://godbolt.org/z/7nMK46bjq
#include
#include
#include
#include
using namespace std; // for simplicity
int main() {
string a{"Part A / Part B"};
{
cout << "Try 1 : with double quote (wrong behavior? delim is
bypassed)\n";
auto v = ::ranges::views::split(a, "/");
for (auto & : v) {
cout << string_view(word) << ' ';
}
cout << "\n\n";
}
{
cout << "Try 1bis : explicitly convert to string: OK\n";
auto v = ::ranges::views::split(a, string("/"));
for (auto & : v) {
cout << string_view(word) << ' ';
}
cout << "\n\n";
}
{
cout << "Try 2 : with single quote: OK\n";
auto v = ::ranges::views::split(a, '/');
for (auto & : v) {
cout << string_view(word) << ' ';
}
cout << "\n\n";
}
{
cout << "Try 3 : with string delimiter: OK\n";
string delim{"/"};
auto v = ::ranges::views::split(a, delim);
for (auto & : v) {
cout << string_view(word) << ' ';
}
cout << "\n\n";
}
{
cout << "Try 4 : with string delimiter: OK\n";
string delim{'/'};
auto v = ::ranges::views::split(a, delim);
for (auto & : v) {
cout << string_view(word) << ' ';
}
cout << "\n\n";
}
return 0;
}
Do you think we could make Try1 to work properly ?
Thanks
[Bug ipa/111088] useless 'xor eax,eax' inserted when a value is not returned and icf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111088 --- Comment #3 from Jan Hubicka --- > But adds a return with a value. And then the inliner inlines foo into foo2 but > we still have the return with a value around ... I guess ICF can special case unused return value, but why this is not taken care of by ipa-sra?
Re: [Bug middle-end/111088] useless 'xor eax,eax' inserted when a value is not returned and icf
> But adds a return with a value. And then the inliner inlines foo into foo2 but > we still have the return with a value around ... I guess ICF can special case unused return value, but why this is not taken care of by ipa-sra?
[Bug tree-optimization/111090] Bogus -Wuninitialized for trivial copy of nested struct with partially initialized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111090 --- Comment #2 from Andrew Pinski --- I don't see how it is bogus as you admit it was only partially initialized even. The act of copying is still an use IIRC.
[Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671 --- Comment #18 from Mark Brown --- It's section placement stuff that's triggering this. You will also be able to build a larger kernel if you try, though I'm not sure that's practical.
[Bug middle-end/111088] useless 'xor eax,eax' inserted when a value is not returned and icf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111088 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-08-21 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- So ICF figures out foo and foo2 are the same and has foo2 tail calls foo: [local count: 1073741824]: retval.2_4 = foo (a_2(D)); [tail call] return retval.2_4; But adds a return with a value. And then the inliner inlines foo into foo2 but we still have the return with a value around ...
[Bug c++/111090] Bogus -Wuninitialized for trivial copy of nested struct with partially initialized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111090 --- Comment #1 from Ed Catmur --- uh, -O -Wall is necessary, obviously. https://godbolt.org/z/eT9dY467P
[Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671 --- Comment #17 from Wilco --- (In reply to Mark Brown from comment #13) > The kernel hasn't got any problem with BTI as far as I am aware - when built > with clang we run the kernel with BTI enabled since clang does just insert a > BTI C at the start of every function, and GCC works fine so long as we don't > get any out of range jumps being generated. The issue is that we don't have > anything to insert veneers in the case where section placement puts static > functions into a distant enough part of memory to need an indirect jump but > GCC has decided to omit the landing pad. Is the kernel already larger than 128 MBytes .text? Or do people do weird stuff with section placement that causes branches to be out of range?
[Bug c++/111090] New: Bogus -Wuninitialized for trivial copy of nested struct with partially initialized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111090
Bug ID: 111090
Summary: Bogus -Wuninitialized for trivial copy of nested
struct with partially initialized array
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ed at catmur dot uk
Target Milestone: ---
struct A {
A() { buf[0] = 0; }
int buf[2];
};
struct B { A a; };
struct C {
C(B const& b) : b(b) {}
B b;
};
struct D {
D(C c) : c(c) {}
C c;
};
D f() { return D(C(B())); }
In constructor 'C::C(const B&)',
inlined from 'D f()' at :14:16:
:7:21: warning: '.B::a.A::a[1]' is used uninitialized
[-Wuninitialized]
7 | C(B const& b) : b(b) {}
| ^~~~
: In function 'D f()':
:14:22: note: '' declared here
14 | D f() { return D(C(B())); }
| ^
This appears to have started in 7.1.
[Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671 --- Comment #16 from Richard Earnshaw --- (In reply to Mark Brown from comment #15) > The kernel module loader simply does not insert veneers at present, and > there were some implementation concerns IIRC. That's not a good reason to weaken the security of the generated code.
[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106652 Igor Kushnir changed: What|Removed |Added CC||igorkuo at meta dot ua --- Comment #20 from Igor Kushnir --- (In reply to Jakub Jelinek from comment #18) > This is now implemented. Shouldn't the sentence "These types are not supported when compiling C++." be removed from the documentation https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Floating-Types.html?
[Bug c++/111083] Test failure of g++.dg/ipa/pr67056.C on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111083 Iain Sandoe changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Iain Sandoe --- @honza, adding you because this test also fails on Linux with "-fPIE" - if that's what you expect then we can handle this just in Darwin, if not expected - then perhaps something else is needed.
[Bug c++/102609] [C++23] P0847R7 - Deducing this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102609
--- Comment #14 from Barry Revzin ---
> I am finding myself realizing that implementing this as a member function and
> turning off member function bits seems to be more difficult than implementing
> it as a static function and implementing member function bits will be.
That's how I implemented this in EDG - static member functions that just have
some extra powers.
> Of these cases, is f0 or f1 and g0 or g1 correct? I assume the answer is f1
> and g1.
Both are correct - you're still a member of S, so you don't have to qualify
S::my_type (I mean, you can, it's not incorrect, but it's just not necessary -
means the same thing either way).
> When deduced, f0 or f1 and g0 or g1? I would definitely think f1 and g1 now.
These now might actually mean different things. Unqualified my_type is still
valid and means S::my_type (i.e. int). But Self::my_type could now mean a
different type. Merging the two examples:
struct S {
using my_type = int;
template
void f0(this Self, my_type);
template
void f1(this Self, Self::my_type);
};
struct D : S {
using my_type = double;
};
D().f0(2.0); // calls S::f0, which takes an int
D().f1(2.0); // calls S::f1, which takes a double
[Bug target/111010] [13/14 regression] error: unable to find a register to spill compiling GCDAProfiling.c since r13-5092-g4e0b504f26f78f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010
--- Comment #12 from Uroš Bizjak ---
gcc-13 version:
--cut here--
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 5363b37d448..df476763f85 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -11527,7 +11527,8 @@ (define_insn_and_split "*concat3_3"
{
split_double_concat (mode, operands[0], operands[3], operands[1]);
DONE;
-})
+}
+ [(set_attr "isa" "*,*,*,x64")])
(define_insn_and_split "*concat3_4"
[(set (match_operand: 0 "nonimmediate_operand" "=ro,r,r,")
@@ -11545,7 +11546,8 @@ (define_insn_and_split "*concat3_4"
{
split_double_concat (mode, operands[0], operands[1], operands[2]);
DONE;
-})
+}
+ [(set_attr "isa" "*,*,*,x64")])
(define_insn_and_split "*concat3_5"
[(set (match_operand:DWI 0 "nonimmediate_operand" "=r,o,o")
--cut here--
[Bug tree-optimization/93080] insert of an extraction on the same location is not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93080 --- Comment #7 from Richard Biener --- comment#4 could be implemented by an associating pattern in match.pd, currently we get a_3 = BIT_INSERT_EXPR ; a_4 = VEC_PERM_EXPR ; associating a VEC_PERM_EXPR when a or b are defined as insertion into b or a respectively so we get a permute of either a or b with itself (and in this case it's a noop permute). Of course with an arbitrary sequence of inserts / extracts / permutes more "generic" association would be necessary and a pure implementation in match.pd looks difficult.
[Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671 --- Comment #15 from Mark Brown --- The kernel module loader simply does not insert veneers at present, and there were some implementation concerns IIRC.
[Bug c++/110566] [13 Regression] ICE when instantiating function template with template template parameter with 2 or more auto parameters with a dependent member template, ICE in tsubst, at cp/pt.cc:1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110566 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Patrick Palka --- The original testcase (passing a partially instantiated template as a ttp) is fixed for GCC 13.3. The follow-up fix r14-2810 (for passing a partially instantiated ttp as a ttp) doesn't seem suitable for backporting..
[Bug c++/110197] [13 Regression] Empty constexpr object constructor erronously claims out of range access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110197 --- Comment #11 from Matt Godbolt --- Thank you Patrick! Great news! About 1/3 of my build's output is this warning right now :)
[Bug c++/110197] [13 Regression] Empty constexpr object constructor erronously claims out of range access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110197 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Patrick Palka --- Fixed for GCC 13.3
[Bug middle-end/111088] useless 'xor eax,eax' inserted when a value is not returned and icf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111088 --- Comment #1 from Andrew Pinski --- It is ICF coming into play and then inlining.
[Bug testsuite/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067
--- Comment #4 from Iain Sandoe ---
clang on Darwin rejects the code thus:
$ ./bin/clang++ /src-local/gcc-master/gcc/testsuite/g++.dg/opt/icf1.C -o i1
-std=c++14
/src-local/gcc-master/gcc/testsuite/g++.dg/opt/icf1.C:5:3: error:
'no_unique_address' attribute only applies to non-bit-field non-static data
members
5 | [[no_unique_address]] extern const int i[] = { 1,2,3 };
this seems to agree with the current WD:
https://eel.is/c++draft/dcl.attr.nouniqueaddr
"9.12.11 No unique address attribute [dcl.attr.nouniqueaddr]
1 #
The attribute-token no_unique_address specifies that a non-static data member
is a potentially-overlapping subobject ([intro.object]). No
attribute-argument-clause shall be present. The attribute may appertain to a
non-static data member other than a bit-field.
"
since the objects in the test case are not non-static, non-bitfield data
members, any application of the attribute would be a GCC extension, I guess?
What is the intent?
[Bug c/95130] GCC ignoring attribute(format(gnu_printf)) on printf in mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95130
--- Comment #22 from Tomas Kalibera ---
(In reply to CVS Commits from comment #21)
> The master branch has been updated by Jonathan Yong :
>
> https://gcc.gnu.org/g:966f3c134bb4802ac7ba0517de4e8e3f6384cfa3
>
> commit r14-3334-g966f3c134bb4802ac7ba0517de4e8e3f6384cfa3
> Author: Tomas Kalibera
> Date: Sun Aug 20 02:16:16 2023 +
>
> Fix format attribute for printf
>
> Since a long time (GCC 4.4?) GCC does support annotating functions
> with either the format attribute "gnu_printf" or "ms_printf" to
> distinguish between different format string interpretations.
>
> However, it seems like the attribute is ignored for the "printf"
> symbol; regardless what the function declaration says, GCC treats
> it as "ms_printf". This has become an issue now that mingw-w64
> supports using the UCRT instead of msvcrt.dll, and in this case
> the stdio functions are declared with the gnu_printf attribute,
> and inttypes.h uses the same format specifiers as in GNU mode.
>
> A reproducible example of the problem:
>
> $ cat format.c
> __attribute__((__format__ (gnu_printf, 1, 2))) int printf (const char
> *__format, ...);
> __attribute__((__format__ (gnu_printf, 1, 2))) int othername (const char
> *__format, ...);
>
> void function(void) {
> long long unsigned x = 42;
> othername("%llu\n", x);
> printf("%llu\n", x);
> }
> $ x86_64-w64-mingw32-gcc -c -Wformat format.c
> format.c: In function 'function':
> format.c:7:15: warning: unknown conversion type character 'l' in format
> [-Wformat=]
> 7 | printf("%llu\n", x);
> | ^
> format.c:7:12: warning: too many arguments for format
> [-Wformat-extra-args]
> 7 | printf("%llu\n", x);
> |^~~~
>
> Note how both functions, printf and othername, are declare with
> identical gnu_printf format attributes - GCC does take this into
> account for "othername" and doesn't produce a warning, but GCC
> seems to disregard the attribute in the printf declaration and
> behave as if it was declared as ms_printf.
>
> If the printf function declaration is changed into a static inline
> function, the actual attribute used is honored though.
>
> gcc/c-family/ChangeLog:
>
> PR c/95130
> * c-format.cc: skip default format for printf symbol if
> explicitly declared by prototype.
>
> Signed-off-by: Tomas Kalibera
> Signed-off-by: Jonathan Yong <10wa...@gmail.com>
Great, thanks a lot for finishing and adding this,
Tomas
[Bug target/111010] [13/14 regression] error: unable to find a register to spill compiling GCDAProfiling.c since r13-5092-g4e0b504f26f78f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010 Uroš Bizjak changed: What|Removed |Added Attachment #55771|0 |1 is obsolete|| --- Comment #11 from Uroš Bizjak --- Created attachment 55772 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55772=edit The correct proposed patch Eh, sorry for wrong attachment. This is the correct one.
[Bug target/111010] [13/14 regression] error: unable to find a register to spill compiling GCDAProfiling.c since r13-5092-g4e0b504f26f78f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010 --- Comment #10 from Uroš Bizjak --- Created attachment 55771 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55771=edit Proposed patch This (untested) patch should solve the PR on trunk.
[Bug testsuite/111067] g++.dg/opt/icf{1,2,3}.C tests fail on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111067 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #3 from Iain Sandoe --- I took a brief look at this over the weekend, but I need to check what is allowed/expected by the ABI - we normally reject cases where two externally-visible symbols have the same address, since that breaks the ld64 'atom model'; how to reconcile that constraint with 'no unique address' is interesting. We do support merging literals, and we can support aliased symbols by instruction to the linker that they are - so there might be viable way(s) to implement.
[Bug bootstrap/111027] [11/12/13/14 Regression] `make install` touches the build directory; Install error "tmp-header-vars: Permission denied", build on NFS, improvement possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111027 --- Comment #4 from etienne_lorrain at yahoo dot fr --- Parallella box is free again. Proposed patch (with a slight offset) is recompiling, result in 2065m36.178s...
[Bug c++/111089] New: ODR violation warning in std::variant implementation when linking(LTO) C++20 and C++17 TUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111089 Bug ID: 111089 Summary: ODR violation warning in std::variant implementation when linking(LTO) C++20 and C++17 TUs Product: gcc Version: 12.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: damian.jarek93 at gmail dot com Target Milestone: --- Created attachment 55770 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55770=edit ii files of a minimal example that reproduces the issue When 2 TUs are LTO-linked, g++ complains about an ODR violation in std::variant's implementation: /usr/bin/g++-12 -flto -Wall -Wextra -g -flto=auto -fno-fat-lto-objects CMakeFiles/main.dir/main.cpp.o -o main libcxx17-lib.a /usr/include/c++/12/variant:244:12: note: type 'struct _Uninitialized' itself violates the C++ One Definition Rule 244 | struct _Uninitialized<_Type, false> |^ /usr/include/c++/12/variant:378:11: note: type 'union _Variadic_union' itself violates the C++ One Definition Rule 378 | union _Variadic_union<_First, _Rest...> | ^ /workspaces/odr-bug-repro/cxx17.hpp:8:6: warning: 'test' violates the C++ One Definition Rule [-Wodr] 8 | void test(std::variant id); | ^ /workspaces/odr-bug-repro/cxx17.cpp:5:6: note: type mismatch in parameter 1 5 | void test(std::variant id) | ^ /usr/include/c++/12/variant:1336:11: note: type 'struct variant' itself violates the C++ One Definition Rule 1336 | class variant | ^ /workspaces/odr-bug-repro/cxx17.cpp:5:6: note: 'test' was previously declared here 5 | void test(std::variant id) | The function 'void test(std::variant id)' must be defined in a TU compiled with -std=gnu++17 and called in a TU compiled with -std=gnu++20. Complete command line that reproduces the issue: /usr/bin/g++-12 -std=gnu++20 -flto -Wall -Wextra -g -o main.cpp.o -c main.cpp /usr/bin/g++-12 -std=gnu++17 -flto -Wall -Wextra -g -o cxx17.cpp.o -c cxx17.cpp /usr/bin/g++-12 -flto -Wall -Wextra -g -flto=auto -fno-fat-lto-objects main.cpp.o cxx17.cpp.o -o main g++ version: Using built-in specs. COLLECT_GCC=g++-12 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 12.3.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-12-ALHxjy/gcc-12-12.3.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-ALHxjy/gcc-12-12.3.0/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.3.0 (Ubuntu 12.3.0-1ubuntu1~22.04) I also tested this bug with g++ 13.1.0 and is still present there, although the warning is slightly less verbose.
[Bug target/111010] [13/14 regression] error: unable to find a register to spill compiling GCDAProfiling.c since r13-5092-g4e0b504f26f78f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010 --- Comment #9 from Uroš Bizjak --- (In reply to r...@cebitec.uni-bielefeld.de from comment #8) > > --- Comment #7 from Richard Biener --- > > > > diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md > > index f3a3305ac4f..d38b9d764d8 100644 > > --- a/gcc/config/i386/i386.md > > +++ b/gcc/config/i386/i386.md > > @@ -11511,7 +11511,7 @@ > > }) > > > > (define_insn_and_split "*concat3_3" > > - [(set (match_operand: 0 "nonimmediate_operand" "=ro,r,r,") > > + [(set (match_operand: 0 "nonimmediate_operand" "=ro,r,r,!") > > (any_or_plus: > > (ashift: > > (zero_extend: > > > > fixes the issue for me, this disparages the ,m,m alternative since > > that makes any reloading difficult(?) and the early-clobber output > > makes register pressure even harder to deal with. > > On the gcc-13 branch, it does indeed, both for the reduced testcase and > the original one. I've also successfully regtested the patch just in > case. I think you should add: (set_attr "isa" "*,*,*,x64") attribute to hard disable 32bit targets from having two memory operands.
[Bug target/111010] [13/14 regression] error: unable to find a register to spill compiling GCDAProfiling.c since r13-5092-g4e0b504f26f78f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111010 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #7 from Richard Biener --- > > diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md > index f3a3305ac4f..d38b9d764d8 100644 > --- a/gcc/config/i386/i386.md > +++ b/gcc/config/i386/i386.md > @@ -11511,7 +11511,7 @@ > }) > > (define_insn_and_split "*concat3_3" > - [(set (match_operand: 0 "nonimmediate_operand" "=ro,r,r,") > + [(set (match_operand: 0 "nonimmediate_operand" "=ro,r,r,!") > (any_or_plus: > (ashift: > (zero_extend: > > fixes the issue for me, this disparages the ,m,m alternative since > that makes any reloading difficult(?) and the early-clobber output > makes register pressure even harder to deal with. On the gcc-13 branch, it does indeed, both for the reduced testcase and the original one. I've also successfully regtested the patch just in case. On trunk, the situation is different, however: even without the patch, the reduced testcase works while the full one fails. With the patch (adjusted to apply to "*concat3_4", unless I'm mistaken here), the situation stays the same: ok for the reduced testcase, failure for the original one.
[Bug c++/111019] [12/13 Regression] Optimizer incorrectly assumes variable is not changed while change happens through another pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111019 --- Comment #12 from Sławomir Fraś --- $ /opt/gcc-745ec1/bin/g++ -v Using built-in specs. COLLECT_GCC=/opt/gcc-745ec1/bin/g++ COLLECT_LTO_WRAPPER=/opt/gcc-745ec1/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-w rapper Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --prefix=/opt/gcc-745ec1 --enable-languages=c, c++,fortran,go --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 14.0.0 20230818 (experimental) (GCC) With the above version i was unable to reproduce the issue using the full tests suite, in that sense i am considering this issue to be resolved. Only issue that i was facing here was caused by the usage of gcc 14.0 instead of gcc 12.3 so i had to suppress following warning: /home/dashboard/factorio/libraries/Agui/GenericTargetable.hpp:55:18: error: storing the address of local variable ‘helper’ in ‘*_5(D)->D.195240.D.130047.D.129358.agui::GenericTargetable::agui::GenericTargetBase.agui::GenericTargetBase::next’ [-Werror=dangling-pointer=] Basically we are using local variables which are registering in some heap allocated classes temporarily but they are aware of that so in the destructor they correctly unlink themselves to avoid heap allocated objects from having pointers to deallocated local variables. This check is a false positive that does not work in our project so i had to suppress it. I think this may be a separate thing so in order to not pollute this bug report i wont provide more details unless you want more of it.
[Bug tree-optimization/111048] [14 Regression] Wrong AVX2 code on highway-1.0.6 on -O2 and above since r14-3243-ga7dba4a1c05a76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111048 prathamesh3492 at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from prathamesh3492 at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/110875] [14 Regression] Dead Code Elimination Regression since r14-2501-g285c9d042e9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110875 Aldy Hernandez changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #2 from Aldy Hernandez --- (In reply to Andrew Pinski from comment #1) > I am super confused about VRP's ranges: > We have the following that ranges that get exported and their relationships: > Global Exported: a.8_105 = [irange] int [-2, 0] > _10 = a.8_105 + -1; > Global Exported: _10 = [irange] int [-INF, -6][-3, -1][1, 2147483645] > _103 = (unsigned int) _10; > Global Exported: _103 = [irange] unsigned int [1, 2147483645][2147483648, > 4294967290][4294967294, +INF] > Simplified relational if (_103 > 1) > into if (_103 != 1) > > > Shouldn't the range of _10 just be [-3,-1] > If so _103 can't get 0 or 1 ? And then if that gets it right then the call > to foo will go away. [It looks like a caching issue of some kind. Looping Andrew.] Yes, that is indeed confusing. _10 should have a more refined range. Note that there's a dependency between a.8_105 and _10: [local count: 327784168]: # f_lsm.17_26 = PHI # a.8_105 = PHI <0(3), _10(13)> # b_lsm.19_33 = PHI # b_lsm_flag.20_53 = PHI <0(3), 1(13)> # a_lsm.21_49 = PHI <_54(D)(3), _10(13)> _9 = e.10_39 + 4294967061; _10 = a.8_105 + -1; if (_10 != -3(OVF)) goto ; [94.50%] else goto ; [5.50%] This is what I see with --param=ranger-debug=tracegori in VRP2... We first calculate a.8_105 to [-INF, -5][-2, 0][2, 2147483646]: 1140 range_of_stmt (a.8_105) at stmt a.8_105 = PHI <0(3), _10(13)> 1141 ROS dependence fill ROS dep fill (a.8_105) at stmt a.8_105 = PHI <0(3), _10(13)> ROS dep fill (_10) at stmt _10 = a.8_105 + -1; 1142 range_of_expr(a.8_105) at stmt _10 = a.8_105 + -1; TRUE : (1142) range_of_expr (a.8_105) [irange] int [-INF, -5][-2, 0][2, 2147483646] Which we later refine with SCEV: Statement _10 = a.8_105 + -1; is executed at most 2147483647 (bounded by 2147483647) + 1 times in loop 4. Loops range found for a.8_105: [irange] int [-2, 0] and calculated range :[irange] int [-INF, -6][-2, 0][2, 2147483645] TRUE : (1140) range_of_stmt (a.8_105) [irange] int [-2, 0] Global Exported: a.8_105 = [irange] int [-2, 0] I have verified that range_of_expr after this point returns [-2, 0], so we know both globally and locally this refined range. However, when we try to fold _10 later on, we use the cached value instead of recalculating with the new range for a.8_105: Folding statement: _10 = a.8_105 + -1; 872 range_of_stmt (_10) at stmt _10 = a.8_105 + -1; TRUE : (872) cached (_10) [irange] int [-INF, -6][-3, -1][1, 2147483645]
[Bug c++/111087] -Wnonnull issued for std::array of zero size when under C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111087 --- Comment #11 from Jonathan Wakely --- For GCC 10 it was arguably even worse: null.cc: In function 'bool hasTag(const char*)': null.cc:14:31: warning: null argument where non-null required (argument 1) [-Wnonnull] 14 | return result->compare(tag) == 0; | ^ This makes it look like GCC is complaining about the 'tag' argument.
[Bug c++/111087] -Wnonnull issued for std::array of zero size when under C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111087
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-08-21
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #10 from Jonathan Wakely ---
The warning in this case is idiotic:
#include
#include
#include
const std::array tags{};
bool hasTag(const char* const tag) {
const auto result = std::lower_bound(tags.begin(), tags.end(), tag);
if (result == tags.end())
return false;
if (!result)
return false;
if (result)
return result->compare(tag) == 0;
}
null.cc: In function 'bool hasTag(const char*)':
null.cc:14:12: warning: 'this' pointer is null [-Wnonnull]
14 | return result->compare(tag) == 0;
|^~
In file included from null.cc:3:
/home/jwakely/gcc/14/include/c++/14.0.0/string_view:364:7: note: in a call to
non-static member function 'constexpr int std::basic_string_view<_CharT,
_Traits>::compare(const _CharT*) const [with _CharT = char; _Traits =
std::char_traits]'
364 | compare(const _CharT* __str) const noexcept
| ^~~
Confirmed as a bug.
[Bug c/111088] New: useless 'xor eax,eax' inserted when a value is not returned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111088
Bug ID: 111088
Summary: useless 'xor eax,eax' inserted when a value is not
returned.
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: charly.poyac at gmail dot com
Target Milestone: ---
I compile this simple C code with GCC 13.2:
int foo(int *a)
{
*a += 1;
}
int foo2(int *a)
{
*a += 1;
}
and it produces the following assembly code with '-O3':
foo:
add DWORD PTR [rdi], 1
ret
foo2:
add DWORD PTR [rdi], 1
xor eax, eax
ret
see godbolt: https://godbolt.org/z/eeT63ePcr
We can see the inconsistency between the two functions with the 'xor eax,eax'
added in foo2. This does not happen if I compile with -O1.
Yes, these functions should return an integer, but they don't. However, this is
allowed by the C standard (2018 6.9.1 11/12).
[Bug tree-optimization/111048] [14 Regression] Wrong AVX2 code on highway-1.0.6 on -O2 and above since r14-3243-ga7dba4a1c05a76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111048 --- Comment #9 from CVS Commits --- The master branch has been updated by Prathamesh Kulkarni : https://gcc.gnu.org/g:649388462e9a3c2de0b90ce525de8044704cc521 commit r14-3355-g649388462e9a3c2de0b90ce525de8044704cc521 Author: Prathamesh Kulkarni Date: Mon Aug 21 15:25:08 2023 +0530 PR111048: Set arg_npatterns correctly. In valid_mask_for_fold_vec_perm_cst we set arg_npatterns always to VECTOR_CST_NPATTERNS (arg0) because of (q1 & 0) == 0: /* Ensure that the stepped sequence always selects from the same input pattern. */ unsigned arg_npatterns = ((q1 & 0) == 0) ? VECTOR_CST_NPATTERNS (arg0) : VECTOR_CST_NPATTERNS (arg1); resulting in wrong code-gen issues. The patch fixes this by changing the condition to (q1 & 1) == 0. gcc/ChangeLog: PR tree-optimization/111048 * fold-const.cc (valid_mask_for_fold_vec_perm_cst_p): Set arg_npatterns correctly. (fold_vec_perm_cst): Remove workaround and again call valid_mask_fold_vec_perm_cst_p for both VLS and VLA vectors. (test_fold_vec_perm_cst::test_nunits_min_4): Add test-case.
[Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671 --- Comment #14 from Richard Earnshaw --- (In reply to Mark Brown from comment #13) > The kernel hasn't got any problem with BTI as far as I am aware - when built > with clang we run the kernel with BTI enabled since clang does just insert a > BTI C at the start of every function, and GCC works fine so long as we don't > get any out of range jumps being generated. The issue is that we don't have > anything to insert veneers in the case where section placement puts static > functions into a distant enough part of memory to need an indirect jump but > GCC has decided to omit the landing pad. The linker has to insert the veneers.
[Bug middle-end/111082] [14 Regression] ICE in expand_fn_using_insn, at internal-fn.cc:214 (AVX512 related)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111082 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:e10cb804e658dbd1e9d58f528f3985362e4e72e7 commit r14-3354-ge10cb804e658dbd1e9d58f528f3985362e4e72e7 Author: Richard Biener Date: Mon Aug 21 11:07:18 2023 +0200 tree-optimization/111082 - bogus promoted min vectorize_slp_instance_root_stmt promotes operations with undefined overflow to unsigned arithmetic but fails to consider operations that do not overflow like MIN which it turned into MIN with wrong signedness and in the case of the PR an unsupported operation. The following rectifies this. PR tree-optimization/111082 * tree-vect-slp.cc (vectorize_slp_instance_root_stmt): Only pun operations that can overflow. * gcc.dg/pr111082.c: New testcase.
[Bug middle-end/111082] [14 Regression] ICE in expand_fn_using_insn, at internal-fn.cc:214 (AVX512 related)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111082 Richard Biener changed: What|Removed |Added Keywords||wrong-code Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 111023, which changed state. Bug 111023 Summary: missing extendv4siv4hi (and friends) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111023 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/111023] missing extendv4siv4hi (and friends)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111023 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Richard Biener --- Let's close it, we very likely have a duplicate.
[Bug c++/111069] Mangling of static structured bindings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111069 Jakub Jelinek changed: What|Removed |Added Attachment #55763|0 |1 is obsolete|| --- Comment #5 from Jakub Jelinek --- Created attachment 55769 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55769=edit gcc14-pr111069.patch Full untested patch.
[Bug middle-end/111082] [14 Regression] ICE in expand_fn_using_insn, at internal-fn.cc:214 (AVX512 related)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111082 --- Comment #5 from Richard Biener --- Interestingly we have CODE_FOR_reduc_smin_scal_v2di at vectorizable_bb_reduc_epilogue time where we check && (!reduction_fn_for_scalar_code (reduc_code, _fn) || reduc_fn == IFN_LAST || !direct_internal_fn_supported_p (reduc_fn, vectype, OPTIMIZE_FOR_BOTH))) which passes. But at that point we have a signed MIN. I have a patch.
[Bug middle-end/111082] [14 Regression] ICE in expand_fn_using_insn, at internal-fn.cc:214 (AVX512 related)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111082 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- I think that's mine.
[Bug debug/111080] [11/12/13/14 Regression] restrict qualifier causes extra debug info to happen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111080 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-08-21 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Confirmed. This is because prune_unused_types_walk marks all restrict types as necessary. There's also DW_TAG_shared_type that's not handled.
[Bug tree-optimization/111073] [13/14 regression] False-positive -Wstringop-overflow when building gdb from trunk with -D_GLIBCXX_ASSERTIONS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111073 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.3
[Bug tree-optimization/111070] [14 Regregression] ./gcc.target/tic6x/abi-align-1.c on x86_64 with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111070 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Richard Biener --- Fixed. Sorry for the breakage.
[Bug tree-optimization/111070] [14 Regregression] ./gcc.target/tic6x/abi-align-1.c on x86_64 with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111070 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:966b0a96523fb7adbf498ac71df5e033c70dc546 commit r14-3351-g966b0a96523fb7adbf498ac71df5e033c70dc546 Author: Richard Biener Date: Mon Aug 21 09:01:00 2023 +0200 tree-optimization/111070 - fix ICE with recent ifcombine fix We now got test coverage for non-SSA name bits so the following amends the SSA_NAME_OCCURS_IN_ABNORMAL_PHI checks. PR tree-optimization/111070 * tree-ssa-ifcombine.cc (ifcombine_ifandif): Check we have an SSA name before checking SSA_NAME_OCCURS_IN_ABNORMAL_PHI. * gcc.dg/pr111070.c: New testcase.
[Bug c++/111087] -Wnonnull issued for std::array of zero size when under C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111087 --- Comment #9 from Adam Badura --- Is there any option to improve the warning so that it is not generated in cases that are valid. I mean, to make it flow-dependent? How it works now? What it takes into account and how to phrase the code to avoid the false-positive?
[Bug tree-optimization/111070] [14 Regregression] ./gcc.target/tic6x/abi-align-1.c on x86_64 with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111070 --- Comment #4 from David Binderman --- Also breaks the linux kernel, so more serious than I thought: drivers/spi/spi-aspeed-smc.c:181:12: internal compiler error: tree check: expected ssa_name, have addr_expr in ifcombine_ifandif, at tree-ssa-ifcombine.cc:492
[Bug c++/111087] -Wnonnull issued for std::array of zero size when under C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111087
--- Comment #8 from Andrew Pinski ---
(In reply to Adam Badura from comment #7)
> So, the cases I described here _is_ a false-positive, however, an expected
> one. Do I understand this correctly?
> It _does not_ generate the warning. So, what prevents generating the warning
> here? How do I formulate the code to avoid the warning?
This does though:
bool foo()
{
const auto a = (class1*)nullptr;
return a != nullptr && a->method1();
}
[Bug c++/111087] -Wnonnull issued for std::array of zero size when under C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111087
--- Comment #7 from Adam Badura ---
So, the cases I described here _is_ a false-positive, however, an expected one.
Do I understand this correctly?
However, consider the code:
class class1
{
public:
bool method1() const;
};
bool foo()
{
const class1* a = nullptr;
return a != nullptr && a->method1();
}
See it also on Compiler Explorer: https://godbolt.org/z/7GKT98Y5b.
It _does not_ generate the warning. So, what prevents generating the warning
here? How do I formulate the code to avoid the warning?
[Bug tree-optimization/111002] Code generation for vectorized -(a[i] != 0) with number of elements change could be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111002 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Andrew Pinski --- Fixed.
[Bug tree-optimization/110922] `(a == b) & (a == c) & (b != c)` is not optimized to false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110922 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-08-21 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Mine.
[Bug tree-optimization/111002] Code generation for vectorized -(a[i] != 0) with number of elements change could be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111002 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:47b833a9abe19d862a773d20dd6f961dcf811a11 commit r14-3350-g47b833a9abe19d862a773d20dd6f961dcf811a11 Author: Andrew Pinski Date: Sun Aug 20 17:22:27 2023 -0700 MATCH: [PR111002] Sink view_convert for vec_cond Like convert we can sink view_convert into vec_cond but we can only do it if the element types are nop_conversions. This is to allow conversion between signed and unsigned types only. Rather than between integer and float types which mess up the vec_cond so that isel does not understand `a?-1:0` is still that. OK? Bootstrapped and tested on x86_64-linux-gnu and aarch64-linux-gnu. PR tree-optimization/111002 gcc/ChangeLog: * match.pd (view_convert(vec_cond(a,b,c))): New pattern. gcc/testsuite/ChangeLog: * gcc.target/aarch64/sve/cond_convert_8.c: New test.
[Bug c++/111087] -Wnonnull issued for std::array of zero size when under C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111087 --- Comment #6 from Andrew Pinski --- Because the warning is not flow dependent. So even things like: const class1 *a = nullptr; a != nullptr && a->method1(); Will also warn.
[Bug c++/111087] -Wnonnull issued for std::array of zero size when under C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111087
--- Comment #5 from Adam Badura ---
(In reply to Andrew Pinski from comment #3)
> The warning is correct as tags.end() and tags.begin() will always be a
> nullptr for std::array
Yes. But what does it change?
`std::lower_bound` gets an empty range (begin == end) and hence will return the
`end` value. Then we check `result != tags.end()` which should cut off since it
will be false and hence we will never reach the place where we use
`result->`...
Let me add, that the issue is not about short-circuiting since it also shows in
the elaborate form:
if (result != tags.end())
{
return result->compare(tag) == 0;
}
else
{
return false;
}
[Bug c++/111087] -Wnonnull issued for std::array of zero size when under C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111087 --- Comment #4 from Andrew Pinski --- just since GCC decides to act const in some cases like constexpr especially with -std=c++20, you get the warning.
[Bug target/111023] missing extendv4siv4hi (and friends)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111023 Uroš Bizjak changed: What|Removed |Added Assignee|ubizjak at gmail dot com |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW CC||ubizjak at gmail dot com --- Comment #7 from Uroš Bizjak --- The target part is now implemented (even for SSE2). Should we keep this PR open as a tree-vectorizer enhancement?
