[Bug tree-optimization/102451] Suspicious null-pointer dereference in delete_dead_or_redundant_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102451 Feng Xue changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Feng Xue --- Fixed
[Bug tree-optimization/102400] Field might miss initialization in vn_reference_insert_pieces()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102400 Feng Xue changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Feng Xue --- Fixed
[Bug tree-optimization/102400] Field might miss initialization in vn_reference_insert_pieces()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102400 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Feng Xue : https://gcc.gnu.org/g:210c3901749a245dc45f04da3dac70ef126e6762 commit r11-9030-g210c3901749a245dc45f04da3dac70ef126e6762 Author: Feng Xue Date: Thu Sep 23 09:14:33 2021 +0800 Fix value uninitialization in vn_reference_insert_pieces [PR102400] 2021-09-23 Feng Xue gcc/ PR tree-optimization/102400 * tree-ssa-sccvn.c (vn_reference_insert_pieces): Initialize result_vdef to zero value.
[Bug tree-optimization/102451] Suspicious null-pointer dereference in delete_dead_or_redundant_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102451 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Feng Xue : https://gcc.gnu.org/g:03a8d9ab4cea24a945bb283c580d53a134221b9b commit r11-9029-g03a8d9ab4cea24a945bb283c580d53a134221b9b Author: Feng Xue Date: Thu Sep 23 08:47:45 2021 +0800 Fix null-pointer dereference in delete_dead_or_redundant_call [PR102451] 2021-09-23 Feng Xue gcc/ PR tree-optimization/102451 * tree-ssa-dse.c (delete_dead_or_redundant_call): Record bb of stmt before removal.
[Bug tree-optimization/102400] Field might miss initialization in vn_reference_insert_pieces()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102400 --- Comment #2 from CVS Commits --- The master branch has been updated by Feng Xue : https://gcc.gnu.org/g:29c92857039d0a105281be61c10c9e851aaeea4a commit r12-3875-g29c92857039d0a105281be61c10c9e851aaeea4a Author: Feng Xue Date: Thu Sep 23 09:14:33 2021 +0800 Fix value uninitialization in vn_reference_insert_pieces [PR102400] 2021-09-23 Feng Xue gcc/ PR tree-optimization/102400 * tree-ssa-sccvn.c (vn_reference_insert_pieces): Initialize result_vdef to zero value.
[Bug tree-optimization/102451] Suspicious null-pointer dereference in delete_dead_or_redundant_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102451 --- Comment #3 from CVS Commits --- The master branch has been updated by Feng Xue : https://gcc.gnu.org/g:f91b11eb8891f3ae910eb3b2e4a48e2d7d670d2d commit r12-3874-gf91b11eb8891f3ae910eb3b2e4a48e2d7d670d2d Author: Feng Xue Date: Thu Sep 23 08:47:45 2021 +0800 Fix null-pointer dereference in delete_dead_or_redundant_call [PR102451] 2021-09-23 Feng Xue gcc/ PR tree-optimization/102451 * tree-ssa-dse.c (delete_dead_or_redundant_call): Record bb of stmt before removal.
[Bug ipa/102474] [12 regression] Crash in ipa-modref compiling Go code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102474 Andrew Pinski changed: What|Removed |Added CC||marxin at gcc dot gnu.org Component|tree-optimization |ipa --- Comment #1 from Andrew Pinski --- /* We assume that containment and lossless merging was tested earlier. */ gcc_checking_assert (!contains (a) && !a.contains (*this) && !merge (a, record_adjustments)); gcc_checking_assert (parm_offset_known && a.parm_offset_known);
[Bug tree-optimization/102474] [12 regression] Crash in ipa-modref compiling Go code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102474 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |12.0
[Bug target/102472] Infinite loop on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102472 Andrew Pinski changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0
[Bug fortran/101320] Bind(C): Missing diagnostic for constraint C1557 on allocatable/pointer arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101320 --- Comment #1 from CVS Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:2646d0e06b170569be1da28fce1d6e2f03a15f60 commit r12-3871-g2646d0e06b170569be1da28fce1d6e2f03a15f60 Author: Sandra Loosemore Date: Thu Sep 23 08:03:52 2021 -0700 Fortran: Diagnose default-initialized pointer/allocatable dummies TS29113 changed what was then C516 in the 2010 Fortran standard (now C1557 in F2018) from disallowing all of pointer, allocatable, and optional attributes on dummy arguments to BIND(C) functions, to disallowing only pointer/allocatable with default-initialization. gfortran was previously failing to diagnose violations of this constraint. 2021-09-23 Sandra Loosemore PR fortran/101320 gcc/fortran/ * decl.c (gfc_verify_c_interop_param): Handle F2018 C1557, aka TS29113 C516. gcc/testsuite/ * gfortran.dg/c-interop/c516.f90: Remove xfails. Add more tests.
[Bug sanitizer/102317] signed integer overflow sanitizer cannot work well with -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317 --- Comment #11 from Kees Cook --- The trouble with "optimize" is that it just doesn't work. The kernel has banned its use because it results in all other optimization options being forgotten for the function in question.
[Bug target/102140] [12 Regression] ICE: in extract_constrain_insn, at recog.c:2670 (insn does not satisfy its constraints) with -Og -fipa-cp -fno-tree-ccp -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102140 --- Comment #4 from Segher Boessenkool --- Confirmed. Doesn't need -mlittle or -mabi=elfv2, or -mcpu=power8 even, but does need -mvsx.
[Bug tree-optimization/102474] New: [12 regression] Crash in ipa-modref compiling Go code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102474
Bug ID: 102474
Summary: [12 regression] Crash in ipa-modref compiling Go code
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at airs dot com
Target Milestone: ---
Compiling this Go program with -O1 -fno-strict-aliasing crashes the compiler in
ipa-modref.
package p
type S struct {
f1 string
f2 interface{}
f3 string
f4 struct {
f41 uint32
f42 struct {
f421 int32
f422 uint32
}
}
f5 struct {
f51 *byte
f52 *byte
f53 *byte
}
f6 struct {
f61 int32
}
f7 struct {
f71 uint64
f72 int64
f73 *byte
}
f8 *byte
}
The crash I see is:
during IPA pass: modref
go1: internal compiler error: in forced_merge, at ipa-modref-tree.h:351
0xcbaff1 modref_access_node::forced_merge(modref_access_node const&, bool)
../../trunk/gcc/ipa-modref-tree.h:351
0xcbe389 modref_ref_node::insert_access(modref_access_node, unsigned long,
bool)
../../trunk/gcc/ipa-modref-tree.h:575
0xcbe8e3 modref_tree::insert(int, int, modref_access_node, bool)
../../trunk/gcc/ipa-modref-tree.h:844
0xcb65de propagate_unknown_call
../../trunk/gcc/ipa-modref.c:3418
0xcb6a69 modref_propagate_in_scc
../../trunk/gcc/ipa-modref.c:3598
0xcb740e execute
../../trunk/gcc/ipa-modref.c:3968
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/77565] `typdef int Int;` --> did you mean `typeof`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77565 --- Comment #7 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:eb9f099c3df2b1b4c5fb0fa25cfdfa3cb5fc817e commit r12-3869-geb9f099c3df2b1b4c5fb0fa25cfdfa3cb5fc817e Author: Michel Morin Date: Thu Sep 16 23:29:54 2021 +0900 c++: add spellcheck suggestions for typedef etc. [PR77565] cp_keyword_starts_decl_specifier_p misses many keywords that can start decl-specifiers. This patch adds support for those keywords. PR c++/77565 gcc/cp/ChangeLog: * parser.c (cp_keyword_starts_decl_specifier_p): Handle more decl-specifiers (typedef/inline/cv/explicit/virtual/friend). gcc/testsuite/ChangeLog: * g++.dg/spellcheck-pr77565.C: New test.
[Bug middle-end/102464] Miss optimization for (_Float16) sqrtf ((float) f16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102464 --- Comment #4 from joseph at codesourcery dot com --- Note that for fma this would only be valid for -funsafe-math-optimizations.
[Bug fortran/102460] fortran internal compile error in coverage.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102460 --- Comment #3 from anlauf at gcc dot gnu.org --- Reduced testcase: MODULE MOD2 IMPLICIT NONE CONTAINS SUBROUTINE SUB1() ENTRY ENTRY1() END SUBROUTINE SUB1 END MODULE MOD2
[Bug fortran/102460] fortran internal compile error in coverage.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102460 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to fail||12.0 Last reconfirmed||2021-09-23 Ever confirmed|0 |1 --- Comment #2 from anlauf at gcc dot gnu.org --- Confirmed. The issue disappears if I comment out the line ENTRY ENTRY1() I also do not see it on 11-branch, but that may be related to my local build.
[Bug target/102472] Infinite loop on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102472 --- Comment #4 from Giulio Benetti --- Created attachment 51506 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51506=edit Pre-processed loop.c(loop.s)
[Bug target/102472] Infinite loop on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102472 --- Comment #3 from Giulio Benetti --- Created attachment 51505 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51505=edit Pre-processed loop.c(loop.i)
[Bug target/102472] Infinite loop on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102472 --- Comment #2 from Giulio Benetti --- Oh, I didn't know it could produce .i and .s even when hanging. But yes, that happens before really building. So .i .s files follow. Thank you and Best regards
[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 --- Comment #10 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2021-September/056571.html
[Bug fortran/102458] ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102458 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #9 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #8) > I think TRANSFER needs to be handled differently. > > From the same section of the Fortran standard, TRANSFER is > rejected if the following does not apply. > >(8) a reference to the intrinsic function TRANSFER where each >argument is a constant expression and each ultimate pointer >component of the SOURCE argument is disassociated, yeah, I did that for the final patch. Will submit soon. > So, one should be able to do something like > >integer,parameter :: n = 4 >integer,parameter :: x(transfer(n, n)) = 1 >print *, x >end > > which gfortran will give > > % gfortran10 -o z a.f90 > % ./z >1 1 1 1 This is less of an issue. We also currently fail on the following: subroutine s4 integer, parameter :: n = 4 integer, parameter :: x(transfer(n, n)) = 1 ! legal integer:: y(transfer(n, n)) = 2 ! legal integer, parameter :: k = size (x) ! ok integer, parameter :: m = size (y) ! fails, tracked separately print *, k, x, y if (k /= size (y)) stop 1 end For some reason we do not simplify SIZE(y), and this reason lies elsewhere. And it is not touch by my patch. > If you remove TRANSFER from the patch, it looks good to me. > We can revisit TRANSFER when Gerhard breaks gfortran, again! ;-) I'll bet he does, but don't hold your breath?
[Bug target/102472] Infinite loop on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102472 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-09-23 Component|c |target Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Keywords||compile-time-hog --- Comment #1 from Andrew Pinski --- >In this case that we have an infinite loop, I don't know how provide .i and .s >files. Can you please point me some instruction for this case? https://gcc.gnu.org/bugs/ has instructions on how to get the .i file. Basically add -save-temps to gcc command line (add -v too)
[Bug c++/98216] [C++20] template mangling for double template argument is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98216 Patrick Palka changed: What|Removed |Added CC||andrei.popa105 at yahoo dot com --- Comment #7 from Patrick Palka --- *** Bug 102092 has been marked as a duplicate of this bug. ***
[Bug c++/102092] [C++2b] Passing argument to auto template parameter modifies the value of argument inside function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102092 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org --- Comment #4 from Patrick Palka --- Thanks for the bug report, confirmed. It looks like the root cause is the same as PR98216, so I'm going to mark this bug a duplicate of that one. *** This bug has been marked as a duplicate of bug 98216 ***
[Bug c++/98216] [C++20] template mangling for double template argument is wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98216 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102463 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Andrew Macleod --- Fixed.
[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102463 --- Comment #7 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:fe4e6c824a580012bf9034cc33f0b440df93f56f commit r12-3868-gfe4e6c824a580012bf9034cc33f0b440df93f56f Author: Andrew MacLeod Date: Thu Sep 23 09:32:00 2021 -0400 Look for a relation between operands only when possible. Do not look for a relation between 2 operands if there is no range-ops handler. gcc/ PR tree-optimization/102463 * gimple-range-fold.cc (fold_using_range::relation_fold_and_or): If there is no range-ops handler, don't look for a relation. gcc/testsuite/ * gcc.dg/pr102463.c: New.
[Bug ipa/102388] [12 Regression] ICE in duplicate, at ipa-prop.c:4436 since r12-2523-g13586172d0b70c9d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102388 --- Comment #2 from Martin Jambor --- I proposed a fix on the mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/580183.html
[Bug fortran/93834] [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93834 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED CC||burnus at gcc dot gnu.org Resolution|--- |FIXED --- Comment #9 from Tobias Burnus --- FIXED. Thanks for the report. Based on the discussion, it was decided that the code is was probably valid (i.e. 'scalar[4]' is regarded as allocatable). Cf. https://gcc.gnu.org/pipermail/fortran/2021-September/056486.html and in particular Malcolm's judgement at https://mailman.j3-fortran.org/pipermail/j3/2021-September/013322.html
[Bug fortran/93834] [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93834 --- Comment #8 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:1b07d9dce6c51c98d011236c3d4cd84a2ed59ba2 commit r12-3866-g1b07d9dce6c51c98d011236c3d4cd84a2ed59ba2 Author: Tobias Burnus Date: Thu Sep 23 18:47:45 2021 +0200 Fortran: Handle allocated() with coindexed scalars [PR93834] While for an allocatable 'array', 'array(:)' and 'array(:)[1]' are not allocatable, it is believed that not only 'scalar' but also 'scalar[1]' is allocatable. However, coarrays are collectively established/allocated; thus, 'allocated(scalar[i])' is equivalent to 'allocated(scalar)'. [At least when assuming that 'i' does not refer to a failed image.] 2021-09-23 Harald Anlauf Tobias Burnus PR fortran/93834 gcc/fortran/ChangeLog: * trans-intrinsic.c (gfc_conv_allocated): Cleanup. Handle coindexed scalar coarrays. gcc/testsuite/ChangeLog: * gfortran.dg/coarray/coarray_allocated.f90: New test.
[Bug target/102473] New: 521.wrf_r 5% slower at -Ofast and generic x86_64 tuning after r12-3426-g8f323c712ea76c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102473 Bug ID: 102473 Summary: 521.wrf_r 5% slower at -Ofast and generic x86_64 tuning after r12-3426-g8f323c712ea76c Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jamborm at gcc dot gnu.org CC: crazylht at gmail dot com Blocks: 26163 Target Milestone: --- Host: x86_64-linux Target: x86_64-linux All three x86_64 LNT machines have detected a 4.5-5.2% performance regression of SPEC FPrate 2017 benchmarks 521.wrf_r when compiled with -Ofast and the default (generic) march and mtune. Zen2 based machine regressed by 5%: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=294.548.0 Zen1 based machine regressed by 5.2%: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=35.548.0 Kabylake based machine regressed by 4.5%: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=34.548.0 On an AMD zen2 based machine I have bisected the regression to commit r12-3426-g8f323c712ea76c: 8f323c712ea76cc4506b03895e9b991e4e4b2baf is the first bad commit commit 8f323c712ea76cc4506b03895e9b991e4e4b2baf Author: liuhongt Date: Tue Sep 7 12:39:04 2021 +0800 Optimize v4sf reduction. gcc/ChangeLog: PR target/101059 * config/i386/sse.md (reduc_plus_scal_): Split to .. (reduc_plus_scal_v4sf): .. this, New define_expand. (reduc_plus_scal_v2df): .. and this, New define_expand. I have confirmed that the commit causes a similar regression on another Intel Skylake server. On the Zen2 machine, this is the difference in samples collected by perf for different symbols (before is commit 60eec23b5ed, after commit 8f323c712ea): | Symbol | sys lib | Before | After | diff | % | |-+-++---+---+---| | __logf_fma | yes | 68882 | 68940 | +58 | +0.08 | | __atanf | yes | 4 | 66196 | -468 | -0.70 | | __module_advect_em_MOD_advect_scalar_pd | no | 62286 | 62348 | +62 | +0.10 | | __powf_fma | yes | 56213 | 56127 | -86 | -0.15 | | __module_mp_wsm5_MOD_nislfv_rain_plm| no | 46990 | 48340 | +1350 | +2.87 | | __module_mp_wsm5_MOD_wsm52d | no | 41031 | 40968 | -63 | -0.15 | | __module_small_step_em_MOD_advance_uv | no | 30908 | 30909 | +1 | +0.00 | | __module_small_step_em_MOD_advance_w| no | 28738 | 28600 | -138 | -0.48 | | __module_advect_em_MOD_advect_scalar| no | 28400 | 28429 | +29 | +0.10 | | __expf_fma | yes | 26702 | 26516 | -186 | -0.70 | | __module_big_step_utilities_em_MOD_phy_prep | no | 25878 | 25816 | -62 | -0.24 | | psim_unstable_ | no | 24994 | 25106 | +112 | +0.45 | | __module_bl_ysu_MOD_ysu2d | no | 24799 | 25251 | +452 | +1.82 | | psih_unstable_ | no | 22600 | 23139 | +539 | +2.38 | | __module_small_step_em_MOD_advance_mu_t | no | 22250 | 22232 | -18 | -0.08 | | __memset_avx2_unaligned_erms| yes | 21748 | 21613 | -135 | -0.62 | | _ZGVbN4vv_powf_sse4 | yes | 21206 | 21355 | +149 | +0.70 | Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 [Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
[Bug target/101985] vec_cpsgn parameter order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985 Bill Schmidt changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Assignee|unassigned at gcc dot gnu.org |wschmidt at gcc dot gnu.org Last reconfirmed||2021-09-23 --- Comment #1 from Bill Schmidt --- Confirmed. I'll take a look.
[Bug c/102472] New: Infinite loop on m68k
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102472 Bug ID: 102472 Summary: Infinite loop on m68k Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: giulio.benetti at benettiengineering dot com Target Milestone: --- When building python-uvloop package on Buildroot for m68k gcc enters an infinite loop on: ''' /home/giuliobenetti/autobuild/run/instance-3/output-1/host/bin/m68k-linux-gcc -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -g2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -g2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC -I/home/giuliobenetti/autobuild/run/instance-3/output-1/host/m68k-buildroot-linux-uclibc/sysroot/usr/include/python3.9 -c uvloop/loop.c -o build/temp.linux-x86_64-3.9/uvloop/loop.o -O2 ''' To reproduce it: # git clone git://git.busybox.net/buildroot # wget https://git.busybox.net/buildroot-test/tree/utils/br-reproduce-build - modify BASE_GIT=... with your buildroot path in br-reproduce-build then: # chmod a+x br-reproduce-build # ./br-reproduce-build 17d6e6422abadcd6313c430c40f2a5d7162dbbd3 The only way I've found to build correctly is to turn off optimization overriding CFLAGS with -O0. In this case that we have an infinite loop, I don't know how provide .i and .s files. Can you please point me some instruction for this case? Thanks in advance
[Bug libstdc++/102425] std::error_code() does not compare equal to std::error_condition()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102425 --- Comment #3 from Jonathan Wakely --- Fixed on trunk so far, but I'll backport it.
[Bug libstdc++/102425] std::error_code() does not compare equal to std::error_condition()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102425 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ce01e2e64c340dadb55a8a24c545a13e654804d4 commit r12-3859-gce01e2e64c340dadb55a8a24c545a13e654804d4 Author: Jonathan Wakely Date: Wed Sep 22 11:58:20 2021 +0100 libstdc++: std::system_category should know meaning of zero [PR102425] Although 0 is not an errno value, it should still be recognized as corresponding to a value belonging to the generic_category(). Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/102425 * src/c++11/system_error.cc (system_error_category::default_error_condition): Add 0 to switch. * testsuite/19_diagnostics/error_category/102425.cc: New test.
[Bug c++/102419] [11/12 Regression][concepts] [regression] return-type-requirement of "Y" does not check that T::type actually exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102419
--- Comment #5 from Patrick Palka ---
(In reply to Arthur O'Dwyer from comment #4)
> > IMHO Clang/MSVC are clearly misbehaving here -- when evaluating the
> > concept-id X, they appear to be substituting {int} into X's
> > constraint-expression instead of into the normal form of X's
> > constraint-expression.
>
> Isn't this situation exactly analogous to `std::void_t`?
>
> template using void_t = void;
> template auto foo(T t) -> void_t; // SFINAEs
> away
> template auto foo(T t) -> int; // this is the only viable
> candidate
> static_assert(std::same_as);
>
> The language has definitely decided that you can't preemptively fold
> `void_t` down to `void`;
True, that
I don't think you should
> be allowed to preemptively fold `Y` down to
> `true`, either.
> I don't know for sure that Clang/MSVC have been authoritatively dubbed
> righteous, but their behavior certainly seems, to me, more consistent and
> useful than GCC's.
(In reply to Arthur O'Dwyer from comment #4)
> > IMHO Clang/MSVC are clearly misbehaving here -- when evaluating the
> > concept-id X, they appear to be substituting {int} into X's
> > constraint-expression instead of into the normal form of X's
> > constraint-expression.
>
> Isn't this situation exactly analogous to `std::void_t`?
>
> template using void_t = void;
> template auto foo(T t) -> void_t; // SFINAEs
> away
> template auto foo(T t) -> int; // this is the only viable
> candidate
> static_assert(std::same_as);
>
> The language has definitely decided that you can't preemptively fold
> `void_t` down to `void`; I don't think you should
> be allowed to preemptively fold `Y` down to
> `true`, either.
I see what you mean, but I think the constraint normalization process as
currently specified forces us to effectively perform such folding.
Specifically in the definition of an atomic constraint
([temp.constr.atomic]p1):
An atomic constraint is formed from an expression E and a mapping from the
template parameters that appear within E to template arguments that are formed
via substitution during constraint normalization in the declaration of a
constrained entity.
the parameter mapping of an atomic constraint is defined to consist only of the
template parameters that _appear within E_. In this case E is just 'true',
which doesn't depend on any template parameters, so the normal form of
Y is just 'true (with empty parameter mapping)', which is
trivially satisfied for all T.
In order to achieve the behavior that you expect, IIUC this definition would
need to be changed to say that the parameter mapping of an atomic constraint
includes all in-scope template parameters and not only those that appear within
the expression.
[Bug tree-optimization/102462] vectorization breaks diagnostic for array out of bound detect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102462 Martin Sebor changed: What|Removed |Added Last reconfirmed||2021-09-23 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Blocks||88443 --- Comment #7 from Martin Sebor --- One thing to note here is that the three Wstringop-overflow tests mentioned in comment #0 disable -Warray-bounds. With the warning enabled the affected cases will (should) continue to trigger the expected diagnostics on the expected lines (and not on the in bounds accesses). I.e., the default GCC invocation (with no special codegen or warning suppression options) should be unaffected by the -O2 -> -O3 change, and so the regression in the quality of these diagnostics can be viewed as only minor. That -Warray-bounds is issued on the correct lines for these cases also confirms the viability of the idea of moving the strlen subset -Wstringop-overflow warnings into the -Warray-bounds pass. (As comment #6 implies, moving the whole strlen pass would likely have bigger repercussions and is not a suitable change just to maintain warning locations). Alternatively, since -Wstringop-overflow is documented to "warn for calls to string manipulation functions" it might make sense to consider disabling the -Wstringop-overflow warnings issued from the strlen pass as long as they're all handled by -Warray-bounds. (I'm not sure they are at present: I think out-of-bounds subobject accesses are not detected.) Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102463 --- Comment #6 from Andrew Macleod --- That trapping routine (relation_fold_and_or) is looking to see if there are any relationships between dependencies that can be exploited. ie c_2 = a_6 > b_7 c_3 = a_6 < b_7 c_4 = c_2 && c_3 if (c_4 != 0) when looking at c_2 and c_3, it notes that they both depend on the same 2 ssa-names, a_6, and a_7. It then queries whether there is a relationship between them when c_2 is [1,1] and c_3 is [1,1]. If so, it then tries to apply that relation to see if the stmt can never be true or not based on that raw relation. In this case, the 2 defining stmts are both PHI nodes, which happen to have the same 2 ssa_names in the dependency list, so it matches the pattern being looked for: # ntdef_6 = PHI # tdef_7 = PHI <_bfd_elf_merge_symbol_h.0_1(2), newdef_10(3)> _5 = __tdef_7 & ntdef_6 both names depend on the value of newdef_10 and _bfd_elf_merge_symbol_h.0_1, so a check is being made for a relationship between op1 and op2 in those stmts. Whats missing is that we can only check for operand relationships in range-ops enabled stmts... The phi will never overtly give us a relation between the first and second operand, so no need to check.
[Bug analyzer/102471] New: RFE: add support to analyzer testsuite for running SAMATE/SARD tests (e.g. Juliet Test Suite)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102471 Bug ID: 102471 Summary: RFE: add support to analyzer testsuite for running SAMATE/SARD tests (e.g. Juliet Test Suite) Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- See: https://www.nist.gov/itl/ssd/software-quality-group/samate https://samate.nist.gov/SARD/testsuite.php The links above have various promising-looking testsuites e.g. - Juliet Test Suite - Klocwork test suite - ITC-Benchmarks etc It would be good to be able to (somehow) automatically run them as part of regression testing of the analyzer - either by turning them directly into DejaGnu tests, or by wrapping the suite's own harness in a way that we can invoke it during "make check".
[Bug c++/102470] C++20 NTTP causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102470
--- Comment #1 from Kun Ge ---
I misplaced the wrong piece of codes.
the code that actually triggered the error is:
//---
#include
#include
struct MemAttr {
std::size_t size;
std::size_t align;
};
template constexpr MemAttr memAttrOf = MemAttr { .size =
sizeof(T), .align = alignof(T) };
template using AlignedStorage =
::std::aligned_storage_t;
template using AlignedStorageFor = AlignedStorage>;
//---
[Bug c++/102470] New: C++20 NTTP causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102470
Bug ID: 102470
Summary: C++20 NTTP causes ICE
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: iDingDong at outlook dot com
Target Milestone: ---
GCC 11.2 reports ICE to the following piece of code:
//---
#include
template struct A {
A(A const&) = default;
};
template T> struct A {
A(A const&) = default;
};
//---
Compiled with:
> gcc -std=c++20 test.cpp
The error message:
> gcc -std=c++20 test.cpp
> test.cpp: In substitution of 'template using AlignedStorage =
> std::aligned_storage_t<((const MemAttr)attr).size, ((const
> MemAttr)attr).align> [with MemAttr attr = memAttrOf]':
> test.cpp:13:75: required from here
> test.cpp:11:73: internal compiler error: Segmentation fault
>11 | template using AlignedStorage =
> ::std::aligned_storage_t;
> |
> ^~~~
> libbacktrace could not find executable to open
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See
[Bug target/102024] [12 Regression] zero width bitfields and ABIs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102024 --- Comment #16 from CVS Commits --- The master branch has been updated by William Schmidt : https://gcc.gnu.org/g:16e3d6b8b2b5168ebc773833f0e7ccf2191932c1 commit r12-3843-g16e3d6b8b2b5168ebc773833f0e7ccf2191932c1 Author: Bill Schmidt Date: Thu Sep 23 07:35:42 2021 -0500 rs6000: Add psabi diagnostic for C++ zero-width bit field ABI change Previously zero-width bit fields were removed from structs, so that otherwise homogeneous aggregates were treated as such and passed in FPRs and VSRs. This was incorrect behavior per the ELFv2 ABI. Now that these fields are no longer being removed, we generate the correct parameter passing code. Alert the unwary user in the rare cases where this behavior changes. 2021-09-23 Bill Schmidt gcc/ PR target/102024 * config/rs6000/rs6000-call.c (rs6000_aggregate_candidate): Detect zero-width bit fields and return indicator. (rs6000_discover_homogeneous_aggregate): Diagnose when the presence of a zero-width bit field changes parameter passing in GCC 12. gcc/testsuite/ PR target/102024 * g++.target/powerpc/pr102024.C: New.
[Bug fortran/102460] fortran internal compile error in coverage.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102460 --- Comment #1 from David Bold --- I got around to compile the most recent version (git commit 2f2dcbe471) and with that I get: MOD2.f:15:72: 15 | END MODULE MOD2 | ^ Error: function starts on a higher line number than it ends [-Werror=coverage-invalid-line-number] f951: some warnings being treated as errors
[Bug go/102469] New: gccgo: error: ‘copy’ defined as both imported name and global name, while golang does not produce this error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102469
Bug ID: 102469
Summary: gccgo: error: ‘copy’ defined as both imported name
and global name, while golang does not produce this
error
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: dilyan.palauzov at aegee dot org
CC: cmang at google dot com
Target Milestone: ---
I download the tip of https://github.com/containers/podman/ , commit
b0d1c0fe22da27c88a0e5d . With `go version go1.16.5 gccgo (GCC) 11.2.1 20210728
(Red Hat 11.2.1-1) linux/amd64` calling `make` the error is:
```
CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build \
-mod=vendor \
-ldflags '-X
github.com/containers/podman/v3/libpod/define.gitCommit=b0d1c0fe22da27c88a0e5de11de08d63ef861347
-X github.com/containers/podman/v3/libpod/define.buildInfo=1632396554 -X
github.com/containers/podman/v3/libpod/config._installPrefix=/usr/local -X
github.com/containers/podman/v3/libpod/config._etcDir=/usr/local/etc ' \
-tags " exclude_graphdriver_btrfs btrfs_noversion selinux systemd
exclude_graphdriver_devicemapper seccomp" \
-o bin/podman ./cmd/podman
go build: when using gccgo toolchain, please pass linker flags using
-gccgoflags, not -ldflags
# github.com/containers/storage/pkg/unshare
unshare.c: In function ‘parse_proc_stringlist’:
unshare.c:137:23: warning: comparison of integer expressions of different
signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Wsign-compare]
137 | for (n = 0; n < used; n++) {
| ^
unshare.c:148:23: warning: comparison of integer expressions of different
signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Wsign-compare]
148 | for (n = 0; n < used; n++) {
| ^
# github.com/containers/podman/v3/libpod
libpod/options.go:81:33: error: ‘copy’ defined as both imported name and global
name
81 |
copy(rt.storageConfig.GraphDriverOptions, config.GraphDriverOptions)
| ^
libpod/container_stat_linux.go:13:49: note: ‘copy’ imported here
13 | "github.com/containers/podman/v3/pkg/copy"
| ^
make: *** [Makefile:300: bin/podman] Error 2
With go version go1.16.8 linux/amd64 on the same system, calling `make`
produces no warngis. Even when I replace `-ldflags` with `-gccgoflags` the
signed/unsigned warning stays, and the `copy` error also stays.
If golang does not emit “error: ‘copy’ defined as both imported name and global
name”, gccgo shall neither.
[Bug c++/102468] New: False acceptance of invalid `using Parent::Grandparent`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102468
Bug ID: 102468
Summary: False acceptance of invalid `using
Parent::Grandparent`
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This code is invalid due-to specific `using` line, but GCC erroneously accepts
it:
```
struct A {};
struct B : A {};
struct C : B {
using B::A; //???
};
```
There shall be an error printed (as MSVC does)
[Bug tree-optimization/102467] Missed SLP discovery for gathers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102467 --- Comment #2 from Richard Biener --- Created attachment 51504 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51504=edit half-way patch A start, lacks adjustment of the code generation part which doesn't expect SLP at the moment.
[Bug tree-optimization/102467] Missed SLP discovery for gathers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102467 Richard Biener changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from Richard Biener --- "easiest" to do with the IFN scheme since then SLP discovery already sees IFN_GATHERs as discovered by pattern recog.
[Bug tree-optimization/102467] New: Missed SLP discovery for gathers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102467
Bug ID: 102467
Summary: Missed SLP discovery for gathers
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
void foo (double * __restrict a, long * __restrict b, double * c)
{
for (int i = 0; i < 1024; ++i)
{
a[2*i] = c[b[2*i]];
a[2*i + 1] = c[b[2*i + 1]];
}
}
is not SLP vectorized.
[Bug c++/98424] The point of destroying temporary objects when initializing an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98424 --- Comment #2 from jim x --- Clang destroys them at the end of the full-expression, see https://godbolt.org/z/3xhPjoh8c
[Bug tree-optimization/102448] [12 Regression] wrong codegen in gcc in spec2017 since 24f99147b9264f8f7d9cfb2fa6bd431edfa252d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102448 --- Comment #8 from Tamar Christina --- Thanks!
[Bug tree-optimization/102448] [12 Regression] wrong codegen in gcc in spec2017 since 24f99147b9264f8f7d9cfb2fa6bd431edfa252d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102448 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Richard Biener --- Fixed.
[Bug tree-optimization/102448] [12 Regression] wrong codegen in gcc in spec2017 since 24f99147b9264f8f7d9cfb2fa6bd431edfa252d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102448 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:c0cc62b32d95caca25a8854e0d2b6f11f5674d30 commit r12-3839-gc0cc62b32d95caca25a8854e0d2b6f11f5674d30 Author: Richard Biener Date: Thu Sep 23 10:27:01 2021 +0200 tree-optimization/102448 - clear copied alignment info from vect This fixes the previous change which removed setting alignment info from the vectorizers idea of how a pointer is being used but left in place the copied info from DR_PTR_INFO without realizing that this is in fact _not_ the alignment of the access but the alignment of a base pointer contained in it. The following makes sure to not use that info. 2021-09-23 Richard Biener PR tree-optimization/102448 * tree-vect-data-refs.c (vect_duplicate_ssa_name_ptr_info): Clear alignment info copied from DR_PTR_INFO.
[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102463 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||amacleod at redhat dot com Last reconfirmed||2021-09-23 --- Comment #5 from Aldy Hernandez --- (In reply to David Binderman from comment #4) > (In reply to Aldy Hernandez from comment #3) > > Could you provide a preprocessed source? > > ? It already is. It might need a few "int" and "void" to keep > modern C compilers happy. > > I forgot to add the relevant flags to the reduce. Sorry. > > Current git range is [5d110fe90afcd850..f6ccb788f29ce79a]. My bad. I got thrown off by the first line and assumed it was some enum specific to bfd. This looks like it came from Andrew's EDGE_EXECUTABLE patches: commit 73cf73af2392e00917de042a4692f6a0b6329ee8 commit 5d110fe90afcd850ea21aee6429f22edd6b1b592 This is an ICE in relation_fold_and_or where the defining statement for an SSA is a PHI, which obviously has no range-ops entry, so we shouldn't dereference its handler: range_operator *handler1 = gimple_range_handler (SSA_NAME_DEF_STMT (ssa1)); range_operator *handler2 = gimple_range_handler (SSA_NAME_DEF_STMT (ssa2)); int_range<2> bool_one (boolean_true_node, boolean_true_node); relation_kind relation1 = handler1->op1_op2_relation (bool_one); relation_kind relation2 = handler2->op1_op2_relation (bool_one); SSA_NAME_DEF_STMT(ssa1) is: ntdef_10 = PHI CCing author.
[Bug tree-optimization/102448] [12 Regression] wrong codegen in gcc in spec2017 since 24f99147b9264f8f7d9cfb2fa6bd431edfa252d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102448
--- Comment #5 from Richard Biener ---
[local count: 5160403229]:
# ivtmp.589_349 = PHI
_903 = (void *) ivtmp.589_349;
[ira-costs.c:1641:24] MEM [(int *)_903] = { 100, 100,
100, 100 };
ivtmp.589_627 = ivtmp.589_349 + 16;
goto ; [100.00%]
that's an endless loop...
but nothing wrong in .vect:
if (_475 <= 2)
goto ; [10.00%]
else
goto ; [90.00%]
[local count: 860067200]:
# RANGE [1, 1073741823] NONZERO 1073741823
bnd.549_503 = niters.548_402 >> 2;
vect_cst__537 = { 100, 100, 100, 100 };
# PT = null { D.10048 } (escaped, escaped heap)
# ALIGN = 8, MISALIGN = 0
vectp_newmem.553_545 = newmem_696 + 4;
[local count: 5160403229]:
# RANGE [0, 2147483647] NONZERO 2147483647
# i_395 = PHI <[ira-costs.c:1640:47] i_23(312), [ira-costs.c:1640:10] 0(397)>
# PT = null { D.10048 } (escaped, escaped heap)
# ALIGN = 4, MISALIGN = 0
# vectp_newmem.552_559 = PHI
# ivtmp_572 = PHI
[ira-costs.c:1641:24] MEM [(int *)vectp_newmem.552_559] =
vect_cst__537;
[ira-costs.c:1640:47] # RANGE [1, 2147483647] NONZERO 2147483647
i_23 = i_395 + 1;
[ira-costs.c:1640:17] # PT = null { D.10048 } (escaped, escaped heap)
# ALIGN = 8, MISALIGN = 0
vectp_newmem.552_560 = vectp_newmem.552_559 + 16;
[ira-costs.c:1640:17] ivtmp_587 = ivtmp_572 + 1;
if (ivtmp_587 < bnd.549_503)
goto ; [83.33%]
else
goto ; [16.67%]
[local count: 4300336028]:
goto ; [100.00%]
in IVOPTs we have
[local count: 5160403229]:
# ivtmp.589_349 = PHI
# PT = null { D.10048 } (escaped, escaped heap)
_903 = (void *) ivtmp.589_349;
[ira-costs.c:1641:24] MEM [(int *)_903] = { 100, 100,
100, 100 };
ivtmp.589_627 = ivtmp.589_349 + 16;
if (ivtmp.589_627 != _914)
goto ; [83.33%]
else
goto ; [16.67%]
but then CCP concludes the test is never false.
Visiting statement:
_914 = _398 + _935;
which is likely CONSTANT
Lattice value changed to CONSTANT 0x4 (0xfff8). Adding SSA edges
to worklist.
marking stmt to be not simulated again
Adding destination of edge (282 -> 283) to worklist
...
Simulating block 283
Visiting PHI node: ivtmp.589_349 = PHI
Argument #0 (283 -> 283 not executable)
Argument #1 (282 -> 283 executable)
ivtmp.589_618 Value: CONSTANT 0x0 (0xfff8)
PHI node value: CONSTANT 0x0 (0xfff8)
Lattice value changed to CONSTANT 0x0 (0xfff8). Adding SSA edges
to worklist.
Visiting statement:
# PT = null { D.10048 } (escaped, escaped heap)
_903 = (void *) ivtmp.589_349;
which is likely CONSTANT
Lattice value changed to CONSTANT 0x0 (0xfff8). Adding SSA edges
to worklist.
Visiting statement:
ivtmp.589_627 = ivtmp.589_349 + 16;
which is likely CONSTANT
Lattice value changed to CONSTANT 0x0 (0xfff8). Adding SSA edges
to worklist.
Visiting statement:
if (ivtmp.589_627 != _914)
which is likely CONSTANT
Adding destination of edge (283 -> 283) to worklist
Simulating block 283
Visiting PHI node: ivtmp.589_349 = PHI
Argument #0 (283 -> 283 executable)
ivtmp.589_627 Value: CONSTANT 0x0 (0xfff8)
Argument #1 (282 -> 283 executable)
ivtmp.589_618 Value: CONSTANT 0x0 (0xfff8)
PHI node value: CONSTANT 0x0 (0xfff8)
so CCP knows that _627 is aligned to 8 but _914 has a bit 0x4 set.
What's wrong is
# PT = { D.10048 } (escaped, escaped heap)
# ALIGN = 8, MISALIGN = 0
vectp_newmem.553_545 = newmem_696 + 4;
since newmem is aligned to 8, but here we offset it by 4.
It seems that DR_PTR_INFO cannot really be used to derive the alignment of
a pointer created from the access since it is the alignment of an SSA name
that's on the base of the ref which means that alignment info in this
does not reflect any constant or variable offset.
[Bug c++/102413] [12 Regression] ICE in cp_lexer_consume_token, at cp/parser.c:1172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102413 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0d39eb28fd2ab00306bd7c0a87b6c0ed615b5d12 commit r12-3831-g0d39eb28fd2ab00306bd7c0a87b6c0ed615b5d12 Author: Jakub Jelinek Date: Thu Sep 23 10:07:49 2021 +0200 openmp: Diagnose omp::directive attribute without balanced token argument [PR102413] If omp::directive attribute argument starting with the opening ( is not a balanced token sequence, then cp_parser_skip_balanced_tokens (parser, 1) returns 1, but the code was subtracting 2 from it and iterating until it was 0, so for the non-balanced case it iterated from (size_t) -1 down to 0. The following patch just diagnoses that as an error. 2021-09-23 Jakub Jelinek PR c++/102413 * parser.c (cp_parser_omp_directive_args): Diagnose if omp::directive is not followed by a balanced token sequence starting with open paren. * g++.dg/gomp/attrs-14.C: New test.
[Bug middle-end/102461] overflow in omp parallel for schedule (static,chunk_size)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102461 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Note, the general OpenMP restrictions say roughly that if there is any overflow during the computation of the number of loops, then the behavior is unspecified. So e.g. a loop #pragma omp for for (int i = -100; i < INT_MAX - 50; i++) is UB, because the number of iterations overflows in int. Though, in your case it is just the chunk_size computation that is done later and nothing talks about that being undefined. In the library for static,chunk_size the code handling it e.g. for long iterators (or whatever fits into it) is: unsigned long n, s0, e0, i, c; long s, e; /* Otherwise, each thread gets exactly chunk_size iterations (if available) each time through the loop. */ s = ws->incr + (ws->incr > 0 ? -1 : 1); n = (ws->end - ws->next + s) / ws->incr; i = thr->ts.team_id; c = ws->chunk_size; /* Initial guess is a C sized chunk positioned nthreads iterations in, offset by our thread number. */ s0 = (thr->ts.static_trip * nthreads + i) * c; e0 = s0 + c; /* Detect overflow. */ if (s0 >= n) return 1; if (e0 > n) e0 = n; /* Transform these to the actual start and end numbers. */ s = (long)s0 * ws->incr + ws->next; e = (long)e0 * ws->incr + ws->next; *pstart = s; *pend = e; if (e0 == n) thr->ts.static_trip = -1; else thr->ts.static_trip++; return 0; Any overflow in the s and n's computation are user's fault. thr->ts.static_trip says how many times the current thread got a chunk assigned before (with -1 means no more work for the current thread), so for e.g. very large values of chunk_size it will be at most 1 for some threads and thread numbers need to fit into int, so we can also assume there won't be more than INT_MAX threads. I guess for * c and + c we should use __builtin_mul_overflow and __builtin_add_overflow. And of course another thing is the inline expansion in omp-expand.c which could do the same thing.
[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102463 --- Comment #4 from David Binderman --- (In reply to Aldy Hernandez from comment #3) > Could you provide a preprocessed source? ? It already is. It might need a few "int" and "void" to keep modern C compilers happy. I forgot to add the relevant flags to the reduce. Sorry. Current git range is [5d110fe90afcd850..f6ccb788f29ce79a].
[Bug tree-optimization/102462] vectorization breaks diagnostic for array out of bound detect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102462 --- Comment #6 from Hongtao.liu --- Move pass_strlen before loop passes @@ -261,6 +261,7 @@ along with GCC; see the file COPYING3. If not see NEXT_PASS (pass_tsan); NEXT_PASS (pass_dse); NEXT_PASS (pass_dce); + NEXT_PASS (pass_strlen); /* Pass group that runs when 1) enabled, 2) there are loops in the function. Make sure to run pass_fix_loops before to discover/remove loops before running the gate function @@ -334,7 +335,6 @@ along with GCC; see the file COPYING3. If not see form if possible. */ NEXT_PASS (pass_thread_jumps); NEXT_PASS (pass_dominator, false /* may_peel_loop_headers_p */); - NEXT_PASS (pass_strlen); NEXT_PASS (pass_thread_jumps); NEXT_PASS (pass_vrp, false /* warn_array_bounds_p */); /* Threading can leave many const/copy propagations in the IL. causes 54 new fails c-c++-common/Wstringop-overflow.c -Wc++-compat (test for warnings, line 93) c-c++-common/Wstringop-overflow.c -Wc++-compat (test for warnings, line 94) c-c++-common/Wstringop-overflow.c -std=gnu++14 (test for warnings, line 93) c-c++-common/Wstringop-overflow.c -std=gnu++14 (test for warnings, line 94) c-c++-common/Wstringop-overflow.c -std=gnu++17 (test for warnings, line 93) c-c++-common/Wstringop-overflow.c -std=gnu++17 (test for warnings, line 94) c-c++-common/Wstringop-overflow.c -std=gnu++2a (test for warnings, line 93) c-c++-common/Wstringop-overflow.c -std=gnu++2a (test for warnings, line 94) c-c++-common/Wstringop-overflow.c -std=gnu++98 (test for warnings, line 93) c-c++-common/Wstringop-overflow.c -std=gnu++98 (test for warnings, line 94) g++.dg/tree-ssa/calloc.C -std=gnu++14 scan-tree-dump-not optimized "malloc" g++.dg/tree-ssa/calloc.C -std=gnu++14 scan-tree-dump-not optimized "memset" g++.dg/tree-ssa/calloc.C -std=gnu++14 scan-tree-dump-times optimized "calloc" 1 g++.dg/tree-ssa/calloc.C -std=gnu++17 scan-tree-dump-not optimized "malloc" g++.dg/tree-ssa/calloc.C -std=gnu++17 scan-tree-dump-not optimized "memset" g++.dg/tree-ssa/calloc.C -std=gnu++17 scan-tree-dump-times optimized "calloc" 1 g++.dg/tree-ssa/calloc.C -std=gnu++2a scan-tree-dump-not optimized "malloc" g++.dg/tree-ssa/calloc.C -std=gnu++2a scan-tree-dump-not optimized "memset" g++.dg/tree-ssa/calloc.C -std=gnu++2a scan-tree-dump-times optimized "calloc" 1 g++.dg/tree-ssa/calloc.C -std=gnu++98 scan-tree-dump-not optimized "malloc" g++.dg/tree-ssa/calloc.C -std=gnu++98 scan-tree-dump-not optimized "memset" g++.dg/tree-ssa/calloc.C -std=gnu++98 scan-tree-dump-times optimized "calloc" 1 gcc.dg/Wstringop-overflow-17.c (test for warnings, line 16) gcc.dg/Wstringop-overflow-17.c (test for warnings, line 9) gcc.dg/Wstringop-overflow-70.c (test for warnings, line 22) gcc.dg/tree-ssa/pr95731.c scan-tree-dump-times optimized " >= 0| < 0" 6 gcc.dg/tree-ssa/pr96480.c scan-tree-dump optimized " = _[0-9]* <= 3;" unix/-m32: c-c++-common/Wstringop-overflow.c -Wc++-compat (test for warnings, line 93) unix/-m32: c-c++-common/Wstringop-overflow.c -Wc++-compat (test for warnings, line 94) unix/-m32: c-c++-common/Wstringop-overflow.c -std=gnu++14 (test for warnings, line 93) unix/-m32: c-c++-common/Wstringop-overflow.c -std=gnu++14 (test for warnings, line 94) unix/-m32: c-c++-common/Wstringop-overflow.c -std=gnu++17 (test for warnings, line 93) unix/-m32: c-c++-common/Wstringop-overflow.c -std=gnu++17 (test for warnings, line 94) unix/-m32: c-c++-common/Wstringop-overflow.c -std=gnu++2a (test for warnings, line 93) unix/-m32: c-c++-common/Wstringop-overflow.c -std=gnu++2a (test for warnings, line 94) unix/-m32: c-c++-common/Wstringop-overflow.c -std=gnu++98 (test for warnings, line 93) unix/-m32: c-c++-common/Wstringop-overflow.c -std=gnu++98 (test for warnings, line 94) unix/-m32: g++.dg/tree-ssa/calloc.C -std=gnu++14 scan-tree-dump-not optimized "malloc" unix/-m32: g++.dg/tree-ssa/calloc.C -std=gnu++14 scan-tree-dump-not optimized "memset" unix/-m32: g++.dg/tree-ssa/calloc.C -std=gnu++14 scan-tree-dump-times optimized "calloc" 1 unix/-m32: g++.dg/tree-ssa/calloc.C -std=gnu++17 scan-tree-dump-not optimized "malloc" unix/-m32: g++.dg/tree-ssa/calloc.C -std=gnu++17 scan-tree-dump-not optimized "memset" unix/-m32: g++.dg/tree-ssa/calloc.C -std=gnu++17 scan-tree-dump-times optimized "calloc" 1 unix/-m32: g++.dg/tree-ssa/calloc.C -std=gnu++2a scan-tree-dump-not optimized "malloc" unix/-m32: g++.dg/tree-ssa/calloc.C -std=gnu++2a scan-tree-dump-not optimized "memset" unix/-m32: g++.dg/tree-ssa/calloc.C -std=gnu++2a scan-tree-dump-times optimized "calloc" 1 unix/-m32: g++.dg/tree-ssa/calloc.C -std=gnu++98 scan-tree-dump-not optimized "malloc" unix/-m32: g++.dg/tree-ssa/calloc.C -std=gnu++98 scan-tree-dump-not optimized "memset" unix/-m32: g++.dg/tree-ssa/calloc.C -std=gnu++98 scan-tree-dump-times optimized "calloc" 1
[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102463 --- Comment #3 from Aldy Hernandez --- Could you provide a preprocessed source?
[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347 --- Comment #10 from rguenther at suse dot de --- On Thu, 23 Sep 2021, linkw at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347 > > --- Comment #9 from Kewen Lin --- > (In reply to Peter Bergner from comment #7) > > (In reply to Martin Liška from comment #6) > > > Quickly looking at the rs6000 code, it fails here: > > > > > > #1 0x11a0993c in rs6000_invalid_builtin > > > (fncode=MMA_BUILTIN_DISASSEMBLE_ACC_INTERNAL) at > > > ../../gcc/config/rs6000/rs6000-call.c:11643 > > > #2 0x11a13134 in rs6000_builtin_decl (code=1603, > > > initialize_p=true) > > > at ../../gcc/config/rs6000/rs6000-call.c:13870 > > > #3 0x115c3900 in unpack_ts_function_decl_value_fields > > > (bp=0x3fffe2f0, expr=0x3fffaf195700) at > > > ../../gcc/tree-streamer-in.c:361 > > > #4 0x115c4790 in streamer_read_tree_bitfields (ib=0x3fffe6a0, > > > data_in=0x132d1910, expr=0x3fffaf195700) at > > > ../../gcc/tree-streamer-in.c:528 > > > #5 0x10deaa28 in lto_read_tree_1 (ib=0x3fffe6a0, > > > data_in=0x132d1910, expr=0x3fffaf195700) at > > > ../../gcc/lto-streamer-in.c:1697 > > > > > > which relies on rs6000_builtin_mask. Note the mask is set here: > > > rs6000_builtin_mask = rs6000_builtin_mask_calculate (); > > > > > > where rs6000_builtin_mask_calculate is based on TARGET_* values. Yeah, that's not going to work - if there are different builtin decls for different flags then you have to use different BUILT_IN_* codes as well.
[Bug tree-optimization/102452] Structs with flexible array members are not optimized on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102452 --- Comment #6 from rguenther at suse dot de --- On Thu, 23 Sep 2021, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102452 > > Andrew Pinski changed: > >What|Removed |Added > >Severity|normal |enhancement > Component|ipa |tree-optimization > > --- Comment #4 from Andrew Pinski --- > Oh it is just esra (and SRA) rejecting the struct: > Rejected (3268): zero structure field size: ret > > Rejected (3311): zero structure field size: ret > Rejected (3309): zero structure field size: D.3309 > > I had read the dump order incorrectly and such. Yeah - not sure why exactly it execuses itself for !DECL_SIZE fields, but well. Something to improve. (just ignore those fields)
[Bug c++/101133] [coroutines] co_await doesn't accept a valid awaitable object if await_resume()'s return type is not a built-in type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101133 emil.kultje at ericsson dot com changed: What|Removed |Added CC||emil.kultje at ericsson dot com --- Comment #1 from emil.kultje at ericsson dot com --- I'm also seeing this. It seems this was introduced in GCC 10.2. It worked fine in GCC 10.1, but not in later version. https://godbolt.org/z/eYjbnoxxK
[Bug tree-optimization/102452] Structs with flexible array members are not optimized on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102452
--- Comment #5 from rguenther at suse dot de ---
On Thu, 23 Sep 2021, pinskia at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102452
>
> --- Comment #3 from Andrew Pinski ---
> get_three after einline w/o USE_FLEX_ARR defined (this is changing the type to
> int):
>
>:
> _5 = test_2(D)->is_a;
> if (_5 != 0)
> goto ; [50.00%]
> else
> goto ; [50.00%]
>
>:
> D.3292 = *test_2(D);
> goto ; [100.00%]
>
>:
> _6 = test_2(D)->as.b.one;
> _7 = (long int) _6;
> _8 = test_2(D)->as.b.two;
> _9 = (long int) _8;
> _10 = test_2(D)->as.b.three;
> _11 = (long int) _10;
> D.3292.as.a.one = _7;
> D.3292.as.a.two = _9;
> D.3292.as.a.three = _11;
>
>:
> _4 = D.3292.as.a.three;
> return _4;
>
> With USE_FLEX_ARR defined to 1:
>:
> _5 = test_2(D)->is_a;
> if (_5 != 0)
> goto ; [50.00%]
> else
> goto ; [50.00%]
>
>:
> D.3293 = *test_2(D);
> goto ; [100.00%]
>
>:
> _6 = test_2(D)->as.b.one;
> _7 = (long int) _6;
> ret.as.a.one = _7;
> _8 = test_2(D)->as.b.two;
> _9 = (long int) _8;
> ret.as.a.two = _9;
> _10 = test_2(D)->as.b.three;
> _11 = (long int) _10;
> ret.as.a.three = _11;
> D.3293 = ret;
> ret ={v} {CLOBBER};
>
>:
> _4 = D.3293.as.a.three;
> return _4;
>
>
> as far as I can tell the IR is the same before that,
> even RSO:
> D.3293 = make_test_a (test_2(D)); [return slot optimization]
>
>
> But it looks in the case of the flex array case, RSO does not actually happen.
Are you sure it's not SRA behaving differently? The IL inlined early
is only showing in later dumps...
[Bug c++/97934] Adding an operator== breaks implicit operator== generation from defaulted <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97934 Fedor Chelnokov changed: What|Removed |Added CC||fchelnokov at gmail dot com --- Comment #3 from Fedor Chelnokov --- I believe, GCC is correct here as well as other compilers: https://gcc.godbolt.org/z/4nrdedbGd
[Bug c++/102465] Inaccessible operator == breaks child class with spaceship operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102465 --- Comment #2 from Fedor Chelnokov --- I believe PR 97934 is not much related, since the code there is processed the same by all compilers. And here GCC is the only one showing the error.
[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347 --- Comment #9 from Kewen Lin --- (In reply to Peter Bergner from comment #7) > (In reply to Martin Liška from comment #6) > > Quickly looking at the rs6000 code, it fails here: > > > > #1 0x11a0993c in rs6000_invalid_builtin > > (fncode=MMA_BUILTIN_DISASSEMBLE_ACC_INTERNAL) at > > ../../gcc/config/rs6000/rs6000-call.c:11643 > > #2 0x11a13134 in rs6000_builtin_decl (code=1603, initialize_p=true) > > at ../../gcc/config/rs6000/rs6000-call.c:13870 > > #3 0x115c3900 in unpack_ts_function_decl_value_fields > > (bp=0x3fffe2f0, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:361 > > #4 0x115c4790 in streamer_read_tree_bitfields (ib=0x3fffe6a0, > > data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:528 > > #5 0x10deaa28 in lto_read_tree_1 (ib=0x3fffe6a0, > > data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/lto-streamer-in.c:1697 > > > > which relies on rs6000_builtin_mask. Note the mask is set here: > > rs6000_builtin_mask = rs6000_builtin_mask_calculate (); > > > > where rs6000_builtin_mask_calculate is based on TARGET_* values. > > Is that really the issue though? In a non-lto compile, > handle_pragma_target() ends up calling rs6000_option_override_internal which > sets the TARGET_* flags for the function given the pragma options. Where > does LTO do that? I think I see lto read in the default options that were > set on the command line, but where and when does LTO set the options defined > by the pragma? Are they even streamed out to the fat obj file? They could > be there, but I'm not seeing it. I guess the problem here is this bif checking is so early, it's when we make up the bif function_decl tree_node, at that time the context is still the one with default option. I may be wrong, what I understood is that the target_option is streamed out as part of its associated function decl into decls section, when streaming in the decls section, the decls are constructed (including function decls with target_option and bif decls), the bif validity checking happen here. But function decls with target_option will be used for setting current function later when lto starts to process cgraph_node one by one. IIUC, fat obj file should not affect since it's mainly to control normal non-lto sections generated or not.
[Bug c++/102465] Inaccessible operator == breaks child class with spaceship operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102465 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97934 --- Comment #1 from Andrew Pinski --- Related to PR 97934.
[Bug c++/102466] New: -O3 -fsanitize=undefined causes warnings (writing 2 bytes into a region of size 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102466
Bug ID: 102466
Summary: -O3 -fsanitize=undefined causes warnings (writing 2
bytes into a region of size 0)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: unlvsur at live dot com
Target Milestone: ---
Created attachment 51503
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51503=edit
Preprocessed file
without -fsanitize=undefined or use -O2 won't trigger the warning here
cqwrteur@Home-Server:~/fast_io/examples/0021.kernel_driver$ g++ -S main.cc
-std=c++20 -I../../include -s -fno-exceptions -fno-rtti -fsanitize=undefined
-O3 -ffreestanding
In function 'constexpr void
fast_io::linux::print_status_define(fast_io::linux::basic_kpr, Args
...) [with bool line = true; ch_type = char; Args =
{fast_io::basic_io_scatter_t,
fast_io::manipulators::scalar_manip_t,
fast_io::basic_io_scatter_t, fast_io::basic_io_scatter_t,
fast_io::manipulators::scalar_manip_t,
fast_io::manipulators::scalar_manip_t}]':
cc1plus: warning: writing 2 bytes into a region of size 0
[-Wstringop-overflow=]
cc1plus: warning: writing 2 bytes into a region of size 0
[-Wstringop-overflow=]
cc1plus: warning: writing 2 bytes into a region of size 0
[-Wstringop-overflow=]
cc1plus: warning: writing 2 bytes into a region of size 0
[-Wstringop-overflow=]
cc1plus: warning: writing 2 bytes into a region of size 0
[-Wstringop-overflow=]
cc1plus: warning: writing 2 bytes into a region of size 0
[-Wstringop-overflow=]
cc1plus: warning: writing 2 bytes into a region of size 0
[-Wstringop-overflow=]
cc1plus: warning: writing 2 bytes into a region of size 0
[-Wstringop-overflow=]
cc1plus: warning: writing 2 bytes into a region of size 0
[-Wstringop-overflow=]
cc1plus: warning: writing 2 bytes into a region of size 0
[-Wstringop-overflow=]
cc1plus: warning: writing 2 bytes into a region of size 0
[-Wstringop-overflow=]
This is freestanding code to reduce size of processor file. You can just treat
printk function as printf. -ffreestanding does not affect whether the warning
would emit or not.
Do not know whether it is a false positive.
[Bug tree-optimization/102452] Structs with flexible array members are not optimized on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102452 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Component|ipa |tree-optimization --- Comment #4 from Andrew Pinski --- Oh it is just esra (and SRA) rejecting the struct: Rejected (3268): zero structure field size: ret Rejected (3311): zero structure field size: ret Rejected (3309): zero structure field size: D.3309 I had read the dump order incorrectly and such.
[Bug c++/102465] New: Inaccessible operator == breaks child class with spaceship operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102465
Bug ID: 102465
Summary: Inaccessible operator == breaks child class with
spaceship operator
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
Below code is valid:
```
#include
struct A {
std::strong_ordering operator <=>(const A &) const = default;
bool operator==(int) const;
};
struct B : A {
virtual std::strong_ordering operator <=>(const B &) const noexcept =
default;
};
B b; //GCC error here
```
but GCC prints an error compiling it. Demo: https://gcc.godbolt.org/z/584nhfxxs
It shall just delete `operator ==` in B.
[Bug tree-optimization/102462] vectorization breaks diagnostic for array out of bound detect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102462 --- Comment #5 from Hongtao.liu --- It looks like vectorized stmt is always marked as the first access lineno.
[Bug tree-optimization/102462] vectorization breaks diagnostic for array out of bound detect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102462
--- Comment #4 from Hongtao.liu ---
case1
struct A1
{
char n;
char a[1];// { dg-message "destination object" "note" }
};
struct A1 a1__ = { 0 };
void ga1__ (void)
{
a1__.a[0] = 0;
a1__.a[1] = 1; // { dg-warning "\\\[-Wstringop-overflow" }
a1__.a[2] = 2; // { dg-warning "\\\[-Wstringop-overflow" }
struct A1 a = { 1 };
a.a[0] = 0;
a.a[1] = 1;// { dg-warning "\\\[-Wstringop-overflow" }
a.a[2] = 2;// { dg-warning "\\\[-Wstringop-overflow" }
sink ();
}
[Bug tree-optimization/102462] vectorization breaks diagnostic for array out of bound detect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102462
--- Comment #3 from Hongtao.liu ---
case3:
struct A1
{
char n;
char a[1];// { dg-message "destination object" "note" }
};
void sink (void*);
struct A1 a1i_1 = { 0, { 1 } };
void ga1i_1 (void)
{
a1i_1.a[0] = 0;
a1i_1.a[1] = 1; // { dg-warning "\\\[-Wstringop-overflow" }
a1i_1.a[2] = 2; // { dg-warning "\\\[-Wstringop-overflow" }
struct A1 a = { 0, { 1 } };
a.a[0] = 1;
a.a[1] = 2; // { dg-warning "\\\[-Wstringop-overflow" }
a.a[2] = 3; // { dg-warning "\\\[-Wstringop-overflow" }
sink ();
}
I think i was wrong, there's no case3, case3 is just case2, part of access
inbound, part is not, now the warning message is from struct A1 a = { 0, { 1 }
}; which is recorded as the vectorized stmt lineno
[case3.c:15:13] MEM [(char *)] = { 0, 1, 2, 3 };
[Bug ipa/102452] Structs with flexible array members are not optimized on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102452
--- Comment #3 from Andrew Pinski ---
get_three after einline w/o USE_FLEX_ARR defined (this is changing the type to
int):
:
_5 = test_2(D)->is_a;
if (_5 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
:
D.3292 = *test_2(D);
goto ; [100.00%]
:
_6 = test_2(D)->as.b.one;
_7 = (long int) _6;
_8 = test_2(D)->as.b.two;
_9 = (long int) _8;
_10 = test_2(D)->as.b.three;
_11 = (long int) _10;
D.3292.as.a.one = _7;
D.3292.as.a.two = _9;
D.3292.as.a.three = _11;
:
_4 = D.3292.as.a.three;
return _4;
With USE_FLEX_ARR defined to 1:
:
_5 = test_2(D)->is_a;
if (_5 != 0)
goto ; [50.00%]
else
goto ; [50.00%]
:
D.3293 = *test_2(D);
goto ; [100.00%]
:
_6 = test_2(D)->as.b.one;
_7 = (long int) _6;
ret.as.a.one = _7;
_8 = test_2(D)->as.b.two;
_9 = (long int) _8;
ret.as.a.two = _9;
_10 = test_2(D)->as.b.three;
_11 = (long int) _10;
ret.as.a.three = _11;
D.3293 = ret;
ret ={v} {CLOBBER};
:
_4 = D.3293.as.a.three;
return _4;
as far as I can tell the IR is the same before that,
even RSO:
D.3293 = make_test_a (test_2(D)); [return slot optimization]
But it looks in the case of the flex array case, RSO does not actually happen.
[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102463 --- Comment #2 from David Binderman --- (In reply to David Binderman from comment #1) > 142 revisions in the gap, trying 24f99147b9264f8f. Revision looks good, trying f6ccb788f29ce79a, although Aldy seems to be in the frame for this one.
[Bug tree-optimization/102448] [12 Regression] wrong codegen in gcc in spec2017 since 24f99147b9264f8f7d9cfb2fa6bd431edfa252d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102448 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target|aarch64 |aarch64, x86_64-*-* Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-09-23 Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- I can reproduce the issue on x86_64 with -O3 -flto (but not -O2 -flto or -O3 -fno-tree-vectorize -flto). I'm taking a look.
[Bug middle-end/102464] Miss optimization for (_Float16) sqrtf ((float) f16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102464 --- Comment #3 from Richard Biener --- There's related optimizations in convert () which should ideally move to match.pd
[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102463 Richard Biener changed: What|Removed |Added Priority|P3 |P1 CC||aldyh at gcc dot gnu.org
[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102347 Kewen Lin changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org, ||rguenth at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org --- Comment #8 from Kewen Lin --- (In reply to Martin Liška from comment #6) > Quickly looking at the rs6000 code, it fails here: > > #1 0x11a0993c in rs6000_invalid_builtin > (fncode=MMA_BUILTIN_DISASSEMBLE_ACC_INTERNAL) at > ../../gcc/config/rs6000/rs6000-call.c:11643 > #2 0x11a13134 in rs6000_builtin_decl (code=1603, initialize_p=true) > at ../../gcc/config/rs6000/rs6000-call.c:13870 > #3 0x115c3900 in unpack_ts_function_decl_value_fields > (bp=0x3fffe2f0, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:361 > #4 0x115c4790 in streamer_read_tree_bitfields (ib=0x3fffe6a0, > data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:528 > #5 0x10deaa28 in lto_read_tree_1 (ib=0x3fffe6a0, > data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/lto-streamer-in.c:1697 > > which relies on rs6000_builtin_mask. Note the mask is set here: > rs6000_builtin_mask = rs6000_builtin_mask_calculate (); > > where rs6000_builtin_mask_calculate is based on TARGET_* values. > > I think the mask check should be deferred later as it should be based on > proper > target_node that is set via rs6000_set_current_function. It should not check > it in lto_read_tree_1. Thanks for looking into this, Martin! I tried to investigate if we can set target_option_node as the appropriate fndecl when doing the check, then both rs6000 and aarch64 ports don't need to change the hook since both of them respect target_option_node switches well. We have streamed out those fndecls with their target_option_nodes (if they have) into the .gnu.lto_.decls.xxx, fndecls are built well after reading, for one bif fndecl, if we know which function it exists in, we can set_current_function to the corresponding fndecl when checking the bif. After some hackings, I noticed that there are two difficulties: 1) For one bif, we need a way to know which fndecls use it. Now there seems no information easy for this right before checking the bif? 2) One bif can sit in several functions which probably have different target_option_nodes, we have to iterate all of them. This seems artificial just for this need. I might still miss something, but after the hacking I agree to update the target hooks is better. For rs6000, the mask checking removal aligns with the way that i386 uses and also some changes like r10-7462 by neglecting mask. Later rs6000_expand_builtin will still do the check with mask. But the erroring would be in LTRANS, WPA phase won't emit error then. Is it one concern? If so, which place can we delay this check to? For aarch64 port, it seems to need some more adjustments?
[Bug tree-optimization/102462] vectorization breaks diagnostic for array out of bound detect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102462 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Can you reproduce compilable small testcases for all three cases here? I can't find 'gali_1' and esp. how struct A1 is laid out.
[Bug ipa/102452] Structs with flexible array members are not optimized on stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102452 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-09-23 --- Comment #2 from Richard Biener --- adding a char member may also change TBAA, so see whether it reproduces with making the flexarray member a int []
[Bug tree-optimization/102448] [12 Regression] wrong codegen in gcc in spec2017 since 24f99147b9264f8f7d9cfb2fa6bd431edfa252d2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102448 --- Comment #3 from Richard Biener --- (In reply to Tamar Christina from comment #2) > I have double checked the revision and it does start happening with it. > > Though I can only reproduce it with -flto. the codegen without lto seems > the same. > > Any ideas how to debug further? Since you identified the offending assembler see what's the corresponding source portion - there look at the .optimized gimple dumps and see when the bad code was introduced. I'll see if the issue reproduces on x86_64. What options are you using for aarch64 besides -flto and which -march?
[Bug tree-optimization/102463] [12 Regression] ice in fold_using_range::relation_fold_and_or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102463 --- Comment #1 from David Binderman --- 142 revisions in the gap, trying 24f99147b9264f8f.
[Bug other/102440] Uinteger Opt/Param but the underlying type is signed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102440 --- Comment #3 from Kewen Lin --- (In reply to Andrew Pinski from comment #2) > The other option handling bug report I saw dealing with the awk script was > recorded as other. Thanks Andrew! I just found there is a "other", how blind I am!
[Bug middle-end/102464] Miss optimization for (_Float16) sqrtf ((float) f16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102464 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-09-23 Keywords||internal-improvement --- Comment #2 from Andrew Pinski --- Confirmed. fabs and fma I don't think they need to be internal functions as there are already tree codes for them.
