[Bug middle-end/102810] [11/12 Regression] Bogus Wstringop-overread passing a smaller array to an array parameter without a bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102810 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/103771] [12 Regression] Missed vectorization under -mavx512f -mavx512vl after r12-5489
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103771
--- Comment #28 from Richard Biener ---
(In reply to Hongtao.liu from comment #25)
> in fold_unary_loc
> ---cut from fold-const.cc-
> 9276 else if (TREE_CODE (arg0) == COND_EXPR)
> 9277{
> 9278 tree arg01 = TREE_OPERAND (arg0, 1);
> 9279 tree arg02 = TREE_OPERAND (arg0, 2);
> 9280 if (! VOID_TYPE_P (TREE_TYPE (arg01)))
> 9281arg01 = fold_build1_loc (loc, code, type,
> 9282 fold_convert_loc (loc,
> 9283 TREE_TYPE (op0),
> arg01));
> 9284 if (! VOID_TYPE_P (TREE_TYPE (arg02)))
> 9285arg02 = fold_build1_loc (loc, code, type,
> 9286 fold_convert_loc (loc,
> 9287 TREE_TYPE (op0),
> arg02));
> 9288=>tem = fold_build3_loc (loc, COND_EXPR, type, TREE_OPERAND
> (arg0, 0),
> 9289 arg01, arg02);
>
> ---end---
>
> gcc always tries to simplify (convert (cond (cmp a b) c d) > (cond (cmp
> a b) (convert c) (convert d))， exactly the opposite of what this case wants.
It also then undos this if the result didn't simplify and plays trick to avoid
recursions.
I think this particular transform ought to be specialized, maybe to
(T)p?(T')a:(T')b or maybe done during gimplification or RTL expansion only.
The "cheap" way of avoiding a conflict is to wrap the match.pd pattern
with opposite logic in
#if GIMPLE
#endif
(with a comment explaining this)
Note that we can move a conversion out only if the sources of the conversions
have compatible types but we always can move a conversion in.
Alternatively this transform can also be done in a vectorizer pattern based
on vector compatibility of the ?: predicate with the data.
[Bug tree-optimization/103121] [12 Regression] Warnings in cp/optimize.c causing build failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121 --- Comment #21 from rguenther at suse dot de --- On Tue, 18 Jan 2022, amacleod at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103121 > > --- Comment #20 from Andrew Macleod --- > I think the anaylsis in comment 5 and onward needs to be redone since it was > using rangers debug output to see something wrong, but the pass isn't even > using ranger.. It is using EVRP as we determined in comments 14 and 15.. > > So I do not know where this stands, I don't think ranger is even involved? The ranger API is, which gives the caller the possibility to pass in a "context" stmt. But with EVRP you can only ever query the "actual" context (the BB the domwalk currently is processing), since global ranges are adjusted. If you ever ask for a different context you will get wrong answers. So maybe the ranger API needs to be adjusted to ICE whenever the context is not the current one in case EVRP is active (not sure if it even knows about the EVRP domwalk). Or using the ranger APIs should be forbidden when the EVRP domwalk is active (or the EVRP domwalk needs to be instructed to not adjust global ranges - IIRC we had a switch for that somewhere).
[Bug target/104110] AArch64 unnecessary use of call-preserved register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104110
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-01-19
Keywords|ra |
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #3 from Andrew Pinski ---
Rs6000 has:
/* On the RS/6000, if it is valid in the insn, it is free. */
case CONST_INT:
if (((outer_code == SET
|| outer_code == PLUS
|| outer_code == MINUS)
&& (satisfies_constraint_I (x)
|| satisfies_constraint_L (x)))
While aarch64 has:
/* If an instruction can incorporate a constant within the
instruction, the instruction's expression avoids calling
rtx_cost() on the constant. If rtx_cost() is called on a
constant, then it is usually because the constant must be
moved into a register by one or more instructions.
The exception is constant 0, which can be expressed
as XZR/WZR and is therefore free. The exception to this is
if we have (set (reg) (const0_rtx)) in which case we must cost
the move. However, we can catch that when we cost the SET, so
we don't need to consider that here. */
if (x == const0_rtx)
*cost = 0;
else
{
/* To an approximation, building any other constant is
proportionally expensive to the number of instructions
required to build that constant. This is true whether we
are compiling for SPEED or otherwise. */
if (!is_a (mode, _mode))
int_mode = word_mode;
*cost = COSTS_N_INSNS (aarch64_internal_mov_immediate
(NULL_RTX, x, false, int_mode));
}
I think rs6000 definition should be used instead otherwise we get the case
where (set (reg) (reg)) is the same cost as (set (reg) (const_int)) so GCC
decides it is better to do the (set (reg) (reg)) instead of staying with the
(set (reg) (const_int)).
[Bug lto/98504] [11/12 Regression] bootstrap broken in libgo on ia64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98504 Richard Biener changed: What|Removed |Added Priority|P3 |P4 --- Comment #14 from Richard Biener --- (In reply to John Paul Adrian Glaubitz from comment #11) > (In reply to John Paul Adrian Glaubitz from comment #10) > > (In reply to Richard Biener from comment #9) > > > Any update on the status on current trunk? > > > > I can give it a try later this week. We have a new shiny ia64 porterbox in > > Debian now :-). > > So, I just did a bootstrap build with > > $ ../configure --prefix=$HOME/gcc-install --enable-multilib > --enable-languages=c,c++,go --with-system-libunwind > > and it built fine without any issues. Btw, that was never broken - broken was a build with --with-build-config=bootstrap-lto-lean I'd still be interested if that now works. P4 as default config bootstrap never was broken and ia64-linux isn't primary or secondary.
[Bug middle-end/102860] [12 regression] libgomp.fortran/simd2.f90 ICEs after r12-4526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102860
--- Comment #9 from rguenther at suse dot de ---
On Tue, 18 Jan 2022, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102860
>
> Jakub Jelinek changed:
>
>What|Removed |Added
>
> CC||jakub at gcc dot gnu.org
>
> --- Comment #7 from Jakub Jelinek ---
> Short testcase:
> function foo(a)
> integer(kind=4) :: a(1024)
> a(:) = modulo (a(:), 39)
> end function
> -O2 -mcpu=power10.
> vect_recog_divmod_pattern only handles TRUNC_{DIV,MOD}_EXPR and EXACT_DIV_EXPR
> (and isn't guaranteed to succeed anyway), but optab_for_tree_code returns the
> same smod_optab or sdiv_optab (if signed; FLOOR_* for unsigned is mapped to
> TRUNC_*).
> I guess the quickest way would be to punt on {CEIL,FLOOR,ROUND}_{DIV,MOD}_EXPR
> in the vectorizer and tree-vect-generic.cc
True.
> Further gradual improvements can be:
> 1) match.pd has:
> /* For unsigned integral types, FLOOR_DIV_EXPR is the same as
>TRUNC_DIV_EXPR. Rewrite into the latter in this case. */
> (simplify
> (floor_div @0 @1)
> (if ((INTEGRAL_TYPE_P (type) || VECTOR_INTEGER_TYPE_P (type))
> && TYPE_UNSIGNED (type))
> (trunc_div @0 @1)))
> but expmed.cc has:
> /* Promote floor rounding to trunc rounding for unsigned operations. */
> if (unsignedp)
> {
> if (code == FLOOR_DIV_EXPR)
> code = TRUNC_DIV_EXPR;
> if (code == FLOOR_MOD_EXPR)
> code = TRUNC_MOD_EXPR;
> if (code == EXACT_DIV_EXPR && op1_is_pow2)
> code = TRUNC_DIV_EXPR;
> }
> Shouldn't we make it
> (for floor_divmod (floor_div floor_mod)
> trunc_divmod (trunc_div trunc_mod)
> (simplify
> (floor_divmod @0 @1)
> (if ((INTEGRAL_TYPE_P (type) || VECTOR_INTEGER_TYPE_P (type))
>&& TYPE_UNSIGNED (type))
>(trunc_divmod @0 @1
> ?
Yeah, if the simplification is incomplete we should amend it.
> 2) as the RTL optabs really do just trunc div/mod, perhaps
> tree-vect-patterns.cc
> could be changed to replace some or all of those operations with the trunc
> operation followed by some arith and cond_exprs so that the vectorizer knows
> actual cost of those operations.
> E.g. it seems expmed.cc expands
> r = x %[fl] y;
> as
> r = x % y; if (r && (x ^ y) < 0) r += y;
> and
> d = x /[fl] y;
> would be
> r = x % y; d = x / y; if (r && (x ^ y) < 0) --d;
> Looking at wide-int.h,
> r = x %[cl] y;
> as
> r = x % y; if (r && (x ^ y) >= 0) r -= y;
> and
> d = /[cl] y;
> as
> r = x % y; d = x / y; if (r && (x ^ y) >= 0) ++d;
> All of the above for signed, as I said earlier, unsigned [fl] is the same as
> trunc and unsigned [cl] should replace (x ^ y) >= 0 with 1.
> [rd] is even more complex.
That sounds reasonable as well. I think we can do 0) and 1) now and
defer 2) to the next stage1, maybe tracking it with an enhancement
bugreport.
[Bug target/104110] AArch64 unnecessary use of call-preserved register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104110 Andrew Pinski changed: What|Removed |Added Target|aarch64 |aarch64*-*-* arm*-*-* --- Comment #2 from Andrew Pinski --- Ok, this is interesting. On PowerPC and x86_64, rtl cse does not do the cse of the constant but for aarch64 and arm it does ... There has to be some cost issue.
[Bug testsuite/102833] [12 regression] gcc.dg/vect/bb-slp-17.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102833 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug testsuite/102833] [12 regression] gcc.dg/vect/bb-slp-17.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102833 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:54e33cf120dab24ce44d7d6028e6247c9489092f commit r12-6722-g54e33cf120dab24ce44d7d6028e6247c9489092f Author: Richard Biener Date: Wed Jan 19 08:17:10 2022 +0100 testsuite/102833 - fix gcc.dg/vect/bb-slp-17.c dump scanning The desired transform requires V2SI vector add support, the closest we have is vect64 so check that which at least fixes the i?86 fail. 2022-01-19 Richard Biener PR testsuite/102833 * gcc.dg/vect/bb-slp-17.c: Require vect64.
[Bug tree-optimization/102943] [12 Regression] Jump threader compile-time hog with 521.wrf_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102943 Richard Biener changed: What|Removed |Added Last reconfirmed|2021-10-26 00:00:00 |2022-1-18 --- Comment #34 from Richard Biener --- We are about as fast as GCC 10 now where GCC 11 was significantly better in overall compile-time. But note this cannot really be accounted just to jump threading anymore (unless of course we thread a lot more). There is a 1% code size "jump" around the time the compile-time increases which can hardly explain all of the difference. Note we are now talking about -O2. I'm leaving this open for more investigation.
[Bug target/104110] AArch64 unnecessary use of call-preserved register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104110 Andrew Pinski changed: What|Removed |Added Keywords||ra --- Comment #1 from Andrew Pinski --- This is interesting. The register allocation should have rematerlized the constant on the other side of the call.
[Bug target/104110] New: AArch64 unnecessary use of call-preserved register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104110
Bug ID: 104110
Summary: AArch64 unnecessary use of call-preserved register
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nate at thatsmathematics dot com
Target Milestone: ---
gcc misses an optimization (or in some sense deoptimizes) by using a
call-preserved register to save a trivial constant across a function call.
Source code:
void bar(unsigned);
unsigned foo(unsigned c) {
bar(1U << c);
return 1;
}
Output from gcc -O3 on AArch64:
foo:
stp x29, x30, [sp, -32]!
mov x29, sp
str x19, [sp, 16]
mov w19, 1
lsl w0, w19, w0
bl bar
mov w0, w19
ldr x19, [sp, 16]
ldp x29, x30, [sp], 32
ret
Note that x19 is used unnecessarily to save the constant 1 across the function
call, causing an unnecessary push and pop. It would have been better to just
use some call-clobbered register for the constant 1 before the function call,
and then a simple `mov w0, 1` afterward.\
Same behavior with -O, -O2, -Os. Tested on godbolt, affects yesterday's trunk
and all the way back to 5.4.
Might be related to bug 70801 or bug 71768 but I am not sure.
[Bug target/104090] [10/11/12 Regression] powerpc: asm machine directive wrong for FSL processors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104090 --- Comment #2 from CVS Commits --- The master branch has been updated by Sebastian Huber : https://gcc.gnu.org/g:1ead972cef7622682c5e6c4fa563c4a894d6e0c3 commit r12-6721-g1ead972cef7622682c5e6c4fa563c4a894d6e0c3 Author: Sebastian Huber Date: Tue Jan 18 12:44:53 2022 +0100 powerc: Fix asm machine directive for some CPUs For some CPUs, the assembler machine directive cannot be determined by ISA flags. gcc/ PR target/104090 * config/rs6000/rs6000.cc (rs6000_machine_from_flags): Use also rs6000_cpu.
[Bug testsuite/104021] gcc.dg/vect/tsvc tests failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104021 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed.
[Bug testsuite/104021] gcc.dg/vect/tsvc tests failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104021 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:8160b410517e1e3493d92358579d380872acb3e8 commit r12-6720-g8160b410517e1e3493d92358579d380872acb3e8 Author: Rimvydas Jasinskas Date: Tue Jan 18 06:27:17 2022 + Fix tsvc test build on DragonFly. Currently all tsvc tests fail to build on DragonFly BSD because they assume and memalign() are available. gcc/testsuite/ChangeLog: PR testsuite/104021 * gcc.dg/vect/tsvc/tsvc.h: Do not include malloc.h on dragonfly and use posix_memalign (). Signed-off-by: Rimvydas Jasinskas
[Bug testsuite/104022] g++.dg/gcov/pr16855.C does not precleanup upon failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104022 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Martin Liška --- Fixed now.
[Bug testsuite/104022] g++.dg/gcov/pr16855.C does not precleanup upon failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104022 --- Comment #4 from Martin Liška --- (In reply to Rimvydas (RJ) from comment #2) > Created attachment 52224 [details] > proposed patch > > I do not have write access. Would Signed-off-by version be OK? Sure, I've just installed that on your behalf.
[Bug testsuite/104022] g++.dg/gcov/pr16855.C does not precleanup upon failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104022 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:32657045bd28f7d35c9b814d8b338c21e4f5dc40 commit r12-6719-g32657045bd28f7d35c9b814d8b338c21e4f5dc40 Author: Rimvydas Jasinskas Date: Tue Jan 18 06:12:45 2022 + Add XFAIL parts of pr16855.C for dragonfly. On DragonFly BSD profiling ends before these DTORs are invoked on dso cleanup. The -static compilation works as expected. gcc/testsuite/ChangeLog: PR testsuite/104022 * g++.dg/gcov/pr16855.C: xfail the count lines for DTORs on dragonfly. * g++.dg/gcov/pr16855-priority.C: Ditto. Adjust source layout so that dejagnu xfail expressions work. Signed-off-by: Rimvydas Jasinskas
[Bug ipa/103378] [12 Regression] ICE: verify_cgraph_node failed (error: semantic interposition mismatch) since r12-5412-g458d2c689963d846
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103378 --- Comment #5 from Martin Liška --- @Honza: Any progress with this one?
[Bug testsuite/104109] [12 Regression] ERROR: g++.dg/gcov/gcov-17.C : error executing dg-final: can't read "script": no such variable by r12-6629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104109 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Martin Liška --- Fixed, thanks for the report.
[Bug testsuite/104109] [12 Regression] ERROR: g++.dg/gcov/gcov-17.C : error executing dg-final: can't read "script": no such variable by r12-6629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104109 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:b01d2059c703d447827cc82e0e27e460a38bfa9f commit r12-6718-gb01d2059c703d447827cc82e0e27e460a38bfa9f Author: Martin Liska Date: Wed Jan 19 07:37:42 2022 +0100 testsuite: fix pytest detection unsupported message. PR testsuite/104109 gcc/testsuite/ChangeLog: * lib/gcov.exp: Fix pytest detection unsupported message.
[Bug testsuite/104109] [12 Regression] ERROR: g++.dg/gcov/gcov-17.C : error executing dg-final: can't read "script": no such variable by r12-6629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104109 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED CC|mliska at suse dot cz |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Mine.
[Bug target/103771] [12 Regression] Missed vectorization under -mavx512f -mavx512vl after r12-5489
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103771 --- Comment #27 from Hongtao.liu --- (In reply to Andrew Pinski from comment #26) > (In reply to Hongtao.liu from comment #25) > > > > gcc always tries to simplify (convert (cond (cmp a b) c d) > (cond (cmp > > a b) (convert c) (convert d))， exactly the opposite of what this case wants. > > Right that is for generic. For the gimple level the function > factor_out_conditional_conversion in phiopt is supposed to undo this but as Oh, thanks for the info. I'll leave it to you in GCC13.
[Bug target/103771] [12 Regression] Missed vectorization under -mavx512f -mavx512vl after r12-5489
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103771 --- Comment #26 from Andrew Pinski --- (In reply to Hongtao.liu from comment #25) > > gcc always tries to simplify (convert (cond (cmp a b) c d) > (cond (cmp > a b) (convert c) (convert d))， exactly the opposite of what this case wants. Right that is for generic. For the gimple level the function factor_out_conditional_conversion in phiopt is supposed to undo this but as I mentioned it does not always.
[Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015 Kewen Lin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Kewen Lin --- Should be fixed on latest trunk.
[Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015 --- Comment #12 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:fc6cd798c07a94d6b0bcc16b175e6e5d6e594c7e commit r12-6717-gfc6cd798c07a94d6b0bcc16b175e6e5d6e594c7e Author: Kewen Lin Date: Tue Jan 18 20:31:46 2022 -0600 testsuite: Adjust possibly fragile slp-perm-9.c [PR104015] As Richard pointed out in PR104015, the test case slp-perm-9.c can be fragile when vectorizer tries to use different vectorisation strategies. As suggested, this patch tries to make the check not sensitive on the re-trying times by removing the times checking. To still retain the test coverage on unnecessary re-trying, for example it exposes this PR104015 on Power9, I added two test cases to powerpc testsuite. gcc/testsuite/ChangeLog: PR tree-optimization/104015 * gcc.dg/vect/slp-perm-9.c: Adjust. * gcc.target/powerpc/pr104015-1.c: New test. * gcc.target/powerpc/pr104015-2.c: New test.
[Bug target/103771] [12 Regression] Missed vectorization under -mavx512f -mavx512vl after r12-5489
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103771
--- Comment #25 from Hongtao.liu ---
in fold_unary_loc
---cut from fold-const.cc-
9276 else if (TREE_CODE (arg0) == COND_EXPR)
9277{
9278 tree arg01 = TREE_OPERAND (arg0, 1);
9279 tree arg02 = TREE_OPERAND (arg0, 2);
9280 if (! VOID_TYPE_P (TREE_TYPE (arg01)))
9281arg01 = fold_build1_loc (loc, code, type,
9282 fold_convert_loc (loc,
9283 TREE_TYPE (op0),
arg01));
9284 if (! VOID_TYPE_P (TREE_TYPE (arg02)))
9285arg02 = fold_build1_loc (loc, code, type,
9286 fold_convert_loc (loc,
9287 TREE_TYPE (op0),
arg02));
9288=>tem = fold_build3_loc (loc, COND_EXPR, type, TREE_OPERAND (arg0,
0),
9289 arg01, arg02);
---end---
gcc always tries to simplify (convert (cond (cmp a b) c d) > (cond (cmp a
b) (convert c) (convert d))， exactly the opposite of what this case wants.
[Bug testsuite/104021] gcc.dg/vect/tsvc tests failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104021 --- Comment #2 from Rimvydas (RJ) --- Created attachment 52225 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52225=edit Signed-off-by version
[Bug testsuite/104022] g++.dg/gcov/pr16855.C does not precleanup upon failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104022 --- Comment #2 from Rimvydas (RJ) --- Created attachment 52224 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52224=edit proposed patch I do not have write access. Would Signed-off-by version be OK?
[Bug libstdc++/104085] mips: libstdc++ ABI check compares against wrong file if GCC is configured with --with-abi=(32|64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104085 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-19 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. Not a regression.
[Bug rtl-optimization/104059] [12 Regression] cprop_hardreg propgates hard registers for mov instructions between different REG_CLASS without considering cost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104059 --- Comment #5 from Andrew Pinski --- Hmm, -fno-tree-ter "fixes" this one too. I have not looked into why though.
[Bug target/104049] [12 Regression] vec_select to subreg lowering causes superfluous moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049 Andrew Pinski changed: What|Removed |Added Component|rtl-optimization|target --- Comment #7 from Andrew Pinski --- Hmm, ;; _43 = .REDUC_PLUS (vect__7.11_47); (insn 23 22 24 (set (reg:V4SI 112) (unspec:V4SI [ (reg:V4SI 103 [ vect__7.11 ]) ] UNSPEC_ADDV)) -1 (nil)) (insn 24 23 0 (set (reg:SI 102 [ _43 ]) (vec_select:SI (reg:V4SI 112) (parallel [ (const_int 0 [0]) ]))) -1 (nil)) Could we just represent REDUC_PLUS as: (insn 23 22 24 (set (reg:SI 112) (unspec:SI [ (reg:V4SI 103 [ vect__7.11 ]) ] UNSPEC_ADDV_1)) -1 (nil)) And then I don't think we will have the issue with the vec_select and subreg really.
[Bug rtl-optimization/104059] [12 Regression] cprop_hardreg propgates hard registers for mov instructions between different REG_CLASS without considering cost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104059
Andrew Pinski changed:
What|Removed |Added
Target|x86_64-*-* i?86-*-* |x86_64-*-* i?86-*-*
|aarch64*-*-*|
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> Figures. I might take a look tomorrow.
Before in GCC 11 for gimple level:
vect_sum_26.13_34 = VIEW_CONVERT_EXPR(vect__7.9_48);
_32 = (vector(4) unsigned int) vect_sum_26.13_34;
_31 = VEC_PERM_EXPR <_32, { 0, 0, 0, 0 }, { 2, 3, 4, 5 }>;
_25 = _31 + _32;
_19 = VEC_PERM_EXPR <_25, { 0, 0, 0, 0 }, { 1, 2, 3, 4 }>;
_18 = _19 + _25;
stmp_sum_26.14_17 = BIT_FIELD_REF <_18, 32, 0>;
_44 = VEC_PERM_EXPR ;
_38 = _44 + vect__7.9_48;
_37 = VEC_PERM_EXPR <_38, { 0, 0, 0, 0 }, { 1, 2, 3, 4 }>;
_36 = _37 + _38;
stmp__9.12_35 = BIT_FIELD_REF <_36, 32, 0>;
_20 = stmp_sum_26.14_17 & 65535;
_10 = (unsigned int) _20;
_12 = stmp__9.12_35 >> 16;
_13 = _10 + _12;
_14 = _13 >> 1;
_23 = (int) _14;
After on the trunk:
_43 = VEC_PERM_EXPR ;
_42 = _43 + vect__7.11_47;
_41 = VEC_PERM_EXPR <_42, { 0, 0, 0, 0 }, { 1, 2, 3, 4 }>;
_34 = _41 + _42;
stmp__9.14_33 = BIT_FIELD_REF <_34, 32, 0>;
_37 = stmp__9.14_33 & 65535;
_12 = stmp__9.14_33 >> 16;
_13 = _12 + _37;
_14 = _13 >> 1;
_23 = (int) _14;
As you can see the number of adds and PERM is better. I don't see anything that
should be done on the gimple level, the gimple level looks decent now.
Basically what was _10 previously is now _37 and all of the extra casts were
removed.
[Bug rtl-optimization/104049] [12 Regression] vec_select to subreg lowering causes superfluous moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049 --- Comment #6 from Andrew Pinski --- Before my patch we had on the gimple level: vect_sum_26.13_38 = VIEW_CONVERT_EXPR(vect__7.9_48); _36 = (vector(4) unsigned int) vect_sum_26.13_38; _35 = .REDUC_PLUS (_36); _34 = (int) _35; _44 = .REDUC_PLUS (vect__7.9_48); _20 = _34 & 65535; _10 = (unsigned int) _20; _12 = _44 >> 16; _13 = _10 + _12; _14 = _13 >> 1; _23 = (int) _14; After we get: _43 = .REDUC_PLUS (vect__7.11_47); _37 = _43 & 65535; _12 = _43 >> 16; _13 = _12 + _37; _14 = _13 >> 1; _23 = (int) _14; Which is obviously better really. So there is nothing to be done on the gimple level really. the only thing I can think of is how reducative plus is implemented.
[Bug rtl-optimization/104049] [12 Regression] vec_select to subreg lowering causes superfluous moves
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104049 --- Comment #5 from Andrew Pinski --- The regression showing up is the same as PR 104059, that is r12-5358-g32221357007666124409ec3ee0d3a1cf263ebc9e .
[Bug c++/99571] ICE for NTTP with pointer to a field inside anonymous union/struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99571
Andrew Pinski changed:
What|Removed |Added
URL|https://godbolt.org/z/rsc6f |
|s |
Summary|ICE for NTTP with pointer |ICE for NTTP with pointer
|to array of union |to a field inside anonymous
||union/struct
--- Comment #2 from Andrew Pinski ---
https://godbolt.org/z/rsc6fs
Here is another testcase which shows a similar issue:
struct I{
union { int a{}; };
int *i;
constexpr I():i(){}
};
constexpr I i;
templatestruct C{};
[[maybe_unused]]Cc;
CUT
Note clang has a bogus warning for the above about the anonymous union (I am
not going to file a bug about it though).
[Bug c++/99493] Address of template parameter object is not a valid template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99493 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-01-19 --- Comment #4 from Andrew Pinski --- Confirmed.
[Bug c++/99493] Address of template parameter object is not a valid template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99493 Andrew Pinski changed: What|Removed |Added URL|https://godbolt.org/z/9zYo8 | |f | --- Comment #3 from Andrew Pinski --- https://godbolt.org/z/9zYo8f
[Bug middle-end/103645] Gimplifier does not remove empty struct stores in a few cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103645 --- Comment #3 from Andrew Pinski --- Created attachment 52223 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52223=edit Patch which has been boostraped and tested a few times This patch fix the issue but I don't think it qualifies for stage 4 so waiting until stage 1 to submit it. Placing it here so it does not get lost.
[Bug target/104104] [12 Regression] Assembler messages: Error: number of operands mismatch for `vxorps'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104104 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug target/104104] [12 Regression] Assembler messages: Error: number of operands mismatch for `vxorps'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104104
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ddce00dba244d889d688490517fb106169a72f01
commit r12-6715-gddce00dba244d889d688490517fb106169a72f01
Author: Jakub Jelinek
Date: Wed Jan 19 02:24:06 2022 +0100
i386: Fix GLC tuning with -masm=intel [PR104104]
> > On Sat, Jan 15, 2022 at 5:39 PM Hongyu Wang
wrote:
> > > Thanks for the suggestion, here is the updated patch that survived
> > > bootstrap/regtest.
Unfortunately the patch results in assembler failures with -masm=intel.
> > > > + if (TARGET_DEST_FALSE_DEPENDENCY
> > > > + && get_attr_dest_false_dep (insn) ==
> > > > +DEST_FALSE_DEP_TRUE)
> > > > +output_asm_insn ("vxorps\t{%x0, %x0, %x0}", operands);
All the vxorps insns were emitted like the above, which means for
-masm=sysv
it looks like
vxorps %xmm3, %xmm3, %xmm3
but for -masm=intel like:
vxorps
We want obviously
vxorps xmm3, xmm3, xmm3
so the following patch just drops the errorneous {}s.
2022-01-19 Jakub Jelinek
PR target/104104
* config/i386/sse.md
(__,
avx512fp16_sh_v8hf,
avx512dq_mul3,
_permvar,
avx2_perm_1, avx512f_perm_1,
avx512dq_rangep,
avx512dq_ranges,
_getmant,
avx512f_vgetmant):
Use vxorps\t%x0, %x0, %x0 instead of vxorps\t{%x0, %x0, %x0}.
* gcc.target/i386/pr104104.c: New test.
[Bug middle-end/104076] bogus -Wdangling-pointer on a conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104076
--- Comment #3 from Martin Sebor ---
Looking at the IL before r12-6694 I'm not sure I see what could be done to keep
the warning from triggering but maybe someone has an idea for a solution I'm
not seeing, in case this comes back with a different test case.
struct S2 f2 (bool b)
{
const struct S1 D.2507[1];
...
:
cleanup.1_26 = 0;
cleanup.2_27 = 0;
if (b_28(D) != 0)
goto ; [INV]
else
goto ; [INV]
:
f1 ();
goto ; [INV]
:
_29 = <<<
_30 = _29;
_31 = 0;
cleanup.1_32 = 1;
S1::S1 (_30, 0);
:
_35 = _30 + 1;
_36 = _31 + -1;
retval.0_37 = _29;
_38 = 0;
cleanup.2_39 = 1;
D.2529.array =
D.2529.nelts = 1;
S2::S2 (, D.2529);
:
# _7 = PHI <_29(5), _44(D)(3)><<< _7 == _29(5) == or
undefined
# _9 = PHI <_38(5), _45(D)(3)>
# cleanup.1_13 = PHI
# cleanup.2_15 = PHI
if (cleanup.2_15 != 0)
goto ; [INV]
else
goto ; [INV]
:
_46 = + 1;
:
# _5 = PHI <_46(7), _47(9)>
if ( == _5)
goto ; [INV]
else
goto ; [INV]
:
_47 = _5 + 18446744073709551615;
S1::~S1 (_47);
goto ; [INV]
:
D.2507 ={v} {CLOBBER};<<< D.2507 clobbered
if (cleanup.1_13 != 0)
goto ; [INV]
else
goto ; [INV]
:
if (_7 != 0B)
goto ; [INV]
else
goto ; [INV]
:
_1 = -_9;
_2 = (sizetype) _1;
_50 = _7 + _2;
:
# _11 = PHI <_50(12), _51(14)><<< _11 points to
if (_11 == _7)<<< -Wdangling-pointer
goto ; [INV]
else
goto ; [INV]
:
_51 = _11 + 18446744073709551615; <<< _51
S1::~S1 (_51);
goto ; [INV]
:
return D.2525;
...
}
cc1plus.r12-6693: all warnings being treated as errors
[Bug libstdc++/104101] [12 Regression] libstdc++ shared_ptr_atomic fails on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104101 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jonathan Wakely --- Fixed
[Bug middle-end/104076] bogus -Wdangling-pointer on a conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104076 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:6325041c2b68af096195e0eef92091b2e293e950 commit r12-6714-g6325041c2b68af096195e0eef92091b2e293e950 Author: Martin Sebor Date: Tue Jan 18 17:56:20 2022 -0700 Add test for bogus warning [PR104076]. Related: PR middle-end/104076 - bogus -Wdangling-pointer on a conditional gcc/testsuite/ChangeLog: PR middle-end/104076 * g++.dg/warn/Wdangling-pointer-3.C: New test.
[Bug middle-end/104103] [12 regression] many excess errors from g++.dg/asan/asan_test.C after r12-6606
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104103 --- Comment #4 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:282110ae8b54250c8dcb73afc6f30761a41e38e6 commit r12-6713-g282110ae8b54250c8dcb73afc6f30761a41e38e6 Author: Martin Sebor Date: Tue Jan 18 17:53:20 2022 -0700 Suppress valid warning [PR104103]. gcc/testsuite/ChangeLog: PR middle-end/104103 * gcc.dg/torture/pr57147-2.c: Prune out expected warning.
[Bug middle-end/104069] -Werror=use-after-free false positive on elfutils-0.186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069 --- Comment #12 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:2f714642e574c64e1c0e093cad3de6f8accb6ec7 commit r12-6712-g2f714642e574c64e1c0e093cad3de6f8accb6ec7 Author: Martin Sebor Date: Tue Jan 18 17:52:01 2022 -0700 Handle failure to determine pointer provenance conservatively [PR104069]. Partly resolves: PR middle-end/104069 - -Werror=use-after-free false positive on elfutils-0.186 gcc/ChangeLog: PR middle-end/104069 * gimple-ssa-warn-access.cc (pointers_related_p): Return false for an unknown result as documented. gcc/testsuite/ChangeLog: PR middle-end/104069 * gcc.dg/Wuse-after-free.c: New test.
[Bug libstdc++/104101] [12 Regression] libstdc++ shared_ptr_atomic fails on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104101 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c3861f79859d96777f86a24261fe639538fd2e1c commit r12-6708-gc3861f79859d96777f86a24261fe639538fd2e1c Author: Jonathan Wakely Date: Tue Jan 18 21:15:05 2022 + libstdc++: Fix std::atomic> for AIX [PR104101] This fixes an on AIX. The lock function currently just spins, which should be changed to use back-off, and maybe then _M_val.wait(__current) when supported. libstdc++-v3/ChangeLog: PR libstdc++/104101 * include/bits/shared_ptr_atomic.h (_Sp_atomic::_Atomic_count::lock): Only use __thread_relax if __cpp_lib_atomic_wait is defined.
[Bug testsuite/104109] [12 Regression] ERROR: g++.dg/gcov/gcov-17.C : error executing dg-final: can't read "script": no such variable by r12-6629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104109
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Summary|[12 Regression] ERROR: |[12 Regression] ERROR:
|g++.dg/gcov/gcov-17.C :|g++.dg/gcov/gcov-17.C :
|error executing dg-final: |error executing dg-final:
|can't read "script": no |can't read "script": no
|such variable |such variable by r12-6629
Last reconfirmed||2022-01-19
Ever confirmed|0 |1
--- Comment #1 from H.J. Lu ---
r12-6629 has
@@ -274,11 +276,8 @@ proc run-gcov-pytest { args } {
set testcase [remote_download host $testcase]
set result [remote_exec host $GCOV "$testcase -i"]
-set pytest_cmd "python3 -m pytest --color=no -rap -s --tb=no"
-set result [remote_exec host "$pytest_cmd --version"]
-set status [lindex $result 0]
-if { $status != 0 } then {
- unsupported "$subdir/$testcase run-gcov-pytest python3 pytest missing"
+if { ![check_effective_target_pytest3] } {
+ unsupported "$script pytest python3 is missing"
^^^ Never defined.
return
}
[Bug testsuite/104109] New: [12 Regression] ERROR: g++.dg/gcov/gcov-17.C : error executing dg-final: can't read "script": no such variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104109 Bug ID: 104109 Summary: [12 Regression] ERROR: g++.dg/gcov/gcov-17.C : error executing dg-final: can't read "script": no such variable Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target Milestone: --- On Linux/x86-64, r12-6639 gave ERROR: g++.dg/gcov/gcov-17.C : error executing dg-final: can't read "script": no such variable ERROR: g++.dg/gcov/pr98273.C : error executing dg-final: can't read "script": no such variable
[Bug middle-end/104069] -Werror=use-after-free false positive on elfutils-0.186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069 --- Comment #11 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #10) > It is not, because it emits a false positive on a fairly common code. > Anyway, if bb3 jumps to bb4, then bb3 should have in the ranger assertion > that in bb3 ret_17 is 0 (it is on the true branch of the ret_17 == 0 && > something test), > so for the PHI, while it is or, it is either 2->4 is the executable edge and > then ret_7 == 0 implies ret_17 == 0, or 3->4 is the executable edge and then > ret_17 == 0 too because that was what was the assertion in bb 3. But > arguably it isn't a very common case for PHIs. So, either the ranger can > have special case for something like that, or the warning code can. I dont follow what you guys are looking at. so I looked in EVRP and i see: ret_17 = realloc (ptr_14(D), size_15(D)); _1 = ret_17 == 0B; _2 = size_15(D) == 0; _3 = _1 & _2; if (_3 != 0) goto ; [INV] else goto ; [INV] 2->3 (T) ret_17 : void * [0B, 0B] === BB 3 _2 _Bool [1, 1] size_15(D) size_t [0, 0] : ret_19 = realloc (ptr_14(D), 1); === BB 4 Imports: ret_7 Exports: ret_7 _2 _Bool VARYING size_15(D) long unsigned int VARYING : # ret_7 = PHI if (ret_7 == 0B) goto ; [INV] So you are saying that ret_17 is 0 if we go 2->3, then 3->4 and set ret_7 to ret_19. And looking backwards, if ret_7 == 0, then ret_7 is zero which implies that ret_17 was zero on the path 2->4 if we came that way and therefore, if we take the branch 4->5, that ret_17 is 0 ? Thats not happening any time soon. Theres way to much conditional context. Basic data flow says we track ret_17 as [0,0] on 2->3 and VARYING on 2->4 BB4 is also a merge point since 3->4, so the means, based on data flow, that ret_17 is now VARYING again. THe diamond has ended, contextual range information is gone. First, PHI arguments are not exports from a block, their aggregator the PHI def is... and there it ends. the computational complexities of generically doing arguments are exponential, esepcially since we know nothing about the edge taken. You need to see some of the crazy PHIs out there. What you are suggesting here is that because the PHI which uses ret_17 on one path must be zero (or whatever range) , and it happens to be zero on the other path, we must therefore know conclusively that it is also zero. My guess is this would be fairly uncommon. Its possible down the road that we can use the gori unwinding to analyze ranges which end a PHI. Winding back from if (ret_7 == 0B) we get [0,0] = PHI that we can teach gori or some other unit about PHIS (we do not understand them yet since GORI is purely a basic block concept) to make queries about ret_17 on each edge.. even 3->4 for no apparent reason, except that we asked about ret_17. Union them all together and see what happens. I'll keep it in mind, but that is not a high priority. You can forget about it for this release tho :-) Besides, the information ranger is providing shouldn't be any different than what we got before... ranger doesn't know anything, neither did previous versions. This isnt a "loss of information" or even a "too good of information" situation. Its basically the same as before is it not?
[Bug c++/104094] Alias template shown in diagnostic with wrong template parameter name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104094 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-01-19 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug middle-end/104103] [12 regression] many excess errors from g++.dg/asan/asan_test.C after r12-6606
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104103 --- Comment #3 from Martin Sebor --- (In reply to seurer from comment #2) The warning for gcc/testsuite/gcc.dg/torture/pr57147-2.c looks correct. The g_return_jmp_buf variable has zero size but it's being passed to a function declared to take an array of one element. Let me suppress it in the test.
[Bug c++/104108] [10/11/12 Regression] [c++17+] template alias inside template with static field of template class rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104108 Andrew Pinski changed: What|Removed |Added Summary|[10/11/12 Regression] |[10/11/12 Regression] |template alias inside |[c++17+] template alias |template with static field |inside template with static |of template class rejected |field of template class ||rejected --- Comment #2 from Andrew Pinski --- Ok, this is only rejected for -std=c++17 and -std=c++20 :).
[Bug c++/96605] ICE in tsubst, at cp/pt.c:14929 on C++20 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96605
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-invalid-code
--- Comment #2 from Andrew Pinski ---
I think this was fixed in GCC 11.1.0:
I get:
:7:11: error: 'Expression_Term' does not constrain a type
7 | template struct dictionary {};
| ^~~
And I think the code is invalid too.
If I change the first two concepts to:
template concept Expression_Term = true;
template concept Array_Term = true;
We accept the code as expected.
[Bug c++/104107] [9/10/11/12 Regression] parsing crashes on class template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104107 --- Comment #2 from Andrew Pinski --- Also note I found a related regression where GCC decides the static field is not a declaration/variable and rejects the code, PR 104108 .
[Bug c++/104107] [9/10/11/12 Regression] parsing crashes on class template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104107
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2022-01-19
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Confirmed, reduced testcase:
template typename tt_w_data>
struct tt_main {
static t_parameter m_parameter;
template typename t_data> using t_make
= t_data;
using t_data = t_make;
};
template struct P {};
tt_main<0, int, P> a;
CUT
I don't know why if I remove the unused template argument targ_id, it works.
[Bug c++/104108] [10/11/12 Regression] template alias inside template with static field of template class rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104108 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.4 --- Comment #1 from Andrew Pinski --- Note the problem here is definitely different from PR 104107 as that one ICEs with GCC 9 while this one starts to be rejected in GCC 10.
[Bug c++/104108] New: [10/11/12 Regression] template alias inside template with static field of template class rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104108
Bug ID: 104108
Summary: [10/11/12 Regression] template alias inside template
with static field of template class rejected
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Take which I accidently reduced from PR 104107:
template typename tt_w_data>
struct tt_main {
static int m_parameter;
template typename t_data> using t_make
= t_data;
};
This should be valid code but currently we reject it with:
:5:25: error: '& tt_main::m_parameter' is not a valid
template argument of type 'const int&' because
'tt_main::m_parameter' is not a variable
5 | = t_data;
| ^
I don't see how tt_main::m_parameter is not a variable because it
looks like one to me.
[Bug ada/103538] [12 Regression] trunk 20211203 fails to build gnat on x86_64-linux-gnux32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103538 H.J. Lu changed: What|Removed |Added Status|WAITING |NEW
[Bug ada/103538] [12 Regression] trunk 20211203 fails to build gnat on x86_64-linux-gnux32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103538 --- Comment #4 from H.J. Lu --- Created attachment 5 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=5=edit A patch Try this.
[Bug c++/104107] [9/10/11/12 Regression] parsing crashes on class template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104107 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Known to fail||9.1.0 Known to work||8.1.0, 8.5.0 Summary|parsing crashes on class|[9/10/11/12 Regression] |template instantiation |parsing crashes on class ||template instantiation Target Milestone|--- |9.5
[Bug c++/104107] New: parsing crashes on class template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104107
Bug ID: 104107
Summary: parsing crashes on class template instantiation
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gzoumix at hotmail dot com
Target Milestone: ---
The following code makes the g++ parser crash on all versions of gcc on
wandbox.org, in C++17 and up. I also have the issue on my ubuntu 21.10 with gcc
11.2.0.
g++ --version:
g++ (Ubuntu 11.2.0-7ubuntu2) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
code:
template
typename tt_w_data>
struct tt_main {
static t_parameter m_parameter;
template typename t_data> using t_make =
t_data;
using t_data = t_make;
};
template
typename tt_w_data>
t_parameter tt_main::m_parameter;
template struct P {};
struct t_parameter {};
using toto = tt_main<0, t_parameter, P>;
int main() {
toto t;
return 0;
}
command line: g++ -v -save-temps -Wall -Wextra -std=c++17 prog.cc
error message:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 11.2.0-7ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-11-ZPT0kp/gcc-11-11.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-11-ZPT0kp/gcc-11-11.2.0/debian/tmp-gcn/usr
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (Ubuntu 11.2.0-7ubuntu2)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c++17'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
/usr/lib/gcc/x86_64-linux-gnu/11/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE prog.cc -mtune=generic -march=x86-64 -std=c++17
-Wall -Wextra -fpch-preprocess -fasynchronous-unwind-tables
-fstack-protector-strong -Wformat-security -fstack-clash-protection
-fcf-protection -o a-prog.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/11"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/11/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/11
/usr/include/x86_64-linux-gnu/c++/11
/usr/include/c++/11/backward
/usr/lib/gcc/x86_64-linux-gnu/11/include
/usr/local/include
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c++17'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
/usr/lib/gcc/x86_64-linux-gnu/11/cc1plus -fpreprocessed a-prog.ii -quiet
-dumpdir a- -dumpbase prog.cc -dumpbase-ext .cc -mtune=generic -march=x86-64
-Wall -Wextra -std=c++17 -version -fasynchronous-unwind-tables
-fstack-protector-strong -Wformat-security -fstack-clash-protection
-fcf-protection -o a-prog.s
GNU C++17 (Ubuntu 11.2.0-7ubuntu2) version 11.2.0 (x86_64-linux-gnu)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.0, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (Ubuntu 11.2.0-7ubuntu2) version 11.2.0 (x86_64-linux-gnu)
compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.0, isl version isl-0.24-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: b2aa013a9bb78f98e29ce58cd37c6337
prog.cc: In instantiation of ‘struct
[Bug c++/104055] Temporary with consteval constructor does not cause the deconstructor to be called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104055
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:1a5145f1e3adf8b2ba4ad416a5ddef59a1e34d48
commit r12-6705-g1a5145f1e3adf8b2ba4ad416a5ddef59a1e34d48
Author: Jakub Jelinek
Date: Wed Jan 19 00:42:18 2022 +0100
c++: Fix handling of temporaries with consteval ctors and non-trivial dtors
[PR104055]
The following testcase is miscompiled. We see the constructor is
immediate,
in build_over_call we trigger:
if (obj_arg && is_dummy_object (obj_arg))
{
call = build_cplus_new (DECL_CONTEXT (fndecl), call,
complain);
obj_arg = NULL_TREE;
}
which makes call a TARGET_EXPR with the dtor in TARGET_EXPR_CLEANUP,
but then call cxx_constant_value on it. In
cxx_eval_outermost_constant_expr
it triggers the:
else if (TREE_CODE (t) != CONSTRUCTOR)
{
r = get_target_expr_sfinae (r, tf_warning_or_error |
tf_no_cleanup);
TREE_CONSTANT (r) = true;
}
which wraps the CONSTRUCTOR r into a new TARGET_EXPR, but one without
dtors (I think we need e.g. the TREE_CONSTANT for the callers),
and finally build_over_call uses that.
The following patch fixes that by using get_target_expr instead
of get_target_expr_sfinae + TREE_CONSTANT (r) = true if t is
a TARGET_EXPR with non-NULL TARGET_EXPR_CLEANUP.
2022-01-19 Jakub Jelinek
PR c++/104055
* constexpr.cc (cxx_eval_outermost_constant_expr): If t is a
TARGET_EXPR with TARGET_EXPR_CLEANUP, use get_target_expr rather
than get_target_expr_sfinae with tf_no_cleanup, and don't set
TREE_CONSTANT.
* g++.dg/cpp2a/consteval27.C: New test.
[Bug c++/104105] Unused nothrow new not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104105 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/102300] [10/11/12 Regression] Qualified name of same template in class template is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102300 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/100198] [12 Regression] ICE with enum in lambda in pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100198 --- Comment #4 from Jason Merrill --- Nested classes/enums like this are broken in pack expansions if they depend on parameter packs. The patch for PR100109 changed this from rejects-valid to ice-on-valid, but it isn't something newly broken. I suppose I could change it back to rejects-valid by reverting the PR100109 patch, but that's just trading one ICE for another. This functionality isn't going to be implemented for GCC 12.
[Bug ada/103538] [12 Regression] trunk 20211203 fails to build gnat on x86_64-linux-gnux32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103538 --- Comment #3 from H.J. Lu --- gcc-interface/Makefile.in has ifeq ($(strip $(filter-out x86_64, $(target_cpu))),) ifeq ($(strip $(MULTISUBDIR)),/32) target_cpu:=i686 else ifeq ($(strip $(MULTISUBDIR)),/x32) target_cpu:=x32 endif endif endif It doesn't set the right target_cpu when -mx32 is the default with x86_64-linux-gnux32.
[Bug middle-end/104076] bogus -Wdangling-pointer on a conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104076 --- Comment #1 from Martin Sebor --- This instance of the warning has disappeared with r12-6694.
[Bug sanitizer/101476] AddressSanitizer check failed, points out a (potentially) non-existing stack error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476 --- Comment #7 from Stas Sergeev --- Created attachment 52221 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52221=edit test case This is a reproducer for both problems. $ cc -Wall -o bug -ggdb3 -fsanitize=address bug.c -O1 to see the canary overwrite problem. $ cc -Wall -o bug -ggdb3 -fsanitize=address bug.c -O0 to see the poisoned stack after pthread_cancel() problem.
[Bug c++/104025] [12 Regression] '-fcompare-debug' failure with enabled warnings since r12-6563-gb8ffa71e4271ae56
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104025 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jason Merrill --- (In reply to Jakub Jelinek from comment #7) > Maybe. But how? Would it push a pair of next_token, input_location ? > I think it isn't easy to recompute input_location after the rollback > otherwise. > And, I'm a little bit worried that such a change could be at this point > quite dangerous, while the above patch affects one spot that has changed, we > have lots of rollbacks in various places. Fair; doing it in saved_token_sentinel seemed like a reasonable compromise.
[Bug c++/104025] [12 Regression] '-fcompare-debug' failure with enabled warnings since r12-6563-gb8ffa71e4271ae56
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104025 --- Comment #8 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2aa184458a11a7ec8c1b451b8eeff458a24632bb commit r12-6703-g2aa184458a11a7ec8c1b451b8eeff458a24632bb Author: Jason Merrill Date: Mon Jan 17 17:16:38 2022 -0500 c++: input_location and lookahead [PR104025] Debug information was getting confused because input_location was different depending on whether we had looked ahead to see if the next tokens look like a template argument list. I tried resetting input_location in cp_lexer_rollback_tokens itself, but that caused regressions, so let's just do it here for now. PR c++/104025 gcc/cp/ChangeLog: * parser.cc (saved_token_sentinel::rollback): Call cp_lexer_set_source_position. (~saved_token_sentinel): Call rollback. gcc/testsuite/ChangeLog: * g++.dg/warn/pr104025.C: New test. Co-authored-by: Jakub Jelinek
[Bug middle-end/104069] -Werror=use-after-free false positive on elfutils-0.186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #10 from Jakub Jelinek --- It is not, because it emits a false positive on a fairly common code. Anyway, if bb3 jumps to bb4, then bb3 should have in the ranger assertion that in bb3 ret_17 is 0 (it is on the true branch of the ret_17 == 0 && something test), so for the PHI, while it is or, it is either 2->4 is the executable edge and then ret_7 == 0 implies ret_17 == 0, or 3->4 is the executable edge and then ret_17 == 0 too because that was what was the assertion in bb 3. But arguably it isn't a very common case for PHIs. So, either the ranger can have special case for something like that, or the warning code can.
[Bug middle-end/104103] [12 regression] many excess errors from g++.dg/asan/asan_test.C after r12-6606
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104103 --- Comment #2 from seurer at gcc dot gnu.org --- Also, g:9d6a0f388eb048f8d87f47af78f07b5ce513bfe6, r12-6606 make -k check-gcc RUNTESTFLAGS="dg-torture.exp=gcc.dg/torture/pr57147-2.c" FAIL: gcc.dg/torture/pr57147-2.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) # of expected passes9 # of unexpected failures1 # of unsupported tests 2 Excess errors: /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/torture/pr57147-2.c:20:3: warning: '_setjmp' accessing 1 byte in a region of size 0 [-Wstringop-overflow=] wd
[Bug c++/98645] [modules] does not work on PowerPC with IEEE 128-bit long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98645 --- Comment #4 from Jakub Jelinek --- PR104052 has maybe more detailed analysis.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 104052, which changed state. Bug 104052 Summary: Modules ICE on powerpc64le-linux with -mabi=ieeelongdouble https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104052 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/98645] [modules] does not work on PowerPC with IEEE 128-bit long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98645 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- *** Bug 104052 has been marked as a duplicate of this bug. ***
[Bug c++/104052] Modules ICE on powerpc64le-linux with -mabi=ieeelongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104052 Jakub Jelinek changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #6 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 98645 ***
[Bug middle-end/104069] -Werror=use-after-free false positive on elfutils-0.186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069 --- Comment #9 from Martin Sebor --- My mistake, a PHI is an OR of its operands, not an AND. With that, the IL doesn't rule out that the subsequent realloc() call isn't made with the argument to a prior successful realloc(). So for the more involved test case in comment #5 the warning is doing what it's supposed to do.
[Bug c++/98645] [modules] does not work on PowerPC with IEEE 128-bit long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98645 --- Comment #2 from Peter Bergner --- Mike, what is the status of this bug? Is this still broken?
[Bug fortran/104100] Passing an allocated array to a C bind function alters the bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104100 --- Comment #3 from Steve Kargl --- On Tue, Jan 18, 2022 at 10:15:25PM +, hzhou321 at anl dot gov wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104100 > > --- Comment #2 from Hui Zhou --- > Great! That means it has already been fixed in the coming 12 series, right? I > was initially a bit confused with your WONTFIX comment. > Yes, it is fixed in the mainline of development, which is expected to be branched for 12.1 in a few days/week. The changes are fairly extensive. I don't know if there are plans to backport to 11-branch.
[Bug tree-optimization/104106] Fail to remove stores to VLA inside loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104106 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Summary|Fail to remove some useless |Fail to remove stores to |loop|VLA inside loops Last reconfirmed||2022-01-18 --- Comment #1 from Andrew Pinski --- If we change the VLA to a normal array, GCC is able to optimize f and g. h is almost done: [local count: 118111600]: if (n_8(D) > 0) goto ; [89.00%] else goto ; [11.00%] [local count: 105119324]: _18 = (unsigned int) n_8(D); _6 = (sizetype) _18; __builtin_memcpy (_a, a_11(D), _6); [local count: 118111600]: _4 = tmp_a[0]; GCC could do a PRE for the load of tmp_a[0] to a_11[0] and unspecified. This is true even with the VLA. As for i, that requires loop fision which GCC does not implement yet (there is another bug about that even).
[Bug tree-optimization/104106] Fail to remove some useless loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104106 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization
[Bug tree-optimization/104106] New: Fail to remove some useless loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104106
Bug ID: 104106
Summary: Fail to remove some useless loop
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
In the following snippet none of the loops are removed when compiled with -O2
or -O3.
In f and g the optimizers shoulds detect that tmp_a is only written and never
read.
In h, only one index of tmp_a is read, so it should be the only one computed.
Ideally, if not too complex for gcc, the first two loops should be removed and
the computations, if any, done on the last loop.
-
int f(char *a, unsigned n) {
char tmp_a[n];
for (unsigned i = 1; i != n; i++) tmp_a[i] = a[i];
return a[0];
}
int g(char *a, int n) {
char tmp_a[n];
for (int i = 1; i < n; i++) tmp_a[i] = a[i] - a[i - 1];
return a[0];
}
int h(char *a, int n) {
char tmp_a[n];
for (int i = 0; i < n; i++) tmp_a[i] = a[i];
return tmp_a[1];
}
int i(char *a, char *b, int n) {
char tmp_a[n];
char tmp_b[n];
for (int i = 1; i < n; i++) tmp_a[i] = a[i] - a[i - 1];
for (int i = 1; i < n; i++) tmp_b[i] = b[i] - b[i - 1];
int result = 0;
for (int i = 1; i < n; i++) result += tmp_a[i] + tmp_b[i];
return result;
}
-
[Bug sanitizer/101476] AddressSanitizer check failed, points out a (potentially) non-existing stack error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101476 --- Comment #6 from Stas Sergeev --- I think the fix (of at least 1 problem here) would be to move this line: https://code.woboq.org/gcc/libsanitizer/asan/asan_thread.cc.html#109 upwards, before this: https://code.woboq.org/gcc/libsanitizer/asan/asan_thread.cc.html#103 It will then unpoison stack before playing its sigaltstack games. But I don't know how to test that idea.
[Bug middle-end/104069] -Werror=use-after-free false positive on elfutils-0.186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069 --- Comment #8 from Jakub Jelinek --- ret_7 == 0 certainly doesn't imply ret_17 == 0, so it is correct ranger doesn't know. ret_7 == 0 implies that either ret_17 == 0 if bb 2 jumped to bb 4, in that case ret_19 isn't even defined, or ret_19 is 0 if bb 3 fell through to bb 4, in that case ret_7 is defined, but could be 0 or could be any other value. So it isn't a bug on the ranger side, but on the warning side.
[Bug fortran/104100] Passing an allocated array to a C bind function alters the bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104100 --- Comment #2 from Hui Zhou --- Great! That means it has already been fixed in the coming 12 series, right? I was initially a bit confused with your WONTFIX comment.
[Bug middle-end/104069] -Werror=use-after-free false positive on elfutils-0.186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069 Martin Sebor changed: What|Removed |Added Component|tree-optimization |middle-end --- Comment #7 from Martin Sebor --- The debug_ranger() output is below for reference: === BB 2 Imports: ret_13 Exports: ret_13 size_9(D) int VARYING : _1 = (long unsigned int) size_9(D); ret_13 = __builtin_realloc (ptr_11(D), _1); if (ret_13 == 0B) goto ; [INV] else goto ; [INV] _1 : long unsigned int [0, 2147483647][18446744071562067968, +INF] 2->3 (T) ret_13 : void * [0B, 0B] 2->5 (F) ret_13 : void * [1B, +INF] === BB 3 Imports: size_9(D) Exports: size_9(D) size_9(D) int VARYING ret_13 void * [0B, 0B] : if (size_9(D) == 0) goto ; [INV] else goto ; [INV] 3->4 (T) size_9(D) : int [0, 0] 3->5 (F) size_9(D) : int [-INF, -1][1, +INF] === BB 4 : ret_15 = __builtin_realloc (ptr_11(D), 1); === BB 5 Imports: ret_3 Exports: ret_3 : # ret_3 = PHI if (ret_3 == 0B) goto ; [INV] else goto ; [INV] 5->6 (T) ret_3 : void * [0B, 0B] 5->11 (F) ret_3 : void * [1B, +INF] === BB 6 Imports: ret_17 Exports: ret_17 size_9(D) int VARYING : _2 = (long unsigned int) size_9(D); ret_17 = __builtin_realloc (ptr_11(D), _2); if (ret_17 == 0B) goto ; [INV] else goto ; [INV] _2 : long unsigned int [0, 2147483647][18446744071562067968, +INF] 6->7 (T) ret_17 : void * [0B, 0B] 6->9 (F) ret_17 : void * [1B, +INF] === BB 7 Imports: size_9(D) Exports: size_9(D) size_9(D) int VARYING ret_17 void * [0B, 0B] : if (size_9(D) == 0) goto ; [INV] else goto ; [INV] 7->8 (T) size_9(D) : int [0, 0] 7->9 (F) size_9(D) : int [-INF, -1][1, +INF] === BB 8 : ret_19 = __builtin_realloc (ptr_11(D), 1); === BB 9 Imports: ret_4 Exports: ret_4 : # ret_4 = PHI if (ret_4 == 0B) goto ; [INV] else goto ; [INV] 9->10 (T) ret_4 : void * [0B, 0B] 9->11 (F) ret_4 : void * [1B, +INF] === BB 10 : __builtin_abort (); === BB 11 Equivalence set : [] Equivalence set : [ret_5, _21] : # ret_5 = PHI _21 = ret_5; ret_5 : void * [1B, +INF] _21 : void * [1B, +INF] === BB 12 : : return _21; Non-varying global ranges: =: _1 : long unsigned int [0, 2147483647][18446744071562067968, +INF] _2 : long unsigned int [0, 2147483647][18446744071562067968, +INF] ret_5 : void * [1B, +INF] _21 : void * [1B, +INF]
[Bug tree-optimization/104069] -Werror=use-after-free false positive on elfutils-0.186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
Martin Sebor changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment #6 from Martin Sebor ---
Thanks. The new test case can be reduced to this:
void *xrealloc (void *ptr, int size)
{
void *ret = __builtin_realloc (ptr, size);
if (!ret && !size)
ret = __builtin_realloc (ptr, 1);
if (!ret) {
ret = __builtin_realloc (ptr, size); <<< -Wuse-after-free
if (!ret && !size)
ret = __builtin_realloc(ptr, 1); <<< -Wuse-after-free
if (!ret)
__builtin_abort ();
}
return ret;
}
I don't see a bug in the warning code but let me CC Andrew for his comments on
the Ranger behavior.
The warnings are false positives but I'm afraid I don't see a bug in the
implementation. Both trigger (at level 2) because the code is unable to rule
out that the successfully reallocated pointer isn't used in a subsequent call
to realloc(). In the unptimized IL the annotated flow for the first warning is
below. It shows that the realloc(ptr) statement in bb 8 isn't reachable with a
nonnull ret_13 (i.e., after a successful call to realloc(ptr) in bb 2) but the
range query for the value of ret_13 in bb 8 returns an unknown (i.e., either
null or nonnull).
Andrew, this is determined by the following test art
gimple-ssa-warn-access.cc:4152:
if (m_ptr_qry.rvals->range_of_expr (vr, realloc_lhs, use_stmt))
realloc_lhs is ret_13 and use_stmt is ret_19 = __builtin_realloc (ptr_11(D),
1). debug_ranger() shows that bb 5 exports ret_3 == 0 but not ret_13 (which is
implied by the ret_3 equality to zero). Is this a limitation I need to be
prepared for?
void * xrealloc (void * ptr, int size)
{
void * ret;
void * D.1996;
long unsigned int _1;
long unsigned int _2;
void * _21;
:
_1 = (long unsigned int) size_9(D);
ret_13 = __builtin_realloc (ptr_11(D), _1);
if (ret_13 == 0B)
goto ; [INV] >>> ret_13 == 0
else
goto ; [INV] >>> ret_13 != 0
:
if (size_9(D) == 0)
goto ; [INV]
else
goto ; [INV]
:
ret_15 = __builtin_realloc (ptr_11(D), 1);<<< ret_13 == 0
:
# ret_3 = PHI
if (ret_3 == 0B)
goto ; [INV] >>> ret_13 == 0 && ret_3 == 0
else
goto ; [INV]
:
_2 = (long unsigned int) size_9(D);
ret_17 = __builtin_realloc (ptr_11(D), _2);
if (ret_17 == 0B)
goto ; [INV] >>> ret_13 == 0 && ret_3 == 0
&& ret_17 == 0
else
goto ; [INV]
:
if (size_9(D) == 0)
goto ; [INV] >>> ret_13 == 0 && ret_3 == 0
&& ret_17 == 0 && size_9 == 0
else
goto ; [INV]
: <<< ret_13 need not be 0 here
ret_19 = __builtin_realloc (ptr_11(D), 1);<<< -Wuse-after-free
:
# ret_4 = PHI
if (ret_4 == 0B)
goto ; [INV]
else
goto ; [INV]
:
__builtin_abort ();
:
# ret_5 = PHI
_21 = ret_5;
:
:
return _21;
}
In the optimized IL (at -O2 below), it looks like the same issue. Again, the
IL makes it clear that the call to realloc(ptr) in bb 5 where the warning
triggers isn't reachable after a successful prior realloc(),
void * xrealloc (void * ptr, int size)
{
void * ret;
long unsigned int _1;
_Bool _2;
_Bool _3;
_Bool _4;
_Bool _5;
_Bool _6;
[local count: 1073741824]:
_1 = (long unsigned int) size_13(D);
ret_17 = __builtin_realloc (ptr_15(D), _1);
_2 = ret_17 == 0B;
_3 = size_13(D) == 0;
_4 = _2 & _3;
if (_4 != 0)
goto ; [33.00%] >>> ret_17 == 0
else
goto ; [67.00%] >>> ret_17 need not be 0
[local count: 354334800]:
ret_19 = __builtin_realloc (ptr_15(D), 1);
[local count: 1073741824]:
# ret_7 = PHI
if (ret_7 == 0B)
goto ; [0.04%]>>> ret_7 == 0 implies ret_17
== 0
else
goto ; [99.96%]
[local count: 429496]: <<< ret_17 == 0 but query
returns unknown
ret_21 = __builtin_realloc (ptr_15(D), _1); <<< -Wuse-after-free
[Bug lto/98504] [11/12 Regression] bootstrap broken in libgo on ia64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98504 --- Comment #13 from John Paul Adrian Glaubitz --- (In reply to Ian Lance Taylor from comment #12) > But, of course, you shouldn't have to. A "make install" should put fmt.gox > in the right place by default. I don't know why you are seeing a problem > there. I gave it a try again. Compiling works, but the program crashes: glaubitz@yttrium:~$ gccgo hello.go -o hello glaubitz@yttrium:~$ ./hello Aborted glaubitz@yttrium:~$
[Bug fortran/104100] Passing an allocated array to a C bind function alters the bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104100 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org Known to work||12.0 --- Comment #1 from kargl at gcc dot gnu.org --- Works with 12.0 % ~/work/bin/gcc -c -O aa.c % gfcx -o z a.f90 -O aa.o % ./z 1 2 3 4 5 Before 1 5 1 2 3 4 5 After: 1 5 Thanks for the bug report, but it should likely be closed with WONTFIX due to the complexity of the changes to ISO_Fortran_binding.h and CFI support. I'll let active gfortran contributors make that decision.
[Bug ada/103538] [12 Regression] trunk 20211203 fails to build gnat on x86_64-linux-gnux32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103538 --- Comment #2 from H.J. Lu --- Created attachment 52220 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52220=edit A patch to update x32 suport
[Bug lto/98504] [11/12 Regression] bootstrap broken in libgo on ia64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98504 --- Comment #12 from Ian Lance Taylor --- You can pass the -I option to tell the compiler where to find the fmt.gox file. But, of course, you shouldn't have to. A "make install" should put fmt.gox in the right place by default. I don't know why you are seeing a problem there.
[Bug c++/104105] New: Unused nothrow new not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104105
Bug ID: 104105
Summary: Unused nothrow new not optimized
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: denis.campredon at gmail dot com
Target Milestone: ---
g++ can remove new calls when the result is unused, but fails to di the same
with nothrow new calls. f() could be compiled to an empty function with
optimisations on.
void f() {
new (std::nothrow) int(5);
new (std::nothrow) int[5];
}
[Bug analyzer/104089] ICE in constant_svalue, at analyzer/svalue.h:271
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104089 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from David Malcolm --- Thanks for filing this bug. It should be fixed by the above commit.
[Bug analyzer/104062] [12 Regression] ICE in get_or_create_cast, at analyzer/region-model-manager.cc:482 since r12-6476-g4f34f8cc1d064bfa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104062 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/104089] ICE in constant_svalue, at analyzer/svalue.h:271
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104089 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:2aefe248aa4160205c44808166393a42031d2dea commit r12-6700-g2aefe248aa4160205c44808166393a42031d2dea Author: David Malcolm Date: Tue Jan 18 11:41:19 2022 -0500 analyzer: fix ICE on unary ops folding to casts of constants [PR104089] gcc/analyzer/ChangeLog: PR analyzer/104089 * region-model-manager.cc (region_model_manager::get_or_create_constant_svalue): Assert that we have a CONSTANT_CLASS_P. (region_model_manager::maybe_fold_unaryop): Only fold a constant when fold_unary's result is a constant or a cast of a constant. gcc/testsuite/ChangeLog: * gcc.dg/analyzer/pr104089.c: New test. PR analyzer/104089 Signed-off-by: David Malcolm
[Bug analyzer/104062] [12 Regression] ICE in get_or_create_cast, at analyzer/region-model-manager.cc:482 since r12-6476-g4f34f8cc1d064bfa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104062 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:79e746bb05e432dcd1c18161469272d67c33d79d commit r12-6699-g79e746bb05e432dcd1c18161469272d67c33d79d Author: David Malcolm Date: Tue Jan 18 10:03:53 2022 -0500 analyzer: fix ICE on realloc of zeroed memory [PR104062] gcc/analyzer/ChangeLog: PR analyzer/104062 * region-model-manager.cc (region_model_manager::maybe_fold_sub_svalue): Avoid casting to NULL type when folding access to repeated svalue. gcc/testsuite/ChangeLog: PR analyzer/104062 * gcc.dg/analyzer/pr104062.c: New test. Signed-off-by: David Malcolm
[Bug fortran/103475] ICE in gfc_expr_attr, at fortran/primary.c:2782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103475 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #2 from anlauf at gcc dot gnu.org --- While the patch in comment#1 looks correct, I don't see the ICE for r12-6697. Running under gdb shows why: we seem to no longer get here.
[Bug libstdc++/104099] [12 Regression] basic_string(nullptr) constructor should not be present before C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104099 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Jonathan Wakely --- Fixed
[Bug libstdc++/104099] [12 Regression] basic_string(nullptr) constructor should not be present before C++23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104099 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:fe3ed885cda5ab920d361b694ee539242052022f commit r12-6698-gfe3ed885cda5ab920d361b694ee539242052022f Author: Jonathan Wakely Date: Tue Jan 18 16:26:45 2022 + libstdc++: Limit new basic_string(nullptr_t) constructor to C++23 [PR104099] The new deleted constructors added by P2166R1 are a breaking change, making previously valid code ill-formed in C++23. As a result, they should only be defined for C++23 and not for C++11 and up. libstdc++-v3/ChangeLog: PR libstdc++/104099 * include/bits/basic_string.h (basic_string(nullptr_t)): Only define for C++23. (operator=(nullptr_t)): Likewise. * include/bits/cow_string.h: Likewise. * include/std/string_view (basic_string_view(nullptr_t)): Likewise. * testsuite/21_strings/basic_string/cons/char/nullptr.cc: Adjust expected error. Add examples that become ill-formed in C++23. * testsuite/21_strings/basic_string_view/cons/char/nonnull.cc: Adjust expected errors. * testsuite/21_strings/basic_string_view/cons/wchar_t/nonnull.cc: Likewise.
