[Bug target/113030] New: ARM32: option parsing for --march= doesn't work for aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113030 Bug ID: 113030 Summary: ARM32: option parsing for --march= doesn't work for aliases Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- seen everywhere, the two last values are documented as aliases: $ awk -f config/arm/parsecpu.awk -v cmd="chkarch armv7-a+simd" config/arm/arm-cpus.in armv7-a+simd $ awk -f config/arm/parsecpu.awk -v cmd="chkarch armv7-a+neon" config/arm/arm-cpus.in error $ awk -f config/arm/parsecpu.awk -v cmd="chkarch armv7-a+neon-vfpv3" config/arm/arm-cpus.in error
[Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591 Richard Biener changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #37 from Richard Biener --- Let's do that then.
[Bug tree-optimization/109543] Avoid using BLKmode for unions with a non-BLKmode member when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109543 --- Comment #7 from Richard Biener --- Yeah, guess we still have target code doing ABI decisions based on mode ...
[Bug target/111231] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231 --- Comment #16 from Mathieu Malaterre --- Could someone from the GCC/armhf team please at least 'confirm' this bug report ? Thanks
[Bug c/80130] Wrong diagnostic: dereferencing type-punned pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80130 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #5 from Sam James --- llvm has had a few attempts at tysan as well which sort of works but never ends up getting merged.
[Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111591 --- Comment #36 from Mathieu Malaterre --- (In reply to Kewen Lin from comment #32) [...] > So IMHO #c1 test case is problematic, hi @Mathieu, could you have a double > check? I vaguely recall crafting this test-case with cvise with gcc-13. This is why it is using some kind of gcc-13 specific `__remove_reference`. I cannot verify the code using clang because of this. I also do not see anything wrong under valgrind. If the other test-case(s) (also cvise-reduced) is/are now working I would say let's close this one as fixed and if it re-appear in the original highway source code, I'll re-run yet another cvise reduction. Thanks everyone for your work ! Very much appreciated.
[Bug rtl-optimization/113029] sel-sched2 ICE in verify_target_availability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113029
Kewen Lin changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=88652
--- Comment #3 from Kewen Lin ---
(In reply to Andrew Pinski from comment #1)
> Maybe https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842#c17 patch helps
Unfortunately it doesn't help, I noticed this and tried below:
diff --git a/gcc/sel-sched.cc b/gcc/sel-sched.cc
index a35b5e16c91..8e3b3bb0467 100644
--- a/gcc/sel-sched.cc
+++ b/gcc/sel-sched.cc
@@ -323,6 +323,10 @@ struct reg_rename
/* The set of ABIs used by calls that the code motion path crosses. */
unsigned int crossed_call_abis : NUM_ABI_IDS;
+
+ /* True if we have merged expressions and one of them had availability
+ bit set. */
+ unsigned int merged_available_expr : 1;
};
/* A global structure that contains the needed information about harg
@@ -388,6 +392,10 @@ struct fur_static_params
/* The set of ABIs used by calls that the code motion path crosses. */
unsigned int crossed_call_abis : NUM_ABI_IDS;
+
+ /* True if we have merged expressions and one of them had availability
+ bit set. */
+ unsigned int merged_available_expr : 1;
};
typedef struct fur_static_params *fur_static_params_p;
@@ -1554,7 +1562,8 @@ verify_target_availability (expr_t expr, regset
used_regs,
|| !hard_available
|| (!reload_completed
&& reg_rename_p->crossed_call_abis
- && REG_N_CALLS_CROSSED (regno) == 0));
+ && REG_N_CALLS_CROSSED (regno) == 0)
+ || reg_rename_p->merged_available_expr);
}
/* Collect unavailable registers due to liveness for EXPR from BNDS
@@ -1654,6 +1663,8 @@ find_best_reg_for_expr (expr_t expr, blist_t bnds, bool
*is_orig_reg_p)
used_regs = get_clear_regset_from_pool ();
CLEAR_HARD_REG_SET (reg_rename_data.unavailable_hard_regs);
+ reg_rename_data.crossed_call_abis = false;
+ reg_rename_data.merged_available_expr = false;
collect_unavailable_regs_from_bnds (expr, bnds, used_regs, _rename_data,
_insns);
@@ -1861,7 +1872,7 @@ identical_copy_p (rtx_insn *insn)
/* Undo all transformations on *AV_PTR that were done when
moving through INSN. */
static void
-undo_transformations (av_set_t *av_ptr, rtx_insn *insn)
+undo_transformations (av_set_t *av_ptr, rtx_insn *insn, void *static_params)
{
av_set_iterator av_iter;
expr_t expr;
@@ -1940,6 +1951,8 @@ undo_transformations (av_set_t *av_ptr, rtx_insn *insn)
copy, which was in turn substituted. The history is
wrong
in this case. Do it the hard way. */
add = substitute_reg_in_expr (tmp_expr, insn, true);
+if (code_motion_path_driver_info == _hooks)
+ ((fur_static_params_p) static_params)->merged_available_expr
= true;
if (add)
av_set_add (_set, tmp_expr);
clear_expr (tmp_expr);
@@ -3273,6 +3286,7 @@ find_used_regs (insn_t insn, av_set_t orig_ops, regset
used_regs,
sparams.crossed_call_abis = 0;
sparams.original_insns = original_insns;
sparams.used_regs = used_regs;
+ sparams.merged_available_expr = false;
/* Set the appropriate hooks and data. */
code_motion_path_driver_info = _hooks;
@@ -3280,6 +3294,7 @@ find_used_regs (insn_t insn, av_set_t orig_ops, regset
used_regs,
res = code_motion_path_driver (insn, orig_ops, NULL, , );
reg_rename_p->crossed_call_abis |= sparams.crossed_call_abis;
+ reg_rename_p->merged_available_expr |= sparams.merged_available_expr;
gcc_assert (res == 1);
gcc_assert (original_insns && *original_insns);
@@ -6570,7 +6585,7 @@ code_motion_path_driver (insn_t insn, av_set_t orig_ops,
ilist_t path,
{
/* Av set ops could have been changed when moving through this
insn. To find them below it, we have to un-substitute them.
*/
- undo_transformations (_ops, insn);
+ undo_transformations (_ops, insn, static_params);
}
else
{
[Bug rtl-optimization/113029] sel-sched2 ICE in verify_target_availability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113029 --- Comment #2 from Kewen Lin --- I noticed there are some existing PRs (PR107984, PR99328, PR88652, PR84842) on verify_target_availability ICE, and in PR84842 there is a tentative patch, I tried to make it fit with the latest trunk, but this still fails, so I file this.
[Bug target/113009] [14] RISC-V: gcc.c-torture/unsorted/dump-noaddr.c flakey tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113009 --- Comment #5 from JuzheZhong --- I don't see this dump FAIL in the trunk now. Could you confirm it ?
[Bug rtl-optimization/113029] sel-sched2 ICE in verify_target_availability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113029 --- Comment #1 from Andrew Pinski --- Maybe https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84842#c17 patch helps
[Bug rtl-optimization/113029] New: sel-sched2 ICE in verify_target_availability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113029
Bug ID: 113029
Summary: sel-sched2 ICE in verify_target_availability
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: linkw at gcc dot gnu.org
Target Milestone: ---
Test case:
#include
#define c(d, g) g, d
#define e(d, g) g, d
vector double f, n;
int m;
int k;
void j (vector double, double, double);
vector double combine (double, double);
vector double i (double, double);
vector double l (vector double, double);
vector double
o (vector double, double)
{
vector double a;
vector double b;
p ("");
j (f, c (1, 2));
j (n, c (3, 4));
b = i (3, 4);
j (a, e (1, 2));
j (b, e (3, 4));
j (l (a, 5.0), e (5, 2));
j (o (b, 6.0), e (3, 6));
k = vec_extract (b, 1);
j (combine (0, k), c (2, 4));
m = vec_extract (b, 0);
j (i (0, m), e (1, 3));
i (0, vec_extract (b, 1));
}
Option: -std=c89 -O2 -mcpu=power10 -fselective-scheduling2
during RTL pass: sched2
test.c: In function ‘o’:
test.c:29:1: internal compiler error: in verify_target_availability, at
sel-sched.cc:1553
29 | }
| ^
0x10c54c43 verify_target_availability
/home/gccbuild/gcc_trunk_git/gcc/gcc/sel-sched.cc:1553
0x10c54c43 find_best_reg_for_expr
/home/gccbuild/gcc_trunk_git/gcc/gcc/sel-sched.cc:1667
0x10c54c43 fill_vec_av_set
/home/gccbuild/gcc_trunk_git/gcc/gcc/sel-sched.cc:3784
0x10cb fill_ready_list
/home/gccbuild/gcc_trunk_git/gcc/gcc/sel-sched.cc:4014
0x10cb find_best_expr
/home/gccbuild/gcc_trunk_git/gcc/gcc/sel-sched.cc:4374
0x10cb fill_insns
/home/gccbuild/gcc_trunk_git/gcc/gcc/sel-sched.cc:5535
0x10cb schedule_on_fences
/home/gccbuild/gcc_trunk_git/gcc/gcc/sel-sched.cc:7353
0x10cb sel_sched_region_2
/home/gccbuild/gcc_trunk_git/gcc/gcc/sel-sched.cc:7491
0x10c57b8b sel_sched_region_1
/home/gccbuild/gcc_trunk_git/gcc/gcc/sel-sched.cc:7533
0x10c59723 sel_sched_region(int)
/home/gccbuild/gcc_trunk_git/gcc/gcc/sel-sched.cc:7634
0x10c59723 sel_sched_region(int)
/home/gccbuild/gcc_trunk_git/gcc/gcc/sel-sched.cc:7619
0x10c59beb run_selective_scheduling()
/home/gccbuild/gcc_trunk_git/gcc/gcc/sel-sched.cc:7720
0x10c2e6ef rest_of_handle_sched2
/home/gccbuild/gcc_trunk_git/gcc/gcc/sched-rgn.cc:3748
0x10c2e6ef execute
/home/gccbuild/gcc_trunk_git/gcc/gcc/sched-rgn.cc:3895
[Bug tree-optimization/112742] missed vectorization with src[a*b+i] where a*b is not int rather than the same precision as size_type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112742 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Andrew Pinski --- I am going to take a stab at implementing this ...
[Bug c++/113020] Explicit template instantiation of template specialization using a template base class fails after extern template declaration with linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113020 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- So yes it is exactly the same as PR 104634 . *** This bug has been marked as a duplicate of bug 104634 ***
[Bug c++/104634] Explicit template instantiation does not work when there are multiple partial template specialization using concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104634 Andrew Pinski changed: What|Removed |Added CC||adrian at woeltche dot de --- Comment #2 from Andrew Pinski --- *** Bug 113020 has been marked as a duplicate of this bug. ***
[Bug c++/113020] Explicit template instantiation of template specialization using a template base class fails after extern template declaration with linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113020 --- Comment #2 from Andrew Pinski --- The commands needed to get the link error without using cmake: ``` g++ -std=c++20 -c -o main.o main.cpp g++ -std=c++20 -c -o base.o base.cpp g++ -std=c++20 -c -o sub.o sub.cpp g++ -o app main.o base.o sub.o ```
[Bug c++/113028] GCC diagnostic pop changes errors to warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113028 --- Comment #2 from Andrew Pinski --- Sorry if I was terse. This is exact same issue as reported in PR 111918 and there has been a patch that was posted to fix the issue (though I don't think it has been reviewed yet).
[Bug c++/113028] GCC diagnostic pop changes errors to warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113028 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 111918 ***
[Bug c++/111918] #pragma GCC diagnostic pop does not restore error status of -Wnarrowing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111918 Andrew Pinski changed: What|Removed |Added CC||dustbingtb at verizon dot net --- Comment #5 from Andrew Pinski --- *** Bug 113028 has been marked as a duplicate of this bug. ***
[Bug c++/113028] New: GCC diagnostic pop changes errors to warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113028
Bug ID: 113028
Summary: GCC diagnostic pop changes errors to warnings
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dustbingtb at verizon dot net
Target Milestone: ---
Target: x86_64-linux-gnu
While debugging compile errors in open-source code after upgrading gcc from
9.x, I ran into this problem with GCC diagnostic push/ignored/pop. It seems
similar to old/resolved Bug 66098/Bug 66711, except it doesn't involve any
-Werror command-line option; in fact, it can be reproduced with just "g++
testfile.cpp". This diagnostic error was added in gcc 10.x, so the specific
example isn't meaningful prior to that; however, the problem persists through
gcc 13.2 and trunk, as per godbolt.
The following code easily demonstrates all the investigative cases just by
modifying the value of TEST_CASE:
- TEST_CASE 0 shows two "error: narrowing conversion of '-2023406815' from
'int' to 'unsigned int' [-Wnarrowing]", which is apparently a correct error
diagnostic that should have been reported by earlier gcc but wasn't (at least,
earlier clang has reported this diagnostic error since at least 2012, and
handles the push/pop properly since then also, BTW).
- TEST_CASE 1 just demonstrates that, when the first error's code is removed
from compilation, the second error still fires as expected (contrast with
behavior of TEST_CASE 3).
- TEST_CASE 2 uses GCC diagnostic ignored "-Wnarrowing" to disable both errors,
which works.
- TEST_CASE 3: the bug. GCC diagnostic push/ignored suppress the first error,
but pop does NOT restore the second error; instead, the second error
mysteriously becomes a warning instead!
// 0: two errors; 1: one (2nd) error; 2: both ignored; 3: 1st ignored 2nd
warns!
#define TEST_CASE 3
int main(int argc, char *argv[])
{
const int HEX_CONST = (int)0x87654321L;
#if TEST_CASE == 3
_Pragma("GCC diagnostic push")
#endif
#if TEST_CASE >= 2
_Pragma("GCC diagnostic ignored \"-Wnarrowing\"")
#endif
unsigned uval = (unsigned)argc;
#if TEST_CASE != 1
switch (uval)
{
case HEX_CONST: ++uval;
default: break;
}
#endif // TEST_CASE != 1
#if TEST_CASE == 3
_Pragma("GCC diagnostic pop")
#endif
switch (--uval)
{
case HEX_CONST: return 0;
default: return 1;
}
}
[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971
--- Comment #20 from JuzheZhong ---
Hi, Andrew.
I saw this code which seems to cause infinite loop:
if (TREE_CODE (arg1) == VECTOR_CST
&& TREE_CODE (arg2) == VECTOR_CST
&& known_eq (TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg1)),
TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg2
{
tree type = TREE_TYPE (arg1);
bool step_ok_p;
if (VECTOR_CST_STEPPED_P (arg1)
&& VECTOR_CST_STEPPED_P (arg2))
/* We can operate directly on the encoding if:
a3 - a2 == a2 - a1 && b3 - b2 == b2 - b1
implies
(a3 op b3) - (a2 op b2) == (a2 op b2) - (a1 op b1)
Addition and subtraction are the supported operators
for which this is true. */
step_ok_p = (code == PLUS_EXPR || code == MINUS_EXPR);
else if (VECTOR_CST_STEPPED_P (arg1))
/* We can operate directly on stepped encodings if:
a3 - a2 == a2 - a1
implies:
(a3 op c) - (a2 op c) == (a2 op c) - (a1 op c)
which is true if (x -> x op c) distributes over addition. */
step_ok_p = distributes_over_addition_p (code, 1);
else
/* Similarly in reverse. */
step_ok_p = distributes_over_addition_p (code, 2);
tree_vector_builder elts;
if (!elts.new_binary_operation (type, arg1, arg2, step_ok_p))
return NULL_TREE;
unsigned int count = elts.encoded_nelts ();
for (unsigned int i = 0; i < count; ++i)
{
tree elem1 = VECTOR_CST_ELT (arg1, i);
tree elem2 = VECTOR_CST_ELT (arg2, i);
tree elt = const_binop (code, elem1, elem2);
/* It is possible that const_binop cannot handle the given
code and return NULL_TREE */
if (elt == NULL_TREE)
return NULL_TREE;
elts.quick_push (elt);
}
return elts.build ();
}
Could you give me suggestions how to fix it?
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #31 from Jerry DeLisle ---
(In reply to anlauf from comment #30)
> (In reply to Jerry DeLisle from comment #29)
> > Created attachment 56883 [details]
> > Updated Descriptions
> >
> > Fixed a few more things, The return value of tand is not in degrees.
>
> I think the following is also incorrect:
>
> @item @code{RESULT = ATAND(Y, X)}
Yes, got that one now. Thanks.
[Bug middle-end/112824] Stack spills and vector splitting with vector builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112824 --- Comment #10 from GCC Commits --- The master branch has been updated by Hongyu Wang : https://gcc.gnu.org/g:a52940cfee0908aed0d2a674a451f6d9984d commit r14-6575-ga52940cfee0908aed0d2a674a451f6d9984d Author: Hongyu Wang Date: Mon Dec 11 09:15:02 2023 +0800 i386: Sync move_max/store_max with prefer-vector-width [PR112824] Currently move_max follows the tuning feature first, but ideally it should sync with prefer-vector-width when it is explicitly set to keep vector move and operation with same vector size. gcc/ChangeLog: PR target/112824 * config/i386/i386-options.cc (ix86_option_override_internal): Sync ix86_move_max/ix86_store_max with prefer_vector_width when it is explicitly set. gcc/testsuite/ChangeLog: PR target/112824 * gcc.target/i386/pieces-memset-45.c: Remove -mprefer-vector-width=256. * g++.target/i386/pr112824-1.C: New test.
[Bug target/112387] RISC-V: failed to SLP INT64 gather load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112387 --- Comment #5 from GCC Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:4bfafea6922dffea145d1aa1d5f5fa4814e66173 commit r14-6572-g4bfafea6922dffea145d1aa1d5f5fa4814e66173 Author: Juzhe-Zhong Date: Fri Dec 15 06:24:32 2023 +0800 RISC-V: Tweak generic vector COST model Notice current generic vector cost model make PR112387 failed to vectorize. Adapt it same as ARM SVE generic vector cost model which can fix it. Committed as it is obvious fix. PR target/112387 gcc/ChangeLog: * config/riscv/riscv.cc: Adapt generic cost model same ARM SVE. gcc/testsuite/ChangeLog: * gcc.dg/vect/costmodel/riscv/rvv/pr112387.c: Moved to... * gcc.dg/vect/costmodel/riscv/rvv/pr112387-1.c: ...here. * gcc.dg/vect/costmodel/riscv/rvv/pr112387-2.c: New test.
[Bug c/111153] RISC-V: Incorrect Vector cost model for reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53 --- Comment #8 from GCC Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:c7ef2189855a8cf12427a778cd5a31d42ddf6260 commit r14-6571-gc7ef2189855a8cf12427a778cd5a31d42ddf6260 Author: Juzhe-Zhong Date: Thu Dec 14 21:45:59 2023 +0800 Middle-end: Do not model address cost for SELECT_VL style vectorization Follow Richard's suggestions, we should not model address cost in the loop vectorizer for select_vl or decrement IV since other style vectorization doesn't do that. To make cost model comparison apple to apple. This patch set COST from 2 to 1 which turns out have better codegen in various codegen for RVV. Ok for trunk ? PR target/53 gcc/ChangeLog: * tree-vect-loop.cc (vect_estimate_min_profitable_iters): Remove address cost for select_vl/decrement IV. gcc/testsuite/ChangeLog: * gcc.dg/vect/costmodel/riscv/rvv/pr53.c: Moved to... * gcc.dg/vect/costmodel/riscv/rvv/pr11153-2.c: ...here. * gcc.dg/vect/costmodel/riscv/rvv/pr53-1.c: New test.
[Bug libstdc++/106749] Implement C++23 library features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106749 Bug 106749 depends on bug 107760, which changed state. Bug 107760 Summary: Implement C++23 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107760 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libstdc++/107760] Implement C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107760 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #3 from Jonathan Wakely --- Done for GCC 14
[Bug libstdc++/107760] Implement C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107760 --- Comment #2 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:fe54b57728c09ab0389e2bb3f079d5210566199d commit r14-6569-gfe54b57728c09ab0389e2bb3f079d5210566199d Author: Jonathan Wakely Date: Thu Dec 14 23:23:34 2023 + libstdc++: Implement C++23 header [PR107760] This adds the C++23 std::print functions, which use std::format to write to a FILE stream or std::ostream (defaulting to stdout). The new extern symbols are in the libstdc++exp.a archive, so we aren't committing to stable symbols in the DSO yet. There's a UTF-8 validating and transcoding function added by this change. That can certainly be optimized, but it's internal to libstdc++exp.a so can be tweaked later at leisure. Currently the external symbols work for all targets, but are only actually used for Windows, where it's necessary to transcode to UTF-16 to write to the console. The standard seems to encourage us to also diagnose invalid UTF-8 for non-Windows targets when writing to a terminal (and only when writing to a terminal), but I'm reliably informed that that wasn't the intent of the wording. Checking for invalid UTF-8 sequences only needs to happen for Windows, which is good as checking for a terminal requires a call to isatty, and on Linux that uses an ioctl syscall, which would make std::print ten times slower! Testing the std::print behaviour is difficult if it depends on whether the output stream is connected to a Windows console or not, as we can't (as far as I know) do that non-interactively in DejaGNU. One of the new tests uses the internal __write_to_terminal function directly. That allows us to verify its UTF-8 error handling on POSIX targets, even though that's not actually used by std::print. For Windows, that __write_to_terminal function transcodes to UTF-16 but then uses WriteConsoleW which fails unless it really is writing to the console. That means the 27_io/print/2.cc test FAILs on Windows. The UTF-16 transcoding has been manually tested using mingw-w64 and Wine, and appears to work. libstdc++-v3/ChangeLog: PR libstdc++/107760 * include/Makefile.am: Add new header. * include/Makefile.in: Regenerate. * include/bits/version.def (__cpp_lib_print): Define. * include/bits/version.h: Regenerate. * include/std/format (__literal_encoding_is_utf8): New function. (_Seq_sink::view()): New member function. * include/std/ostream (vprintf_nonunicode, vprintf_unicode) (print, println): New functions. * include/std/print: New file. * src/c++23/Makefile.am: Add new source file. * src/c++23/Makefile.in: Regenerate. * src/c++23/print.cc: New file. * testsuite/27_io/basic_ostream/print/1.cc: New test. * testsuite/27_io/print/1.cc: New test. * testsuite/27_io/print/2.cc: New test.
[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971 --- Comment #19 from JuzheZhong --- OK. I think we can't reproduce same issue on ARM SVE since VNx8HI is poly size [4,4] SI mode. Wheras, RVV with zvl256b is [8,8] SImode that ARM SVE never has such size scalable SI mode. I guess Robin is going to work on it and has some ideas to fix it. Looking forward to Robin's comments.
[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971 --- Comment #18 from Andrew Pinski --- (In reply to JuzheZhong from comment #17) > Ok. Thanks for confirm it. > enough ? If it can fix our RISC-V ICE. No, that is actually the wrong place to fix it. This was just to see if that would fix the issue. The correct place to fix this is in const_binop, see comment #9 and comment #11 .
[Bug target/89606] Extra mov after structure load instructions on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89606 --- Comment #3 from Andrew Pinski --- On the trunk (20231213) for aarch64, only f2 still has extra moves.
[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971 --- Comment #17 from JuzheZhong --- Ok. Thanks for confirm it. Hi, Andrew. Is this following: ``` /* x & 0 -> 0 */ (simplify (bit_and @0 integer_zerop@1) @1) ``` to ``` /* x & 0 -> 0 */ (simplify (bit_and:c @0 integer_zerop@1) @1) ``` enough ? If it can fix our RISC-V ICE.
[Bug target/113027] New: aarch64 is missing vec_set and vec_extract for structure modes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113027
Bug ID: 113027
Summary: aarch64 is missing vec_set and vec_extract for
structure modes
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
The lack of vec_set and vec_extract optabs for structure modes means that the
following testcase spills to the stack when compiled at -O2:
#include
float64x2x2_t f1 (float64x2x2_t x) { x.val[0][1] += 1.0; return x; }
float64x2x3_t f2 (float64x2x3_t x) { x.val[0][0] = x.val[1][1] + x.val[2][0];
return x; }
float64x2x4_t f3 (float64x2x4_t x) { x.val[0][0] = x.val[1][1] + x.val[2][0] -
x.val[3][1]; return x; }
For example:
f1:
sub sp, sp, #32
fmovd31, 1.0e+0
st1 {v0.2d - v1.2d}, [sp]
ldr d30, [sp, 8]
faddd31, d31, d30
str d31, [sp, 8]
ld1 {v0.2d - v1.2d}, [sp]
add sp, sp, 32
ret
With the extra patterns, we instead get:
f1:
dup d31, v0.d[1]
fmovd30, 1.0e+0
faddd30, d31, d30
ins v0.d[1], v30.d[0]
ret
f2:
dup d31, v1.d[1]
faddd31, d31, d2
ins v0.d[0], v31.d[0]
ret
f3:
dup d31, v1.d[1]
dup d30, v3.d[1]
faddd31, d31, d2
fsubd30, d31, d30
ins v0.d[0], v30.d[0]
ret
Fixing this might also make it possible to use structure modes for arrays (c.f.
PR109543).
[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971 Patrick O'Neill changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|NEW --- Comment #16 from Patrick O'Neill --- False alarm. Looks like the vls change (which also affected pr112773) made this failure hidden on trunk. Adding -fno-vect-cost-model shows the issue: https://godbolt.org/z/fe8ETverz Trunk still has the issue.
[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971 Patrick O'Neill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Patrick O'Neill --- (In reply to JuzheZhong from comment #14) > Oh, I just take a look again. It seems that the issue is fixed on the trunk ? > > Hi, Patrick. > > https://godbolt.org/z/f1rnsYxf9 > > Could you confirm it ? > > If it is fixed, could you send a patch with the test ? > > Thanks. Yay! Will do - I'm a bit tied up today/tomorrow but I'll figure out what fixed it/send a patch when I get the chance
[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971 --- Comment #14 from JuzheZhong --- Oh, I just take a look again. It seems that the issue is fixed on the trunk ? Hi, Patrick. https://godbolt.org/z/f1rnsYxf9 Could you confirm it ? If it is fixed, could you send a patch with the test ? Thanks.
[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971 --- Comment #13 from Andrew Pinski --- (In reply to JuzheZhong from comment #12) > Thanks Andrew. > > Will you send the patch to fix this ICE for RISC-V ? I doubt I will have time to work on it really. I have not figured out just yet to produce an ARMv9-a SVE testcase but maybe next week if I do figure that out, I Might find some time to work on it.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #30 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #29)
> Created attachment 56883 [details]
> Updated Descriptions
>
> Fixed a few more things, The return value of tand is not in degrees.
I think the following is also incorrect:
@item @code{RESULT = ATAND(Y, X)}
We accept only the variant with one real argument X,
or one needs to use ATAN2D (Y, X). Another old copy bug.
ATAN is different in this respect.
[Bug middle-end/112971] [14] RISC-V rv64gcv_zvl256b vector -O3: internal compiler error: Segmentation fault signal terminated program cc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112971 --- Comment #12 from JuzheZhong --- Thanks Andrew. Will you send the patch to fix this ICE for RISC-V ? It's important for risc-v since it is ICE bug that we should land it in GCC-14 release.
[Bug analyzer/96395] Generalize gcc.dg/analyzer tests to be run with both C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96395 --- Comment #8 from GCC Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:ae034b9106fbdd855ec22ce221bb61a1a9a532c3 commit r14-6564-gae034b9106fbdd855ec22ce221bb61a1a9a532c3 Author: David Malcolm Date: Thu Dec 14 16:53:50 2023 -0500 testsuite: move more analyzer test cases to c-c++-common (3) [PR96395] Move a further 268 tests from gcc.dg/analyzer to c-c++-common/analyzer. gcc/testsuite/ChangeLog: PR analyzer/96395 * c-c++-common/analyzer/analyzer-decls.h: New header. * gcc.dg/analyzer/20020129-1.c: Move to... * c-c++-common/analyzer/20020129-1.c: ...here. * gcc.dg/analyzer/SARD-tc117-basic-1-min.c: Move to... * c-c++-common/analyzer/SARD-tc117-basic-1-min.c: ...here. * gcc.dg/analyzer/SARD-tc249-basic-00034-min.c: Move to... * c-c++-common/analyzer/SARD-tc249-basic-00034-min.c: ...here. * gcc.dg/analyzer/abort.c: Move to... * c-c++-common/analyzer/abort.c: ...here. * gcc.dg/analyzer/aliasing-1.c: Move to... * c-c++-common/analyzer/aliasing-1.c: ...here. * gcc.dg/analyzer/aliasing-2.c: Move to... * c-c++-common/analyzer/aliasing-2.c: ...here. * gcc.dg/analyzer/alloca-leak.c: Move to... * c-c++-common/analyzer/alloca-leak.c: ...here. * gcc.dg/analyzer/analyzer-debugging-fns-1.c: Move to... * c-c++-common/analyzer/analyzer-debugging-fns-1.c: ...here. * gcc.dg/analyzer/analyzer-verbosity-2a.c: Move to... * c-c++-common/analyzer/analyzer-verbosity-2a.c: ...here. * gcc.dg/analyzer/analyzer-verbosity-3a.c: Move to... * c-c++-common/analyzer/analyzer-verbosity-3a.c: ...here. * gcc.dg/analyzer/asm-x86-1.c: Move to... * c-c++-common/analyzer/asm-x86-1.c: ...here. * gcc.dg/analyzer/attr-alloc_size-3.c: Move to... * c-c++-common/analyzer/attr-alloc_size-3.c: ...here. * gcc.dg/analyzer/attr-const-1.c: Move to... * c-c++-common/analyzer/attr-const-1.c: ...here. * gcc.dg/analyzer/attr-const-2.c: Move to... * c-c++-common/analyzer/attr-const-2.c: ...here. * gcc.dg/analyzer/attr-const-3.c: Move to... * c-c++-common/analyzer/attr-const-3.c: ...here. * gcc.dg/analyzer/attr-malloc-2.c: Move to... * c-c++-common/analyzer/attr-malloc-2.c: ...here. * gcc.dg/analyzer/attr-malloc-4.c: Move to... * c-c++-common/analyzer/attr-malloc-4.c: ...here. * gcc.dg/analyzer/attr-malloc-5.c: Move to... * c-c++-common/analyzer/attr-malloc-5.c: ...here. * gcc.dg/analyzer/attr-malloc-misuses.c: Move to... * c-c++-common/analyzer/attr-malloc-misuses.c: ...here. * gcc.dg/analyzer/attr-tainted_args-misuses.c: Move to... * c-c++-common/analyzer/attr-tainted_args-misuses.c: ...here. * gcc.dg/analyzer/bzip2-arg-parse-1.c: Move to... * c-c++-common/analyzer/bzip2-arg-parse-1.c: ...here. * gcc.dg/analyzer/call-summaries-1.c: Move to... * c-c++-common/analyzer/call-summaries-1.c: ...here. * gcc.dg/analyzer/call-summaries-3.c: Move to... * c-c++-common/analyzer/call-summaries-3.c: ...here. * gcc.dg/analyzer/call-summaries-asm-x86.c: Move to... * c-c++-common/analyzer/call-summaries-asm-x86.c: ...here. * gcc.dg/analyzer/callbacks-1.c: Move to... * c-c++-common/analyzer/callbacks-1.c: ...here. * gcc.dg/analyzer/callbacks-2.c: Move to... * c-c++-common/analyzer/callbacks-2.c: ...here. * gcc.dg/analyzer/callbacks-3.c: Move to... * c-c++-common/analyzer/callbacks-3.c: ...here. * gcc.dg/analyzer/capacity-2.c: Move to... * c-c++-common/analyzer/capacity-2.c: ...here. * gcc.dg/analyzer/capacity-3.c: Move to... * c-c++-common/analyzer/capacity-3.c: ...here. * gcc.dg/analyzer/casts-1.c: Move to... * c-c++-common/analyzer/casts-1.c: ...here. * gcc.dg/analyzer/casts-2.c: Move to... * c-c++-common/analyzer/casts-2.c: ...here. * gcc.dg/analyzer/clobbers-1.c: Move to... * c-c++-common/analyzer/clobbers-1.c: ...here. * gcc.dg/analyzer/compound-assignment-4.c: Move to... * c-c++-common/analyzer/compound-assignment-4.c: ...here. * gcc.dg/analyzer/data-model-12.c: Move to... * c-c++-common/analyzer/data-model-12.c: ...here. * gcc.dg/analyzer/data-model-14.c: Move to... * c-c++-common/analyzer/data-model-14.c: ...here. * gcc.dg/analyzer/data-model-18.c: Move to... *
[Bug tree-optimization/113026] Bogus -Wstringop-overflow warning on simple memcpy type loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113026 --- Comment #1 from Andrew Pinski --- IIRC there is a known issue with Wstringop-overflow and the vectorizer ...
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #29 from Jerry DeLisle --- Created attachment 56883 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56883=edit Updated Descriptions Fixed a few more things, The return value of tand is not in degrees.
[Bug c++/113025] Pointer is sometimes assumed to be 16-byte aligned even when there is no such guarantee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113025 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- So __m128i is a 16byte aligned type, you need to use __m128i_u if it is supported.
[Bug c++/112482] error when auto(x) is used in a variable initializer (block scope)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112482 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Marek Polacek --- Fixed for GCC 14.
[Bug tree-optimization/113026] New: Bogus -Wstringop-overflow warning on simple memcpy type loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113026
Bug ID: 113026
Summary: Bogus -Wstringop-overflow warning on simple memcpy
type loop
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
Target Milestone: ---
The following testcase has a bogus warning on trunk back to at least gcc 11.
bergner@ltcden2-lp1:LTC193379$ cat bug.c
char dst[16];
long n = 16;
void
foo (char *src)
{
for (long i = 0; i < n; i++)
dst[i] = src[i];
}
bergner@ltcden2-lp1:LTC193379$ /opt/gcc-nightly/trunk/bin/gcc -S -O3
-mcpu=power8 bug.c
bug.c: In function ‘foo’:
bug.c:8:12: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
8 | dst[i] = src[i];
| ~~~^~~~
bug.c:1:6: note: at offset 16 into destination object ‘dst’ of size 16
1 | char dst[16];
| ^~~
bug.c:8:12: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
8 | dst[i] = src[i];
| ~~~^~~~
bug.c:1:6: note: at offset 17 into destination object ‘dst’ of size 16
1 | char dst[16];
| ^~~
[Bug c++/112482] error when auto(x) is used in a variable initializer (block scope)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112482
--- Comment #1 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:1ae71269890f532a2bb06b84fc49f474c16e230d
commit r14-6563-g1ae71269890f532a2bb06b84fc49f474c16e230d
Author: Marek Polacek
Date: Thu Dec 14 12:01:21 2023 -0500
c++: fix parsing with auto(x) at block scope [PR112482]
This is sort of like r14-5514, but at block scope. Consider
struct A { A(int, int); };
void
g (int a)
{
A bar(auto(a), 42); // not a fn decl
}
where we emit error: 'auto' parameter not permitted in this context
which is bogus -- bar doesn't declare a function, so the auto is OK,
but we don't know it till we've seen the second argument. The error
comes from grokdeclarator invoked just after we've parsed the auto(a).
A possible approach seems to be to delay the auto parameter checking
and only check once we know we are indeed dealing with a function
declaration. For tparms, we should still emit the error right away.
PR c++/112482
gcc/cp/ChangeLog:
* decl.cc (grokdeclarator): Do not issue the auto parameter error
while
tentatively parsing a function parameter.
* parser.cc (cp_parser_parameter_declaration_clause): Check it
here.
gcc/testsuite/ChangeLog:
* g++.dg/cpp23/auto-fncast15.C: New test.
[Bug middle-end/111260] [14 Regression] arm/aarch64: ice in maybe_legitimize_operand with ?: and constants and different types since r14-2667-gceae1400cf24f329393e96dd9720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111260 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Andrew Pinski --- Fixed.
[Bug middle-end/111260] [14 Regression] arm/aarch64: ice in maybe_legitimize_operand with ?: and constants and different types since r14-2667-gceae1400cf24f329393e96dd9720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111260 --- Comment #12 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:5fa27d9f8c4bec65887654e374146926d76690b0 commit r14-6562-g5fa27d9f8c4bec65887654e374146926d76690b0 Author: Andrew Pinski Date: Tue Dec 12 21:55:50 2023 -0800 middle-end: Fix up constant handling in emit_conditional_move [PR111260] After r14-2667-gceae1400cf24f329393e96dd9720, we force a constant to a register if it is shared with one of the other operands. The problem is used the comparison mode for the register but that could be different from the operand mode. This causes some issues on some targets. To fix it, we need to make sure the mode of the comparison matches the mode of the other operands, before we can compare the constants (CONST_INT has no modes so compare_rtx returns true if they have the same value even if the usage is in a different mode). Bootstrapped and tested on both aarch64-linux-gnu and x86_64-linux. PR middle-end/111260 gcc/ChangeLog: * optabs.cc (emit_conditional_move): Change the modes to be equal before forcing the constant to a register. gcc/testsuite/ChangeLog: * gcc.c-torture/compile/condmove-1.c: New test. Signed-off-by: Andrew Pinski
[Bug c++/113025] New: Pointer is sometimes assumed to be 16-byte aligned even when there is no such guarantee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113025 Bug ID: 113025 Summary: Pointer is sometimes assumed to be 16-byte aligned even when there is no such guarantee Product: gcc Version: 8.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: juki at gcc dot mail.kapsi.fi Target Milestone: --- The following code is miscompiled in some cases when optimization levels is -O3: // from https://github.com/intel/ARM_NEON_2_x86_SSE/blob/master/NEON_2_SSE.h #define LOAD_SI128(ptr) \ ( ((uintptr_t)(ptr) & 15) == 0 ) ? _mm_load_si128((__m128i*)(ptr)) : _mm_loadu_si128((__m128i*)(ptr)) This macro is used by several different operations in the linked header file that simulate ARM NEON intrinsics that load 128-bit long integer vector from unaligned memory addresses. With low optimization levels and most of the time anyway, function works as expected: - If pointer to the memory location is 16-byte aligned and compiler knows this, it generates opcode "movdqa" matching __mm_load_si128() intrinsic. - If pointer has unknown or non-16-byte alignment, opcode "movdqu" matching _mm_loadu_si128() intrinsic is generated and actual alignment test is optimized away as unnecessary. However, in some cases when macro is used to load 1 or 2 byte aligned data, 16-byte aligned opcode is generated instead and General Protection Fault happens due to invalid alignment. Function where this happens just gets a raw pointer, for example, const uint8_t *as an input and compiler should have no reason to assume that it would be 16-byte aligned all the time. Issue was first detected with gcc 8.4.0 but it was also verified to happen with gcc 9.4.0 and gcc 12.2.0 in different places depending on the version. gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 8.4.0-1ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 8.4.0 (Ubuntu 8.4.0-1ubuntu1~18.04) I was unable to generate a simple example when this happens and complex examples are from proprietary code. Hopefully this still helps someone to understand the issue better. What I do know at the moment: - Bug happens at least with C++ frontend when compiling for x86_64 - Bug happens with and without LTO - Bug has only happened with -O3, never with -O2 or -O1 - Bug seems to only happen in very specific cases but it is common enough to crop up in several very different algorithms that use this same operation above. - Minor changes, like changing inline keyword for a related function or changing -DNDEBUG from commandline to another setting, has a potential to "fix" the issue momentarily for that particular location. - Only the first access in the generated function with offset 0 to that pointer is wrong. Later accesses with some variable offset added to that pointer again use unaligned access like they should. - 16-byte aligned access was assumed even when the parent function was looping through different offsets with steps of 1 and calling function with miscompiled code in the same translation unit. So context has given no reason to assume 16-byte alignment for the pointer. - All tested compilers from 8.4.0 to 12.2.0 were producing the same error with the same compiler parameters but errors were not necessarily generated in the same functions. No GCC version from the tested set was found to produce only working code with full optimizations enabled. Clang does not seem to share this issue. The only thing I can think of is that during some more aggressive optimization passes, pointer somehow gets wrong alignment information attached to it. However, I know nothing of GCC's internals to understand how this could happen.
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535 --- Comment #37 from Ian Lance Taylor --- Search for this comment in the top-level configure.ac file. # Disable libgo for some systems where it is known to not work. # For testing, you can easily override this with --enable-libgo. That said if you don't configure with --enable-languages=go then you shouldn't get libgo.
[Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773 --- Comment #17 from Patrick O'Neill --- (In reply to Robin Dapp from comment #16) > I'd hope it was not fixed by this but just latent because we chose a > VLS-mode vectorization instead. Hopefully we're better off with the fix > than without :) Using -fno-vect-cost-model confirms that r14-6472-g8501edba91e didn't actually fix the problem, but it's fixed on trunk. I'll send a patch to add -fno-vect-cost-model to the testcase options.
[Bug c++/112869] [14 Regression] ICE at gimplify_expr, at gimplify.cc:17531 on libopenmpt-0.7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112869 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek --- Fixed.
[Bug c++/112869] [14 Regression] ICE at gimplify_expr, at gimplify.cc:17531 on libopenmpt-0.7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112869 --- Comment #6 from GCC Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:8cccdc2176740f3e034ee6caa49552cf2f142744 commit r14-6561-g8cccdc2176740f3e034ee6caa49552cf2f142744 Author: Marek Polacek Date: Tue Dec 5 15:23:52 2023 -0500 c++: fix ICE with sizeof in a template [PR112869] This test shows that we cannot clear *walk_subtrees in cp_fold_immediate_r when we're in_immediate_context, because that checks even e.g. sk_template_parms, and, as the comment says, affects cp_fold_r as well. Here we had an expression with min ((long int) VIEW_CONVERT_EXPR(bytecount), (long int) <<< Unknown tree: sizeof_expr (int) <<< error >>> >>>) as its sub-expression, and we never evaluated that into min ((long int) bytecount, 4) so the SIZEOF_EXPR leaked into the middle end. We need to make sure we are calling cp_fold on the SIZEOF_EXPR. PR c++/112869 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_fold_immediate_r): Check cp_unevaluated_operand and DECL_IMMEDIATE_FUNCTION_P rather than in_immediate_context. gcc/testsuite/ChangeLog: * g++.dg/template/sizeof18.C: New test.
[Bug target/113023] RISCV redundant code for loading fixed address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113023 --- Comment #5 from Andreas Schwab --- If the linker relaxation does not remove a relaxable move then it is a bug in the linker.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #28 from Steve Kargl --- On Thu, Dec 14, 2023 at 08:35:32PM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 > > --- Comment #27 from Jerry DeLisle --- > Created attachment 56882 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56882=edit > Description changes > > This is what I arrived at going through. OK? > Thanks. That looks goog, but I think we need to also update what is returned. ASIND has The real part of the result is in degrees and lies in the range -90 \leq \Re \asin(x) \leq 90. Writing the "The real part of" seems redundant if not a bit misleading.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #27 from Jerry DeLisle --- Created attachment 56882 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56882=edit Description changes This is what I arrived at going through. OK?
[Bug target/113023] RISCV redundant code for loading fixed address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113023 --- Comment #4 from Iain Finlay --- GCC does know that it needs LANCHOR0 and LANCHOR0+4 (meaning a difference of 4). The 12-bit lower portion can be provided in the load and store commands. It seems just an implementation choice in pcnt0 that it commits to the addi rather than use the lw/sw, no?
[Bug target/113023] RISCV redundant code for loading fixed address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113023 --- Comment #3 from Iain Finlay --- It does not get removed. It ends up in the final image. It is also redundant because load and store can also add a 12 bit signed offset.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #26 from Jerry DeLisle --- Auditing now
[Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773 --- Comment #16 from Robin Dapp --- I'd hope it was not fixed by this but just latent because we chose a VLS-mode vectorization instead. Hopefully we're better off with the fix than without :)
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #25 from Steve Kargl ---
On Thu, Dec 14, 2023 at 07:48:08PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
>
> --- Comment #24 from anlauf at gcc dot gnu.org ---
> (In reply to Jerry DeLisle from comment #23)
> > I am going to suggest the following. The wording was confusing around the
> > functionality of the option vs the intrinsics. Hope this is OK?
> >
> > @opindex @code{fdec-math}
> > @item -fdec-math
> > Obsolete flag. The purpose of this option was to
> > enable legacy math intrinsics such as COTAN and degree-valued trigonometric
> > functions (e.g. TAND, ATAND, etc...) for compatibility with older code. This
> > option is no longer operable. The trigonometric functions are now either
> > part of Fortran 2023 or GNU extensions.
>
> I am not a native speaker, so this is certainly better than what I wrote.
>
Your English is much better than my non-existent German. ;-)
The above is fine for the -fdec-math option. However, we'll need
to audit the description of each function to cleanup the non-support
for complex. For example, ASIND has
_Arguments_:
X The type shall be either ‘REAL’ and a magnitude
that is less than or equal to one - or be ‘COMPLEX’.
_Return value_:
The return value is of the same type and kind as X. The real part
of the result is in degrees and lies in the range -90 \leq \Re
\asin(x) \leq 90.
These should likely read
_Arguments_:
X The type shall be ‘REAL’. The magnitude of X should be
less than or equal to one.
_Return value_:
The return value is of the same type and kind as X. The
result is in degrees and lies in the range -90 \leq \Re
\asin(x) \leq 90.
[Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773 Patrick O'Neill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Patrick O'Neill --- Fixed on trunk. Weirdly this was fixed before Robin's patch by this patch: r14-6472-g8501edba91e
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #24 from anlauf at gcc dot gnu.org ---
(In reply to Jerry DeLisle from comment #23)
> I am going to suggest the following. The wording was confusing around the
> functionality of the option vs the intrinsics. Hope this is OK?
>
> @opindex @code{fdec-math}
> @item -fdec-math
> Obsolete flag. The purpose of this option was to
> enable legacy math intrinsics such as COTAN and degree-valued trigonometric
> functions (e.g. TAND, ATAND, etc...) for compatibility with older code. This
> option is no longer operable. The trigonometric functions are now either
> part of Fortran 2023 or GNU extensions.
I am not a native speaker, so this is certainly better than what I wrote.
[Bug tree-optimization/110279] [14 Regression] Regressions on aarch64 cause by handing FMA in reassoc (510.parest_r, 508.namd_r)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110279 --- Comment #5 from GCC Commits --- The master branch has been updated by Di Zhao : https://gcc.gnu.org/g:8afdbcdd7abe1e3c7a81e07f34c256e7f2dbc652 commit r14-6559-g8afdbcdd7abe1e3c7a81e07f34c256e7f2dbc652 Author: Di Zhao Date: Fri Dec 15 03:22:32 2023 +0800 Consider fully pipelined FMA in get_reassociation_width Add a new parameter param_fully_pipelined_fma. If it is non-zero, reassociation considers the benefit of parallelizing FMA's multiplication part and addition part, assuming FMUL and FMA use the same units that can also do FADD. With the patch and new option, there's ~2% improvement in spec2017 508.namd on AmpereOne. (The other options are "-Ofast -mcpu=ampere1 -flto".) PR tree-optimization/110279 gcc/ChangeLog: * doc/invoke.texi: New parameter fully-pipelined-fma. * params.opt: New parameter fully-pipelined-fma. * tree-ssa-reassoc.cc (get_mult_latency_consider_fma): Return the latency of MULT_EXPRs that can't be hidden by the FMAs. (get_reassociation_width): Search for a smaller width considering the benefit of fully pipelined FMA. (rank_ops_for_fma): Return the number of MULT_EXPRs. (reassociate_bb): Pass the number of MULT_EXPRs to get_reassociation_width; avoid calling get_reassociation_width twice. gcc/testsuite/ChangeLog: * gcc.dg/pr110279-2.c: New test.
[Bug target/113023] RISCV redundant code for loading fixed address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113023 --- Comment #2 from Andreas Schwab --- The insn is _not_ redundant, there is a relocation on it. The linker relaxation will eventually remove it when it becomes unnessessary.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #23 from Jerry DeLisle ---
I am going to suggest the following. The wording was confusing around the
functionality of the option vs the intrinsics. Hope this is OK?
@opindex @code{fdec-math}
@item -fdec-math
Obsolete flag. The purpose of this option was to
enable legacy math intrinsics such as COTAN and degree-valued trigonometric
functions (e.g. TAND, ATAND, etc...) for compatibility with older code. This
option is no longer operable. The trigonometric functions are now either
part of Fortran 2023 or GNU extensions.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #22 from Jerry DeLisle --- (In reply to anlauf from comment #20) > (In reply to Jerry DeLisle from comment #18) > > I have the patch applied. > > > > make pdf and make info work as expected. I fixed a minor typo in a comment > > for intrinsic.cc. I have a few of the git magics to do. Shall I submit to > > the list before commit? > > Have you seen my comment#14? Passed in the wind. I can go back and adjust that. No big deal.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #21 from GCC Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:95b70545331764c85079a1d0e1e19b605bda1456 commit r14-6558-g95b70545331764c85079a1d0e1e19b605bda1456 Author: Jerry DeLisle Date: Wed Dec 13 19:04:50 2023 -0800 fortran: Add degree based trig functions for F2023 PR fortran/112873 gcc/fortran/ChangeLog: * gfortran.texi: Update to reflect the changes. * intrinsic.cc (add_functions): Update the standard that the various degree trigonometric functions have been described in. (gfc_check_intrinsic_standard): Add an error string for F2023. * intrinsic.texi: Update accordingly.
[Bug target/113023] RISCV redundant code for loading fixed address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113023 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- _Z5pcnt1v: lui a5,%hi(.LANCHOR0) addia5,a5,%lo(.LANCHOR0) lw a4,4(a5) #APP # 16 "test.cpp" 1 cpop a4, a4 # 0 "" 2 #NO_APP sw a4,0(a5) ... _Z5pcnt0v: lui a5,%hi(.LANCHOR0+4) lw a0,%lo(.LANCHOR0+4)(a5) >From GCC point of view this is correct as GCC does not know if %hi(.LANCHOR0+4) == %hi(.LANCHOR0)
[Bug tree-optimization/109543] Avoid using BLKmode for unions with a non-BLKmode member when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109543 --- Comment #6 from richard.sandiford at arm dot com --- Here's a proof of concept patch that fixes the testcase for -mstrict-align. The VECTOR_MODE_P part would need to be behind a new target hook, to avoid accidentally breaking someone's ABI. For default-align, we should probably make double[4] use V4DFmode via aarch64_array_mode.
[Bug tree-optimization/109543] Avoid using BLKmode for unions with a non-BLKmode member when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109543
--- Comment #5 from Richard Sandiford ---
I think the loop in compute_mode_layout needs to be smarter
for unions. At the moment it's sensitive to field order,
which doesn't make much conceptual sense.
E.g. for the admittedly contrived example:
#include
union u1 {
int32x2x2_t x;
__int128 y __attribute__((packed));
};
union u2 {
__attribute__((packed)) __int128 y;
int32x2x2_t x;
};
compiled with -mstrict-align, the loop produces V2x2SImode for
union u1 (good!) but TImode for union u2 (requires too much alignment).
That doesn't matter as things stand, since we don't accept unions
with vector modes. But if we did, union u1 would be placed in registers
and union u2 wouldn't.
[Bug tree-optimization/113024] Nested cast not optimized out in GIMPLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113024
--- Comment #2 from Andrew Pinski ---
Confirmed.
Note if the final convert was a truncation from the original one, match is able
to remove the inner cast since r14-2890-gcc2003cd87532f (PR 93044).
That is:
```
unsigned char
foo1 (signed short x)
{
unsigned long long y = x;
return y;
}
```
Maybe that part of the pattern could be improved to catch the testcase in
comment #0 too.
[Bug tree-optimization/113024] Nested cast not optimized out in GIMPLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113024 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Last reconfirmed||2023-12-14 --- Comment #1 from Jakub Jelinek --- Created attachment 56880 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56880=edit gcc14-pr113024.patch Untested fix.
[Bug tree-optimization/113024] Nested cast not optimized out in GIMPLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113024 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords|ice-on-valid-code |missed-optimization
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #20 from anlauf at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #18) > I have the patch applied. > > make pdf and make info work as expected. I fixed a minor typo in a comment > for intrinsic.cc. I have a few of the git magics to do. Shall I submit to > the list before commit? Have you seen my comment#14?
[Bug c++/113021] [constexpr] gcc rejects initializing struct containing vector during constant evaluation depending if the struct also contains other member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113021 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-12-14 Status|UNCONFIRMED |NEW Keywords||needs-reduction --- Comment #1 from Andrew Pinski --- Confirmed. We should reduce this to remove the include file too ...
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #19 from Steve Kargl --- On Thu, Dec 14, 2023 at 05:03:35PM +, jvdelisle at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 > > --- Comment #18 from Jerry DeLisle --- > I have the patch applied. > > make pdf and make info work as expected. I fixed a minor typo in a comment > for > intrinsic.cc. I have a few of the git magics to do. Shall I submit to the list > before commit? > Given that Harald reviewed my initial submission, and you now have taken the patch and reviewed it sufficiently to find a typo, I think you can commit it. Submit whatever you've committed to the list and refer to the PR for our discussion.
[Bug c++/113020] Explicit template instantiation of template specialization using a template base class fails after extern template declaration with linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113020 --- Comment #1 from Andrew Pinski --- Side note, I wish "Compiler Explorer" was able to a simple make file instead of cmake.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #18 from Jerry DeLisle --- I have the patch applied. make pdf and make info work as expected. I fixed a minor typo in a comment for intrinsic.cc. I have a few of the git magics to do. Shall I submit to the list before commit?
[Bug target/111556] OMP_* environment variables not read if libgomp is loaded via dlopen([..], [..]|RTLD_DEEPBIND) and the process executable access the environ global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111556 --- Comment #5 from Jakub Jelinek --- The not dereferencing NULL environ is PR111413 and has been fixed already. That is something different from what is reported here, and as I said, there is nothing that can be done about it except "don't do it".
[Bug target/112999] riscv: Infinite loop with mask extraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112999 --- Comment #3 from GCC Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:e5e1999aa664333f766f3e6cc6996f769d50ae7a commit r14-6556-ge5e1999aa664333f766f3e6cc6996f769d50ae7a Author: Robin Dapp Date: Wed Dec 13 16:42:28 2023 +0100 expmed: Compare unit_precision for better mode. In extract_bit_field_1 we try to get a better vector mode before extracting from it. Better refers to the case when the requested target mode does not equal the inner mode of the vector to extract from and we have an equivalent tieable vector mode with a fitting inner mode. On riscv this triggered an ICE (PR112999) because we would take the detour of extracting from a mask-mode vector via a vector integer mode. One element of that mode could be subreg-punned with TImode which, in turn, would need to be operated on in DImode chunks. This patch adds && known_eq (bitsize, GET_MODE_UNIT_PRECISION (new_mode)) && multiple_p (bitnum, GET_MODE_UNIT_PRECISION (new_mode)) to the list of criteria for a better mode. gcc/ChangeLog: PR target/112999 * expmed.cc (extract_bit_field_1): Ensure better mode has fitting unit_precision. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/pr112999.c: New test.
[Bug target/112773] [14 Regression] RISC-V ICE: in force_align_down_and_div, at poly-int.h:1828 on rv32gcv_zvl256b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112773 --- Comment #14 from GCC Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:0a5170b5f596bb5fcedf25d93952b979d02d1f56 commit r14-6555-g0a5170b5f596bb5fcedf25d93952b979d02d1f56 Author: Robin Dapp Date: Sun Dec 3 21:55:16 2023 +0100 expmed: Use GET_MODE_PRECISION and expander's output mode. This changes the vec_extract path of extract_bit_field to use GET_MODE_PRECISION instead of GET_MODE_BITSIZE and uses the mode obtained from insn_data[icode].operand[0] as target mode. Also, it adds a vec_extractbi expander for riscv that maps to vec_extractqi. This fixes an ICE on riscv where we did not find a vec_extract optab and continued with the generic code which requires 1-byte alignment that riscv mask modes do not provide. Apart from that it adds poly_int support to riscv's vec_extract expander and makes the RVV..BImode -> QImode expander call emit_vec_extract in order not to duplicate code. gcc/ChangeLog: PR target/112773 * config/riscv/autovec.md (vec_extractbi): New expander calling vec_extractqi. * config/riscv/riscv-protos.h (riscv_legitimize_poly_move): Export. (emit_vec_extract): Change argument from poly_int64 to rtx. * config/riscv/riscv-v.cc (shuffle_extract_and_slide1up_patterns): Ditto. * config/riscv/riscv.cc (riscv_legitimize_poly_move): Export. (riscv_legitimize_move): Use rtx instead of poly_int64. * expmed.cc (store_bit_field_1): Change BITSIZE to PRECISION. (extract_bit_field_1): Change BITSIZE to PRECISION and use return mode from insn_data as target mode. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/partial/pr112773.c: New test.
[Bug target/111556] OMP_* environment variables not read if libgomp is loaded via dlopen([..], [..]|RTLD_DEEPBIND) and the process executable access the environ global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111556 Jay changed: What|Removed |Added CC||gnu.org at hovland dot cx --- Comment #4 from Jay --- Hi, I am using PHP with an extension imagick. PHP loads this extension with dlopen() and flag RTLD_DEEPBIND. At some point libgomp gets loaded in this process. During libgomp and initialize_env(), the process crashes because environ is probably not initialised yet causing line 2062 in env.c to crash at: <<< for (env = environ; *env != 0; env++) Loading the same extension without deepbind solves the problem since I guess the environ-variable gets overloaded/set by calling code, but perhaps you could add a non-NULL test ? It would probably solve the problem when using deepbind.
[Bug target/113019] [NOT A BUG] Multi-architecture binaries for Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113019 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #6 from Andrew Pinski --- Dup of bug 78464. *** This bug has been marked as a duplicate of bug 78464 ***
[Bug c/78464] Feature request: automatic function multi versioning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78464 Andrew Pinski changed: What|Removed |Added CC||aros at gmx dot com --- Comment #2 from Andrew Pinski --- *** Bug 113019 has been marked as a duplicate of this bug. ***
[Bug target/113019] [NOT A BUG] Multi-architecture binaries for Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113019 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|target Severity|normal |enhancement
[Bug tree-optimization/113024] New: Nested cast not optimized out in GIMPLE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113024
Bug ID: 113024
Summary: Nested cast not optimized out in GIMPLE
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, unassigned at gcc dot gnu.org,
zsojka at seznam dot cz
Depends on: 112941
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
+++ This bug was initially created as a clone of Bug #112941 +++
The above PR leads to a question, why don't we optimize:
unsigned int
foo (signed char x)
{
unsigned long long y = x;
return y;
}
unsigned int
bar (signed char x)
{
return (unsigned long long) x;
}
We do optimize the bar case in convert.cc's
CASE_CONVERT:
{
tree argtype = TREE_TYPE (TREE_OPERAND (expr, 0));
/* Don't introduce a "can't convert between vector values
of different size" error. */
if (TREE_CODE (argtype) == VECTOR_TYPE
&& maybe_ne (GET_MODE_SIZE (TYPE_MODE (argtype)),
GET_MODE_SIZE (TYPE_MODE (type
break;
}
/* If truncating after truncating, might as well do all at once.
If truncating after extending, we may get rid of wasted work.
*/
return convert (type, get_unwidened (TREE_OPERAND (expr, 0),
type));
This is the truncating after extending case.
Now, for
unsigned int
baz (unsigned char x)
{
unsigned long long y = x;
return y;
}
we optimize it in the match.pd
/* Likewise, if the intermediate and initial types are either both
float or both integer, we don't need the middle conversion if the
former is wider than the latter and doesn't change the signedness
(for integers). Avoid this if the final type is a pointer since
then we sometimes need the middle conversion. */
(if (((inter_int && inside_int) || (inter_float && inside_float))
&& (final_int || final_float)
&& inter_prec >= inside_prec
&& (inter_float || inter_unsignedp == inside_unsignedp))
(ocvt @0))
case.
In the foo case, we have inter_int && inside_int && final_int && inside_prec <
final_prec && final_prec < inter_prec && (!inside_unsignedp) && inter_unsignedp
&& final_unsignedp, so don't trigger the above condition.
Slightly later, there is a comment which describes the reason why 2 conversions
would be needed:
/* Two conversions in a row are not needed unless:
- some conversion is floating-point (overstrict for now), or
- some conversion is a vector (overstrict for now), or
- the intermediate type is narrower than both initial and
final, or
- the intermediate type and innermost type differ in signedness,
and the outermost type is wider than the intermediate, or
- the initial type is a pointer type and the precisions of the
intermediate and final types differ, or
- the final type is a pointer type and the precisions of the
initial and intermediate types differ. */
and I believe none of those bullets apply here, while intermediate type and
innermost type differ in signedness, the outermost type is not wider than the
intermediate.
But the actually implemented rule below it has 7 cases rather than 6.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112941
[Bug 112941] during GIMPLE pass: bitintlower ICE: in handle_operand_addr, at
gimple-lower-bitint.cc:2126 (gimple-lower-bitint.cc:2134) at -O with _BitInt()
[Bug libstdc++/109536] Failure to compile constexpr std::vector with -D_GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109536 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #6 from Jonathan Wakely --- Fixed for GCC 14
[Bug libstdc++/109536] Failure to compile constexpr std::vector with -D_GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109536 --- Comment #5 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:7d00a59229ee17af009a3c6c6208b0611740ed49 commit r14-6553-g7d00a59229ee17af009a3c6c6208b0611740ed49 Author: Jonathan Wakely Date: Wed Dec 6 13:39:52 2023 + libstdc++: Make __gnu_debug::vector usable in constant expressions [PR109536] This makes constexpr std::vector (mostly) work in Debug Mode. All safe iterator instrumentation and checking is disabled during constant evaluation, because it requires mutex locks and calls to non-inline functions defined in libstdc++.so. It should be OK to disable the safety checks, because most UB should be detected during constant evaluation anyway. We could try to enable the full checking in constexpr, but it would mean wrapping all the non-inline functions like _M_attach with an inline _M_constexpr_attach that does the iterator housekeeping inline without mutex locks when called for constant evaluation, and calls the non-inline function at runtime. That could be done in future if we find that we've lost safety or useful checking by disabling the safe iterators. There are a few test failures in C++20 mode, which I'm unable to explain. The _Safe_iterator::operator++() member gives errors for using non-constexpr functions during constant evaluation, even though those functions are guarded by std::is_constant_evaluated() checks. The same code works fine for C++23 and up. libstdc++-v3/ChangeLog: PR libstdc++/109536 * include/bits/c++config (__glibcxx_constexpr_assert): Remove macro. * include/bits/stl_algobase.h (__niter_base, __copy_move_a) (__copy_move_backward_a, __fill_a, __fill_n_a, __equal_aux) (__lexicographical_compare_aux): Add constexpr to overloads for debug mode iterators. * include/debug/helper_functions.h (__unsafe): Add constexpr. * include/debug/macros.h (_GLIBCXX_DEBUG_VERIFY_COND_AT): Remove macro, folding it into ... (_GLIBCXX_DEBUG_VERIFY_AT_F): ... here. Do not use __glibcxx_constexpr_assert. * include/debug/safe_base.h (_Safe_iterator_base): Add constexpr to some member functions. Omit attaching, detaching and checking operations during constant evaluation. * include/debug/safe_container.h (_Safe_container): Likewise. * include/debug/safe_iterator.h (_Safe_iterator): Likewise. * include/debug/safe_iterator.tcc (__niter_base, __copy_move_a) (__copy_move_backward_a, __fill_a, __fill_n_a, __equal_aux) (__lexicographical_compare_aux): Add constexpr. * include/debug/vector (_Safe_vector, vector): Add constexpr. Omit safe iterator operations during constant evaluation. * testsuite/23_containers/vector/bool/capacity/constexpr.cc: Remove dg-xfail-if for debug mode. * testsuite/23_containers/vector/bool/cmp_c++20.cc: Likewise. * testsuite/23_containers/vector/bool/cons/constexpr.cc: Likewise. * testsuite/23_containers/vector/bool/element_access/1.cc: Likewise. * testsuite/23_containers/vector/bool/element_access/constexpr.cc: Likewise. * testsuite/23_containers/vector/bool/modifiers/assign/constexpr.cc: Likewise. * testsuite/23_containers/vector/bool/modifiers/constexpr.cc: Likewise. * testsuite/23_containers/vector/bool/modifiers/swap/constexpr.cc: Likewise. * testsuite/23_containers/vector/capacity/constexpr.cc: Likewise. * testsuite/23_containers/vector/cmp_c++20.cc: Likewise. * testsuite/23_containers/vector/cons/constexpr.cc: Likewise. * testsuite/23_containers/vector/data_access/constexpr.cc: Likewise. * testsuite/23_containers/vector/element_access/constexpr.cc: Likewise. * testsuite/23_containers/vector/modifiers/assign/constexpr.cc: Likewise. * testsuite/23_containers/vector/modifiers/constexpr.cc: Likewise. * testsuite/23_containers/vector/modifiers/swap/constexpr.cc: Likewise. * testsuite/23_containers/vector/cons/destructible_debug_neg.cc: Adjust dg-error line number.
[Bug tree-optimization/113018] ICE in gimple_convert, gimple-fold.cc during the SLP pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113018 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/113018] ICE in gimple_convert, gimple-fold.cc during the SLP pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113018 --- Comment #3 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:4e9b2c94e45f5991a472fb639fb2baa6aa42b76b commit r14-6552-g4e9b2c94e45f5991a472fb639fb2baa6aa42b76b Author: Richard Biener Date: Thu Dec 14 16:00:50 2023 +0100 tree-optimization/113018 - ICE with BB reduction vectorization When BB reduction vectorization picks up a chain with an ASM def in it and that's inside the vectorized region we fail to get its LHS. Instead of trying to get the correct def the following avoids vectorizing such def and instead keeps it as def to add in the epilog. PR tree-optimization/113018 * tree-vect-slp.cc (vect_slp_check_for_roots): Only start SLP discovery from stmts with a LHS.
[Bug tree-optimization/111515] [14 Regression] Missed Dead Code Elimination since r14-4089-gd45ddc2c04e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111515
--- Comment #7 from Richard Biener ---
So like the following which disables threading ending in a
if (..)
__builtin_unreachable ();
branch when we thread to the _reachable_ side of it. We keep threading
to the __builtin_unreachable () side as that might result in resolving
earlier branches on the path. It's going to be interesting to argue
that __builtin_abort () shouldn't be treated this way (but I think
__builtin_unreachable and __builtin_unreachable_trap should not differ
for QOI reasons?)
diff --git a/gcc/tree-ssa-threadbackward.cc b/gcc/tree-ssa-threadbackward.cc
index c45f4b261ad..22f6254cf98 100644
--- a/gcc/tree-ssa-threadbackward.cc
+++ b/gcc/tree-ssa-threadbackward.cc
@@ -878,6 +878,26 @@ back_threader_profitability::profitable_path_p (const
vec _path,
"non-empty latch\n");
return false;
}
+
+ /* We don't want to duplicate a path when the branch we resolve is
+ going to be elided anyway unless we figure the path is unreachable
+ itself. */
+ edge_iterator ei;
+ edge e;
+ gcall *call;
+ FOR_EACH_EDGE (e, ei, taken_edge->src->succs)
+ if (e != taken_edge
+ && (call = safe_as_a (*gsi_last_bb (e->dest)))
+ && (gimple_call_builtin_p (call, BUILT_IN_UNREACHABLE)
+ || gimple_call_builtin_p (call, BUILT_IN_UNREACHABLE_TRAP)))
+ {
+ if (dump_file && (dump_flags & TDF_DETAILS))
+ fprintf (dump_file,
+" FAIL: Thread ends on the reachable side of a branch "
+"to unreachable\n");
+ return false;
+ }
+
if (dump_file && (dump_flags & TDF_DETAILS))
fputc ('\n', dump_file);
return true;
[Bug libstdc++/113007] `std::variant` converting constructor and `operator=` compile while the C++ Standard says they must not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113007 --- Comment #7 from Pavel Novikov --- (In reply to Jonathan Wakely from comment #5&6) Got it. Thank you for taking the time to expansively explain what I left out, and confirming my understanding. Now it's time to file a bug in MSVC's standard library.
[Bug tree-optimization/112941] during GIMPLE pass: bitintlower ICE: in handle_operand_addr, at gimple-lower-bitint.cc:2126 (gimple-lower-bitint.cc:2134) at -O with _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112941
--- Comment #3 from Jakub Jelinek ---
Simplified:
unsigned _BitInt(2049)
foo (unsigned _BitInt(6384) x, _BitInt(8) y)
{
return x * y;
}
_BitInt(2049)
bar (unsigned _BitInt(6384) x, _BitInt(1023) y)
{
return x * y;
}
[Bug tree-optimization/112793] [11/12/13 regression] ICE when building stellarium (internal compiler error: in vect_schedule_slp_node, at tree-vect-slp.cc:9062)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112793 Richard Biener changed: What|Removed |Added Target Milestone|14.0|11.5 Summary|[14 regression] ICE when|[11/12/13 regression] ICE |building stellarium |when building stellarium |(internal compiler error: |(internal compiler error: |in vect_schedule_slp_node, |in vect_schedule_slp_node, |at tree-vect-slp.cc:9062) |at tree-vect-slp.cc:9062) Known to work||14.0 Priority|P3 |P2 --- Comment #14 from Richard Biener --- Fixed on trunk. As said, I think the issue is latent so I'm marking it for backporting.
[Bug target/112906] [14 Regression] aarch64: ICE with SVE ACLE code at -O2 since r14-3981-g0f1f6cf87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112906 Alex Coplan changed: What|Removed |Added Keywords||patch --- Comment #4 from Alex Coplan --- Patches posted (and approved subject to no further comments from Vlad): https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640535.html https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640536.html
[Bug tree-optimization/112793] [14 regression] ICE when building stellarium (internal compiler error: in vect_schedule_slp_node, at tree-vect-slp.cc:9062)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112793 --- Comment #13 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:d782ec8362eadc3169286eb1e39c631effd02323 commit r14-6550-gd782ec8362eadc3169286eb1e39c631effd02323 Author: Richard Biener Date: Wed Dec 13 14:23:31 2023 +0100 tree-optimization/112793 - SLP of constant/external code-generated twice The following makes the attempt at code-generating a constant/external SLP node twice well-formed as that can happen when partitioning BB vectorization attempts where we keep constants/externals unpartitioned. PR tree-optimization/112793 * tree-vect-slp.cc (vect_schedule_slp_node): Already code-generated constant/external nodes are OK. * g++.dg/vect/pr112793.cc: New testcase.
[Bug c++/113023] New: RISCV redundant code for loading fixed address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113023 Bug ID: 113023 Summary: RISCV redundant code for loading fixed address Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: iwfinlay at gmail dot com Target Milestone: --- Created attachment 56879 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56879=edit Save temps from: riscv64-unknown-elf-g++ --save-temps -march=rv32imv_zbb_zbs -mabi=ilp32 -O3 -Wall -Wextra -c test.cpp Load immediate of a constant leaves a redundant addi x, x, 0 (aka mv x, x) for the lower bits of the constant in some cases. The generated code is functionally correct but loses performance. void pcnt0() updates a global structure. int pcnt1() returns the value. Both access the global structure for the input but pcnt0() has the redundant mv a5, a5. Note that the use of cpop is not significant (other functions show the same behavior in the attached test case). Disassembly of section .text: 0028 <_Z5pcnt0v>: 28: 07b7lui a5,0x0 2c: 00078793mv a5,a5 30: 0047a703lw a4,4(a5) # 4 <_Z6globalv+0x4> 34: 60271713cpopa4,a4 38: 00e7a023sw a4,0(a5) 3c: 8067ret 0040 <_Z5pcnt1v>: 40: 07b7lui a5,0x0 44: 0047a503lw a0,4(a5) # 4 <_Z6globalv+0x4> 48: 60251513cpopa0,a0 4c: 8067ret riscv64-unknown-elf-g++ --save-temps -march=rv32imv_zbb_zbs -mabi=ilp32 -O3 -Wall -Wextra -c test.cpp riscv64-unknown-elf-objdump -d test.o > test.asm (subset shown above) A brew install of GCC for RISCV is used for this case. The problem originated in client code with a customized compiler build (also 12.2).
[Bug target/113022] New: GCN offloading bricked by "amdgcn: Work around XNACK register allocation problem"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113022 Bug ID: 113022 Summary: GCN offloading bricked by "amdgcn: Work around XNACK register allocation problem" Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: openacc, openmp, testsuite-fail Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org CC: ams at gcc dot gnu.org, jules at gcc dot gnu.org Target Milestone: --- Target: GCN I've not seen a problem in GCN target testing, but GCN offloading -- at least in my testing -- is bricked (for non-'-march=gfx90a'?) by the recent commit r14-6503-g4c12bcbeb0c0fd6da4c56e7622814201daadd585 "amdgcn: Work around XNACK register allocation problem": /tmp/ccwsYf5g.mkoffload.2.s:1:17: error: .amdgcn_target directive's target id amdgcn-unknown-amdhsa--gfx900:xnack- does not match the specified target id amdgcn-unknown-amdhsa--gfx900 .amdgcn_target "amdgcn-unknown-amdhsa--gfx900:xnack-" ^ /tmp/ccwsYf5g.mkoffload.2.s:29:4: error: .amdhsa_reserve_xnack_mask does not match target id .amdhsa_reserve_xnack_mask0 ^~ [...] Reverting that commit is my workaround for the time being. Is maybe simply something missing in GCN 'mkoffload'?
[Bug rtl-optimization/113019] [NOT A BUG] Multi-architecture binaries for Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113019 --- Comment #5 from Artem S. Tashkinov --- (In reply to ktkachov from comment #1) > GCC provides the Function Multiversioning feature that's supported on some > architectures: > https://gcc.gnu.org/onlinedocs/gcc/Function-Multiversioning.html > > That seems to do what you want? This can only be achieved manually by rewriting everything, while I was thinking about something compiler-side which you can enabled as a compile option.
[Bug rtl-optimization/113019] [NOT A BUG] Multi-architecture binaries for Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113019 --- Comment #3 from ultrafine at gmx dot com --- Yeah, I'm looking forward to being able to compile this way: -march=x86-64 -mextra-arch=x86-64-v3 And do _nothing_ else and get a single binary. And then at runtime the appropriate code for the detected uArch gets executed. --- Comment #4 from ultrafine at gmx dot com --- To make it simple Linux distros seemingly want to be able to compile a single binary (application or shared library) which has two distinct code paths for different flavours of the x86-64 arch to extract maximum performance from it regardless of the CPU it's being executed on.
