[Bug c++/56289] Bad location for unused value warning with comma operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56289 Gayathri Gottumukkala changed: What|Removed |Added CC||gayathri.gottumukkala.27@gm ||ail.com --- Comment #5 from Gayathri Gottumukkala --- We cannot cast the two variables in single line using void. Instead of that we have to use void for two variables separately.
[Bug c++/65350] [C++14] operator new[] should not be called if # of initializer elements exceeds # of elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65350 Gayathri Gottumukkala changed: What|Removed |Added CC||gayathri.gottumukkala.27@gm ||ail.com --- Comment #4 from Gayathri Gottumukkala --- "cout" statement is executed before the exception is raised, hence two lines are printed as output.
[Bug c++/70352] [C++11] auto cannot be used in the type-id of a new-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70352 Gayathri Gottumukkala changed: What|Removed |Added CC||gayathri.gottumukkala.27@gm ||ail.com --- Comment #3 from Gayathri Gottumukkala --- Syntax error, by removing braces and by releasing the memory of variable, the code is getting compiled.
[Bug c++/111316] std::vector's operator < does not work with recursive data type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111316 --- Comment #3 from Andrew Pinski --- See https://cplusplus.github.io/CWG/issues/2369.html
[Bug c++/111316] std::vector's operator < does not work with recursive data type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111316 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=99599 --- Comment #2 from Andrew Pinski --- Most likely a dup of bug 99599.
[Bug c++/111316] std::vector's operator < does not work with recursive data type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111316 --- Comment #1 from Andrew Pinski --- Yes and GCC is the only compiler which implements the atomic constraint rule for C++20.
[Bug c++/111316] New: std::vector's operator < does not work with recursive data type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111316
Bug ID: 111316
Summary: std::vector's operator < does not work with recursive
data type
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xgao at nvidia dot com
Target Milestone: ---
Created attachment 55847
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55847=edit
minimum repro
The attached minimal repro does not work on g++ on C++20, but it works with g++
on C++17 and clang++ on both C++17 and C++20. See the code for detail:
Error message:
/usr/include/c++/13.2.1/compare:1216:18: error: satisfaction of atomic
constraint ‘requires{{__t < __u} -> decltype(auto) [requires
std::__detail::__boolean_testable<, >];{__u < __t} ->
decltype(auto) [requires std::__detail::__boolean_testable<, >];}
[with _Tp = _Tp; _Up = _Up]’ depends on itself
[Bug libstdc++/111315] libstdc++ stacktrace testsuite failures with --enable-default-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111315 --- Comment #1 from Andrew Pinski --- Hmm, is libbacktrace not working with PIE applications ...
[Bug c++/111314] Can not deduct parameter pack as a single type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111314
--- Comment #2 from Andrew Pinski ---
If change DynamicType to a variable length template, then it works; that is:
template class, typename...>
struct DynamicType {};
[Bug libstdc++/111315] New: libstdc++ stacktrace testsuite failures with --enable-default-pie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111315 Bug ID: 111315 Summary: libstdc++ stacktrace testsuite failures with --enable-default-pie Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rimvydas.jas at gmail dot com Target Milestone: --- The GCC configured with --enable-default-pie gives: === libstdc++ tests === Running target unix FAIL: 19_diagnostics/stacktrace/entry.cc execution test FAIL: 19_diagnostics/stacktrace/stacktrace.cc execution test libstdc++-v3/testsuite/19_diagnostics/stacktrace/entry.cc:39: void test_members(): Assertion 'e1.source_line() == (__LINE__ - 5)' failed. libstdc++-v3/testsuite/19_diagnostics/stacktrace/stacktrace.cc:132: void test_assign(): Assertion 's0.at(0).source_line() == (__LINE__ - 4)' failed. In both cases source_line() methods return 0. Also, the -fno-pie option cannot be used when linking these tescases: /usr/bin/ld: /tmp/ccv2BTff.o: relocation R_X86_64_32 against symbol `_ZNSt16stacktrace_entry14_S_err_handlerEPvPKci' can not be used when making a PIE object; recompile with -fPIE
[Bug c++/111314] Can not deduct parameter pack as a single type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111314
--- Comment #1 from Andrew Pinski ---
Reduced testcase:
template
struct Template1 {};
template class, typename>
struct DynamicType {};
template
struct is_dynamic_type
{ static constexpr bool value = false; };
template class Template, typename... Ts>
struct is_dynamic_type>
{ static constexpr bool value = true; };
// This fails:
static_assert(is_dynamic_type>::value, "");
[Bug target/111313] RISC-V: Incorrect vsetvl code gen for 2 level loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111313 --- Comment #1 from CVS Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:572abb52f5761a647035ee39d0e443c1c3622e75 commit r14-3765-g572abb52f5761a647035ee39d0e443c1c3622e75 Author: Juzhe-Zhong Date: Thu Sep 7 11:35:53 2023 +0800 RISC-V: Remove incorrect earliest vsetvl post optimization[PR111313] This patch removes the incorrect earliest poset vsetvl optimization, such bug was found in vect-double-reduc-5.c which is runtime(execution fail) and also in PR111313. For VLMAX intrinsics, we always emit a bogus patter which is vlmax_avl (see vector.md) to occupy a scalar register which is used by the following RVV instruction which is VLMAX AVL. Then for O2, O3, Ofast, earliest LCM works so well. However, for O1, the vlmax_avl is not well optimized in the before pass which confused LCM earliest so that we will end up with some redundant vsetvli zero,zero instructions in O1. (Note that O2 O3 Ofast are all good). To elide those redundant vsetvli zero,zero, I added cleanup_earliest_vsetvls to elide those redundant vsetvls. Now, after I review the implementation of this post optimizaiton again, I found it is incorrect and it is hard to do the post optimizations for vsetvls that earliest LCM failed to eliminate. Besides, such performance issues only happen in O1 or O0, such issues may not be serious. So remove it and we may will find another way (E.g. adjust vlmax_avl pattern COST) to optimize it if we really need to care about performance for O1. PR target/111313 gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (pass_vsetvl::cleanup_earliest_vsetvls): Remove. (pass_vsetvl::df_post_optimization): Remove incorrect function. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/vsetvl/avl_single-13.c: Adapt test. * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-17.c: Skip check for O1. * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-18.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-19.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_bb_prop-20.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-1.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-10.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-11.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-12.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-13.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-14.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-15.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-16.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-17.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-18.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-19.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-2.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-20.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-21.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-22.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-23.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-24.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-25.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-26.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-27.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-28.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-3.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-4.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-5.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-6.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-7.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-8.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_phi-9.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_switch_vtype-2.c: Ditto. * gcc.target/riscv/rvv/autovec/pr111313.c: New test.
[Bug c++/111314] New: Can not deduct parameter pack as a single type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111314
Bug ID: 111314
Summary: Can not deduct parameter pack as a single type
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: xgao at nvidia dot com
Target Milestone: ---
The following code does not work:
#include
template
struct Template {};
template typename, typename>
struct DynamicType {};
template
struct is_dynamic_type : std::false_type {};
template typename Template, typename... Ts>
struct is_dynamic_type> : std::true_type {};
template
constexpr bool is_dynamic_type_v = is_dynamic_type::value;
// This fails:
static_assert(is_dynamic_type_v>);
int main() {}
[Bug tree-optimization/111268] [14 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111268
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-09-07
Ever confirmed|0 |1
--- Comment #8 from Andrew Pinski ---
Reduced testcase:
```
#include
void f(unsigned long *expected, svuint64_t values) {
svst1_u64(svptrue_b64(), expected, values);
expected[0] = (expected[0]+1);
expected[1] = (expected[1]+1);
}
```
[Bug c/111313] New: RISC-V: Incorrect code gen for 2 level loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111313
Bug ID: 111313
Summary: RISC-V: Incorrect code gen for 2 level loop
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pan2.li at intel dot com
Target Milestone: ---
Created attachment 55846
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55846=edit
Reproduce code
Given we have an example code as below.
#define K 32
signed short in[2*K][K] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
signed short coeff[K][K] __attribute__ ((__aligned__(__BIGGEST_ALIGNMENT__)));
__attribute__ ((noinline)) void
test ()
{
for (int j = 0; j < K; j++)
{
for (int i = 0; i < 2*K; i++)
in[i][j] = i+j;
for (int i = 0; i < K; i++)
coeff[i][j] = i + 2;
}
}
When compile with option similar to "-march=rv64imafdcv -mabi=lp64d
-mcmodel=medlow -fdiagnostics-plain-output -flto -ffat-lto-objects --param
riscv-autovec-preference=scalable -Wno-psabi -ftree-vectorize
-fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common
-fdump-tree-vect-details "
The assembly code will be:
init_in:
lui t1,%hi(coeff)
lui a7,%hi(in)
csrra0,vlenb
addit1,t1,%lo(coeff)
addia7,a7,%lo(in)
srlia0,a0,2
li a6,0
li t3,32
vsetvli a1,zero,e16,mf2,ta,ma
vid.v v3
vsll.vi v3,v3,6
.L2:
mv a2,a7
li a4,64
vmv.v.x v4,a6 <= this insn will have e16 first, and then e32 when loop
back
vsetvli zero,zero,e32,m1,ta,ma
vid.v v2
.L3:
vsetvli zero,zero,e16,mf2,ta,ma
vmv1r.v v1,v2
vncvt.x.x.w v1,v1
vsetvli a5,a4,e8,mf4,ta,ma
vsetvli a3,zero,e16,mf2,ta,ma
sub a4,a4,a5
vadd.vv v1,v1,v4
vsetvli zero,a5,e16,mf2,ta,ma
sllia5,a5,6
vsuxei16.v v1,(a2),v3
vsetvli a1,zero,e32,m1,ta,ma
add a2,a2,a5
vmv.v.x v1,a0
vadd.vv v2,v2,v1
bne a4,zero,.L3
mv a2,t1
li a4,32
vid.v v2
.L4:
vsetvli zero,zero,e16,mf2,ta,ma
vmv1r.v v1,v2
vncvt.x.x.w v1,v1
vsetvli a5,a4,e8,mf4,ta,ma
vsetvli a3,zero,e16,mf2,ta,ma
sub a4,a4,a5
vadd.vi v1,v1,2
vsetvli zero,a5,e16,mf2,ta,ma
sllia5,a5,6
vsuxei16.v v1,(a2),v3
vsetvli a1,zero,e32,m1,ta,ma
add a2,a2,a5
vmv.v.x v1,a0
vadd.vv v2,v2,v1
bne a4,zero,.L4
addiw a6,a6,1
addit1,t1,2
addia7,a7,2
bne a6,t3,.L2
ret
[Bug go/111310] BITINT_TYPE unsupported in godump.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111310 Ian Lance Taylor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Ian Lance Taylor --- Thanks, fixed.
[Bug tree-optimization/111303] [14 Regression] ICE: in type, at value-range.h:869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303 Andrew Pinski changed: What|Removed |Added Summary|ICE: in type, at|[14 Regression] ICE: in |value-range.h:869 |type, at value-range.h:869 Keywords||ice-on-valid-code Status|NEW |ASSIGNED Component|c |tree-optimization
[Bug target/111311] RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311 --- Comment #2 from JuzheZhong --- All FAILS in this PR are not a big deal which will be easily addressed (except LTO). We should enable vect.exp tests which have full coverage of vector tests. But we are still have 2 real FAILS (current 46FAILS = 44 dump FAILs and 2 execution FAILs). https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628838.html I am waiting for those 2 real FAILS are fixed then merge that patch.
[Bug go/111310] BITINT_TYPE unsupported in godump.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111310 --- Comment #1 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:e4775af423a590947a10429b9fa889f5d3d41d40 commit r14-3762-ge4775af423a590947a10429b9fa889f5d3d41d40 Author: Ian Lance Taylor Date: Wed Sep 6 15:09:31 2023 -0700 -fgo-dump-spec: support _BitInt gcc/ PR go/111310 * godump.cc (go_format_type): Handle BITINT_TYPE. gcc/testsuite/ PR go/111310 * gcc.misc-tests/godump-1.c: Add _BitInt test cases.
[Bug target/111311] RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111311 --- Comment #1 from JuzheZhong --- Except the known issue (LTO issue). All other issues are either bugus FAILS or very simple bugs. Fixing them just need a few days (maybe 2 ~ 3days). I will fix them first before sending new feature patches and the future new patches should always pass all regression tests with enablig vector extension.
[Bug analyzer/110520] -Wanalyzer-null-dereference false nagetive with `*ptr = 10086`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110520 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-09-06 --- Comment #1 from David Malcolm --- Thanks for filing this bug. With trunk (for gcc 14) I correctly get a NPD warning (true positive): https://godbolt.org/z/a5h38cz7d With gcc 13.2, I don't (false negative): https://godbolt.org/z/PKnToYK8v I've been rewriting C string handling for gcc 14, so it's likely this now working is a side-effect of that. Keeping open to track adding a regression test for this.
[Bug analyzer/111095] -Wanalyzer-out-of-bounds false negative with `return l_1322[9];` at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111095 --- Comment #2 from David Malcolm --- (In reply to David Malcolm from comment #1) [...] > I'll open a bug about that. Filed as bug 111312; made this one block that one.
[Bug analyzer/111213] -Wanalyzer-out-of-bounds false negative with `return arr[9];` at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111213 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-09-06 Ever confirmed|0 |1 --- Comment #2 from David Malcolm --- (In reply to David Malcolm from comment #1) [...] > If that's the case, that's a strong argument that the analyzer should run > earlier. I'm not sure if we have an existing bug about that. Filed as bug 111312; made this one block that one.
[Bug analyzer/111312] New: Should the analyzer run earlier?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111312
Bug ID: 111312
Summary: Should the analyzer run earlier?
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Blocks: 111095, 111213
Target Milestone: ---
I made the analyzer run when it does in order to take advantage of the LTO
streaming representation.
But:
I'm having to recommend disabling optimizations for various -fanalyzer
warnings:
* -Wanalyzer-deref-before-check
* -Wanalyzer-infinite-recursion
* -Wanalyzer-tainted-assertion
and eventually:
* -Wanalyzer-infinite-loop (work-in-progess; see bug 106147)
Also, various bugs are showing up where the analyzer fails to warn on clearly
wrong code (presumably due to the optimizer removing code containing undefined
behavior before the analyzer ever sees it; see e.g. bug 111095 and bug 111213).
Also: there's a tension between warnings and optimization: the optimizer takes
advantage of undefined behavior (assuming it's not present), but we want to
complain about the presence of undefined behavior.
Plus it's better to report things to the user in a form closer to that in which
they wrote the code.
When should we run?
* immediately after we reach "generic"
* could give us per-argument locations at call sites
* once we're in gimple-cfg (but no ssa?)
* once we're in gimple-ssa
Costs/Benefits of running at different times
* is inlining saving us?
* do we want to use the callgraph?
* do we want to use the loop information? (see bug 109252)
* do we want to use ranger? (need SSA)
* do we want to use the CFGs?
* do we want to reuse ipa-devirt?
* presumably we don't want to reimplement lowering of OpenMP, exceptions, etc
* PR analyzer/100116 ("analyzer event messages for conditionals have the
sense of the gimple IR rather than the source")
We're not currently analyzing the user's code, we're analyzing the user's code
after the optimizer has manipulated it, taking advantage of undefined behavior.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111095
[Bug 111095] -Wanalyzer-out-of-bounds false negative with `return l_1322[9];`
at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111213
[Bug 111213] -Wanalyzer-out-of-bounds false negative with `return arr[9];` at
-O1 and above
[Bug analyzer/111095] -Wanalyzer-out-of-bounds false negative with `return l_1322[9];` at -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111095 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Summary|-Wanalyzer-out-of-bounds|-Wanalyzer-out-of-bounds |false negative with `return |false negative with `return |l_1322[9];` |l_1322[9];` at -O1 and ||above Last reconfirmed||2023-09-06 --- Comment #1 from David Malcolm --- Thanks for filing this bug. This looks similar to bug 111213. Adding -fdump-ipa-analyzer=stderr shows that at -O1 and above, the entire body of the function is optimized away before the analyzer even sees it (presumably due to undefined behavior). My hypothesis is that the optimizer sees the undefined behavior and optimizes the function away (but I haven't checked the details). If that's the case, that's a strong argument that the analyzer should run earlier. I'll open a bug about that.
[Bug target/111311] New: RISC-V regression testsuite errors with --param=riscv-autovec-preference=scalable
ill-4.c check-function-bodies spill_5 UNRESOLVED: gcc.target/riscv/rvv/base/spill-4.c check-function-bodies spill_6 UNRESOLVED: gcc.target/riscv/rvv/base/spill-4.c check-function-bodies spill_7 FAIL: gcc.target/riscv/rvv/base/spill-5.c (internal compiler error: in partial_subreg_p, at rtl.h:3186) FAIL: gcc.target/riscv/rvv/base/spill-5.c (test for excess errors) UNRESOLVED: gcc.target/riscv/rvv/base/spill-5.c check-function-bodies spill_3 UNRESOLVED: gcc.target/riscv/rvv/base/spill-5.c check-function-bodies spill_4 UNRESOLVED: gcc.target/riscv/rvv/base/spill-5.c check-function-bodies spill_5 UNRESOLVED: gcc.target/riscv/rvv/base/spill-5.c check-function-bodies spill_6 UNRESOLVED: gcc.target/riscv/rvv/base/spill-5.c check-function-bodies spill_7 FAIL: gcc.target/riscv/rvv/base/spill-6.c (internal compiler error: in partial_subreg_p, at rtl.h:3186) FAIL: gcc.target/riscv/rvv/base/spill-6.c (test for excess errors) UNRESOLVED: gcc.target/riscv/rvv/base/spill-6.c check-function-bodies spill_4 UNRESOLVED: gcc.target/riscv/rvv/base/spill-6.c check-function-bodies spill_5 UNRESOLVED: gcc.target/riscv/rvv/base/spill-6.c check-function-bodies spill_6 UNRESOLVED: gcc.target/riscv/rvv/base/spill-6.c check-function-bodies spill_7 FAIL: gcc.target/riscv/rvv/base/spill-sp-adjust.c (internal compiler error: in partial_subreg_p, at rtl.h:3186) FAIL: gcc.target/riscv/rvv/base/spill-sp-adjust.c (test for excess errors) UNRESOLVED: gcc.target/riscv/rvv/base/spill-sp-adjust.c scan-assembler-not addi\\tsp,sp,0 FAIL: gcc.target/riscv/rvv/base/vector-abi-4.c (test for bogus messages, line 9) === gcc Summary === # of expected passes180698 # of unexpected failures716 # of unexpected successes 7 # of expected failures 1257 # of unresolved testcases 442 # of unsupported tests 3412 /home/rdapp/projects/gcc/build/gcc/xgcc version 14.0.0 20230906 (experimental) (GCC) Host is x86_64-pc-linux-gnu === g++ tests === Running target unix/-march=rv64gcv/--param=riscv-autovec-preference=scalable WARNING: Assuming target board is the local machine (which is probably wrong). FAIL: c-c++-common/opaque-vector.c -std=c++14 (internal compiler error: in emit_move_multi_word, at expr.cc:4079) FAIL: c-c++-common/opaque-vector.c -std=c++14 (test for excess errors) FAIL: c-c++-common/opaque-vector.c -std=c++17 (internal compiler error: in emit_move_multi_word, at expr.cc:4079) FAIL: c-c++-common/opaque-vector.c -std=c++17 (test for excess errors) FAIL: c-c++-common/opaque-vector.c -std=c++20 (internal compiler error: in emit_move_multi_word, at expr.cc:4079) FAIL: c-c++-common/opaque-vector.c -std=c++20 (test for excess errors) FAIL: c-c++-common/opaque-vector.c -std=c++98 (internal compiler error: in emit_move_multi_word, at expr.cc:4079) FAIL: c-c++-common/opaque-vector.c -std=c++98 (test for excess errors) FAIL: c-c++-common/pr105998.c -std=c++14 (internal compiler error: in emit_move_multi_word, at expr.cc:4079) FAIL: c-c++-common/pr105998.c -std=c++14 (test for excess errors) FAIL: c-c++-common/pr105998.c -std=c++17 (internal compiler error: in emit_move_multi_word, at expr.cc:4079) FAIL: c-c++-common/pr105998.c -std=c++17 (test for excess errors) FAIL: c-c++-common/pr105998.c -std=c++20 (internal compiler error: in emit_move_multi_word, at expr.cc:4079) FAIL: c-c++-common/pr105998.c -std=c++20 (test for excess errors) FAIL: c-c++-common/pr105998.c -std=c++98 (internal compiler error: in emit_move_multi_word, at expr.cc:4079) FAIL: c-c++-common/pr105998.c -std=c++98 (test for excess errors) FAIL: c-c++-common/scal-to-vec2.c -std=gnu++14 (test for excess errors) FAIL: c-c++-common/scal-to-vec2.c -std=gnu++17 (test for excess errors) FAIL: c-c++-common/scal-to-vec2.c -std=gnu++20 (test for excess errors) FAIL: c-c++-common/scal-to-vec2.c -std=gnu++98 (test for excess errors) FAIL: c-c++-common/spec-barrier-1.c -std=gnu++14 (test for excess errors) FAIL: c-c++-common/spec-barrier-1.c -std=gnu++17 (test for excess errors) FAIL: c-c++-common/spec-barrier-1.c -std=gnu++20 (test for excess errors) FAIL: c-c++-common/spec-barrier-1.c -std=gnu++98 (test for excess errors) FAIL: c-c++-common/vector-compare-1.c -std=gnu++14 (test for excess errors) FAIL: c-c++-common/vector-compare-1.c -std=gnu++17 (test for excess errors) FAIL: c-c++-common/vector-compare-1.c -std=gnu++20 (test for excess errors) FAIL: c-c++-common/vector-compare-1.c -std=gnu++98 (test for excess errors) FAIL: c-c++-common/vector-compare-2.c -std=gnu++14 (test for excess errors) FAIL: c-c++-common/vector-compare-2.c -std=gnu++17 (test for excess errors) FAIL: c-c++-common/vector-compare-2.c -std=gnu++20 (test for excess errors) FAIL: c-c++-common/vector-compare-2.c -std=gnu++98 (test for excess errors) FAIL: c-c++-common/vector-scalar.c -std=c++14 (internal compiler error: in emit_move_multi_word, at expr.cc:4079) FAIL: c-c++-common/vector-scalar.c -std=c++14 (test for exc
[Bug go/111310] New: BITINT_TYPE unsupported in godump.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111310 Bug ID: 111310 Summary: BITINT_TYPE unsupported in godump.cc Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: go Assignee: ian at airs dot com Reporter: pinskia at gcc dot gnu.org CC: adam.warner.nz at gmail dot com, alx at kernel dot org, bergner at gcc dot gnu.org, charlet at gcc dot gnu.org, chfast at gmail dot com, dje at gcc dot gnu.org, dkm at gcc dot gnu.org, ebotcazou at gcc dot gnu.org, fw at gcc dot gnu.org, george at bott dot gg, hjl.tools at gmail dot com, jakub at gcc dot gnu.org, jsm28 at gcc dot gnu.org, leni536 at gmail dot com, rguenth at gcc dot gnu.org, rsandifo at gcc dot gnu.org, segher at gcc dot gnu.org, sjames at gcc dot gnu.org, tmgross at umich dot edu, unassigned at gcc dot gnu.org, uweigand at gcc dot gnu.org Depends on: 102989, 111308 Target Milestone: --- +++ This bug was initially created as a clone of Bug #111308 +++ +++ This bug was initially created as a clone of Bug #102989 +++ BITINT_TYPE support to godump.cc, as I have no idea what you want to do in go for that. Example of problematic declaration in some header (so far on x86-64) would be extern _BitInt(157) foo (unsigned _BitInt(384) x, signed _BitInt(15) y, int z); Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 [Bug 102989] Implement C2x's n2763 (_BitInt) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111308 [Bug 111308] BITINT_TYPE unsupported in c-ada-spec.cc
[Bug ada/111308] BITINT_TYPE unsupported in c-ada-spec.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111308 Eric Botcazou changed: What|Removed |Added Last reconfirmed||2023-09-06 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Eric Botcazou --- Thanks for creating the PR. We'll need to think about it indeed.
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050
--- Comment #6 from TC ---
The crash is gone if lib2.o is compiled with bits/hashtable_policy.h patched
like so:
--- a/path/to/gcc-13/include/c++/13.2.0/bits/hashtable_policy.h
+++ b/hashtable_policy.h
@@ -327,18 +327,22 @@ namespace __detail
__gnu_cxx::__aligned_buffer<_Value> _M_storage;
+ [[__gnu__::__always_inline__]]
_Value*
_M_valptr() noexcept
{ return _M_storage._M_ptr(); }
+ [[__gnu__::__always_inline__]]
const _Value*
_M_valptr() const noexcept
{ return _M_storage._M_ptr(); }
+ [[__gnu__::__always_inline__]]
_Value&
_M_v() noexcept
{ return *_M_valptr(); }
+ [[__gnu__::__always_inline__]]
const _Value&
_M_v() const noexcept
{ return *_M_valptr(); }
I'm following up with my reporter to see if this also fixes the problem with
their actual code.
[Bug c++/110158] Cannot use union with std::string inside in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110158
--- Comment #6 from danakj at orodu dot net ---
In case it is of help, here's an even smaller repro that clang reports the
error in libstdc++. For whatever reason gcc does not notice the libstdc++ bug
here.
https://gcc.godbolt.org/z/Phndafeoe
```
#include
struct S {
constexpr ~S() {}
std::string s;
};
constexpr std::string foo(const S& s) { return s.s; }
static_assert(foo(S("hi")) == "hi"); // Fails.
static_assert(foo(S("a longer string works")) == "a longer string works");
int main() {}
```
The error:
```
:11:15: error: static assertion expression is not an integral constant
expression
static_assert(foo(S("hi")) == "hi");
^~~~
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/basic_string.h:356:10:
note: assignment to member '_M_local_buf' of union with no active member is not
allowed in a constant expression
__c = _CharT();
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/basic_string.tcc:229:4:
note: in call to '(("hi")).s->_M_use_local_data()'
_M_use_local_data();
^
/opt/compiler-explorer/gcc-12.2.0/lib/gcc/x86_64-linux-gnu/12.2.0/../../../../include/c++/12.2.0/bits/basic_string.h:642:2:
note: in call to '(("hi")).s->_M_construct(&"hi"[0], &"hi"[2], {{}})'
_M_construct(__s, __end, forward_iterator_tag());
^
:11:21: note: in call to 'basic_string(&"hi"[0],
std::allocator())'
static_assert(foo(S("hi")) == "hi");
^
1 error generated.
```
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050
--- Comment #5 from TC ---
Minimal example:
$ cat lib1.cpp
#include
#include
static std::unordered_set set;
void del(const std::string& s) {
set.erase(s);
}
$ cat lib2.cpp
#include
#include
static std::unordered_set set;
void add(const std::string& s) {
set.emplace(s);
}
const std::string& get(const std::string& s) {
return *set.find(s);
}
$ cat main.cpp
#include
void add(const std::string&);
void del(const std::string&);
const std::string& get(const std::string&);
int main() {
add("foo");
del("bar");
(void) get("foo").size();
}
$ g++-10 -std=c++17 lib1.cpp -c -o lib1.o
$ g++-13 -std=c++17 lib2.cpp -c -o lib2.o
$ g++-13 -std=c++17 main.cpp lib1.o lib2.o -o test
$ ./test
Segmentation fault (core dumped)
[Bug c++/110158] Cannot use union with std::string inside in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110158 --- Comment #5 from danakj at orodu dot net --- As a means to work around #4 in static asserts, making your string long enough that it avoids the SSO will allow the compiler to accept it.
[Bug c/111309] va_arg alternative for _BitInt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111309 --- Comment #3 from joseph at codesourcery dot com --- Defined values for 0 are marginally more convenient for implementing the standard operations which have defined results for all arguments, and I think it's appropriate for the type-generic built-in functions to work for all integer types - at least all unsigned integer types (and including unsigned __int128) - rather than just _BitInt types. ( itself - providing both functions and type-generic macros - makes most sense to provide in libc, I think. The type-generic macros there don't actually support bit-precise types whose width doesn't match a standard/extended type, but providing such support, given appropriate built-in functions, certainly makes sense as an extension.)
[Bug c/111309] va_arg alternative for _BitInt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111309 --- Comment #2 from Jakub Jelinek --- For clz/ctz/parity/popcount/clrsb/ffs, it should be quite easy to implement them, the primary questions are, what the builtin name should be (because __builtin_clz etc. is already taken for unsigned int argument (resp. int for clrsb), so we want some suffix either for all type-generic _BitInt types, or make it type-generic completely and support all integral types in there. And second question for clz/ctz is whether we should preserve the UB behavior for 0 argument, or define return value even for those. For larger _BitInt it will be implemented using loops and so will need to take 0 limbs into account anyway, so the advantage of invoking UB on it is smaller, and for users testing whether _BitInt(32768) is non-zero is already quite expensive if they wanted to have well-defined result in that case.
[Bug fortran/111304] Problem when passing implicit arrays of characters to functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111304 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #2 from anlauf at gcc dot gnu.org --- Looks like a duplicate of pr85547. *** This bug has been marked as a duplicate of bug 85547 ***
[Bug fortran/85547] Run-time error: character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85547 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||mailling-lists-bd at posteo dot de --- Comment #7 from anlauf at gcc dot gnu.org --- *** Bug 111304 has been marked as a duplicate of this bug. ***
[Bug c/111309] va_arg alternative for _BitInt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111309 --- Comment #1 from joseph at codesourcery dot com --- Yes, we should have APIs for building type-generic _BitInt interfaces (also a width-of operation to give the width in bits of an integer type; also type-generic versions of operations such as clz, ctz, parity, popcount that work to the width in bits of any unsigned operand). Though I suspect any library implementations of printf _BitInt support would end up needing architecture-specific workarounds for a while to avoid depending on having GCC new enough to support _BitInt in order to build a library with that support.
[Bug libstdc++/111050] [11/12/13/14 Regression] ABI break in _Hash_node_value_base since GCC 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111050 François Dumont changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from François Dumont --- Considering that explosion is taking place in your code built with a gcc post-11 while calling _M_next() on a _Hashtable instance node coming from a .so built with a gcc pre-11 version I think your solution should work. I'll send a patch proposal to mailing list.
[Bug c/111309] New: va_arg alternative for _BitInt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111309
Bug ID: 111309
Summary: va_arg alternative for _BitInt
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
For https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2858.pdf , I wonder if we
shouldn't have a __builtin_va_arg variant which would allow to read arbitrary
_BitInt
into array of limbs. The builtin IMHO should be passed at least the N from
_BitInt(N), probably whether it is signed vs. unsigned and pointer to the array
of limbs, dunno whether it should only support limb type which it also uses for
the libgcc APIs or whether the type should be e.g. inferred from the scalar
integer type the pointer argument points to. And whether the endianity in
which limbs are ordered should be host endianity, some other argument to the
builtin, or always the _BitInt endianity.
On arches like x86-64 where the passing ABI says for N <= 8 pass like char, for
N <= 16 pass like short, for N <= 32 pass like int, for N <= 64 pass like long
long, otherwise pass like struct { long long a[(N + 63) / 64]; } it would need
to differentiate at runtime (unless N is constant obviously) the different
cases to perform proper VA_ARG for that, plus handle the generic case which
would be always passed in memory.
[Bug ada/111308] New: BITINT_TYPE unsupported in c-ada-spec.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111308 Bug ID: 111308 Summary: BITINT_TYPE unsupported in c-ada-spec.cc Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org CC: adam.warner.nz at gmail dot com, alx at kernel dot org, bergner at gcc dot gnu.org, chfast at gmail dot com, dje at gcc dot gnu.org, dkm at gcc dot gnu.org, fw at gcc dot gnu.org, george at bott dot gg, hjl.tools at gmail dot com, jakub at gcc dot gnu.org, jsm28 at gcc dot gnu.org, leni536 at gmail dot com, rguenth at gcc dot gnu.org, rsandifo at gcc dot gnu.org, segher at gcc dot gnu.org, sjames at gcc dot gnu.org, tmgross at umich dot edu, uweigand at gcc dot gnu.org Depends on: 102989 Target Milestone: --- +++ This bug was initially created as a clone of Bug #102989 +++ I haven't added BITINT_TYPE support to c-ada-spec.cc, as I have no idea what you want to do in Ada for that. Example of problematic declaration in some header (so far on x86-64) would be extern _BitInt(157) foo (unsigned _BitInt(384) x, signed _BitInt(15) y, int z); Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 [Bug 102989] Implement C2x's n2763 (_BitInt)
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #110 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:52e270e847d240fb68a27c88ee60189515a6 commit r14-3759-g52e270e847d240fb68a27c88ee60189515a6 Author: Jakub Jelinek Date: Wed Sep 6 17:52:24 2023 +0200 Additional _BitInt test coverage [PR102989] On Tue, Sep 05, 2023 at 10:40:26PM +, Joseph Myers wrote: > Additional tests I think should be added (for things I expect should > already work): > > * Tests for BITINT_MAXWIDTH in . Test that it's defined for > C2x, but not defined for C11/C17 (the latter independent of whether the > target has _BitInt support). Test the value as well: _BitInt > (BITINT_MAXWIDTH) should be OK (both signed and unsigned) but _BitInt > (BITINT_MAXWIDTH + 1) should not be OK. Also test that BITINT_MAXWIDTH >= > ULLONG_MAX. > > * Test _BitInt (N) where N is a constexpr variable or enum constant (I > expect these should work - the required call to convert_lvalue_to_rvalue > for constexpr to work is present - but I don't see such tests in the > testsuite). > > * Test that -funsigned-bitfields does not affect the signedness of _BitInt > (N) bit-fields (the standard wording isn't entirely clear, but that's > what's implemented in the patches). > > * Test the errors for _Sat used with _BitInt (though such a test might not > actually run at present because no target supports both features). The following patch does that plus for most of the new changes in the C _BitInt support patch requested in patch review it also does testsuite coverage. 2023-09-06 Jakub Jelinek PR c/102989 * gcc.dg/bitint-2.c (foo): Add tests for constexpr var or enumerator arguments of _BitInt. * gcc.dg/bitint-31.c: Remove forgotten 0 &&. * gcc.dg/bitint-32.c: New test. * gcc.dg/bitint-33.c: New test. * gcc.dg/bitint-34.c: New test. * gcc.dg/bitint-35.c: New test. * gcc.dg/bitint-36.c: New test. * gcc.dg/fixed-point/bitint-1.c: New test.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #109 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:dce6f6a974d4ecce8491c989c35e23c59223f762
commit r14-3758-gdce6f6a974d4ecce8491c989c35e23c59223f762
Author: Jakub Jelinek
Date: Wed Sep 6 17:50:49 2023 +0200
Handle BITINT_TYPE in build_{,minus_}one_cst [PR102989]
Recent match.pd changes trigger ICE in build_minus_one_cst, apparently
I forgot to handle BITINT_TYPE in these (while I've handled it in
build_zero_cst).
2023-09-06 Jakub Jelinek
PR c/102989
* tree.cc (build_one_cst, build_minus_one_cst): Handle BITINT_TYPE
like INTEGER_TYPE.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #107 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c62c82dc98dcb7420498b7114bf4cd2ec1a81405 commit r14-3756-gc62c82dc98dcb7420498b7114bf4cd2ec1a81405 Author: Jakub Jelinek Date: Wed Sep 6 17:47:49 2023 +0200 Add further _BitInt <-> floating point tests [PR102989] Here are just the testsuite additions from libgcc _BitInt patch review. On Fri, Sep 01, 2023 at 09:48:22PM +, Joseph Myers wrote: > 1. Test overflowing conversions to integers (including from inf or NaN) > raise FE_INVALID. (Note: it's not specified in the standard whether > inexact conversions to integers raise FE_INEXACT or not, so testing that > seems less important.) This is in gcc.dg/bitint-28.c (FE_INVALID) and gcc.dg/bitint-29.c (FE_INEXACT) for binary and dfp/bitint-8.c new tests. > 2. Test conversions from integers to floating point raise FE_INEXACT when > inexact, together with FE_OVERFLOW when overflowing (while exact > conversions don't raise exceptions). This is in gcc.dg/bitint-30.c new test. > 3. Test conversions from integers to floating point respect the rounding > mode. This is in gcc.dg/bitint-31.c new test. > 4. Test converting floating-point values in the range (-1.0, 0.0] to both > unsigned and signed _BitInt; I didn't see such tests for binary floating > types, only for decimal types, and the decimal tests didn't include tests > of negative zero itself as the value converted to _BitInt. This is done as incremental changes to existing tests. > 5. Test conversions of noncanonical BID zero to integers (these tests > would be specific to BID). See below for a bug in this area. This is done in dfp/bitint-7.c test. 2023-09-06 Jakub Jelinek PR c/102989 * gcc.dg/torture/bitint-21.c (main): Add tests for -1 for signed only, -1 + epsilon, another (-1, 0) range value and -0. * gcc.dg/torture/bitint-22.c (main): Likewise. * gcc.dg/bitint-28.c: New test. * gcc.dg/bitint-29.c: New test. * gcc.dg/bitint-30.c: New test. * gcc.dg/bitint-31.c: New test. * gcc.dg/dfp/bitint-1.c (main): Add tests for -1 for signed only, -1 + epsilon and -0. * gcc.dg/dfp/bitint-2.c (main): Likewise. * gcc.dg/dfp/bitint-3.c (main): Likewise. * gcc.dg/dfp/bitint-7.c: New test. * gcc.dg/dfp/bitint-8.c: New test.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #104 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a2f50aa2c578eb0572935e61818e1f2b18b53fd6 commit r14-3753-ga2f50aa2c578eb0572935e61818e1f2b18b53fd6 Author: Jakub Jelinek Date: Wed Sep 6 17:37:53 2023 +0200 testsuite part 2 for _BitInt support [PR102989] This is second part of the testcase additions in order to fit into mailing lists limits. Most of these tests are for the floating point conversions, atomics, __builtin_*_overflow and -fsanitize=undefined. 2023-09-06 Jakub Jelinek PR c/102989 gcc/testsuite/ * gcc.dg/torture/bitint-20.c: New test. * gcc.dg/torture/bitint-21.c: New test. * gcc.dg/torture/bitint-22.c: New test. * gcc.dg/torture/bitint-23.c: New test. * gcc.dg/torture/bitint-24.c: New test. * gcc.dg/torture/bitint-25.c: New test. * gcc.dg/torture/bitint-26.c: New test. * gcc.dg/torture/bitint-27.c: New test. * gcc.dg/torture/bitint-28.c: New test. * gcc.dg/torture/bitint-29.c: New test. * gcc.dg/torture/bitint-30.c: New test. * gcc.dg/torture/bitint-31.c: New test. * gcc.dg/torture/bitint-32.c: New test. * gcc.dg/torture/bitint-33.c: New test. * gcc.dg/torture/bitint-34.c: New test. * gcc.dg/torture/bitint-35.c: New test. * gcc.dg/torture/bitint-36.c: New test. * gcc.dg/torture/bitint-37.c: New test. * gcc.dg/torture/bitint-38.c: New test. * gcc.dg/torture/bitint-39.c: New test. * gcc.dg/torture/bitint-40.c: New test. * gcc.dg/torture/bitint-41.c: New test. * gcc.dg/torture/bitint-42.c: New test. * gcc.dg/atomic/stdatomic-bitint-1.c: New test. * gcc.dg/atomic/stdatomic-bitint-2.c: New test. * gcc.dg/dfp/bitint-1.c: New test. * gcc.dg/dfp/bitint-2.c: New test. * gcc.dg/dfp/bitint-3.c: New test. * gcc.dg/dfp/bitint-4.c: New test. * gcc.dg/dfp/bitint-5.c: New test. * gcc.dg/dfp/bitint-6.c: New test. * gcc.dg/ubsan/bitint-1.c: New test. * gcc.dg/ubsan/bitint-2.c: New test. * gcc.dg/ubsan/bitint-3.c: New test.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #105 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f76ae4369cb6f38e17510704e5b6e53847d2a648
commit r14-3754-gf76ae4369cb6f38e17510704e5b6e53847d2a648
Author: Jakub Jelinek
Date: Wed Sep 6 17:39:15 2023 +0200
C _BitInt incremental fixes [PR102989]
On Wed, Aug 09, 2023 at 09:17:57PM +, Joseph Myers wrote:
> > - _Complex _BitInt(N) isn't supported; again mainly because none of the
psABIs
> > mention how those should be passed/returned; in a limited way they
are
> > supported internally because the internal functions into which
> > __builtin_{add,sub,mul}_overflow{,_p} is lowered return COMPLEX_TYPE
as a
> > hack to return 2 values without using references/pointers
>
> What happens when the usual arithmetic conversions are applied to
> operands, one of which is a complex integer type and the other of which
is
> a wider _BitInt type? I don't see anything in the code to disallow this
> case (which would produce an expression with a _Complex _BitInt type), or
> any testcases for it.
I've added a sorry for that case (+ return the narrower COMPLEX_TYPE).
Also added testcase to verify we don't create VECTOR_TYPEs of BITINT_TYPE
even if they have mode precision and suitable size (others were rejected
already before).
> Other testcases I think should be present (along with any corresponding
> changes needed to the code itself):
>
> * Verifying that the new integer constant suffix is rejected for C++.
Done.
> * Verifying appropriate pedwarn-if-pedantic for the new constant suffix
> for versions of C before C2x (and probably for use of _BitInt type
> specifiers before C2x as well) - along with the expected -Wc11-c2x-compat
> handling (in C2x mode) / -pedantic -Wno-c11-c2x-compat in older modes.
Done.
Here is an incremental patch which does that.
2023-09-06 Jakub Jelinek
PR c/102989
gcc/c/
* c-decl.cc (finish_declspecs): Emit pedwarn_c11 on _BitInt.
* c-typeck.cc (c_common_type): Emit sorry for common type between
_Complex integer and larger _BitInt and return the _Complex
integer.
gcc/c-family/
* c-attribs.cc (type_valid_for_vector_size): Reject vector types
with BITINT_TYPE elements even if they have mode precision and
suitable size.
gcc/testsuite/
* gcc.dg/bitint-19.c: New test.
* gcc.dg/bitint-20.c: New test.
* gcc.dg/bitint-21.c: New test.
* gcc.dg/bitint-22.c: New test.
* gcc.dg/bitint-23.c: New test.
* gcc.dg/bitint-24.c: New test.
* gcc.dg/bitint-25.c: New test.
* gcc.dg/bitint-26.c: New test.
* gcc.dg/bitint-27.c: New test.
* g++.dg/ext/bitint1.C: New test.
* g++.dg/ext/bitint2.C: New test.
* g++.dg/ext/bitint3.C: New test.
* g++.dg/ext/bitint4.C: New test.
libcpp/
* expr.cc (cpp_classify_number): Diagnose wb literal suffixes
for -pedantic* before C2X or -Wc11-c2x-compat.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #106 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f6e0ec5696ec5f52baed71fe23f978bcef80d458
commit r14-3755-gf6e0ec5696ec5f52baed71fe23f978bcef80d458
Author: Jakub Jelinek
Date: Wed Sep 6 17:42:37 2023 +0200
libgcc _BitInt helper documentation [PR102989]
On Mon, Aug 21, 2023 at 05:32:04PM +, Joseph Myers wrote:
> I think the libgcc functions (i.e. those exported by libgcc, to which
> references are generated by the compiler) need documenting in
libgcc.texi.
> Internal functions or macros in the libgcc patch need appropriate
comments
> specifying their semantics; especially FP_TO_BITINT and FP_FROM_BITINT
> which have a lot of arguments and no comments saying what the semantics
of
> the macros and their arguments are supposed to me.
Here is an incremental patch which does that.
2023-09-06 Jakub Jelinek
PR c/102989
gcc/
* doc/libgcc.texi (Bit-precise integer arithmetic functions):
Document general rules for _BitInt support library functions
and document __mulbitint3 and __divmodbitint4.
(Conversion functions): Document __fix{s,d,x,t}fbitint,
__floatbitint{s,d,x,t,h,b}f, __bid_fix{s,d,t}dbitint and
__bid_floatbitint{s,d,t}d.
libgcc/
* libgcc2.c (bitint_negate): Add function comment.
* soft-fp/bitint.h (bitint_negate): Add function comment.
(FP_TO_BITINT, FP_FROM_BITINT): Add comment explaining the macros.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #108 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:3ad9948b3e716885ce66bdf1c8e053880a843a2b
commit r14-3757-g3ad9948b3e716885ce66bdf1c8e053880a843a2b
Author: Jakub Jelinek
Date: Wed Sep 6 17:49:44 2023 +0200
_BitInt profile fixes [PR102989]
On Thu, Aug 24, 2023 at 03:14:32PM +0200, Jan Hubicka via Gcc-patches
wrote:
> this patch extends verifier to check that all probabilities and counts
are
> initialized if profile is supposed to be present. This is a bit
complicated
> by the posibility that we inline !flag_guess_branch_probability function
> into function with profile defined and in this case we need to stop
> verification. For this reason I added flag to cfg structure tracking
this.
This patch broke a couple of _BitInt tests (in the admittedly still
uncommitted series - still waiting for review of the C FE bits).
Here is a minimal patch to make it work again, though I'm not sure
if in the if_then_else and if_then_if_then_else cases I shouldn't scale
count of the other bbs as well. if_then method creates
if (COND) new_bb1;
in a middle of some pre-existing bb (with PROB that COND is true),
if_then_else
if (COND) new_bb1; else new_bb2;
and if_then_if_then_else
if (COND1) { if (COND2) new_bb2; else new_bb1; }
with PROB1 and PROB2 probabilities that COND1 and COND2 are true.
The lowering happens shortly after IPA.
2023-09-06 Jakub Jelinek
PR c/102989
* gimple-lower-bitint.cc (bitint_large_huge::if_then_else,
bitint_large_huge::if_then_if_then_else): Use make_single_succ_edge
rather than make_edge, initialize bb->count.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #103 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:faff31701d50fab08d75fbb13affc82cff74a72c
commit r14-3752-gfaff31701d50fab08d75fbb13affc82cff74a72c
Author: Jakub Jelinek
Date: Wed Sep 6 17:36:41 2023 +0200
testsuite part 1 for _BitInt support [PR102989]
This patch adds first part of the testsuite support. When creating the
testcases, I've been using
https://defuse.ca/big-number-calculator.htm
tool, a randombitint tool I wrote (posted as a reply to the first series)
plus
LLVM trunk on godbolt and the WIP GCC support checking if both compilers
agree on stuff (and in case of differences tried constant evaluation etc.).
The whole testsuite has been also tested with
make -j32 -k check-gcc GCC_TEST_RUN_EXPENSIVE=1 \
RUNTESTFLAGS='GCC_TEST_RUN_EXPENSIVE=1 --target_board=unix\{-m32,-m64\}
ubsan.exp=bitint*.c dg.exp=bitint* dg-torture.exp=bitint*'
to verify it in all modes, normally I'm limitting the torture tests to just
-O0 and -O2 because they are quite large and expensive.
Generally it is needed to test different _BitInt precisions because they
are lowered differently (the small vs. medium vs. large vs. huge, precision
of multiples of limb precision or some other etc.).
2023-09-06 Jakub Jelinek
PR c/102989
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_bitint,
check_effective_target_bitint128,
check_effective_target_bitint575):
New effective targets.
* gcc.dg/bitint-1.c: New test.
* gcc.dg/bitint-2.c: New test.
* gcc.dg/bitint-3.c: New test.
* gcc.dg/bitint-4.c: New test.
* gcc.dg/bitint-5.c: New test.
* gcc.dg/bitint-6.c: New test.
* gcc.dg/bitint-7.c: New test.
* gcc.dg/bitint-8.c: New test.
* gcc.dg/bitint-9.c: New test.
* gcc.dg/bitint-10.c: New test.
* gcc.dg/bitint-11.c: New test.
* gcc.dg/bitint-12.c: New test.
* gcc.dg/bitint-13.c: New test.
* gcc.dg/bitint-14.c: New test.
* gcc.dg/bitint-15.c: New test.
* gcc.dg/bitint-16.c: New test.
* gcc.dg/bitint-17.c: New test.
* gcc.dg/bitint-18.c: New test.
* gcc.dg/torture/bitint-1.c: New test.
* gcc.dg/torture/bitint-2.c: New test.
* gcc.dg/torture/bitint-3.c: New test.
* gcc.dg/torture/bitint-4.c: New test.
* gcc.dg/torture/bitint-5.c: New test.
* gcc.dg/torture/bitint-6.c: New test.
* gcc.dg/torture/bitint-7.c: New test.
* gcc.dg/torture/bitint-8.c: New test.
* gcc.dg/torture/bitint-9.c: New test.
* gcc.dg/torture/bitint-10.c: New test.
* gcc.dg/torture/bitint-11.c: New test.
* gcc.dg/torture/bitint-12.c: New test.
* gcc.dg/torture/bitint-13.c: New test.
* gcc.dg/torture/bitint-14.c: New test.
* gcc.dg/torture/bitint-15.c: New test.
* gcc.dg/torture/bitint-16.c: New test.
* gcc.dg/torture/bitint-17.c: New test.
* gcc.dg/torture/bitint-18.c: New test.
* gcc.dg/torture/bitint-19.c: New test.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989
--- Comment #101 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2ce182e258d3ab11310442d5f4dd1d063018aca9
commit r14-3750-g2ce182e258d3ab11310442d5f4dd1d063018aca9
Author: Jakub Jelinek
Date: Wed Sep 6 17:33:05 2023 +0200
libgcc _BitInt support [PR102989]
This patch adds the library helpers for multiplication, division + modulo
and casts from and to floating point (both binary and decimal).
As described in the intro, the first step is try to reduce further the
passed in precision by skipping over most significant limbs with just zeros
or sign bit copies. For multiplication and division I've implemented
a simple algorithm, using something smarter like Karatsuba or Toom N-Way
might be faster for very large _BitInts (which we don't support right now
anyway), but could mean more code in libgcc, which maybe isn't what people
are willing to accept.
For the to/from floating point conversions the patch uses soft-fp, because
it already has tons of handy macros which can be used for that. In theory
it could be implemented using {,unsigned} long long or {,unsigned} __int128
to/from floating point conversions with some frexp before/after, but at
that
point we already need to force it into integer registers and analyze it
anyway. Plus, for 32-bit arches there is no __int128 that could be used
for XF/TF mode stuff.
I know that soft-fp is owned by glibc and I think the op-common.h change
should be propagated there, but the bitint stuff is really GCC specific
and IMHO doesn't belong into the glibc copy.
2023-09-06 Jakub Jelinek
PR c/102989
libgcc/
* config/aarch64/t-softfp (softfp_extras): Use += rather than :=.
* config/i386/64/t-softfp (softfp_extras): Likewise.
* config/i386/libgcc-glibc.ver (GCC_14.0.0): Export _BitInt support
routines.
* config/i386/t-softfp (softfp_extras): Add fixxfbitint and
bf, hf and xf mode floatbitint.
(CFLAGS-floatbitintbf.c, CFLAGS-floatbitinthf.c): Add -msse2.
* config/riscv/t-softfp32 (softfp_extras): Use += rather than :=.
* config/rs6000/t-e500v1-fp (softfp_extras): Likewise.
* config/rs6000/t-e500v2-fp (softfp_extras): Likewise.
* config/t-softfp (softfp_floatbitint_funcs): New.
(softfp_bid_list): New.
(softfp_func_list): Add sf and df mode from and to _BitInt
libcalls.
(softfp_bid_file_list): New.
(LIB2ADD_ST): Add $(softfp_bid_file_list).
* config/t-softfp-sfdftf (softfp_extras): Add fixtfbitint and
floatbitinttf.
* config/t-softfp-tf (softfp_extras): Likewise.
* libgcc2.c (bitint_reduce_prec): New inline function.
(BITINT_INC, BITINT_END): Define.
(bitint_mul_1, bitint_addmul_1): New helper functions.
(__mulbitint3): New function.
(bitint_negate, bitint_submul_1): New helper functions.
(__divmodbitint4): New function.
* libgcc2.h (LIBGCC2_UNITS_PER_WORD): When building _BitInt support
libcalls, redefine depending on __LIBGCC_BITINT_LIMB_WIDTH__.
(__mulbitint3, __divmodbitint4): Declare.
* libgcc-std.ver.in (GCC_14.0.0): Export _BitInt support routines.
* Makefile.in (lib2funcs): Add _mulbitint3.
(LIB2_DIVMOD_FUNCS): Add _divmodbitint4.
* soft-fp/bitint.h: New file.
* soft-fp/fixdfbitint.c: New file.
* soft-fp/fixsfbitint.c: New file.
* soft-fp/fixtfbitint.c: New file.
* soft-fp/fixxfbitint.c: New file.
* soft-fp/floatbitintbf.c: New file.
* soft-fp/floatbitintdf.c: New file.
* soft-fp/floatbitinthf.c: New file.
* soft-fp/floatbitintsf.c: New file.
* soft-fp/floatbitinttf.c: New file.
* soft-fp/floatbitintxf.c: New file.
* soft-fp/op-common.h (_FP_FROM_INT): Add support for rsize up to
4 * _FP_W_TYPE_SIZE rather than just 2 * _FP_W_TYPE_SIZE.
* soft-fp/bitintpow10.c: New file.
* soft-fp/fixsdbitint.c: New file.
* soft-fp/fixddbitint.c: New file.
* soft-fp/fixtdbitint.c: New file.
* soft-fp/floatbitintsd.c: New file.
* soft-fp/floatbitintdd.c: New file.
* soft-fp/floatbitinttd.c: New file.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #102 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:8c984a1c3693df63520558631c827bb2c2d8b5bc commit r14-3751-g8c984a1c3693df63520558631c827bb2c2d8b5bc Author: Jakub Jelinek Date: Wed Sep 6 17:34:49 2023 +0200 C _BitInt support [PR102989] This patch adds the C FE support, c-family support, small libcpp change so that 123wb and 42uwb suffixes are handled plus glimits.h change to define BITINT_MAXWIDTH macro. The previous patches really do nothing without this, which enables all the support. 2023-09-06 Jakub Jelinek PR c/102989 gcc/ * glimits.h (BITINT_MAXWIDTH): Define if __BITINT_MAXWIDTH__ is predefined. gcc/c-family/ * c-common.cc (c_common_reswords): Add _BitInt as keyword. (unsafe_conversion_p): Handle BITINT_TYPE like INTEGER_TYPE. (c_common_signed_or_unsigned_type): Handle BITINT_TYPE. (c_common_truthvalue_conversion, c_common_get_alias_set, check_builtin_function_arguments): Handle BITINT_TYPE like INTEGER_TYPE. (sync_resolve_size): Add ORIG_FORMAT argument. If FETCH && !ORIG_FORMAT, type is BITINT_TYPE, return -1 if size isn't one of 1, 2, 4, 8 or 16 or if it is 16 but TImode is not supported. (atomic_bitint_fetch_using_cas_loop): New function. (resolve_overloaded_builtin): Adjust sync_resolve_size caller. If -1 is returned, use atomic_bitint_fetch_using_cas_loop to lower it. Formatting fix. (keyword_begins_type_specifier): Handle RID_BITINT. * c-common.h (enum rid): Add RID_BITINT enumerator. * c-cppbuiltin.cc (c_cpp_builtins): For C call targetm.c.bitint_type_info and predefine __BITINT_MAXWIDTH__ and for -fbuilding-libgcc also __LIBGCC_BITINT_LIMB_WIDTH__ and __LIBGCC_BITINT_ORDER__ macros if _BitInt is supported. * c-lex.cc (interpret_integer): Handle CPP_N_BITINT. * c-pretty-print.cc (c_pretty_printer::simple_type_specifier, c_pretty_printer::direct_abstract_declarator, c_pretty_printer::direct_declarator, c_pretty_printer::declarator): Handle BITINT_TYPE. (pp_c_integer_constant): Handle printing of large precision wide_ints which would buffer overflow digit_buffer. * c-warn.cc (conversion_warning, warnings_for_convert_and_check, warnings_for_convert_and_check): Handle BITINT_TYPE like INTEGER_TYPE. gcc/c/ * c-convert.cc (c_convert): Handle BITINT_TYPE like INTEGER_TYPE. * c-decl.cc (check_bitfield_type_and_width): Allow BITINT_TYPE bit-fields. (finish_struct): Prefer to use BITINT_TYPE for BITINT_TYPE bit-fields if possible. (declspecs_add_type): Formatting fixes. Handle cts_bitint. Adjust for added union in *specs. Handle RID_BITINT. (finish_declspecs): Handle cts_bitint. Adjust for added union in *specs. * c-parser.cc (c_keyword_starts_typename, c_token_starts_declspecs, c_parser_declspecs, c_parser_gnu_attribute_any_word): Handle RID_BITINT. (c_parser_omp_clause_schedule): Handle BITINT_TYPE like INTEGER_TYPE. * c-tree.h (enum c_typespec_keyword): Mention _BitInt in comment. Add cts_bitint enumerator. (struct c_declspecs): Move int_n_idx and floatn_nx_idx into a union and add bitint_prec there as well. * c-typeck.cc (c_common_type, comptypes_internal): Handle BITINT_TYPE. (perform_integral_promotions): Promote BITINT_TYPE bit-fields to their declared type. (build_array_ref, build_unary_op, build_conditional_expr, build_c_cast, convert_for_assignment, digest_init, build_binary_op): Handle BITINT_TYPE. * c-fold.cc (c_fully_fold_internal): Handle BITINT_TYPE like INTEGER_TYPE. * c-aux-info.cc (gen_type): Handle BITINT_TYPE. libcpp/ * expr.cc (interpret_int_suffix): Handle wb and WB suffixes. * include/cpplib.h (CPP_N_BITINT): Define.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #100 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7a610d44d855424518ecb4429ea5226ed2c32543 commit r14-3749-g7a610d44d855424518ecb4429ea5226ed2c32543 Author: Jakub Jelinek Date: Wed Sep 6 17:31:23 2023 +0200 libgcc: Generated tables for _BitInt <-> _Decimal* conversions [PR102989] The following patch adds a header with generated helper tables to support computation of powers of 10 from 10^0 to 10^6111 inclusive into a sufficiently large array of _BitInt limbs. This is split from the rest of the libgcc _BitInt support because it is quite large and together it would run into gcc-patches mail length limits. 2023-09-06 Jakub Jelinek PR c/102989 libgcc/ * soft-fp/bitintpow10.h: New file.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #99 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:95521e15b6ef00c192a1bbd7c13b5f35395c7c9e commit r14-3748-g95521e15b6ef00c192a1bbd7c13b5f35395c7c9e Author: Jakub Jelinek Date: Wed Sep 6 17:30:07 2023 +0200 ubsan: _BitInt -fsanitize=undefined support [PR102989] The following patch introduces some -fsanitize=undefined support for _BitInt, but some of the diagnostics is limited by lack of proper support in the library. I've filed https://github.com/llvm/llvm-project/issues/64100 to request proper support, for now some of the diagnostics might have less or more confusing or inaccurate wording but UB should still be diagnosed when it happens. 2023-09-06 Jakub Jelinek PR c/102989 gcc/ * internal-fn.cc (expand_ubsan_result_store): Add LHS, MODE and DO_ERROR arguments. For non-mode precision BITINT_TYPE results check if all padding bits up to mode precision are zeros or sign bit copies and if not, jump to DO_ERROR. (expand_addsub_overflow, expand_neg_overflow, expand_mul_overflow): Adjust expand_ubsan_result_store callers. * ubsan.cc: Include target.h and langhooks.h. (ubsan_encode_value): Pass BITINT_TYPE values which fit into pointer size converted to pointer sized integer, pass BITINT_TYPE values which fit into TImode (if supported) or DImode as those integer types or otherwise for now punt (pass 0). (ubsan_type_descriptor): Handle BITINT_TYPE. For pstyle of UBSAN_PRINT_FORCE_INT use TK_Integer (0x) mode with a TImode/DImode precision rather than TK_Unknown used otherwise for large/huge BITINT_TYPEs. (instrument_si_overflow): Instrument BITINT_TYPE operations even when they don't have mode precision. * ubsan.h (enum ubsan_print_style): New enumerator. gcc/c-family/ * c-ubsan.cc (ubsan_instrument_shift): Use UBSAN_PRINT_FORCE_INT for type0 type descriptor.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #98 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b38deff6127778fed453bb647e32738ba5c78e33 commit r14-3747-gb38deff6127778fed453bb647e32738ba5c78e33 Author: Jakub Jelinek Date: Wed Sep 6 17:29:17 2023 +0200 i386: Enable _BitInt on x86-64 [PR102989] The following patch enables _BitInt support on x86-64, the only target which has _BitInt specified in psABI. 2023-09-06 Jakub Jelinek PR c/102989 * config/i386/i386.cc (classify_argument): Handle BITINT_TYPE. (ix86_bitint_type_info): New function. (TARGET_C_BITINT_TYPE_INFO): Redefine.
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #96 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4f4fa2501186e43d115238ae938b3df322c9e02a commit r14-3745-g4f4fa2501186e43d115238ae938b3df322c9e02a Author: Jakub Jelinek Date: Wed Sep 6 17:25:49 2023 +0200 Middle-end _BitInt support [PR102989] The following patch introduces the middle-end part of the _BitInt support, a new BITINT_TYPE, handling it where needed, except the lowering pass and sanitizer support. 2023-09-06 Jakub Jelinek PR c/102989 * tree.def (BITINT_TYPE): New type. * tree.h (TREE_CHECK6, TREE_NOT_CHECK6): Define. (NUMERICAL_TYPE_CHECK, INTEGRAL_TYPE_P): Include BITINT_TYPE. (BITINT_TYPE_P): Define. (CONSTRUCTOR_BITFIELD_P): Return true even for BLKmode bit-fields if they have BITINT_TYPE type. (tree_check6, tree_not_check6): New inline functions. (any_integral_type_check): Include BITINT_TYPE. (build_bitint_type): Declare. * tree.cc (tree_code_size, wide_int_to_tree_1, cache_integer_cst, build_zero_cst, type_hash_canon_hash, type_cache_hasher::equal, type_hash_canon): Handle BITINT_TYPE. (bitint_type_cache): New variable. (build_bitint_type): New function. (signed_or_unsigned_type_for, verify_type_variant, verify_type): Handle BITINT_TYPE. (tree_cc_finalize): Free bitint_type_cache. * builtins.cc (type_to_class): Handle BITINT_TYPE. (fold_builtin_unordered_cmp): Handle BITINT_TYPE like INTEGER_TYPE. * cfgexpand.cc (expand_debug_expr): Punt on BLKmode BITINT_TYPE INTEGER_CSTs. * convert.cc (convert_to_pointer_1, convert_to_real_1, convert_to_complex_1): Handle BITINT_TYPE like INTEGER_TYPE. (convert_to_integer_1): Likewise. For BITINT_TYPE don't check GET_MODE_PRECISION (TYPE_MODE (type)). * doc/generic.texi (BITINT_TYPE): Document. * doc/tm.texi.in (TARGET_C_BITINT_TYPE_INFO): New. * doc/tm.texi: Regenerated. * dwarf2out.cc (base_type_die, is_base_type, modified_type_die, gen_type_die_with_usage): Handle BITINT_TYPE. (rtl_for_decl_init): Punt on BLKmode BITINT_TYPE INTEGER_CSTs or handle those which fit into shwi. * expr.cc (expand_expr_real_1): Define EXTEND_BITINT macro, reduce to bitfield precision reads from BITINT_TYPE vars, parameters or memory locations. Expand large/huge BITINT_TYPE INTEGER_CSTs into memory. * fold-const.cc (fold_convert_loc, make_range_step): Handle BITINT_TYPE. (extract_muldiv_1): For BITINT_TYPE use TYPE_PRECISION rather than GET_MODE_SIZE (SCALAR_INT_TYPE_MODE). (native_encode_int, native_interpret_int, native_interpret_expr): Handle BITINT_TYPE. * gimple-expr.cc (useless_type_conversion_p): Make BITINT_TYPE to some other integral type or vice versa conversions non-useless. * gimple-fold.cc (gimple_fold_builtin_memset): Punt for BITINT_TYPE. (clear_padding_unit): Mention in comment that _BitInt types don't need to fit either. (clear_padding_bitint_needs_padding_p): New function. (clear_padding_type_may_have_padding_p): Handle BITINT_TYPE. (clear_padding_type): Likewise. * internal-fn.cc (expand_mul_overflow): For unsigned non-mode precision operands force pos_neg? to 1. (expand_MULBITINT, expand_DIVMODBITINT, expand_FLOATTOBITINT, expand_BITINTTOFLOAT): New functions. * internal-fn.def (MULBITINT, DIVMODBITINT, FLOATTOBITINT, BITINTTOFLOAT): New internal functions. * internal-fn.h (expand_MULBITINT, expand_DIVMODBITINT, expand_FLOATTOBITINT, expand_BITINTTOFLOAT): Declare. * match.pd (non-equality compare simplifications from fold_binary): Punt if TYPE_MODE (arg1_type) is BLKmode. * pretty-print.h (pp_wide_int): Handle printing of large precision wide_ints which would buffer overflow digit_buffer. * stor-layout.cc (finish_bitfield_representative): For bit-fields with BITINT_TYPE, prefer representatives with precisions in multiple of limb precision. (layout_type): Handle BITINT_TYPE. Handle COMPLEX_TYPE with BLKmode element type and assert it is BITINT_TYPE. * target.def (bitint_type_info): New C target hook. * target.h (struct bitint_info): New type. * targhooks.cc (default_bitint_type_info): New function. * targhooks.h (default_bitint_type_info):
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 --- Comment #97 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a9d6c7fbeb374365058ffe2b9815d2b4b7193d38 commit r14-3746-ga9d6c7fbeb374365058ffe2b9815d2b4b7193d38 Author: Jakub Jelinek Date: Wed Sep 6 17:27:41 2023 +0200 _BitInt lowering support [PR102989] The following patch adds a new bitintlower lowering pass which lowers most operations on medium _BitInt into operations on corresponding integer types, large _BitInt into straight line code operating on 2 or more limbs and finally huge _BitInt into a loop plus optional straight line code. As the only supported architecture is little-endian, the lowering only supports little-endian for now, because it would be impossible to test it all for big-endian. Rest is written with any endian support in mind, but of course only little-endian has been actually tested. I hope it is ok to add big-endian support to the lowering pass incrementally later when first big-endian target shows with the backend support. There are 2 possibilities of adding such support, one would be minimal one, just tweak limb_access function and perhaps one or two other spots and transform there the indexes from little endian (index 0 is least significant) to big endian for just the memory access. Advantage is I think maintainance costs, disadvantage is that the loops will still iterate from 0 to some number of limbs and we'd rely on IVOPTs or something similar changing it later if needed. Or we could make those indexes endian related everywhere, though I'm afraid that would be several hundreds of changes. For switches indexed by large/huge _BitInt the patch invokes what the switch lowering pass does (but only on those specific switches, not all of them); the switch lowering breaks the switches into clusters and none of the clusters can have a range which doesn't fit into 64-bit UWHI, everything else will be turned into a tree of comparisons. For clusters normally emitted as smaller switches, because we already have a guarantee that the low .. high range is at most 64 bits, the patch forces subtraction of the low and turns it into a 64-bit switch. This is done before the actual pass starts. Similarly, we cancel lowering of certain constructs like ABS_EXPR, ABSU_EXPR, MIN_EXPR, MAX_EXPR and COND_EXPR and turn those back to simpler comparisons etc., so that fewer operations need to be lowered later. 2023-09-06 Jakub Jelinek PR c/102989 * Makefile.in (OBJS): Add gimple-lower-bitint.o. * passes.def: Add pass_lower_bitint after pass_lower_complex and pass_lower_bitint_O0 after pass_lower_complex_O0. * tree-pass.h (PROP_gimple_lbitint): Define. (make_pass_lower_bitint_O0, make_pass_lower_bitint): Declare. * gimple-lower-bitint.h: New file. * tree-ssa-live.h (struct _var_map): Add bitint member. (init_var_map): Adjust declaration. (region_contains_p): Handle map->bitint like map->outofssa_p. * tree-ssa-live.cc (init_var_map): Add BITINT argument, initialize map->bitint and set map->outofssa_p to false if it is non-NULL. * tree-ssa-coalesce.cc: Include gimple-lower-bitint.h. (build_ssa_conflict_graph): Call build_bitint_stmt_ssa_conflicts if map->bitint. (create_coalesce_list_for_region): For map->bitint ignore SSA_NAMEs not in that bitmap, and allow res without default def. (compute_optimized_partition_bases): In map->bitint mode try hard to coalesce any SSA_NAMEs with the same size. (coalesce_bitint): New function. (coalesce_ssa_name): In map->bitint mode, or map->bitmap into used_in_copies and call coalesce_bitint. * gimple-lower-bitint.cc: New file.
[Bug c/110664] -std=c2x -pedantic-errors pedwarns on _Float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110664 --- Comment #4 from Jakub Jelinek --- Oops, sorry, failed to find this PR when writing the patch.
[Bug c/110664] -std=c2x -pedantic-errors pedwarns on _Float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110664
Joseph S. Myers changed:
What|Removed |Added
Target Milestone|--- |14.0
Resolution|--- |FIXED
Status|NEW |RESOLVED
--- Comment #3 from Joseph S. Myers ---
Fixed by
commit r14-3731-g80acabb6dd05090db67805cdd358fe974b45e2ed
Author: Jakub Jelinek
Date: Wed Sep 6 08:51:00 2023 +0200
c: Don't pedwarn on _FloatN{,x} or {f,F}N{,x} suffixes for C2X
[Bug fortran/111304] Problem when passing implicit arrays of characters to functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111304 --- Comment #1 from Baptiste Demoulin --- One comment: replacing `trim(prefix)` with `prefix(1:len_trim(prefix))` leads to the same result, as does putting simply `prefix`, so the problem does not seem to be related to using the `trim` function.
[Bug c/111307] New: RFE: builtin to construct va_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111307
Bug ID: 111307
Summary: RFE: builtin to construct va_list
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: equinox-gccbugs at diac24 dot net
Target Milestone: ---
A common pattern of defining a pair of varargs functions looks like:
void somefuncv(char *spec, va_list ap)
{
/* ... */
}
void somefunc(char *spec, ...)
{
va_list ap
va_start(ap, spec);
sumefuncv(spec, ap);
va_end(ap);
}
somefunc("%d", 1234); /* => quite a bit of wasted moving bits around */
However, the resulting code for calling somefunc() is suboptimal; the arguments
are arranged as specified by the psABI, only to then be rearranged into a
va_list by somefunc (which can be rather complex since somefunc has no clue
about type, number, or even floating-point calling conventions of its
arguments.)
It would be very helpful if GCC added a builtin function to create a va_list
for a given "...", with a (pseudo-)prototype like "__builtin_va_list
__builtin_va_construct(...)". This could be used to directly put together a
va_list at the caller's location, e.g.:
#define somefunc(spec, ...) somefuncv(spec,
__builtin_va_construct(__VA_ARGS__))
somefunc("%d", 1234); /* => minimal va_list to carry a single int */
Thus the round-trip through the psABI could be avoided, with the caller
constructing a minimal (since it knows all the args) va_list.
(This builtin would also make inlining varargs functions much less relevant,
since there are no more actual varargs functions in the latter example...)
[Bug c++/107198] [13/14 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:752 since r13-3175-g6ffbf87ca66f4ed9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107198 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug middle-end/111296] RISC-V vector: ICE in lra_split_hard_reg_for during reload pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111296 --- Comment #3 from CVS Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:6b96de22d6bcadb45530c1898b264e4738afa4fd commit r14-3744-g6b96de22d6bcadb45530c1898b264e4738afa4fd Author: Juzhe-Zhong Date: Wed Sep 6 22:28:03 2023 +0800 RISC-V: Fix incorrect mode tieable which cause ICE in RA[PR111296] This patch fix incorrect mode tieable between DI and V2SI which cause ICE in RA. gcc/ChangeLog: PR target/111296 * config/riscv/riscv.cc (riscv_modes_tieable_p): Fix incorrect mode tieable for RVV modes. gcc/testsuite/ChangeLog: PR target/111296 * g++.target/riscv/rvv/base/pr111296.C: New test.
[Bug target/111295] RISC-V vector ICE in vsetvl pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111295 --- Comment #6 from CVS Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:1b4c70d4271a00514ae20970d483c3b78d9d66ef commit r14-3743-g1b4c70d4271a00514ae20970d483c3b78d9d66ef Author: Juzhe-Zhong Date: Wed Sep 6 20:47:24 2023 +0800 RISC-V: Fix VSETVL PASS AVL/VL fetch bug[111295] Fix bugzilla: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111295 gcc/ChangeLog: PR target/111295 * config/riscv/riscv-vsetvl.cc (insert_vsetvl): Bug fix. gcc/testsuite/ChangeLog: PR target/111295 * gcc.target/riscv/rvv/autovec/pr111295.c: New test.
[Bug c++/83028] Incorrect -Wsequence-point warning in correct C++17 code with new evaluation order rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83028 --- Comment #5 from Jonathan Wakely --- Yes, obviously, because separate statements have a sequence point between them.
[Bug c++/52953] function parameter name redeclarations not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52953 --- Comment #13 from Jonathan Wakely --- Yes, Bug 74 is already closed as a duplicate of this one.
[Bug other/111288] formatting mistake in HTML documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111288 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2023-09-06 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #5 from Jonathan Wakely --- If you have an assignment in place then all you need to do is send the patch to the gcc-patches list.
[Bug c++/111300] [14 Regression] g++.dg/modules/xtreme-header_b.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111300 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2023-09-06 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- I'm going to "fix" this by moving the offending inline function out of the header, into libstdc++exp.a But it looks like there's a front end bug here, which will still be latent after that.
[Bug analyzer/105899] RFE: -fanalyzer could complain about misuses of standard C string APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105899 --- Comment #14 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:f2d7a4001a33884bc1dfd8da58e58dee18e3cd71 commit r14-3741-gf2d7a4001a33884bc1dfd8da58e58dee18e3cd71 Author: David Malcolm Date: Wed Sep 6 09:32:07 2023 -0400 analyzer: implement kf_strstr [PR105899] gcc/analyzer/ChangeLog: PR analyzer/105899 * kf.cc (class kf_strstr): New. (kf_strstr::impl_call_post): New. (register_known_functions): Register it. gcc/testsuite/ChangeLog: PR analyzer/105899 * c-c++-common/analyzer/strstr-1.c: New test. Signed-off-by: David Malcolm
[Bug analyzer/105899] RFE: -fanalyzer could complain about misuses of standard C string APIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105899 --- Comment #13 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:b51cde34d4e7504e821d935152c0ece0ce0dc74d commit r14-3740-gb51cde34d4e7504e821d935152c0ece0ce0dc74d Author: David Malcolm Date: Wed Sep 6 09:32:01 2023 -0400 analyzer: implement kf_strncpy [PR105899] gcc/analyzer/ChangeLog: PR analyzer/105899 * kf.cc (class kf_strncpy): New. (kf_strncpy::impl_call_post): New. (register_known_functions): Register it. * region-model.cc (region_model::read_bytes): Handle unknown number of bytes. gcc/testsuite/ChangeLog: PR analyzer/105899 * c-c++-common/analyzer/null-terminated-strings-2.c: New test. * c-c++-common/analyzer/overlapping-buffers.c: Update dg-bogus directives to avoid clashing with note from that might happen to have the same line number. Add strpncpy test coverage. * c-c++-common/analyzer/strncpy-1.c: New test. * gcc.dg/analyzer/null-terminated-strings-1.c (test_filled_nonzero): New. (void test_filled_zero): New. (test_filled_symbolic): New. Signed-off-by: David Malcolm
[Bug c++/107198] [13/14 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:752 since r13-3175-g6ffbf87ca66f4ed9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107198 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #7 from Marek Polacek --- Started with r13-3175: commit 6ffbf87ca66f4ed9cd79cff675fabe2109e46e85 Author: Jason Merrill Date: Sat Sep 17 12:04:05 2022 +0200 c++: track whether we expect a TARGET_EXPR to be elided
[Bug target/111232] RISC-V: Failed to combine vwmul + vadd into vwmacc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111232 JuzheZhong changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from JuzheZhong --- Fixed.
[Bug target/111295] RISC-V vector ICE in vsetvl pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111295 --- Comment #5 from JuzheZhong --- I see. A candidate patch to fix this issue: https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629456.html
[Bug c/111303] ICE: in type, at value-range.h:869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303 --- Comment #4 from Jiu Fu Guo --- For the pattern: "(X + C) / N", "op (plus@3 @0 INTEGER_CST@1) INTEGER_CST@2)" where "X" has value-range, and "X + C" does not overflow: && get_range_query (cfun)->range_of_expr (vr0, @0)) && get_range_query (cfun)->range_of_expr (vr1, @1) && range_op_handler (PLUS_EXPR).overflow_free_p (vr0, vr1) Then "@3"(it is X+C) would be with value-range usually. But for particular cases, like this PR, "vr3" is undefined. Below would be the reason for why "vr3" is undefined: _3 = _2 + -5; if (0 != 0) goto ; [34.00%] else goto ; [66.00%] ;; succ: 3 ;; 4 ;; basic block 3, loop depth 0 ;; pred: 2 _5 = _3 / 5; ;; succ: 4 The whole pattern "(_2 + -5 ) / 5" is in "bb 3", but "bb" would be unreachable (because "if (0 != 0)" is always false). And "get_range_query (cfun)->range_of_expr (vr3, @3)" is checked in "bb 3", "range_of_expr" gets an "undefined vr3".
[Bug c/111303] ICE: in type, at value-range.h:869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303 --- Comment #3 from Jiu Fu Guo --- In the pattern of match.pd, there is: && range_op_handler (PLUS_EXPR).overflow_free_p (vr0, vr1) && get_range_query (cfun)->range_of_expr (vr3, @3) /* "X+C" and "X" are not of opposite sign. */ && (TYPE_UNSIGNED (type) || (vr0.nonnegative_p () && vr3.nonnegative_p ()) || (vr0.nonpositive_p () && vr3.nonpositive_p ( For this case, "vr3" is "undefined_p", then "vr3.nonnegative_p ()" trige ICE. Checking "!vr3.undefine_p ()" would be a safe fix for this ICE.
[Bug c++/111306] New: macro-fusion makes error on conjugate complex multiplication
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111306
Bug ID: 111306
Summary: macro-fusion makes error on conjugate complex
multiplication
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: joony.wie at samsung dot com
Target Milestone: ---
It seems that the operands src1 and src2 of "_mm512_fcmul_pch" are swapped for
macro-fusion with optimize option.
If the operands are swapped, the imag value of result will have incorrect sign
bit.
So, the operands should not be swapped in these conjugate complex
multiplication intrinsics.
Let me show the example and the output.
output:
3.00 -4.00 // w/o optimize.
3.00 4.00 // w/ optimize.
https://godbolt.org/z/df9Gz18hc // but may not executable
```
#include
#include
__attribute__((optimize("O0")))
auto func0(_Float16 *a, _Float16 *b, int n, _Float16 *c) {
__m512h rA = _mm512_loadu_ph(a);
for (int i = 0; i < n; i += 32) {
__m512h rB = _mm512_loadu_ph(b + i);
_mm512_storeu_ph(c + i, _mm512_fcmul_pch(rB, rA));
}
}
__attribute__((optimize("O")))
auto func1(_Float16 *a, _Float16 *b, int n, _Float16 *c) {
__m512h rA = _mm512_loadu_ph(a);
for (int i = 0; i < n; i += 32) {
__m512h rB = _mm512_loadu_ph(b + i);
_mm512_storeu_ph(c + i, _mm512_fcmul_pch(rB, rA));
}
}
int main() {
int n = 32;
_Float16 a[n], b[n], c[n];
for (int i = 1; i <= n; i++) {
a[i - 1] = i & 1 ? -i : i;
b[i - 1] = i;
}
func0(a, b, n, c);
for (int i = 0; i < n / 32 * 2; i++) {
printf("%f ", (float)c[i]);
}
printf("\n");
func1(a, b, n, c);
for (int i = 0; i < n / 32 * 2; i++) {
printf("%f ", (float)c[i]);
}
printf("\n");
return 0;
}
```
[Bug analyzer/111305] New: GCC Static Analyzer -Wanalyzer-out-of-bounds FP and ICE problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111305
Bug ID: 111305
Summary: GCC Static Analyzer -Wanalyzer-out-of-bounds FP and
ICE problem
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: geoffreydgr at icloud dot com
Target Milestone: ---
ICE bug when analyzing the folowing program. And there also is a FP report of
out-of-bounds.
cmd: gcc -O0 -fanalyzer
gcc version: x86-64 gcc (trunk)
see it live:
https://godbolt.org/z/qKxde131e
```
#include
#include
struct a {
uint32_t b;
};
union c {
int8_t b;
};
int32_t *d( int32_t *j, int32_t k, struct a l) {
int64_t m[1]= {0};
for (l.b = 0; l.b <= 0; l.b++) {
printf("FLAG\n");
l.b == 12 && m[l.b];
}
}
```
out:
```
: In function 'd':
:15:19: warning: stack-based buffer over-read [CWE-121]
[-Wanalyzer-out-of-bounds]
15 | l.b == 12 && m[l.b];
| ~^
'd': events 1-10
|
| 12 | int64_t m[1]= {0};
| | ^
| | |
| | (1) capacity: 8 bytes
| 13 | for (l.b = 0; l.b <= 0; l.b++) {
| |
| | |
| | (2) following 'true' branch...
| | (6) following 'true' branch...
| 14 | printf("FLAG\n");
| |
| | |
| | (3) ...to here
| | (7) ...to here
| 15 | l.b == 12 && m[l.b];
| | ~~~
| | | | |
| | | | (9) ...to here
| | | (10) read of 8 bytes at offset 'l.b * 8' exceeds
'm'
| | (4) following 'false' branch...
| | (5) ...to here
| | (8) following 'true' branch...
|
:15:19: note: valid subscripts for 'm' are '[0]' to '[0]'
15 | l.b == 12 && m[l.b];
| ~^
during IPA pass: analyzer
:15:15: internal compiler error: in decompose, at wide-int.h:990
15 | l.b == 12 && m[l.b];
| ~~^
0x21af71e internal_error(char const*, ...)
???:0
0x9dd814 fancy_abort(char const*, int, char const*)
???:0
0x185a343 tree_zero_one_valued_p(tree_node*)
???:0
0x214b222 generic_simplify_MULT_EXPR(unsigned int, tree_code, tree_node*,
tree_node*, tree_node*)
???:0
0xce1d05 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
???:0
0xce96cd fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
???:0
0x18f3716 generic_simplify_23(unsigned int, tree_node*, tree_node*, tree_node*,
tree_node**, tree_code)
???:0
0x186889c generic_simplify_PLUS_EXPR(unsigned int, tree_code, tree_node*,
tree_node*, tree_node*)
???:0
0xce1d05 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
???:0
0xce96cd fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
???:0
0x21505bf generic_simplify_MULT_EXPR(unsigned int, tree_code, tree_node*,
tree_node*, tree_node*)
???:0
0xce1d05 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
???:0
0xce96cd fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_node*)
???:0
0x14d2c3f ana::region_offset::calc_symbolic_bit_offset(ana::region_model
const&) const
???:0
0x217faff ana::access_range::get_size(ana::region_model const&,
ana::bit_size_expr*) const
???:0
0x218cad3 ana::access_diagram_impl::access_diagram_impl(ana::access_operation
const&, diagnostic_event_id_t, text_art::style_manager&, text_art::theme
const&, ana::logger*)
???:0
0x2180abb ana::access_diagram::access_diagram(ana::access_operation const&,
diagnostic_event_id_t, text_art::style_manager&, text_art::theme const&,
ana::logger*)
???:0
0x2111f43 ana::symbolic_buffer_over_read::emit(rich_location*, ana::logger*)
???:0
0x2139d1e ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic&)
???:0
0x213a520 ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #61 from Andrew Church --- For the record, I'll maintain a copy of my (unaccepted) patch to add -Wunused-result=strict at: https://achurch.org/patch-pile/#gcc (wur-strict.diff) This flag obviously shouldn't be relied on in released packages, but it may be helpful for individual users trying to work around this issue.
Re: School District Contact - 2023
Hi there, We are excited to offer you a comprehensive email list of school districts that includes key contact information such as phone numbers, email addresses, mailing addresses, company revenue, size, and web addresses. Our databases also cover related industries such as: * K-12 schools * Universities * Vocational schools and training programs * Performing arts schools * Fitness centers and gyms * Child care services and providers * Educational publishers and suppliers If you're interested, we would be happy to provide you with relevant counts and a test file based on your specific requirements. Thank you for your time and consideration, and please let us know if you have any questions or concerns. Best regards, Donna Smith To remove from this mailing reply with the subject line " LEAVE US".
[Bug fortran/111304] New: Problem when passing implicit arrays of characters to functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111304 Bug ID: 111304 Summary: Problem when passing implicit arrays of characters to functions Product: gcc Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mailling-lists-bd at posteo dot de Target Milestone: --- Hi, In the following code, the first call to `func1` works as expected and prints the content of the array `my_directory`, while the second call, with the array defined directly in the function argument, leads to SIGABRT and prints ``` ARRAY = my_directory/file1my_directory/file2my_directory/dum1 my_directory/dum2 corrupted size vs. prev_size ``` I have tested with gfortran 13.2.1 (gfortran -o test program.f90), on Fedora 38. It should also be noticed that both function calls run fine if we remove the `trim(prefix)//` from each character string. ``` program test implicit none character(len=256) :: test_array(4) character(len=:), allocatable :: prefix integer :: res prefix = 'my_directory' test_array = [ character(len=256) :: & & trim(prefix)//'/file1', & & trim(prefix)//'/file2', & & trim(prefix)//'/dum1', & & trim(prefix)//'/dum2' & & ] print *, 'Test with "res = func1(test_array)"' res = func1(test_array) print *, 'Test with "res = func1([ character(len=) :: ...] )"' res = func1([ character(len=256) :: & & trim(prefix)//'/file1', & & trim(prefix)//'/file2', & & trim(prefix)//'/dum1', & & trim(prefix)//'/dum2' & & ]) contains function func1(array) result(res) character(len=*), intent(in) :: array(:) integer :: res print *, 'ARRAY = ', array res = 0 end function func1 end program test ```
[Bug c/111303] ICE: in type, at value-range.h:869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303 Jiu Fu Guo changed: What|Removed |Added Last reconfirmed||2023-09-06 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c/111303] ICE: in type, at value-range.h:869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303 Jiu Fu Guo changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |guojiufu at gcc dot gnu.org --- Comment #2 from Jiu Fu Guo --- Thanks for reporting this!
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 --- Comment #60 from Segher Boessenkool --- (In reply to Roman Krotov from comment #59) > All, what I'm asking for, is to make something like -Wno-void-unused, which > would suppress the warnings only for the (void) casted calls. So you want to not warn for some (just *some*) explicitly unused cases, and do warn for other explicitly unused cases, and all implicitly unused cases? While the author of the code explicitly asked for a warning message to be emitted in all such cases: "The 'warn_unused_result' attribute causes a warning to be emitted if a caller of the function with this attribute does not use its return value." > This is desperately needed by the projects like systemd (see the first link > in my first comment) as a less severe variant than -Wno-unused-result, so > that they won't get punished with less diagnostics. They (like EVERYONE ELSE IN THE WORLD) should not use -Werror, if they do not like punishment. Warnings are warnings. The author of your code (the header files for the library code) wanted everyone to be warned about not using the return value from a certain function. He/she was almost certainly right about that. And it is easy to suppress the warning in the few cases where you really want to. > I don't see any reason not to implement -Wno-void-unused with the similar > description (stating that it's not recommended, if you want) to help the > projects like systemd. Define what it would do *exactly*, make a patch for it (including for the documentation, amending all existing documentation as well), and do that in such a way that it a) is correct, and b) makes any sense. Then send the patch to gcc-patches@. If you do not want to do all that work (including the very much non-trivial amount of follow-up work that will cause), then please go away? Don't tell us to do insane things that are an incredible amount of work just because you had a bad idea and now want it to become reality. > It won't change the meaning of the wur attribute, bacause it will be a > non-default switch. This makes no sense at all.
[Bug target/111295] RISC-V vector ICE in vsetvl pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111295 --- Comment #4 from Jeremy Bennett --- @JuzheZhong - it's a C test case, not C++. Look like you are trying to compile it as C++.
[Bug target/111295] RISC-V vector ICE in vsetvl pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111295 --- Comment #3 from JuzheZhong --- This code can not be compiled: cc1plus: warning: command-line option '-Wno-implicit-function-declaration' is valid for C/ObjC but not for C++ bug.C: In function 'int q()': bug.C:6:9: warning: empty parentheses were disambiguated as a function declaration [-Wvexing-parse] 6 | int r (); | ^~ bug.C:6:9: note: remove parentheses to default-initialize a variable 6 | int r (); | ^~ | -- bug.C:25:19: error: 's' was not declared in this scope 25 | s (-l, ~0); | ^ bug.C:26:19: error: 't' was not declared in this scope 26 | t (j); | ^ bug.C:27:43: error: 'u' was not declared in this scope 27 | d = d + (a & 1000 ? u (r, 2) : b); | ^ bug.C:31:13: error: 's' was not declared in this scope 31 | p ? s () : 0; | ^ bug.C:33:1: warning: no return statement in function returning non-void [-Wreturn-type] 33 | }
[Bug target/111232] RISC-V: Failed to combine vwmul + vadd into vwmacc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111232 --- Comment #2 from CVS Commits --- The trunk branch has been updated by Lehua Ding : https://gcc.gnu.org/g:9ee40b9a7bee83394fc7ba6fef71cb76d91b49c8 commit r14-3735-g9ee40b9a7bee83394fc7ba6fef71cb76d91b49c8 Author: Lehua Ding Date: Mon Sep 4 17:15:08 2023 +0800 RISC-V: Keep vlmax vector operators in simple form until split1 pass This patch keep vlmax vector pattern in simple before split1 pass which will allow more optimization (e.g. combine) before split1 pass. This patch changes the vlmax pattern in autovec.md to define_insn_and_split as much as possible and clean up some combine patterns that are no longer needed. This patch also fixed PR111232 bug which was caused by a combined failed. PR target/111232 gcc/ChangeLog: * config/riscv/autovec-opt.md (@pred_single_widen_mul): Delete. (*pred_widen_mulsu): Delete. (*pred_single_widen_mul): Delete. (*dual_widen_): Add new combine patterns. (*single_widen_sub): Ditto. (*single_widen_add): Ditto. (*single_widen_mult): Ditto. (*dual_widen_mulsu): Ditto. (*dual_widen_mulus): Ditto. (*dual_widen_): Ditto. (*single_widen_add): Ditto. (*single_widen_sub): Ditto. (*single_widen_mult): Ditto. * config/riscv/autovec.md (3): Change define_expand to define_insn_and_split. (2): Ditto. (abs2): Ditto. (smul3_highpart): Ditto. (umul3_highpart): Ditto. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/widen/widen-4.c: Add more testcases. * gcc.target/riscv/rvv/autovec/widen/widen-complicate-4.c: Ditto. * gcc.target/riscv/rvv/autovec/pr111232.c: New test.
[Bug c/111303] ICE: in type, at value-range.h:869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303 Shaohua Li changed: What|Removed |Added CC||guojiufu at gcc dot gnu.org --- Comment #1 from Shaohua Li --- Bisected to r14-3644-g1aceceb1e2
[Bug target/111295] RISC-V vector ICE in vsetvl pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111295 JuzheZhong changed: What|Removed |Added CC||juzhe.zhong at rivai dot ai --- Comment #2 from JuzheZhong --- confirm
[Bug middle-end/111296] RISC-V vector: ICE in lra_split_hard_reg_for during reload pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111296 JuzheZhong changed: What|Removed |Added CC||juzhe.zhong at rivai dot ai --- Comment #2 from JuzheZhong --- confirm
[Bug libstdc++/111238] libstdc++ tests should use -Wl,-gc-sections in more configurations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111238 --- Comment #3 from Christophe Lyon --- The original problem is fixed by https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628998.html, and it seems better not to call GLIBCXX_CHECK_LINKER_FEATURES and silently hide a potential problem. Maybe we should actually remove -gc-sections from native builds too, so that all configurations are consistent? https://gcc.gnu.org/pipermail/gcc-patches/2023-September/629031.html
[Bug c/111303] New: ICE: in type, at value-range.h:869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111303
Bug ID: 111303
Summary: ICE: in type, at value-range.h:869
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
gcc at -O2 crashes on the following test case.
Compiler explorer: https://godbolt.org/z/qK6dMTK14
$ cat a.c
unsigned char a;
int b(int c) {
if (c >= 5000)
return c / 5;
}
void d() { b(a - 5); }
int main() {}
$
$ gcc -O2 a.c
during GIMPLE pass: evrp
: In function 'd':
:7:1: internal compiler error: in type, at value-range.h:869
7 | int main() {}
| ^~~
0x21af71e internal_error(char const*, ...)
???:0
0x9dd814 fancy_abort(char const*, int, char const*)
???:0
0x16cada5 gimple_simplify_TRUNC_DIV_EXPR(gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), code_helper, tree_node*, tree_node*, tree_node*)
???:0
0x180c22a gimple_match_op::resimplify(gimple**, tree_node* (*)(tree_node*))
???:0
0x180c880 gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
???:0
0x1f41940 gimple_ranger::fold_stmt(gimple_stmt_iterator*, tree_node*
(*)(tree_node*))
???:0
0x13c5478 rvrp_folder::fold_stmt(gimple_stmt_iterator*)
???:0
0x12a653e substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
???:0
0x1f09107 dom_walker::walk(basic_block_def*)
???:0
0x12a568b substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
???:0
0x13c4f9c execute_ranger_vrp(function*, bool, bool)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #12 from Iain Sandoe --- (In reply to Iain Sandoe from comment #11) > (In reply to François Dumont from comment #10) > > This is because you are facing the PR65762 issue. I just attached a path > > proposal to it that you need to apply too to be able to run your test. > > You'll be even able to simply use --disable-libstdcxx-dual-abi cause I made > > cxx11 abi the default in this case. > > Yes, with the second patch applied, that works for me also. > > Does gnu-versioned-namespace work for you with these two patches applied? > (I have a patch to enable versioned namespace on Darwin, which is very > similar to the GNU one, but it no longer builds).. FAOD, by which I mean "--enable-symvers=gnu-versioned-namespace" with no other configure options (which AFAICT disables dual ABI and enables the new one) ... I have more-or-less copied the gnu case for Darwin, but perhaps missed some case?
[Bug libstdc++/83077] sso-string @ gnu-versioned-namespace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 --- Comment #11 from Iain Sandoe --- (In reply to François Dumont from comment #10) > This is because you are facing the PR65762 issue. I just attached a path > proposal to it that you need to apply too to be able to run your test. > You'll be even able to simply use --disable-libstdcxx-dual-abi cause I made > cxx11 abi the default in this case. Yes, with the second patch applied, that works for me also. Does gnu-versioned-namespace work for you with these two patches applied? (I have a patch to enable versioned namespace on Darwin, which is very similar to the GNU one, but it no longer builds)..
[Bug libstdc++/111302] aligned std::experimental::simd loads and stores are not constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111302 Matthias Kretz (Vir) changed: What|Removed |Added Target Milestone|--- |14.0 Last reconfirmed||2023-09-06 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug libstdc++/111302] New: aligned std::experimental::simd loads and stores are not constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111302
Bug ID: 111302
Summary: aligned std::experimental::simd loads and stores are
not constant expressions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: mkretz at gcc dot gnu.org
Reporter: mkretz at gcc dot gnu.org
Target Milestone: ---
Test case (https://godbolt.org/z/d16rvjjsK):
#include
namespace stdx = std::experimental;
using V = stdx::native_simd;
alignas(64) constexpr float mem[32] = {};
constexpr V zero1 = V(mem, stdx::element_aligned);
constexpr V zero2 = V(mem, stdx::vector_aligned);
constexpr V zero3 = V(mem, stdx::overaligned<64>);
constexpr float tmp1 = [](){
float buf[V::size()] = {};
V().copy_to(buf, stdx::element_aligned);
return buf[0];
}();
constexpr float tmp2 = [](){
alignas(stdx::memory_alignment_v) float buf[V::size()] = {};
V().copy_to(buf, stdx::vector_aligned);
return buf[0];
}();
constexpr float tmp3 = [](){
alignas(64) float buf[V::size()] = {};
V().copy_to(buf, stdx::overaligned<64>);
return buf[0];
}();
The element_aligned variants compile. The others don't, but they should.
[Bug target/110643] [13/14 Regression] aarch64: Miscompilation at O1 level (O0 is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110643 --- Comment #12 from Mathieu Malaterre --- regression started today % cvise check.sh math_test.cc 00:00:27 INFO ===< 3971165 >=== 00:00:27 INFO running 4 interestingness tests in parallel 00:00:27 INFO INITIAL PASSES 00:00:27 INFO ===< IncludesPass >===
[Bug c++/83028] Incorrect -Wsequence-point warning in correct C++17 code with new evaluation order rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83028 Gayathri Gottumukkala changed: What|Removed |Added CC||gayathri.gottumukkala.27@gm ||ail.com --- Comment #4 from Gayathri Gottumukkala --- The code gives warning if we use different flags while compiling. If we give individual print statements instead of one single statement, then there will be no warnings and it is compiled successfully.
[Bug c++/52953] function parameter name redeclarations not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52953 Gayathri Gottumukkala changed: What|Removed |Added CC||gayathri.gottumukkala.27@gm ||ail.com --- Comment #12 from Gayathri Gottumukkala --- It is the duplicate of bug 74. Arguments of function redeclared in the function definition which is not possible.
[Bug c++/107198] [13/14 Regression] ICE in cp_gimplify_expr, at cp/cp-gimplify.cc:752 since r13-3175-g6ffbf87ca66f4ed9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107198 Gayathri Gottumukkala changed: What|Removed |Added CC||gayathri.gottumukkala.27@gm ||ail.com --- Comment #6 from Gayathri Gottumukkala --- This bug can fix by enabling exception handler we can enable by using -fno-exceptions flag.
