[Bug testsuite/108985] new test case gcc.dg/vect/pr108950.c from r13-6384-ge3837b6f6c28a1 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108985 --- Comment #1 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:a2926653ebbc88e8bba335563fa86b44651598d6 commit r13-6406-ga2926653ebbc88e8bba335563fa86b44651598d6 Author: Richard Biener Date: Thu Mar 2 09:03:37 2023 +0100 testsuite/108985 - missing vect_simd_clones target requirement on test Added. PR testsuite/108985 * gcc.dg/vect/pr108950.c: Require vect_simd_clones.
[Bug testsuite/108985] new test case gcc.dg/vect/pr108950.c from r13-6384-ge3837b6f6c28a1 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108985 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Should be fixed.
[Bug c++/105839] internal compiler error: in tsubst_omp_for_iterator with openmp and structured bindings in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105839 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f0ef740d54f47ff614eb02e13e8f4cb11dfbb140 commit r13-6407-gf0ef740d54f47ff614eb02e13e8f4cb11dfbb140 Author: Jakub Jelinek Date: Thu Mar 2 09:02:12 2023 +0100 openmp: Fix up error recovery for invalid structured bindings in OpenMP range for loops [PR105839] The PR108503 temporary DECL_HAS_VALUE_EXPR_P clearing code can ICE during recovery, because cp_finish_decomp when it detects errors and reports them clears DECL_HAS_VALUE_EXPR_P, clears DECL_VALUE_EXPR and sets TREE_TYPE of the structured binding vars to error_mark_node. The PR108503 code had an assertion that DECL_HAS_VALUE_EXPR_P is set so that it can clear it and restore later. The following patch allows DECL_HAS_VALUE_EXPR_P to be unset if type is error_mark_node and doesn't set it again in that case. 2023-03-02 Jakub Jelinek PR c++/105839 * parser.cc (cp_convert_omp_range_for): Allow in assert decomp_first_name without DECL_HAS_VALUE_EXPR_P if it has error_mark_node type. (cp_finish_omp_range_for): Don't set DECL_HAS_VALUE_EXPR_P back on decls which have error_mark_node type. * g++.dg/gomp/pr105839-1.C: New test. * g++.dg/gomp/pr105839-2.C: New test.
[Bug c++/108934] [12/13 Regression] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cc88366a80e35b3e53141f49d3071010ff3c2ef8 commit r13-6408-gcc88366a80e35b3e53141f49d3071010ff3c2ef8 Author: Jakub Jelinek Date: Thu Mar 2 09:27:40 2023 +0100 fold-const: Ignore padding bits in native_interpret_expr REAL_CST reverse verification [PR108934] In the following testcase we try to std::bit_cast a (pair of) integral value(s) which has some non-zero bits in the place of x86 long double (for 64-bit 16 byte type with 10 bytes actually loaded/stored by hw, for 32-bit 12 byte) and starting with my PR104522 change we reject that as native_interpret_expr fails on it. The PR104522 change extends what has been done before for MODE_COMPOSITE_P (but those don't have any padding bits) to all floating point types, because e.g. the exact x86 long double has various bit combinations we don't support, like pseudo-(denormals,infinities,NaNs) or unnormals. The HW handles some of those as exceptional cases and others similarly to the non-pseudo ones. But for the padding bits it actually doesn't load/store those bits at all, it loads/stores 10 bytes. So, I think we should exempt the padding bits from the reverse comparison (the native_encode_expr bits for the padding will be all zeros), which the following patch does. For bit_cast it is similar to e.g. ignoring padding bits if the destination is a structure which has padding bits in there. The change changed auto-init-4.c to how it has been behaving before the PR105259 change, where some more VCEs can be now done. 2023-03-02 Jakub Jelinek PR c++/108934 * fold-const.cc (native_interpret_expr) : Before memcmp comparison copy the bytes from ptr to a temporary buffer and clearing padding bits in there. * gcc.target/i386/auto-init-4.c: Revert PR105259 change. * g++.target/i386/pr108934.C: New test.
[Bug c++/108934] [12 Regression] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934 Jakub Jelinek changed: What|Removed |Added Summary|[12/13 Regression] |[12 Regression] |bit_cast'ing to long double |bit_cast'ing to long double |errors out with "the|errors out with "the |argument cannot be |argument cannot be |interpreted" since gcc-12 |interpreted" since gcc-12 --- Comment #8 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/108165] -Wdangling-reference false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165 --- Comment #12 from Martin Liška --- (In reply to Marek Polacek from comment #11) > No, because as Comment 9 says, there's no good way to suppress the warning. > I'm currently leaning towards closing the BZ and suggesting adding a #pragma > to disable the warning. Another solution would be the removal of the warning from -Wall?
[Bug testsuite/108973] [13 Regression] Sufficiently narrow terminal window causes selftest failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108973
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Wrapping tests individually for each possible $COLUMNS case would be a
maintainance nightmare, e.g. trying to make it work with COLUNMS in [30, 41]
inclusive means:
--- gcc/diagnostic-show-locus.cc.jj 2023-01-02 09:32:39.783033909 +0100
+++ gcc/diagnostic-show-locus.cc2023-03-02 09:45:42.432403239 +0100
@@ -4436,7 +4436,7 @@ test_add_location_if_nearby (const line_
/* Test of add_location_if_nearby on the same line as the
primary location. */
- {
+ if (get_terminal_width () > 41) {
const location_t missing_close_brace_1_39
= linemap_position_for_line_and_column (line_table, ord_map, 1, 39);
const location_t matching_open_brace_1_18
@@ -4501,7 +4501,7 @@ test_diagnostic_show_locus_fixit_lines (
/* A pair of tests for modernizing the initializers to C99-style. */
/* The one-liner case (line 2). */
- {
+ if (get_terminal_width () > 31) {
test_diagnostic_context dc;
const location_t x
= linemap_position_for_line_and_column (line_table, ord_map, 2, 24);
@@ -4521,7 +4521,7 @@ test_diagnostic_show_locus_fixit_lines (
verify that insertion fixit on line 3 is still printed (and that
span starts are printed due to the gap between the span at line 3
and that at line 6). */
- {
+ if (get_terminal_width () > 34) {
test_diagnostic_context dc;
const location_t y
= linemap_position_for_line_and_column (line_table, ord_map, 3, 24);
@@ -4543,7 +4543,7 @@ test_diagnostic_show_locus_fixit_lines (
/* As above, but verify the behavior of multiple line spans
with line-numbering enabled. */
- {
+ if (get_terminal_width () > 40) {
const location_t y
= linemap_position_for_line_and_column (line_table, ord_map, 3, 24);
const location_t colon
@@ -4756,7 +4756,7 @@ test_overlapped_fixit_printing (const li
but for which the *printing* may need consolidation. */
/* Example where 3 fix-it hints are printed as one. */
- {
+ if (get_terminal_width () > 30) {
test_diagnostic_context dc;
rich_location richloc (line_table, expr);
richloc.add_fixit_replace (open_paren, "const_cast<");
@@ -4826,7 +4826,7 @@ test_overlapped_fixit_printing (const li
}
/* Example where two are consolidated during printing. */
- {
+ if (get_terminal_width () > 30) {
test_diagnostic_context dc;
rich_location richloc (line_table, expr);
richloc.add_fixit_replace (open_paren, "CAST (");
@@ -4843,7 +4843,7 @@ test_overlapped_fixit_printing (const li
}
/* Example where none are consolidated during printing. */
- {
+ if (get_terminal_width () > 30) {
test_diagnostic_context dc;
rich_location richloc (line_table, expr);
richloc.add_fixit_replace (open_paren, "CST (");
@@ -4860,7 +4860,7 @@ test_overlapped_fixit_printing (const li
}
/* Example of deletion fix-it hints. */
- {
+ if (get_terminal_width () > 30) {
test_diagnostic_context dc;
rich_location richloc (line_table, expr);
richloc.add_fixit_insert_before (open_paren, "(bar *)");
@@ -4880,7 +4880,7 @@ test_overlapped_fixit_printing (const li
}
/* Example of deletion fix-it hints that would overlap. */
- {
+ if (get_terminal_width () > 30) {
test_diagnostic_context dc;
rich_location richloc (line_table, expr);
richloc.add_fixit_insert_before (open_paren, "(longer *)");
@@ -4900,7 +4900,7 @@ test_overlapped_fixit_printing (const li
}
/* Example of insertion fix-it hints that would overlap. */
- {
+ if (get_terminal_width () > 30) {
test_diagnostic_context dc;
rich_location richloc (line_table, expr);
richloc.add_fixit_insert_before (open_paren, "LONGER THAN THE CAST");
@@ -4967,7 +4967,7 @@ test_overlapped_fixit_printing_utf8 (con
but for which the *printing* may need consolidation. */
/* Example where 3 fix-it hints are printed as one. */
- {
+ if (get_terminal_width () > 30) {
test_diagnostic_context dc;
rich_location richloc (line_table, expr);
richloc.add_fixit_replace (open_paren, "const_cast<");
@@ -5043,7 +5043,7 @@ test_overlapped_fixit_printing_utf8 (con
}
/* Example where two are consolidated during printing. */
- {
+ if (get_terminal_width () > 30) {
test_diagnostic_context dc;
rich_location richloc (line_table, expr);
richloc.add_fixit_replace (open_paren, "CAST (");
@@ -5063,7 +5063,7 @@ test_overlapped_fixit_printing_utf8 (con
}
/* Example where none are consolidated during printing. */
- {
+ if (get_terminal_width () > 30) {
test_diagnostic_context dc;
rich_location richloc (line_table, expr);
richloc.add_fixit_replace (op
[Bug testsuite/108973] [13 Regression] Sufficiently narrow terminal window causes selftest failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108973 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 54568 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54568&action=edit gcc13-pr108973.patch So, I think we should just make sure test_diagnostic_context has reasonable caret_max_width...
[Bug tree-optimization/108988] gimple_fold_builtin_fputs doesn't preserve gimple_builtin_call_types_compatible_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 54569 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54569&action=edit gcc13-pr108988.patch Untested fix. In this function len is already checked to be INTEGER_CST, so just fold_convert is sufficient. Went through the whole gimple-fold.cc and all other values computed by c_strlen or get_maxval_strlen etc. are properly folded to size_type_node when needed.
[Bug driver/108865] gcc on Windows fails with Unicode path to source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 --- Comment #15 from Costas Argyris --- Sounds like I am hitting a separate existing limitation that has nothing to do with this bug. Do we need a new bug report for that one then? FWIW, gcc/config.host wasn't doing anything with host_extra_objs before this patch (it was simply empty), so it makes sense that this issue was hidden until now. host_extra_objs is being used here https://github.com/gcc-mirror/gcc/blob/master/gcc/configure#L12796 https://github.com/gcc-mirror/gcc/blob/master/gcc/configure.ac#L1843 What kind of work would be required to fix it?Can we get away with simply creating a dummy reference that would force the linker to include it?
[Bug libstdc++/108974] std::barrier except completion function which is not manifestly noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108974 --- Comment #5 from Jonathan Wakely --- (In reply to Jiang An from comment #3) > I've mailed to LWG Chair for this... Thanks, the new issue will be opened soon.
[Bug c/108986] Incorrect warning for [static] array parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986 Richard Biener changed: What|Removed |Added Known to fail||12.2.0, 13.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-03-02 Keywords||diagnostic --- Comment #2 from Richard Biener --- Confirmed.
[Bug target/108987] [13 Regression] RISC-V: shiftadd cost model bug needlessly preferring syth_multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108987 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target||riscv Target Milestone|--- |13.0
[Bug tree-optimization/108430] [13 Regression] Wrong code with -msve-vector-bits=512 since r13-707-g68e0063397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108430
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:2a8ce4b52f5892a10a02b94d7be689e59a444ff6
commit r13-6409-g2a8ce4b52f5892a10a02b94d7be689e59a444ff6
Author: Richard Sandiford
Date: Thu Mar 2 10:30:20 2023 +
vect: Fix voluntarily-masked negative conditionals [PR108430]
vectorizable_condition checks whether a COND_EXPR condition is used
elsewhere with a loop mask. If so, it applies the loop mask to the
COND_EXPR too, to reduce the number of live masks and to increase the
chance of combining the AND with the comparison.
There is also code to do this for inverted conditions. E.g. if
we have a < b ? c : d and something else is conditional on !(a < b)
(such as a load in d), we use !(a < b) ? d : c and apply the loop
mask to !(a < b).
This inversion relied on the function's bitop1/bitop2 mechanism.
However, that mechanism is skipped if the condition is split out of
the COND_EXPR as a separate statement. This meant that we could end
up using the inverse of the intended condition.
There is a separate way of negating the condition when a mask
is being applied (which is also used for EXTRACT_LAST reductions).
This patch uses that instead.
As well as the testcase, this fixes aarch64/sve/vcond_{4,17}_run.c.
gcc/
PR tree-optimization/108430
* tree-vect-stmts.cc (vectorizable_condition): Fix handling
of inverted condition.
gcc/testsuite/
PR tree-optimization/108430
* gcc.target/aarch64/sve/pr108430.c: New test.
[Bug target/108603] [12/13 Regression] ICE in output_operand_lossage with SVE and ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108603 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:b09dc74801cf4e19bdf5fcd18a5cd53fc9e9ca9a commit r13-6410-gb09dc74801cf4e19bdf5fcd18a5cd53fc9e9ca9a Author: Richard Sandiford Date: Thu Mar 2 10:30:21 2023 + Avoid creating (const (reg ...)) [PR108603] convert_memory_address_addr_space_1 has two modes: one in which it tries to create a self-contained RTL expression (which might fail) and one in which it can emit new instructions where necessary. When handling a CONST, the function recurses into the CONST's operand and then constifies the result. But that's only valid if the result is still a self-contained expression. If new instructions have been emitted, the expression will refer to the (non-constant) results of those instructions. In the PR, this caused us to emit a nonsensical (const (reg ...)) REG_EQUAL note. gcc/ PR tree-optimization/108603 * explow.cc (convert_memory_address_addr_space_1): Only wrap the result of a recursive call in a CONST if no instructions were emitted. gcc/testsuite/ PR tree-optimization/108603 * gcc.target/aarch64/sve/pr108603.c: New test.
[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846 --- Comment #20 from Giuseppe D'Angelo --- Thanks for the patch! Should ranges_algobase.h also be similarly changed? There's a memmove in its copy/move code as well: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/bits/ranges_algobase.h;hb=HEAD#l263
[Bug tree-optimization/108430] [13 Regression] Wrong code with -msve-vector-bits=512 since r13-707-g68e0063397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108430 --- Comment #4 from rsandifo at gcc dot gnu.org --- Fixed on trunk, but the underlying bug is present in GCC 12 too.
[Bug libstdc++/108976] codecvt for Unicode allows surrogate code points
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108976 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-03-02 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Thanks for the testcase, I'd been meaning to look into exactly this issue.
[Bug libstdc++/108976] codecvt for Unicode allows surrogate code points
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108976 --- Comment #2 from Dimitrij Mijoski --- (In reply to Dimitrij Mijoski from comment #0) > Those that read from UCS-2 seem to me like they properly report the error. > Reading from UTF-16 can not have this bug by definition. From what I > checked, the functions for reading UTF-16 properly treat unpaired surrogate > code units as error. Seems like the conversion from UCS-2 to UTF-16BE/LE is also affected. This conversions is called via codecvt_utf16::out(). See line https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/src/c%2B%2B11/codecvt.cc;h=02f05752de84139a7eb7c3d40946b61f4c0334cf;hb=HEAD#l656 it only checks for high surrogate but should also check for low.
[Bug libstdc++/108976] codecvt for Unicode allows surrogate code points
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108976
--- Comment #3 from Jonathan Wakely ---
I have some new code for handling UTF-8 for std::print, and using that code
your relaxed u8str gets converted to 12 U+FFFD code points when printed to a
terminal, which I think is correct.
#include
int main()
{
char u8str[] = "\uC800\uCBFF\uCC00\uCFFF";
std::println("valid UTF-8: {}", u8str);
u8str[0] = u8str[3] = u8str[6] = u8str[9] = 0xED; // turn the C into D.
// now the string is D800, DBFF, DC00 and DFFF encoded in relaxed UTF-8
// that allows surrogate code points.
std::vprint_nonunicode("invalid UTF-8 printed raw: {}\n",
std::make_format_args(u8str));
std::println("invalid UTF-8 printed safely: {}", u8str);
}
$ g++ -std=c++23 surr.cc && ./a.out && ./a.out | xxd
valid UTF-8: 저쯿찀쿿
invalid UTF-8 printed raw:
invalid UTF-8 printed safely:
: 7661 6c69 6420 5554 462d 383a 20ec a080 valid UTF-8: ...
0010: ecaf bfec b080 ecbf bf0a 696e 7661 6c69 ..invali
0020: 6420 5554 462d 3820 7072 696e 7465 6420 d UTF-8 printed
0030: 7261 773a 20ed a080 edaf bfed b080 edbf raw: ...
0040: bf0a 696e 7661 6c69 6420 5554 462d 3820 ..invalid UTF-8
0050: 7072 696e 7465 6420 7361 6665 6c79 3a20 printed safely:
0060: efbf bdef bfbd efbf bdef bfbd efbf bdef
0070: bfbd efbf bdef bfbd efbf bdef bfbd efbf
0080: bdef bfbd 0a .
The new code is also much faster, so I'm thinking of rewriting some of the
src/c++11/codecvt.cc facets to use it. But that's a longer term project, we
should fix this bug first.
[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846 --- Comment #21 from Jonathan Wakely --- Indeed it should.
[Bug target/108738] compile-time and memory-hog in mdreorg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108738 --- Comment #7 from Richard Biener --- So it's now better than before but still quadratic. Finding a strathegic place to limit the search with some --param might be a solution, but there's no easy point to hook that into. You'd not want to disable the whole pass but terminate the greedy search and axe the candidates sofar processed (to not run into the same ones again), which might then result in "odd" STV decisions if the remains are picked up. To avoid this maybe maintain a "too big" set of candidates and if a further greedy search lands at a insn in that set, axe that search as well. Note it's not the size of the set but the complexity of the search that needs limiting, so count the number of ref visits through analyze_register_chain for an invocation of scalar_chain::build and limit that to some --param. I'm trying to prototype that.
[Bug tree-optimization/108979] [13 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.cc:248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108979 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #3 from rsandifo at gcc dot gnu.org --- Testing a patch.
[Bug target/106770] powerpc64le: Unnecessary xxpermdi before mfvsrd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106770 --- Comment #10 from Surya Kumari Jangala --- The swap pass analyzes vector computations and removes unnecessary doubleword swaps (xxswapdi instructions). The swap pass first constructs webs and removes swap instructions if possible. If the web contains operations that are sensitive to element order, such as an extract, then such instructions should be modified. For example, the lane is changed on an extract operation. As we saw in comment 9, the swap pass has incorrectly changed the lane of the vec_extract. The swap pass modifies the extract operation even though there are no swap instructions in the web. This is a bug in the swap pass. It should modify only those operations which are present in webs having swap instructions.
[Bug c/108989] New: Two small almost identical programs give different results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108989
Bug ID: 108989
Summary: Two small almost identical programs give different
results
Product: gcc
Version: og10 (devel/omp/gcc-10)
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: d.j.allerton at sheffield dot ac.uk
Target Milestone: ---
Created attachment 54570
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54570&action=edit
A small program doing 2D geometry. No math calls, just addition, subtraction,
mutiplication and division of floats.
In a small program, the following lines give different reults:
x = x0 + ((r1 * r1 - r2 * r2 + x2 * x2) / (2.0 * x2));
y = y0 + ((r1 * r1 - r3 * r3 + x3 * x3 + y3 * y3 - 2.0 * x3 * x) / (2.0 *
y3));
printf("x=%f y=%f\n", x, y);
and
x = ((r1 * r1 - r2 * r2 + x2 * x2) / (2.0 * x2));
y = ((r1 * r1 - r3 * r3 + x3 * x3 + y3 * y3 - 2.0 * x3 * x) / (2.0 * y3));
printf("x=%f y=%f\n", x + x0, y + y0);
the first example gives: x=-0.00 y=33.070801 (which is wrong)
the second example gives: x=0.00 y=7.315198 (which is correct)
The only difference is the addition of x0 and y0 in the sets of expressions.
The two programs are attached. They don't use any libraries other than stdlib.h
and stdio.h. I use gcc version 10.2.0 on msys2 on a PC and version 10.2.1 on a
Raspberry Pi 4B and get the same errors with both compilers. A colleague gets
the same errors with version 12.1.0 on a PC.
[Bug rtl-optimization/108681] [12 Regression] gcc hangs compiling opencv/channels_combine.cpp for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108681 tt_1 changed: What|Removed |Added CC||herrtimson at yahoo dot de --- Comment #13 from tt_1 --- Hey everyone, has this been fixed in gcc-12 branch as well? Summary states it is a gcc-12 regression, fix went into gcc-13 and 12.2.1 is known to work. Is this summary correct, or does the fix still need to be backported to the gcc-12 branch?
[Bug rtl-optimization/108681] [12 Regression] gcc hangs compiling opencv/channels_combine.cpp for aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108681 rsandifo at gcc dot gnu.org changed: What|Removed |Added Known to work|12.2.1 | --- Comment #14 from rsandifo at gcc dot gnu.org --- No, it's not in GCC 12 branch yet. I'm leaving it for a few weeks to see if there's any fallout on trunk before backporting. I've removed the misleading "Known to work", thanks for the heads up.
[Bug target/106770] powerpc64le: Unnecessary xxpermdi before mfvsrd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106770 --- Comment #11 from Segher Boessenkool --- (In reply to Jens Seifert from comment #6) > The left part of VSX registers overlaps with floating point registers, that > is why no register xxpermdi is required and mfvsrd can access all (left) > parts of VSX registers directly. The mfvsrd instruction was invented before ELFv2 (at the same time as mfvsrwz). Everything in common use was big-endian then. The insns to move GPR->VSR that initially existed were mtvstrd and mtvsrw[az], all of which write to dword 0 of the target VSR. Dword 0 of vector regs is where 64-bit entities in vector regs are stored in the ABIs, sure, and that corresponds to the FPRs in the ISA. mtvsrdd and mtvsrws were added in ISA 3.0 (p9), together with mfvsrld, to make little-endian work better with little-endian ELFv2. > The xxpermdi x,y,y,3 indicates to me that gcc prefers right part of register > which might also cause the xxpermdi at the beginning. And with -mbig you get ,2 here. It is accidental. > At the end the mystery > is why gcc adds 3 xxpermdi to the code. As I said, this is constructed during expand, to make correct code. That is all that expand should do: make correct (and well-optimisable, "open structured", easy to transform, code). We should be able to optimise this to something better in later passes that *are* supposed to make faster code. Like the p8 swaps pass, which mostly zaps unnecessary pairs of swaps, or the swiss army bazooka combine, or even many earlier passes if such an xxpermdi insn is truly superfluous. It usually is not, we are dealing with the full 128-bit VSRs there, there is no way of saying we do not care about part of the register contents. Making infra for that is big work. We can make things easier by expressing things as 64 bit earlier. We can (and should) also investigate why the mfvsrd is not combined (as in, what the instruction combiner pass does) with the xxpermdi. There are many things not quite perfect here.
[Bug c/108989] Two small almost identical programs give different results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108989 Andreas Schwab changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andreas Schwab --- x is used to compute y.
[Bug tree-optimization/97956] [11 Regression] ICE in build2, at tree.c:4872 since r11-2709-g866626efd749ed3e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97956 --- Comment #6 from CVS Commits --- The master branch has been updated by Jonathan Yong : https://gcc.gnu.org/g:62a8d31ecc07041af4a81353c2d57d9845c4b771 commit r13-6414-g62a8d31ecc07041af4a81353c2d57d9845c4b771 Author: Jonathan Yong <10wa...@gmail.com> Date: Mon Feb 27 10:02:32 2023 + gcc.dg/memchr-3.c: Account for LLP64 warnings gcc/testsuite/ChangeLog: PR middle-end/97956 * gcc.dg/memchr-3.c (memchr): Account for LLP64 warnings. Signed-off-by: Jonathan Yong <10wa...@gmail.com>
[Bug middle-end/108990] New: Too restrictive precision check in fold and simplify pattern for PR70920
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108990
Bug ID: 108990
Summary: Too restrictive precision check in fold and simplify
pattern for PR70920
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
While experimenting with a new gimple pass we noticed that pr70920.c is
sensitive on order of substitutions made. If 0 is propagated first into if
stmt, match and simplify fails to simplify the conditional since it compares
pointer type 0 with integer converted to pointer type.
TYPE_PRECISION of int is 32.
(for cmp (ne eq)
(simplify
(cmp (convert @0) INTEGER_CST@1)
(if (((POINTER_TYPE_P (TREE_TYPE (@0))
&& !FUNC_OR_METHOD_TYPE_P (TREE_TYPE (TREE_TYPE (@0)))
&& INTEGRAL_TYPE_P (TREE_TYPE (@1))
/* Don't perform this optimization in GENERIC if @0 has reference
type when sanitizing. See PR101210. */
&& !(GENERIC
&& TREE_CODE (TREE_TYPE (@0)) == REFERENCE_TYPE
&& (flag_sanitize & (SANITIZE_NULL | SANITIZE_ALIGNMENT
|| (INTEGRAL_TYPE_P (TREE_TYPE (@0))
&& POINTER_TYPE_P (TREE_TYPE (@1))
&& !FUNC_OR_METHOD_TYPE_P (TREE_TYPE (TREE_TYPE (@1)
&& TYPE_PRECISION (TREE_TYPE (@0)) == TYPE_PRECISION (TREE_TYPE (@1)))
(cmp @0 (convert @1)
So last conditional is false (32 and 64)
In this adjusted testcase:
#include
void f1();
void f2();
void
foo (int a)
{
int *b = (int *)a;
if (b == (void *)0)
{
f1 ();
}
}
the unnecessary cast survives to forwprop while it chould be caught by cpp1
[Bug tree-optimization/108953] inefficient codegen for trivial equality
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108953
--- Comment #3 from Jakub Jelinek ---
BTW, I've tried:
struct A
{
unsigned char a, b, c, d;
unsigned short e, f;
int g;
bool operator== (A const &) const = default;
};
struct B
{
unsigned char b;
bool operator== (B const &) const = default;
};
struct C
{
unsigned char a, b, c;
B d;
unsigned short e, f;
int g;
bool operator== (C const &) const = default;
};
struct D
{
unsigned char b;
bool operator== (D const &x) const { return b == x.b; }
};
struct E
{
unsigned char a, b, c;
D d;
unsigned short e, f;
int g;
bool operator== (E const &) const = default;
};
struct F
{
unsigned char a, b, c, d;
unsigned short e, f;
int g;
bool operator== (F const &x) const {
if (a != x.a) return false;
if (b != x.b) return false;
if (c != x.c) return false;
if (d != x.d) return false;
if (e != x.e) return false;
if (f != x.f) return false;
return g == x.a;
}
};
struct G
{
unsigned char a, b, c, d;
unsigned short e, f;
float g;
bool operator== (G const &) const = default;
};
bool
foo (A const &lhs, A const &rhs)
{
return lhs == rhs;
}
bool
bar (C const &lhs, C const &rhs)
{
return lhs == rhs;
}
bool
baz (E const &lhs, E const &rhs)
{
return lhs == rhs;
}
bool
qux (F const &lhs, F const &rhs)
{
return lhs == rhs;
}
bool
corge (G const &lhs, G const &rhs)
{
return lhs == rhs;
}
to see what clang trunk does and they optimize this way only the defaulted
bool A::operator== (A const &) const, nothing else, so it clearly isn't a late
pattern matching. Probably just they notice that the structure only contains
integral fields
and in that case emit memcmp for the portions without padding bits if certain
conditions are met (seems two consecutive char fields are vectorized, but 3
result in memcmp).
But certainly even the nested struct with also defaulted operator== isn't
optimized that way at all, even the unaffected consecutive parts there.
Just in case we'd like to do this as a late pattern matching optimization and
in the C++ FE.
Note, I wonder if reassoc wouldn't be the right spot instead of store-merging.
[Bug sanitizer/108963] ASAN produces wrong line number in the report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108963 Martin Liška changed: What|Removed |Added Last reconfirmed||2023-03-02 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=108023 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- Yes, I can see it's very similar to the other problem as I can see a LIM happening in the output: [local count: 955630224]: d__lsm.8_9 = MEM[(int *)[pr108963.c:13:3] &d + 4B]; _18 = c.3_12 + 1; ivtmp.12_23 = (unsigned char) _18; [local count: 8687547547]: # d__lsm.8_5 = PHI <[pr108963.c:8:14] _4(4), d__lsm.8_9(3)> # ivtmp.12_3 = PHI [pr108963.c:8:14] _4 = d__lsm.8_5 | 2; [pr108963.c:7:12 discrim 1] ivtmp.12_17 = ivtmp.12_3 + 1; [pr108963.c:7:12 discrim 1] if (ivtmp.12_17 != 3) goto ; [89.00%] else goto ; [11.00%]
[Bug testsuite/108973] [13 Regression] Sufficiently narrow terminal window causes selftest failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108973 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #5 from Martin Liška --- What a funny selftest failure!
[Bug c++/108972] ICE: tree check: expected tree that contains 'decl common' structure, have 'error_mark' in compare_lambda_template_head, at cp/lambda.cc:1551 since r13-3601-g2b0e81d5cc2f7e1d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108972 Martin Liška changed: What|Removed |Added CC||nathan at gcc dot gnu.org Summary|ICE: tree check: expected |ICE: tree check: expected |tree that contains 'decl|tree that contains 'decl |common' structure, have |common' structure, have |'error_mark' in |'error_mark' in |compare_lambda_template_hea |compare_lambda_template_hea |d, at cp/lambda.cc:1551 |d, at cp/lambda.cc:1551 ||since ||r13-3601-g2b0e81d5cc2f7e1d --- Comment #2 from Martin Liška --- Likely started with r13-3601-g2b0e81d5cc2f7e1d.
[Bug c/108986] [11/12/13 Regression] Incorrect warning for [static] array parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |12.3 Summary|Incorrect warning for |[11/12/13 Regression] |[static] array parameter|Incorrect warning for ||[static] array parameter CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- One warning with the bogus [static 28] appeared with -O2 -Wall in r12-6606-g9d6a0f388eb048f8d87f With -O0 -Wall we started warning once with correct [static 7] in r11-3305-gbaad4c48a85a354d2bf1 and the bogus [static 28] first appeared in r11-3540-g873f8c1e6df94a9dcbfbe69 and two warnings starting with r12-6606.
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #7 from Martin Uecker ---
An attribute is certainly simpler and should be easy to add.
I proposed similar extension for C23 and there was some interest,
but I did not have time to follow up.
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2660.pdf
Sizeof is not a constant expression in ISO C for a VLA and it is not a constant
expression if the struct contains a VLA (GNU extension). So this is already
the case and nothing would need to change. It would also potentially avoid
mistakes when computing the size of such a struct. But the rules for
initialization are not so clear.
I do not think it is a good idea to differentiate between file scope structs
and others. This would be confusing.
Considering that the GNU extensions is rarely used, one could consider
redefining the meaning of
int n = 1;
struct {
int n;
char buf[n];
};
so that the 'n' refers to the member. Or we add a new syntax similar to
designators (which intuitively makes sense to me).
[Bug c++/106259] [10/11/12/13 Regression] ICE in diag_mismatched_tags, at cp/parser.cc:33896
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106259
--- Comment #6 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:71afd0628419c5d670701cb35bc9860380c7d9fb
commit r13-6417-g71afd0628419c5d670701cb35bc9860380c7d9fb
Author: Marek Polacek
Date: Wed Mar 1 14:28:46 2023 -0500
c++: ICE with -Wmismatched-tags and member template [PR106259]
-Wmismatched-tags warns about the (harmless) struct/class mismatch.
For, e.g.,
template struct A { };
class A a;
it works by adding A to the class2loc hash table while parsing the
class-head and then, while parsing the elaborate type-specifier, we
add A. At the end of c_parse_file we go through the table and
warn about the class-key mismatches. In this PR we crash though; we
have
template struct A {
template struct W { };
};
struct A::W w; // #1
where while parsing A and #1 we've stashed
A
A::W
A::W
into class2loc. Then in class_decl_loc_t::diag_mismatched_tags TYPE
is A::W, and specialization_of gets us A::W, which
is not in class2loc, so we crash on gcc_assert (cdlguide). But it's
OK not to have found A::W, we should just look one "level" up,
that is, A::W.
It's important to handle class specializations, so e.g.
template<>
struct A {
template
class W { };
};
where W's class-key is different than in the primary template above,
so we should warn depending on whether we're looking into A
or into a different instantiation.
PR c++/106259
gcc/cp/ChangeLog:
* parser.cc (class_decl_loc_t::diag_mismatched_tags): If the first
lookup of SPEC didn't find anything, try to look for
most_general_template.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wmismatched-tags-11.C: New test.
[Bug c++/106259] [10/11/12 Regression] ICE in diag_mismatched_tags, at cp/parser.cc:33896
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106259 Marek Polacek changed: What|Removed |Added Summary|[10/11/12/13 Regression]|[10/11/12 Regression] ICE |ICE in |in diag_mismatched_tags, at |diag_mismatched_tags, at|cp/parser.cc:33896 |cp/parser.cc:33896 | --- Comment #7 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/108542] [13 Regression] ICE in instantiate_type, at cp/class.cc:8833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108542 Marek Polacek changed: What|Removed |Added Priority|P1 |P2 CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Invalid code -> downgrading to P2.
[Bug c++/108165] -Wdangling-reference false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108165 --- Comment #13 from Marek Polacek --- I would really not like to do that, the false positives rate is pretty low.
[Bug tree-optimization/108979] [13 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.cc:248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108979 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:076d309e36c682176e9f85dc8593e6f2c9e6e75f commit r13-6418-g076d309e36c682176e9f85dc8593e6f2c9e6e75f Author: Richard Sandiford Date: Thu Mar 2 16:39:50 2023 + vect: Don't apply masks to operations on invariants [PR108979] The loop body in the testcase contains an operation on invariants. SLP detects this and can hoist/schedule the operation outside of the loop. However, after the fix for PR96373, we would try to apply a loop mask to this operation, even though the mask is defined in the loop. The patch does what Richi suggested in the PR: suppress the masking for externs and constants. gcc/ PR tree-optimization/108979 * tree-vect-stmts.cc (vectorizable_operation): Don't mask operations on invariants. gcc/testsuite/ PR tree-optimization/108979 * gfortran.dg/vect/pr108979.f90: New test.
[Bug tree-optimization/108979] [13 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.cc:248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108979 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from rsandifo at gcc dot gnu.org --- Fixed. I'll fold this into the backport for PR96373.
[Bug target/108315] -mcpu=power10 changes ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108315 --- Comment #10 from Alexander Monakov --- (In reply to Rui Ueyama from comment #9) > I'm the maintainer of the mold linker. I didn't implement that POWER10 ABI > because I didn't have an access to a POWER10 machine and therefore couldn't > verify the correctness of my implementation. Thanks for the info. It might be better to explicitly diagnose the '.localentry 1' case and error out instead of producing an executable that will continue to run with wrong r2 after the mislinked call returns.
[Bug libstdc++/62196] running time segment fault with valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62196 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #2 from Jonathan Wakely --- (In reply to baoshan from comment #0) > x[vmask] = vm6; This program has a bug here. The statement above will assign the 6 elements of vm6 to the elements of x selected by the mask. But the mask only has 3 true elements. You cannot assign 6 elements from vm6 to 3 elements of x.
[Bug testsuite/108991] New: [13 regression] gcc.dg/memchr-3.c fails after r13-6414-g62a8d31ecc0704
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108991 Bug ID: 108991 Summary: [13 regression] gcc.dg/memchr-3.c fails after r13-6414-g62a8d31ecc0704 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:62a8d31ecc07041af4a81353c2d57d9845c4b771, r13-6414-g62a8d31ecc0704 make -k check-gcc RUNTESTFLAGS="dg.exp=gcc.dg/memchr-3.c" FAIL: gcc.dg/memchr-3.c target llp64 (test for warnings, line 9) # of expected passes1 # of unexpected failures1 Looks like a missing warning? spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/memchr-3.c -fdiagnostics-plain-output -O2 -Wall -S -o memchr-3.s^M FAIL: gcc.dg/memchr-3.c target llp64 (test for warnings, line 9) Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled3864749.cc -fdiagnostics-plain-output -Wno-complain-wrong-lang -S -o exceptions_enabled3864749.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled3864749.cc -fdiagnostics-plain-output -Wno-complain-wrong-lang -S -o exceptions_enabled3864749.s^M PASS: gcc.dg/memchr-3.c (test for excess errors) testcase /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/dg.exp completed in 0 seconds === gcc Summary === # of expected passes1 # of unexpected failures1 commit 62a8d31ecc07041af4a81353c2d57d9845c4b771 (HEAD) Author: Jonathan Yong <10wa...@gmail.com> Date: Mon Feb 27 10:02:32 2023 + gcc.dg/memchr-3.c: Account for LLP64 warnings
[Bug rtl-optimization/108992] New: Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992
Bug ID: 108992
Summary: Regression: Branch direction canonicalization leads to
pointless tail duplication / CSE/sinking by inverting
branch
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
There are two regressions, in GCC 7 and in GCC 8. If you invert branch manually
(replace 'cond' with '!cond') - the results were the same previously.
// Regressed since GCC 7: https://godbolt.org/z/h4brz7zG9
void use(int *);
void use2(int *);
void foo(bool cond, int * p)
{
if (cond) {
use(p);
}
use2(p);
}
// GCC 6
foo(bool, int*):
testdil, dil
pushrbx
mov rbx, rsi
je .L2
mov rdi, rsi
calluse(int*)
.L2:
mov rdi, rbx
pop rbx
jmp use2(int*)
// GCC 7
foo(bool, int*):
testdil, dil
jne .L8
mov rdi, rsi
jmp use2(int*)
.L8:
sub rsp, 24
mov rdi, rsi
mov QWORD PTR [rsp+8], rsi
calluse2(int*)
mov rsi, QWORD PTR [rsp+8]
add rsp, 24
mov rdi, rsi
jmp use2(int*)
// Regressed since GCC 8: https://godbolt.org/z/MjxqTnbKa
void use(int *);
void use2(int *);
void foo(int * p, bool cond)
{
if (cond) {
use(p);
}
use2(p);
}
// GCC 7
foo(int*, bool):
testsil, sil
pushrbx
mov rbx, rdi
je .L2
calluse(int*)
.L2:
mov rdi, rbx
pop rbx
jmp use2(int*)
// GCC 8
foo(int*, bool):
pushrbx
mov rbx, rdi
testsil, sil
jne .L5
mov rdi, rbx
pop rbx
jmp use2(int*)
.L5:
calluse(int*)
mov rdi, rbx
pop rbx
jmp use2(int*)
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #8 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #7)
> An attribute is certainly simpler and should be easy to add.
yes.
>
> I proposed similar extension for C23 and there was some interest,
> but I did not have time to follow up.
>
> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2660.pdf
very interesting proposal!
are there any discussions on this proposal? if so, can you point me to them?
>
>
> Sizeof is not a constant expression in ISO C for a VLA and it is not a
> constant expression if the struct contains a VLA (GNU extension). So this
> is already the case and nothing would need to change. It would also
> potentially
> avoid mistakes when computing the size of such a struct.
agreed.
However, my understanding is: VLA is only valid inside a function scope. GCC
use a special SAVE_EXPR to record its size expression. and evaluated during
runtime only once.
when this variable length concept is extended to global scope, not sure how to
implement the size expression? need some study here.
> But the
> rules for initialization are not so clear.
shall we make this clear?
>
> I do not think it is a good idea to differentiate between file scope structs
> and others. This would be confusing.
Yes. agreed.
this proposal basically is to extend the VLA concept from function scope to
global scope. is my understanding correct?
>
> Considering that the GNU extensions is rarely used, one could consider
> redefining the meaning of
>
> int n = 1;
> struct {
> int n;
> char buf[n];
> };
>
> so that the 'n' refers to the member. Or we add a new syntax similar to
> designators (which intuitively makes sense to me).
designator might be better IMO.
a question here is:
for the following nested structure:
struct object {
...
char items;
...
struct inner {
...
int flex[];
};
} *ptr;
what kind of syntax is good to represent the upper bound of "flex" in the inner
struct with "items" in the outer structure? any suggestion?
[Bug c/108986] [11/12/13 Regression] Incorrect warning for [static] array parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 54571 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54571&action=edit gcc13-pr108986.patch Untested fix for both issues.
[Bug c++/108993] New: Value initialization does not occur for derived class with -Os, for gcc versions > 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993
Bug ID: 108993
Summary: Value initialization does not occur for derived class
with -Os, for gcc versions > 5
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: daniel.gotsch at bluerivertech dot com
Target Milestone: ---
Minimal example:
#include
struct Base {
Base() {} // not a default constructor
double x;
};
struct Derived : public Base {
Derived() = default; // default constructor should lead to
zero-initialization
};
int main () {
Base a{};
std::cout << a.x; // Could be any value
Derived b{};
std::cout << b.x; // Should be set 0 but isn't set 0 when compiled with -Os
flag
}
see compiler output https://godbolt.org/z/Ecr1K9cMM
The class Derived has a default constructor which satisfies (2) of
value-initalization meaning the object should be zero-initialized.
see https://en.cppreference.com/w/cpp/language/value_initialization
Zero-initialization should zero-out the base class too, see
https://en.cppreference.com/w/cpp/language/zero_initialization
[Bug libgcc/108994] New: LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994
Bug ID: 108994
Summary: LLVM JIT segfaults in libgcc after upgrading from gcc
12.2.1 to 13.0.1
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: tstellar at redhat dot com
Target Milestone: ---
On AArch64, I'm seeing some test failures when building the latest LLVM main
branch with gcc 13.0.1 installed on my system. Downgrading to 12.2.1 allows
the test to pass.
For example, clang/test/Interpreter/global-dtor.cpp fails with this stack
trace:
#0 0xf7c5e608 in classify_object_over_fdes () from
/lib64/libgcc_s.so.1
#1 0xf7c5f130 in __deregister_frame_info_bases () from
/lib64/libgcc_s.so.1
#2 0xf7c5f930 in __deregister_frame () from /lib64/libgcc_s.so.1
#3 0x01351bc0 in llvm_orc_deregisterEHFrameSectionWrapper ()
#4 0x00db9f74 in
llvm::orc::SelfExecutorProcessControl::callWrapperAsync(llvm::orc::ExecutorAddr,
llvm::orc::ExecutorProcessControl::IncomingWFRHandler, llvm::ArrayRef) ()
#5 0x00da0198 in
llvm::orc::ExecutorProcessControl::callWrapper(llvm::orc::ExecutorAddr,
llvm::ArrayRef) ()
#6 0x00dc03d4 in llvm::Error
llvm::orc::shared::WrapperFunction)>::call),
llvm::orc::ExecutorAddrRange&>(llvm::orc::ExecutorAddr,
llvm::orc::ExecutorAddrRange&)::{lambda(char const*, unsigned long)#1},
llvm::orc::shared::SPSEmpty,
llvm::orc::ExecutorAddrRange>(llvm::orc::ExecutorProcessControl::callSPSWrapper),
llvm::orc::ExecutorAddrRange&>(llvm::orc::ExecutorAddr,
llvm::orc::ExecutorAddrRange&)::{lambda(char const*, unsigned long)#1} const&,
llvm::orc::shared::SPSEmpty&, llvm::orc::ExecutorAddrRange const&) ()
#7 0x00dc0358 in
llvm::orc::EPCEHFrameRegistrar::deregisterEHFrames(llvm::orc::ExecutorAddrRange)
()
#8 0x00da8170 in
llvm::orc::EHFrameRegistrationPlugin::notifyRemovingResources(llvm::orc::JITDylib&,
unsigned long) ()
#9 0x00da711c in
llvm::orc::ObjectLinkingLayer::handleRemoveResources(llvm::orc::JITDylib&,
unsigned long) ()
#10 0x00d7336c in
llvm::orc::ExecutionSession::removeResourceTracker(llvm::orc::ResourceTracker&)
()
#11 0x00d791cc in llvm::orc::JITDylib::clear() ()
#12 0x00d8582c in llvm::orc::ExecutionSession::endSession() ()
#13 0x00d9b014 in llvm::orc::LLJIT::~LLJIT() ()
#14 0x00d9b170 in llvm::orc::LLJIT::~LLJIT() ()
#15 0x00ff07e0 in clang::IncrementalExecutor::~IncrementalExecutor() ()
#16 0x00fef788 in clang::Interpreter::~Interpreter() ()
#17 0x00a46010 in main ()
The crashing program is clang-repl, which is a C++ interpreter, so it's
crashing while trying to run the code, not while trying to compile it. I'm
working on getting a better reproducer, but if you have access to an AArch64
machine you can reproduce it like this:
git clone https://github.com/llvm/llvm-project
cd llvm-project
cmake -G Ninja -B build -S llvm -DCMAKE_BUILD_TYPE=release
-DLLVM_ENABLE_PROJECTS=clang -DLLVM_BUILD_LLVM_DYLIB=ON
-DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang
./build/bin/clang-repl < test.cpp
ninja -C build clang-repl
--
test.cpp:
extern "C" int printf(const char *, ...);
struct D { float f = 1.0; D *m = nullptr; D(){} ~D() { printf("D[f=%f,
m=0x%llx]\n", f, reinterpret_cast(m)); }} d;
// CHECK: D[f=1.00, m=0x0]
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #9 from Martin Uecker ---
Am Donnerstag, dem 02.03.2023 um 17:34 + schrieb qinzhao at gcc dot
gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #8 from qinzhao at gcc dot gnu.org ---
> (In reply to Martin Uecker from comment #7)
> > An attribute is certainly simpler and should be easy to add.
> yes.
> >
> > I proposed similar extension for C23 and there was some interest,
> > but I did not have time to follow up.
> >
> > https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2660.pdf
> very interesting proposal!
> are there any discussions on this proposal? if so, can you point me to them?
One has to check the minutes from the WG14 meetings. You
will find those at the website. But I forgot at which
meeting it was discussed. Although completeness
and quality of the minutes varies, so I am not sure how
interesting this is.
https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log
There were thee follow-up proposals which I advanced for
C23, but I changed jobs and most of them got delayed too
much for C23.
But we made variably modified types mandatory in C23 to
help with bounds checking and this already works quite
nicely with GCC / Clang:
https://godbolt.org/z/ddfsdWPMj
> >
> >
> > Sizeof is not a constant expression in ISO C for a VLA and it is not a
> > constant expression if the struct contains a VLA (GNU extension). So this
> > is already the case and nothing would need to change. It would also
> > potentially
> > avoid mistakes when computing the size of such a struct.
> agreed.
> However, my understanding is: VLA is only valid inside a function scope. GCC
> use a special SAVE_EXPR to record its size expression. and evaluated during
> runtime only once.
Yes, this is correct.
> when this variable length concept is extended to global scope, not sure how to
> implement the size expression? need some study here.
Here, we want to use a member of the struct as a size
expression. This could work equally at function and file scope.
But the semantics need to be worked out. I have started to work
on a patch for GCC a couple of weeks ago using PLACEHOLDER_EXPR,
but did not get very far.
The idea is to evaluate the size expression whenever the member
with the size is accesses. If the size is not set before, this
would be undefined behavior.
Other languages such as Ada support this, so in principle this
should be a piece of cake.
>
> > But the
> > rules for initialization are not so clear.
> shall we make this clear?
We should...
> >
> > I do not think it is a good idea to differentiate between file scope structs
> > and others. This would be confusing.
> Yes. agreed.
>
> this proposal basically is to extend the VLA concept from function scope to
> global scope. is my understanding correct?
I would say the idea is to allow size expressions to refer
to member of a struct instead of only automatic variables.
>
> >
> > Considering that the GNU extensions is rarely used, one could consider
> > redefining the meaning of
> >
> > int n = 1;
> > struct {
> > int n;
> > char buf[n];
> > };
> >
> > so that the 'n' refers to the member. Or we add a new syntax similar to
> > designators (which intuitively makes sense to me).
> designator might be better IMO.
>
> a question here is:
>
> for the following nested structure:
>
> struct object {
> ...
> char items;
> ...
> struct inner {
> ...
> int flex[];
> };
> } *ptr;
>
> what kind of syntax is good to represent the upper bound of "flex" in the
> inner
> struct with "items" in the outer structure? any suggestion?
I would disallow it. At least at first. It also raises some
questions: For example, one could form a pointer to the inner
struct, and then it is not clear how 'items' could be accessed
anymore.
Martin
[Bug debug/108716] [10/11/12/13 Regression] Incorrect DW_AT_decl_{line,column} in DW_TAG_imported_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108716 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4d82022bfd15d36717bf60a11e75e9ea02204269 commit r13-6419-g4d82022bfd15d36717bf60a11e75e9ea02204269 Author: Jakub Jelinek Date: Thu Mar 2 19:17:52 2023 +0100 c++, debug: Fix up locus of DW_TAG_imported_module [PR108716] Before IMPORTED_DECL has been introduced in PR37410, we used to emit correct DW_AT_decl_line on DW_TAG_imported_module on the testcase below, after that change we haven't emitted it at all for a while and after some time started emitting incorrect locus, in particular the location of } closing the function. The problem is that while we have correct EXPR_LOCATION on the USING_STMT, when genericizing that USING_STMT into IMPORTED_DECL we don't copy the location to DECL_SOURCE_LOCATION, so it gets whatever input_location happens to be when it is created. 2023-03-02 Jakub Jelinek PR debug/108716 * cp-gimplify.cc (cp_genericize_r) : Set DECL_SOURCE_LOCATION on IMPORTED_DECL to expression location of USING_STMT or input_location. * g++.dg/debug/dwarf2/pr108716.C: New test.
[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994 Jonathan Wakely changed: What|Removed |Added Summary|LLVM JIT segfaults in |[13 Regression] LLVM JIT |libgcc after upgrading from |segfaults in libgcc after |gcc 12.2.1 to 13.0.1|upgrading from gcc 12.2.1 ||to 13.0.1 Known to fail||13.0 Target Milestone|--- |13.0 Known to work||12.2.1
[Bug debug/108716] [10/11/12 Regression] Incorrect DW_AT_decl_{line,column} in DW_TAG_imported_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108716
Jakub Jelinek changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression]
|Incorrect |Incorrect
|DW_AT_decl_{line,column} in |DW_AT_decl_{line,column} in
|DW_TAG_imported_decl|DW_TAG_imported_decl
--- Comment #3 from Jakub Jelinek ---
Fixed on the trunk so far.
[Bug analyzer/107060] -fanalyzer unbearably slow when compiling GNU Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107060 --- Comment #9 from David Malcolm --- Reconfirming, alas. I just tried adding emacs to my integration test suite [1], and xdisp.c is still a big outlier, taking ~15 minutes; with gcc (GCC) 13.0.1 20230202 (experimental). [1] https://github.com/davidmalcolm/gcc-analyzer-integration-tests/issues/2
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896 --- Comment #10 from Martin Uecker --- And to get bounds checking for the flexible array member today, one could use a macro to attach the bound back to the array on member access. https://godbolt.org/z/GbaoYrhav But the bound from the type is not fed back into __builtin_dynamic_object_size(), so this currently only helps for direct array refs. But this is something we may be able to improve.
[Bug sanitizer/108995] New: Missed signed integer overflow checks in UBsan?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108995
Bug ID: 108995
Summary: Missed signed integer overflow checks in UBsan?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
$ cat abc.c
int printf(const char *, ...);
int a;
const int b = 44514;
int *c = &a;
void main(void) {
*c = 65526 * b / 6;
printf("%d\n", a);
}
Ubsan did not emit any message. However, the outputs are different.
$ gcc-trunk -O3 -fsanitize=undefined abc.c ; ./a.out
-229690488
$ gcc-trunk -fsanitize=undefined abc.c ; ./a.out
486137394
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 --- Comment #7 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:20bd258d0fa09837b3a93478ef92d8789cbcd442 commit r13-6420-g20bd258d0fa09837b3a93478ef92d8789cbcd442 Author: David Malcolm Date: Thu Mar 2 14:01:19 2023 -0500 analyzer: fix uninit false +ves reading from DECL_HARD_REGISTER [PR108968] gcc/analyzer/ChangeLog: PR analyzer/108968 * region-model.cc (region_model::get_rvalue_1): Handle VAR_DECLs with a DECL_HARD_REGISTER by returning UNKNOWN. gcc/testsuite/ChangeLog: PR analyzer/108968 * gcc.dg/analyzer/uninit-pr108968-register.c: New test. Signed-off-by: David Malcolm
[Bug c++/108243] [10/11/12/13 Regression] Missed optimization for static const std::string_view(const char*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108243 --- Comment #12 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:cbaa1d9c218d9c0b5e34e510a462ff4e299a0f3f commit r13-6421-gcbaa1d9c218d9c0b5e34e510a462ff4e299a0f3f Author: Patrick Palka Date: Thu Mar 2 14:03:21 2023 -0500 c++: constant non-copy-init is manifestly constant [PR108243] According to [basic.start.static]/2 and [expr.const]/2, a variable with static storage duration initialized with a constant initializer has constant initialization, and such an initializer is manifestly constant-evaluated. For copy initialization, we're already getting this right because in that case check_initializer would consistently call store_init_value, which for TREE_STATIC variables calls fold_non_dependent_init with m_c_e=true. But for direct (or default) initialization, check_initializer doesn't always call store_init_value. We instead however always call maybe_constant_init from expand_default_init[1], albeit with m_c_e=false which means we don't get the "manifestly constant-evaluated" part right for non-copy-init. This patch fixes this by setting m_c_e=true in maybe_constant_init for static storage duration variables, mainly for benefit of the call to maybe_constant_init from expand_default_init. [1]: this maybe_constant_init call isn't reached in the copy-init case because there init is a CONSTRUCTOR rather than a TREE_LIST, and so we exit early from expand_default_init, returning an INIT_EXPR. This INIT_EXPR is ultimately what causes us to consistently hit the store_init_value code path from check_initializer in the copy-init case. PR c++/108243 gcc/cp/ChangeLog: * constexpr.cc (maybe_constant_init_1): Override manifestly_const_eval to true if is_static. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/is-constant-evaluated14.C: New test.
[Bug c++/108243] [10/11/12/13 Regression] Missed optimization for static const std::string_view(const char*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108243 --- Comment #13 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:5425159d176a7a92afc932cbb22d8822667099c4 commit r13-6422-g5425159d176a7a92afc932cbb22d8822667099c4 Author: Patrick Palka Date: Thu Mar 2 14:04:50 2023 -0500 c++: more mce_false folding from cp_fully_fold_init [PR108243] We should also fold the overall initializer passed to cp_fully_fold_init with mce_false, which allows folding of the copy-initialization of 'a1' in the below testcase (the initializer here is an AGGR_INIT_EXPR). Unfortunately this doesn't help with direct- or default-initialization because we don't call cp_fully_fold_init in that case, and even if we did the initializer in that case is expressed as a bare CALL_EXPR instead of an AGGR_INIT_EXPR, which cp_fully_fold_init can't really fold. PR c++/108243 PR c++/97553 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_fully_fold): Add an internal overload that additionally takes and propagate an mce_value parameter, and define the existing public overload in terms of it. (cp_fully_fold_init): Pass mce_false to cp_fully_fold. gcc/testsuite/ChangeLog: * g++.dg/opt/is_constant_evaluated3.C: New test.
[Bug c++/97553] [missed optimization] constexprness not noticed when UBsan enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97553 --- Comment #7 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:5425159d176a7a92afc932cbb22d8822667099c4 commit r13-6422-g5425159d176a7a92afc932cbb22d8822667099c4 Author: Patrick Palka Date: Thu Mar 2 14:04:50 2023 -0500 c++: more mce_false folding from cp_fully_fold_init [PR108243] We should also fold the overall initializer passed to cp_fully_fold_init with mce_false, which allows folding of the copy-initialization of 'a1' in the below testcase (the initializer here is an AGGR_INIT_EXPR). Unfortunately this doesn't help with direct- or default-initialization because we don't call cp_fully_fold_init in that case, and even if we did the initializer in that case is expressed as a bare CALL_EXPR instead of an AGGR_INIT_EXPR, which cp_fully_fold_init can't really fold. PR c++/108243 PR c++/97553 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_fully_fold): Add an internal overload that additionally takes and propagate an mce_value parameter, and define the existing public overload in terms of it. (cp_fully_fold_init): Pass mce_false to cp_fully_fold. gcc/testsuite/ChangeLog: * g++.dg/opt/is_constant_evaluated3.C: New test.
[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994 --- Comment #1 from Andrew Pinski --- Can you supply the output of "gcc -v"? There was a bug dealing with the unwinder which wad fixed in the last month.
[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994 --- Comment #2 from Tom Stellard --- $ gcc -v Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-redhat-linux/13/lto-wrapper Target: aarch64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --enable-libstdcxx-backtrace --with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-13.0.1-20230221/obj-aarch64-redhat-linux/isl-install --enable-gnu-indirect-function --build=aarch64-redhat-linux --with-build-config=bootstrap-lto --enable-link-serialization=1 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.1 20230221 (Red Hat 13.0.1-0) (GCC)
[Bug rtl-optimization/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992 --- Comment #1 from Andrew Pinski --- Why do you think this is a bug? I don't see anything wrong with the newer versions of gcc. Duplicating the basic blocks is done on purpose for speed reasons.
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 David Malcolm changed: What|Removed |Added Last reconfirmed||2023-03-02 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #8 from David Malcolm --- I've attempted to work around this with the above patch (for gcc 13). As written, this ought to suppress the "uninit" false positive, but I didn't have a good kind of symbolic value to use for the resulting pointer, hence the analyzer will treat the result of get_cpu_info as an "unknowable" pointer, which might lead to a chain of follow-up false positives if there's logic in the code being analyzed that relies on dereferencing the result and getting consistent results. Can you attach a typical preprocessed source file from xen (the GPL licensed part) that was showing this (use -E), so I can poke at it to see how well this workaround works - thanks! Keeping open in case this needs further work, and to possibly track backporting to GCC 12.
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #9)
>
> https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log
thanks for the info.
>
> But we made variably modified types mandatory in C23 to
> help with bounds checking and this already works quite
> nicely with GCC / Clang:
>
> https://godbolt.org/z/ddfsdWPMj
nice!
can you provide a pointer to the section in C23 that made this change?
>
> > when this variable length concept is extended to global scope, not sure how
> > to
> > implement the size expression? need some study here.
>
> Here, we want to use a member of the struct as a size
> expression. This could work equally at function and file scope.
> But the semantics need to be worked out. I have started to work
> on a patch for GCC a couple of weeks ago using PLACEHOLDER_EXPR,
> but did not get very far.
>
> The idea is to evaluate the size expression whenever the member
> with the size is accesses. If the size is not set before, this
> would be undefined behavior.
>
> Other languages such as Ada support this, so in principle this
> should be a piece of cake.
Oh, Ada can support this already?
how does Ada implement this?
then we can just borrow Ada's implementation idea to implement this in C if
this is approved as an GCC extension for C.
> > this proposal basically is to extend the VLA concept from function scope to
> > global scope. is my understanding correct?
>
> I would say the idea is to allow size expressions to refer
> to member of a struct instead of only automatic variables.
>
Okay.
> > a question here is:
> >
> > for the following nested structure:
> >
> > struct object {
> > ...
> > char items;
> > ...
> > struct inner {
> > ...
> > int flex[];
> > };
> > } *ptr;
> >
> > what kind of syntax is good to represent the upper bound of "flex" in the
> > inner
> > struct with "items" in the outer structure? any suggestion?
>
> I would disallow it. At least at first. It also raises some
> questions: For example, one could form a pointer to the inner
> struct, and then it is not clear how 'items' could be accessed
> anymore.
>
Okay.
[Bug rtl-optimization/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992 --- Comment #2 from Nikita Kniazev --- > Why do you think this is a bug? > I don't see anything wrong with the newer versions of gcc. > Duplicating the basic blocks is done on purpose for speed reasons. I understand that removing diamonds is done to open more optimization opportunities but in this case there is none; not undoing the cloning leads to code size increases which creates unnecessary pressure on instruction cache.
[Bug c++/108243] [10/11/12 Regression] Missed optimization for static const std::string_view(const char*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108243
Patrick Palka changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12 Regression]
|Missed optimization for |Missed optimization for
|static const|static const
|std::string_view(const |std::string_view(const
|char*) |char*)
--- Comment #14 from Patrick Palka ---
The original testcase is fixed for GCC 13 by comment #12, so that we now
correctly constant initialize 'static const string_view foo("bar");'.
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896 --- Comment #12 from qinzhao at gcc dot gnu.org --- (In reply to Martin Uecker from comment #9) > > Here, we want to use a member of the struct as a size > expression. This could work equally at function and file scope. > But the semantics need to be worked out. I have started to work > on a patch for GCC a couple of weeks ago using PLACEHOLDER_EXPR, > but did not get very far. what kind of semantics your patch will support?
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #13 from Martin Uecker ---
Am Donnerstag, dem 02.03.2023 um 19:47 + schrieb qinzhao at gcc dot
gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #11 from qinzhao at gcc dot gnu.org ---
> (In reply to Martin Uecker from comment #9)
> >
> > https://www.open-std.org/jtc1/sc22/wg14/www/wg14_document_log
> thanks for the info.
> >
> > But we made variably modified types mandatory in C23 to
> > help with bounds checking and this already works quite
> > nicely with GCC / Clang:
> >
> > https://godbolt.org/z/ddfsdWPMj
> nice!
> can you provide a pointer to the section in C23 that made this change?
VLAs and VM types exist since C99 and were made optional in C11.
The minimal change we adopted to make support for VM types
(but not VLAs) mandatory again was:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2778.pdf
UBSan support in GCC to diagnose such out of bounds accesses
was added here:
https://gcc.gnu.org/git/?p=gcc.git&a=commit;h=04fd785e38c4c37ae4f71704397a27a924baf4d9
> >
> > > when this variable length concept is extended to global scope, not sure
> > > how to
> > > implement the size expression? need some study here.
> >
> > Here, we want to use a member of the struct as a size
> > expression. This could work equally at function and file scope.
> > But the semantics need to be worked out. I have started to work
> > on a patch for GCC a couple of weeks ago using PLACEHOLDER_EXPR,
> > but did not get very far.
> >
> > The idea is to evaluate the size expression whenever the member
> > with the size is accesses. If the size is not set before, this
> > would be undefined behavior.
> >
> > Other languages such as Ada support this, so in principle this
> > should be a piece of cake.
> Oh, Ada can support this already?
> how does Ada implement this?
I think using PLACEHOLDER_EXPR that are insert into the size
expression and then replaced later by the struct being accessed,
e.g.
struct foo {
int len;
char buf[PLACEHOLDER_EXPR.len]
};
and then later when we have
struct foo x;
x->buf
we would replace in the size of the type for x->buf the placeholder
with x itself.
> then we can just borrow Ada's implementation idea to implement this in C if
> this is approved as an GCC extension for C.
Yes, this was what I wanted to do... My main use case is not flexible
array members but VM types in struct:
struct foo {
int len;
char (*buf)[.len];
};
This has less issues because the size of the struct then does not depend
on the length.
But I am still trying to understand how this all works in GCC.
Martin
[Bug libgcc/108994] [13 Regression] LLVM JIT segfaults in libgcc after upgrading from gcc 12.2.1 to 13.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108994 --- Comment #3 from Andrew Pinski --- Maybe related to : r13-2801-g94ccaf62c378c3 r13-2870-g386ebf75f4c034
[Bug c/108996] New: Proposal for adding DWARF call site information got GCC with -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108996
Bug ID: 108996
Summary: Proposal for adding DWARF call site information got
GCC with -O0
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cel at us dot ibm.com
Target Milestone: ---
On PowerPC, the address of the buffer to return non-trivial values such as
structures is passed in register r3. The value of r3 on entry may change in
the body of the caller. Thus the contents of r3 can not be used by GDB at the
function exit to access the address of the buffer.
GDB needs to have the value of r3 on entry to the function to be able to print
the return value of the function when the function exits. GDB is able to get
the value of r3 from the caller at the time of the function call if the needed
DWARF information is available. Currently the only way to get the needed DWARF
information is to compile with -fvar-tracking. The option actually saves lots
of additional information which may negatively impact the size and speed of the
binary when compiled with -O0. We have not done any investigation to determine
the exact amounts but is based on a best guess.
GDB doesn't need all the information provided by -fvar-tracking, actually a
small subset of the information.
Currently GDB on PowerPC will attempt to determine the value of r3 on entry.
If the needed DWARF information is not available, GDB will print the message:
"Cannot resolve DW_OP_entry_value for the return value. Try compiling
with -fvar-tracking. “
The following is an example of how gdb is unable to print the return value. It
is a stripped down version of the gdb testsuite test
gdb/testsuite/gdb.cp/non-trivial-retval.cc.
class B
{
public:
B () {}
B (const B &obj);
int b;
};
B::B(const B &obj)
{
b = obj.b;
}
B
f2 (int i1, int i2)
{
B b;
b.b = i1 + i2;
return b;
}
int
main (void)
{
int i1 = 23;
int i2 = 100;
B b = f2 (i1, i2);
return 0;
}
# compile the program, without -fvar-tracking
gcc -g -o non-trivial-retval non-trivial-retval.cc
# Run GDB
gdb ./non-trivial-retval
...
gdb) break main
Breakpoint 1 at 0x1744: file non-trivial-retval.cc, line 28.
(gdb) r
Starting program: /home/carll/GDB/binutils-gdb-
current/gdb/testsuite/gdb.cp/non-trivial-retval
[Thread debugging using libthread_db
enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Breakpoint 1, main () at non-trivial-retval.cc:28
28 int i1 = 23;
(gdb) n
29 int i2 = 100;
(gdb) n
31 B b = f2 (i1, i2);
(gdb) s
f2 (i1=23, i2=100) at non-trivial-retval.cc:18
18 B b;
(gdb) finish
warning: Cannot determine the function return value. << Message to
user
Try compiling with -fvar-tracking. << Message to
user
Run till exit from #0 f2 (i1=23, i2=100) at non-trivial-
retval.cc:18
main () at non-trivial-retval.cc:32
32 return 0;
Value returned has type: B. Cannot determine contents << GDB can not
determine return value
(gdb)
When we compile with -fvar-tracking we can print the return value.
# Compile with -fvar-tracking
gcc -g -O0 -fvar-tracking -o non-trivial-retval non-trivial-retval.cc
# Run GDB
gdb ./non-trivial-retval
(gdb) break main
Breakpoint 1 at 0x1730: file non-trivial-retval.cc, line 27.
(gdb) r
Starting program: /home/carll/GDB/binutils-gdb-
current/gdb/testsuite/gdb.cp/non-trivial-retval
[Thread debugging using libthread_db
enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Breakpoint 1, 0x1730 in main () at non-trivial-
retval.cc:27
27 {
(gdb) s
28 int i1 = 23;
(gdb) s
29 int i2 = 100;
(gdb) s
31 B b = f2 (i1, i2);
(gdb) s
0x16b4 in f2 (i1=i1@entry=23, i2=i2@entry=100)
at non-trivial-retval.cc:17
17 {
(gdb) finish
Run till exit from #0 0x16b4 in f2 (i1=i1@entry=23,
i2=i2@entry=100) at non-trivial-retval.cc:17
main () at non-trivial-retval.cc:32
32 return 0;
Value returned is $1 = {b = 123}<< GDB can print the return
value
Looking at the dwarf information, we need to compile with -g -O2 -fvar-
tracking to get the info we need:
gcc -g -O0 -fvar-tracking -o non-trivial-retval non-trivial-retval.cc
dwarfdump non-trivial-retval > non-trivial-retval.dwarf
...
DW_AT_GNU_locviews0x0039
< 2><0x00d6> DW_TAG_variable
DW_AT_name b
DW
[Bug c++/108993] Value initialization does not occur for derived class , for gcc versions > 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108993 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code --- Comment #1 from Andrew Pinski --- Hmm, I noticed that since GCC 7 with -std=c++17, the b.x is not initialized at all. So the question I have is there a difference between C++ standards here? Note the issue is we call Base's constructor after doing the zero initialization and the Base's constructor has a clobber in it which I think is correct. This is all front-end generation and not exactly related to the optimizations directly.
[Bug fortran/106856] [12/13 Regression][OOP] CLASS attribute handling / ICE in gfc_conv_expr_present, at fortran/trans-expr.cc:1977 since r12-4346-geb92cd57a1ebe7cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106856 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 #5 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #4) > - testcase pr69398.f90 ICE's - as expected, see comment in new testcase > class_75.f90. Shall we mark this one as XFAIL for the time being and > reopen pr69398? This intermediate regression appears to result from an invalid double-free. I plan to package an updated patch for submission.
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 --- Comment #9 from Andrew Cooper --- Thank-you for the fix. I've recompiled master and this uninitialised warning has gone. Unfortunately, Xen isn't GCC-13 clean (seems like a real bug in Xen), and the analyser has pointed out various other things which I'm still looking in to. I don't see anything which looks like it is a new knock-on effect from this change. Our code does fundamentally rely on get_cpu_info() always returning the same pointer (on a single CPU). For example, `current` is defined as `get_cpu_info()->current` and we do expect that to yield the same pointer when used multiple times. Even if the analyser was interpreting the generated asm, there's no way it could prove this without knowing the size/alignment constraints of our stacks. Would a const annotation on get_cpu_info() be likely to help? It occurs to me that this is true in all cases that the compiler could legitimately reason about. (It would only cease being true if we fell off our stack, at which point UB is the very least of our worries.)
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 --- Comment #10 from Andrew Cooper --- >From trying this out, a const attribute doesn't alter the code generation in the slightest, so I presume GCC has already figured the const-ness out.
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 --- Comment #11 from David Malcolm --- (In reply to Andrew Cooper from comment #9) [...snip...] > Would a const annotation on get_cpu_info() be likely to help? It occurs to > me that this is true in all cases that the compiler could legitimately > reason about. (It would only cease being true if we fell off our stack, at > which point UB is the very least of our worries.) Probably not (without further patching of the analyzer, at least). For functions it can't see the definition of, the analyzer will respect const annotations and treat such a function as always returning the same results when given the same set of arguments. However, I don't think it will respect a const annotation on an function it can see the definition of; I think in your case it will simply try to (badly) simulate the insides of get_cpu_info. To what extent that's going to lead to false positives is hard to say.
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 --- Comment #12 from David Malcolm --- (In reply to Andrew Cooper from comment #9) [...snip...] > Our code does fundamentally rely on get_cpu_info() always returning the same > pointer (on a single CPU). For example, `current` is defined as > `get_cpu_info()->current` and we do expect that to yield the same pointer > when used multiple times. > > Even if the analyser was interpreting the generated asm, there's no way it > could prove this without knowing the size/alignment constraints of our > stacks. Another issue is that even if the analyzer "knows" that get_cpu_info() always returns the same value, it doesn't know what memory is being pointed to, and so has to assume that in: T old_value = get_cpu_info()->current; some_function_call (); T new_value = get_cpu_info()->current; that old_value doesn't necessarily equal new_value, since some_function_call () could have modified the value of "current".
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #13 from Andrew Cooper ---
I've constructed an example which might be the knockon effect you were worried
about?
void foo(char *other)
{
char *ptr = NULL;
if ( current->domain )
ptr = other;
asm volatile ("cmc");
if ( current->domain )
ptr[0] = ~ptr[0];
}
yields
arch/x86/tmp.c: In function 'foo':
arch/x86/tmp.c:14:22: error: dereference of NULL 'ptr' [CWE-476]
[-Werror=analyzer-null-dereference]
14 | ptr[0] = ~ptr[0];
| ~~~^~~
'foo': events 1-5
|
|8 | if ( current->domain )
| |^
| ||
| |(1) following 'false' branch...
|..
| 11 | asm volatile ("cmc");
| | ~~~
| | |
| | (2) ...to here
| 12 |
| 13 | if ( current->domain )
| |~
| ||
| |(3) following 'true' branch...
| 14 | ptr[0] = ~ptr[0];
| | ~~~ ~~
| | ||
| | |(5) dereference of NULL 'ptr'
| | (4) ...to here
|
[Bug c++/108975] [10/11/12/13 Regression] ICE on constexpr variable used as nontype template since r9-5473-ge32fc4499f863f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
Patrick Palka changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression]
|ICE on constexpr variable |ICE on constexpr variable
|used as nontype template|used as nontype template
|since |since
|e32fc4499f863fe0fa81767d11f |r9-5473-ge32fc4499f863f
|40ad2f1ab1668 |
--- Comment #12 from Patrick Palka ---
(In reply to Patrick Palka from comment #11)
> Started with r268016
... aka r9-5473-ge32fc4499f863f.
More reduced testcase:
template
void f() {
constexpr int dim = 1;
auto f = [&] {
int n[dim * 1];
};
}
template void f();
: In instantiation of ‘void f() [with T = int]’:
:9:22: required from here
:5:11: internal compiler error: in lookup_template_class, at
cp/pt.cc:10080
We similarly crash when using a generic lambda:
template
void f() {
constexpr int dim = 1;
auto f = [&] (auto) {
int n[dim * 1];
};
f(0);
}
template void f();
In either case, since dim is a constant variable we should prune the implicit
capture of it and sizeof(f) should be 1.
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 --- Comment #14 from Andrew Cooper --- Created attachment 54572 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54572&action=edit Preprocessed example
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 --- Comment #15 from Andrew Cooper --- Wow that's a lot of junk getting included for the minimal include set I could easily make. It occurs to me only after posting that you're liable to fail at: asm ( ".include \"arch/x86/include/asm/asm-macros.h\"" ); which always trips things up. You can safely drop it if you're just interested in the analyser behaviour.
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #16 from David Malcolm ---
Minimized version of attachment 54572:
struct cpu_info {
/* [...snip...] */
struct vcpu *current_vcpu;
/* [...snip...] */
};
struct vcpu
{
/* [...snip...] */
struct domain *domain;
/* [...snip...] */
};
static __inline__ struct cpu_info *get_cpu_info_from_stack(unsigned long sp)
{
return (struct cpu_info *)((sp | 1L) << 12) << 3) - 1)) + 1) - 1;
}
static __inline__ struct cpu_info *get_cpu_info(void)
{
register unsigned long sp asm("rsp");
return get_cpu_info_from_stack(sp);
}
void foo(char *other)
{
char *ptr = ((void*)0);
if ( ((get_cpu_info()->current_vcpu))->domain )
ptr = other;
asm volatile ("cmc");
if ( ((get_cpu_info()->current_vcpu))->domain )
ptr[0] = ~ptr[0];
}
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968
--- Comment #17 from David Malcolm ---
...where trunk emits:
test.c:35:22: warning: dereference of NULL 'ptr' [CWE-476]
[-Wanalyzer-null-dereference]
35 | ptr[0] = ~ptr[0];
| ~~~^~~
'foo': events 1-6
|
| 27 | char *ptr = ((void*)0);
| | ^~~
| | |
| | (1) 'ptr' is NULL
| 28 |
| 29 | if ( ((get_cpu_info()->current_vcpu))->domain )
| |~
| ||
| |(2) following 'false' branch...
|..
| 32 | asm volatile ("cmc");
| | ~~~
| | |
| | (3) ...to here
| 33 |
| 34 | if ( ((get_cpu_info()->current_vcpu))->domain )
| |~
| ||
| |(4) following 'true' branch...
| 35 | ptr[0] = ~ptr[0];
| | ~~
| | |
| | (5) ...to here
| | (6) dereference of NULL 'ptr'
|
[Bug analyzer/108968] fanalyzer false positive with the uninitalised-ness of the stack pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108968 --- Comment #18 from David Malcolm --- Looks like it doesn't even need the asm stmt at line 32 to consider that it could take the false-then-true path.
[Bug fortran/106856] [12/13 Regression][OOP] CLASS attribute handling / ICE in gfc_conv_expr_present, at fortran/trans-expr.cc:1977 since r12-4346-geb92cd57a1ebe7cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106856 --- Comment #6 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-March/059003.html
[Bug rtl-optimization/90706] [10/11/12/13 Regression] Useless code generated for stack / register operations on AVR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90706 --- Comment #18 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:2639f9d2313664e6b4ed2f8131fefa60aeeb0518 commit r13-6424-g2639f9d2313664e6b4ed2f8131fefa60aeeb0518 Author: Vladimir N. Makarov Date: Thu Mar 2 16:29:05 2023 -0500 IRA: Use minimal cost for hard register movement This is the 2nd attempt to fix PR90706. IRA calculates wrong AVR costs for moving general hard regs of SFmode. This was the reason for spilling a pseudo in the PR. In this patch we use smaller move cost of hard reg in its natural and operand modes. PR rtl-optimization/90706 gcc/ChangeLog: * ira-costs.cc: Include print-rtl.h. (record_reg_classes, scan_one_insn): Add code to print debug info. (record_operand_costs): Find and use smaller cost for hard reg move. gcc/testsuite/ChangeLog: * gcc.target/avr/pr90706.c: New.
[Bug c++/84471] Debugger jumps back to lambda capture location every time a captured variable is odr-used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84471 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |13.0 --- Comment #6 from Jason Merrill --- Fixed for GCC 13.
[Bug c++/107504] Debugger jumps back to structured binding declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107504 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |13.0 Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- Fixed.
[Bug rtl-optimization/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992 --- Comment #3 from Andrew Pinski --- Did you see this in real code or you just noticed this while looking at code generation?
[Bug middle-end/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #4 from Andrew Pinski ---
I suspect this is not a bug, GCC tries to optimze the fast path into straight
line code without any waste of space.
In the first case GCC predicts that the cond is going to be true 66% of the
time because there is comparison against 0 prediction going in the heurstics.
For the first testcase if you do:
void use(int *);
void use2(int *);
void foo(bool cond, int * p)
{
if (__builtin_expect(cond, 1)) {
use(p);
}
use2(p);
}
Then you get the result you want.
Adding the builtin_expect for the second case you get the same too.
Basically GCC is pushing what it thinks as cold code away from the original
path.
[Bug c++/107939] [11/12/13 Regression] Rejects use of `extern const` variable in a template since r11-557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107939 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- A similar example extern const int z; template constexpr auto p = z; works, because require_constant_expression is OK with 'z' here. The difference between 'z' here and 'q' in the previous test is INTEGRAL_OR_ENUMERATION_TYPE_P, which makes decl_maybe_constant_var_p return different answers: else if (CP_TYPE_CONST_NON_VOLATILE_P (type) && INTEGRAL_OR_ENUMERATION_TYPE_P (type)) /* And const integers. */;
[Bug tree-optimization/108997] New: GCC prediction on bool comparisons seems wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108997
Bug ID: 108997
Summary: GCC prediction on bool comparisons seems wrong
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
I noticed this while looking into 108992.
I suspect we look into this but I am not 100% sure this is a bug.
Testcase:
void use(int *);
void use2(int *);
void foo(bool cond, int * p)
{
if (cond) {
use(p);
}
use2(p);
}
GCC predicts the branch to be taken 66% of the time, but I would have assume it
should be 50% as it is a bool and there is no other information. I suspect this
is due to prediction when comparing against 0.
[Bug jit/107999] [13 Regression] jit.dg/test-error-array-bounds.c now fails because [-Warray-bounds] was updated to [-Warray-bounds=] in error messages after r13-4410-g7c01d029fca669263b9c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107999 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:6b432c0f777ab9b8436fb07f71de6ea4d259b869 commit r13-6425-g6b432c0f777ab9b8436fb07f71de6ea4d259b869 Author: Guillaume Gomez Date: Thu Mar 2 17:52:07 2023 -0500 jit, testsuite: fix a failing test by updating its error string [PR107999] gcc/testsuite/ChangeLog: PR jit/107999 * jit.dg/test-error-array-bounds.c: Update test. Signed-off-by: Guillaume Gomez
[Bug middle-end/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992 --- Comment #5 from Andrew Pinski --- Note I filed PR 108997 for what seems like the wrong heurstic for the prediction.
[Bug jit/107999] [13 Regression] jit.dg/test-error-array-bounds.c now fails because [-Warray-bounds] was updated to [-Warray-bounds=] in error messages after r13-4410-g7c01d029fca669263b9c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107999 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above patch. Given that this failure started with r13-4410-g7c01d029fca669263b9c2, no backporting is needed. Marking as resolved.
[Bug middle-end/108990] Too restrictive precision check in fold and simplify pattern for PR70920
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108990 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=70920 Last reconfirmed||2023-03-02 Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- There are other patterns which handle different precision integeral types though. e.g. match.pd:5780 /* If possible, express the comparison in the shorter mode. */ (if ((cmp == EQ_EXPR || cmp == NE_EXPR || TYPE_UNSIGNED (TREE_TYPE (@0)) == TYPE_UNSIGNED (TREE_TYPE (@00)) || (!TYPE_UNSIGNED (TREE_TYPE (@0)) && TYPE_UNSIGNED (TREE_TYPE (@00 && (types_match (TREE_TYPE (@10), TREE_TYPE (@00)) || ((TYPE_PRECISION (TREE_TYPE (@00)) >= TYPE_PRECISION (TREE_TYPE (@10))) && (TYPE_UNSIGNED (TREE_TYPE (@00)) == TYPE_UNSIGNED (TREE_TYPE (@10 || (TREE_CODE (@10) == INTEGER_CST && INTEGRAL_TYPE_P (TREE_TYPE (@00)) && int_fits_type_p (@10, TREE_TYPE (@00) (cmp @00 (convert @10)) I wonder if the pattern for PR 70920 should be combined with the above one and fixed up.
[Bug middle-end/108992] Regression: Branch direction canonicalization leads to pointless tail duplication / CSE/sinking by inverting branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108992
--- Comment #6 from Nikita Kniazev ---
> Did you see this in real code or you just noticed this while looking at code
> generation?
If you mean do I have any benchmark - unfortunately no. I noticed it for a
while by poking different code to compare Clang codegen to GCC.
> In the first case GCC predicts that the cond is going to be true 66% of the
> time
The 66% thing is what I also noticed for a while.
> because there is comparison against 0 prediction going in the heurstics.
The duplication happens even if I make cond int and compare with any other
value
void use(int *);
void use2(int *);
void foo(int * p, int cond)
{
if (cond == 789) {
use(p);
}
use2(p);
}
[Bug tree-optimization/108997] GCC prediction on bool comparisons seems wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108997
Nikita Kniazev changed:
What|Removed |Added
CC||nok.raven at gmail dot com
--- Comment #1 from Nikita Kniazev ---
Is it about bool?
void use(int *);
void use2(int *);
void foo(int * p, int cond)
{
if (cond == 789) {
use(p);
}
use2(p);
}
