[Bug c/108982] While recompiling when even we modify any line in got its giving error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982 vinay kumar changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #5 from vinay kumar --- Hi Richard Biener, We already contacted Oracle, but they are not suggesting anything for this GCC as it is freeware.
[Bug tree-optimization/108979] [13 Regression] ICE in compute_live_loop_exits, at tree-ssa-loop-manip.cc:248
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108979 Richard Biener changed: What|Removed |Added Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org CC||rsandifo at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #2 from Richard Biener --- Error: definition in block 4 does not dominate use in block 6 for SSA_NAME: loop_mask_16 in statement: vect__33.10_19 = .COND_MUL (loop_mask_16, _1, _4, _1); that stmt ended up in the preheader. That happens when scheduling t.f90:4:26: note: node 0x3c6a870 (max_nunits=4, refcnt=1) vector([4,4]) real(kind=4) t.f90:4:26: note: op template: _33 = tmp_17(D) * p_bd_18(D); t.f90:4:26: note: stmt 0 _33 = tmp_17(D) * p_bd_18(D); t.f90:4:26: note: stmt 1 _33 = tmp_17(D) * p_bd_18(D); t.f90:4:26: note: children 0x3c6a900 0x3c6a990 because as can be seen, the operands are all loop invariant and we are appearantly not honoring the implicit dependence on a mask (those are not added as implicit operand to the SLP graph - something we eventually would want to do). Now - it's also completely unnecessary to mask this statement, and _that's_ possibly the easier way out here. Instead of -fnon-call-exceptions one can also use -fno-tree-loop-im to keep the invariant computation inside the loop and trigger the same ICE. Richard - you are more familiar with loop masking - where do we decide whether a stmt needs masking and couldn't we easily decide it doesn't need if all operand dt are external or invariant?
[Bug target/108910] [12/13 Regression] Further ICE in aarch64_layout_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9b4f7004a77b10bc403875f56c94f73ef86562d8
commit r13-6385-g9b4f7004a77b10bc403875f56c94f73ef86562d8
Author: Jakub Jelinek
Date: Wed Mar 1 09:54:52 2023 +0100
lto: Fix up lto_fixup_prevailing_type [PR108910]
Without LTO, TYPE_POINTER_TO/TYPE_REFERENCE_TO chains are only maintained
inside of build_{pointer,reference}_type_for_mode and those routines
ensure that the pointer/reference type added to the chain is really
without any user attributes (unless something would modify the types
in place, but that would be wrong).
Now, LTO adds stuff to these chains in lto_fixup_prevailing_type but
doesn't guarantee that. The testcase in the PR (which I'm not including
for testsuite because when (I hope) the aarch64 backend bug will be fixed,
the testcase would work either way) shows a case where user has
TYPE_USER_ALIGN type with very high alignment, as there aren't enough
pointers to float in the code left that one becomes the prevailing one
(because types with attributes are created with build_distinct_type_copy
and thus their own TYPE_MAIN_VARIANTs), lto_fixup_prevailing_type puts
it into the TYPE_POINTER_TO chain of float and later on during expansion
of __builtin_cexpif expander uses build_pointer_type (float_type_node)
to emit a sincosf call and instead of getting a normal pointer type gets
this non-standard one.
The following patch fixes that by not adding into those chains
types with TYPE_ATTRIBUTES, and for REFERENCE_TYPEs not even with
TYPE_REF_IS_RVALUE - while the C++ FE adds those into those chains,
it always ensures such a type goes immediately after the corresponding
non-TYPE_REF_IS_RVALUE REFERENCE_TYPE with the same
mode/TYPE_REF_CAN_ALIAS_ALL, so LTO would need to ensure that too, but
TYPE_REF_IS_RVALUE types are looked that way only in the C++ FE.
2023-03-01 Jakub Jelinek
PR target/108910
* lto-common.cc (lto_fixup_prevailing_type): Don't add t to
TYPE_POINTER_TO or TYPE_REFERENCE_TO chain if it has
TYPE_ATTRIBUTES or is TYPE_REF_IS_RVALUE.
[Bug c/108982] While recompiling when even we modify any line in got its giving error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #6 from Jakub Jelinek --- As has been said, GCC 4.8.x is not supported here for years and gcc.gnu.org isn't an appropriate site to search for paid support for those old gcc versions.
[Bug target/108910] [12/13 Regression] Further ICE in aarch64_layout_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910 --- Comment #8 from Jakub Jelinek --- The above commit fixed just the #c4 testcase, not the #c0 one.
[Bug tree-optimization/108970] [13 Regression] ICE in vect_do_peeling, at tree-vect-loop-manip.cc:2971, or ICE in dump_printf_loc, at dumpfile.cc:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108970 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:85203d52bfa4a84da5f50e0a242891308ffa8d83 commit r13-6386-g85203d52bfa4a84da5f50e0a242891308ffa8d83 Author: Richard Biener Date: Wed Mar 1 09:10:19 2023 +0100 tree-optimization/108970 - ICE with vectorizer peeling The function slpeel_can_duplicate_loop_p fails to verify we can copy blocks, instead slpeel_tree_duplicate_loop_to_edge_cfg does but that's too late. The following fixes this, also simplifying error reporting which is somewhat pointless if we ICE immediately. PR tree-optimization/108970 * tree-vect-loop-manip.cc (slpeel_can_duplicate_loop_p): Check we can copy the BBs. (slpeel_tree_duplicate_loop_to_edge_cfg): Avoid redundant check. (vect_do_peeling): Streamline error handling. * gcc.dg/pr108970.c: New testcase.
[Bug c/108982] While recompiling when even we modify any line in got its giving error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982 vinay kumar changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #7 from vinay kumar --- Hi Jakub Jelinek, Thanks for update. could you please provide where I can get latest GCC RPM which supported by gcc.gnu.org. because from many websites we are able to get GCC binaries but not able found its dependencies, so we are not able to upgrade GCC to latest versions.
[Bug tree-optimization/108970] [13 Regression] ICE in vect_do_peeling, at tree-vect-loop-manip.cc:2971, or ICE in dump_printf_loc, at dumpfile.cc:1359
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108970 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||13.0 Resolution|--- |FIXED --- Comment #3 from Richard Biener --- The issue is latent of course, but unlikely to hit us in practice.
[Bug c/108982] While recompiling when even we modify any line in got its giving error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #8 from Jakub Jelinek --- See https://gcc.gnu.org/install/binaries.html - as written there, we (gcc.gnu.org) don't offer any binaries, just sources.
[Bug ada/108983] New: [13 Regression] Ada build is broken for Native (and Canadian) crosses after r13-6351-ge6d39f68d03c46
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108983 Bug ID: 108983 Summary: [13 Regression] Ada build is broken for Native (and Canadian) crosses after r13-6351-ge6d39f68d03c46 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org CC: dkm at gcc dot gnu.org Target Milestone: --- r13-6351-ge6d39f68d03c46 modifies * Make-generated.in: Use GNATMAKE. * gcc-interface/Makefile.in: Ditto. but $(GNATMAKE) is for $host and some tools are being built for $build. Up to now we have relied on the install quirk of Ada that the native gnatx are not qualified (so that 'gnatmake' is correct for $build and any other gnatmake needs to be qualified. for my 0.02 GBP - we should probably add GNAT_FOR_BUILD to disambiguate this. here's a hack patch that allows build for a native cross ($build != $host == $target) to complete. (I think the GNATxxx_FOR_BUILD needs to be at the top level, so I am not posting this for review) diff --git a/gcc/ada/Make-generated.in b/gcc/ada/Make-generated.in index 34c86b2cd63..80a573d3ce5 100644 --- a/gcc/ada/Make-generated.in +++ b/gcc/ada/Make-generated.in @@ -18,7 +18,7 @@ GEN_IL_FLAGS = -gnata -gnat2012 -gnatw.g -gnatyg -gnatU $(GEN_IL_INCLUDES) ada/seinfo_tables.ads ada/seinfo_tables.adb ada/sinfo.h ada/einfo.h ada/nmake.ads ada/nmake.adb ada/seinfo.ads ada/sinfo-nodes.ads ada/sinfo-nodes.adb ada/einfo-entities.ads ada/einfo-entities.adb: ada/stamp-gen_il ; @true ada/stamp-gen_il: $(fsrcdir)/ada/gen_il* $(MKDIR) ada/gen_il - cd ada/gen_il; $(GNATMAKE) -q -g $(GEN_IL_FLAGS) gen_il-main + cd ada/gen_il; $(GNATMAKE_FOR_BUILD) -q -g $(GEN_IL_FLAGS) gen_il-main # Ignore errors to work around finalization issues in older compilers - cd ada/gen_il; ./gen_il-main $(fsrcdir)/../move-if-change ada/gen_il/seinfo_tables.ads ada/seinfo_tables.ads @@ -39,14 +39,14 @@ ada/stamp-gen_il: $(fsrcdir)/ada/gen_il* # would cause bootstrapping with older compilers to fail. You can call it by # hand, as a sanity check that these files are legal. ada/seinfo_tables.o: ada/seinfo_tables.ads ada/seinfo_tables.adb - cd ada ; $(GNATMAKE) $(GEN_IL_INCLUDES) seinfo_tables.adb -gnatU -gnatX + cd ada ; $(GNATMAKE_FOR_BUILD) $(GEN_IL_INCLUDES) seinfo_tables.adb -gnatU -gnatX ada/snames.h ada/snames.ads ada/snames.adb : ada/stamp-snames ; @true ada/stamp-snames : ada/snames.ads-tmpl ada/snames.adb-tmpl ada/snames.h-tmpl ada/xsnamest.adb ada/xutil.ads ada/xutil.adb -$(MKDIR) ada/bldtools/snamest $(RM) $(addprefix ada/bldtools/snamest/,$(notdir $^)) $(CP) $^ ada/bldtools/snamest - cd ada/bldtools/snamest; $(GNATMAKE) -q xsnamest ; ./xsnamest + cd ada/bldtools/snamest; $(GNATMAKE_FOR_BUILD) -q xsnamest ; ./xsnamest $(fsrcdir)/../move-if-change ada/bldtools/snamest/snames.ns ada/snames.ads $(fsrcdir)/../move-if-change ada/bldtools/snamest/snames.nb ada/snames.adb $(fsrcdir)/../move-if-change ada/bldtools/snamest/snames.nh ada/snames.h diff --git a/gcc/ada/gcc-interface/Make-lang.in b/gcc/ada/gcc-interface/Make-lang.in index 9507f2f0920..b1afdad5e4c 100644 --- a/gcc/ada/gcc-interface/Make-lang.in +++ b/gcc/ada/gcc-interface/Make-lang.in @@ -186,6 +186,9 @@ ada.serial = gnat1$(exeext) # There are too many Ada sources to check against here. Let's # always force the recursive make. +GNATMAKE_FOR_BUILD=gnatmake +GNATBIND_FOR_BUILD=gnatbind +GNATLINK_FOR_BUILD=gnatlink ifeq ($(build), $(host)) ifeq ($(host), $(target)) # This is a regular native. So use the compiler from our current build @@ -197,7 +200,10 @@ ifeq ($(build), $(host)) ADA_INCLUDES="-I- -I../generated -I../rts" \ GNATMAKE="../../gnatmake" \ GNATLINK="../../gnatlink" \ -GNATBIND="../../gnatbind" +GNATBIND="../../gnatbind" \ +GNATMAKE_FOR_BUILD=$(GNATMAKE_FOR_BUILD) \ +GNATBIND_FOR_BUILD=$(GNATBIND_FOR_BUILD) \ +GNATLINK_FOR_BUILD=$(GNATLINK_FOR_BUILD) else # This is a regular cross compiler. Use the native compiler to compile # the tools. @@ -216,6 +222,9 @@ ifeq ($(build), $(host)) GNATMAKE="gnatmake" \ GNATBIND="gnatbind" \ GNATLINK="gnatlink" \ +GNATMAKE_FOR_BUILD=$(GNATMAKE_FOR_BUILD) \ +GNATBIND_FOR_BUILD=$(GNATBIND_FOR_BUILD) \ +GNATLINK_FOR_BUILD=$(GNATLINK_FOR_BUILD) \ LIBGNAT="" endif else @@ -227,6 +236,9 @@ else GNATBIND_FOR_HOST=$(host_noncanonical)-gnatbind GNATLINK_FOR_HOST=$(host_noncanonical)-gnatlink GNATLS_FOR_HOST=$(host_noncanonical)-gnatls + GNATMAKE_FOR_BUILD=gnatmake + GNATBIND_FOR_BUILD=gnatbind + GNATLINK_FOR_BUILD=gnatlink ifeq ($(host), $(target)) # This is a c
[Bug ada/108983] [13 Regression] Ada build is broken for Native (and Canadian) crosses after r13-6351-ge6d39f68d03c46
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108983 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |13.0 Keywords||build --- Comment #1 from Richard Biener --- +1 GNATMAKE_FOR_BUILD sounds exactly correct The other option is reverting the offending revision.
[Bug c++/108606] [13 Regression] ICE in potential_constant_expression_1 with friend function declaration inside a local class of a generic/templated lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108606 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b222e725f53231a0bd9799ca93892a79d592a5f3 commit r13-6387-gb222e725f53231a0bd9799ca93892a79d592a5f3 Author: Jakub Jelinek Date: Wed Mar 1 10:22:59 2023 +0100 c++: Don't recurse on DECL_INITIAL for DECL_EXPR on non-VAR_DECLs [PR108606] The r13-2965-g73d9b0e5947e16 change changed the line touched in this patch from return RECUR (tmp, want_rval); to return RECUR (DECL_INITIAL (tmp), want_rval); This is on DECL_EXPR handling code, where tmp can be lots of different trees and DECL_INITIAL unfortunately also means different things on different trees. It is the initializer on VAR_DECL, DECL_ARG_TYPE on PARM_DECLs (though those are unlikely to have DECL_EXPRs), for FUNCTION_DECLs the body, ..., USING_DECL_DECLS on USING_DECLs and DECL_FRIENDLIST on TYPE_DECLs. The testcase below ICEs because we have a DECL_EXPR for TYPE_DECL which has non-NULL DECL_FRIENDLIST and we certainly can't recurse on the friend list. The following patch will RECUR on DECL_INITIAL only for VAR_DECLs and for anything else just return true. 2023-03-01 Jakub Jelinek PR c++/108606 * constexpr.cc (potential_constant_expression_1) : Only recurse on DECL_INITIAL (tmp) if tmp is a VAR_DECL, otherwise just return true. * g++.dg/cpp1y/pr108606.C: New test.
[Bug debug/108967] internal compiler error: in expand_debug_expr, at cfgexpand.cc:5450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108967
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:520403f324a6ed8b527f39239709dd0841b992e2
commit r13-6388-g520403f324a6ed8b527f39239709dd0841b992e2
Author: Jakub Jelinek
Date: Wed Mar 1 10:26:46 2023 +0100
cfgexpand: Handle WIDEN_{PLUS,MINUS}_EXPR and
VEC_WIDEN_{PLUS,MINUS}_{HI,LO}_EXPR in expand_debug_expr [PR108967]
When these tree codes were introduced, expand_debug_expr hasn't been
updated to handle them. For the VEC_*_EXPR we currently mostly punt, the
non-vector ones can be handled easily. In release compilers this doesn't
ICE, but with checking we ICE so that we make sure to handle all the needed
tree codes there.
2023-03-01 Jakub Jelinek
PR debug/108967
* cfgexpand.cc (expand_debug_expr): Handle WIDEN_{PLUS,MINUS}_EXPR
and VEC_WIDEN_{PLUS,MINUS}_{HI,LO}_EXPR.
* g++.dg/debug/pr108967.C: New test.
[Bug c++/108606] [13 Regression] ICE in potential_constant_expression_1 with friend function declaration inside a local class of a generic/templated lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108606 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug debug/108967] [11/12 Regression] internal compiler error: in expand_debug_expr, at cfgexpand.cc:5450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108967 Jakub Jelinek changed: What|Removed |Added Summary|internal compiler error: in |[11/12 Regression] internal |expand_debug_expr, at |compiler error: in |cfgexpand.cc:5450 |expand_debug_expr, at ||cfgexpand.cc:5450 --- Comment #7 from Jakub Jelinek --- Fixed for trunk so far. Bisected with -O2 -g -ftree-vectorize to that r11-5160-g9fc9573f9a5e9432e53c commit.
[Bug sanitizer/108894] -fsanitize=bounds missing bounds provided by __builtin_dynamic_object_size()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108894 --- Comment #15 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f72c8918416f67aad907752f1892c19eda12eecb commit r13-6389-gf72c8918416f67aad907752f1892c19eda12eecb Author: Jakub Jelinek Date: Wed Mar 1 10:49:38 2023 +0100 ubsan: Add another testcase for [0] array in the middle of struct [PR108894] I think it is useful to cover also this, rather than just arrays at the flexible array member positions. 2023-03-01 Jakub Jelinek PR sanitizer/108894 * c-c++-common/ubsan/bounds-16.c: New test.
[Bug target/108984] New: [13 Regression] LTO bootstrap causes testsuite ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984 Bug ID: 108984 Summary: [13 Regression] LTO bootstrap causes testsuite ICE Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- I'm seeing the following ICE in a testsuite run after a simple ../configure --with-build-config=bootstrap-lto on x86_64-linux #0 0x00de94bf in general_operand (op=0x0, mode=E_DImode) at ../../gcc/gcc/recog.cc:1435 #1 0x018740f9 in nonimmediate_operand (mode=E_DImode, op=0x0) at ../../gcc/gcc/recog.cc:1720 #2 x86_64_szext_general_operand (mode=E_DImode, op=0x0) at ../../gcc/gcc/config/i386/predicates.md:505 #3 x86_64_szext_general_operand (op=0x0, mode=E_DImode) at ../../gcc/gcc/config/i386/predicates.md:503 #4 0x011fcd1d in insn_operand_matches (operand=0x0, opno=2, icode=CODE_FOR_anddi3) at ../../gcc/gcc/optabs.cc:7793 #5 gen_and2_insn (x=0x767b9420, y=0x0) at ../../gcc/gcc/config/i386/i386.cc:8415 #6 0x011fcfb3 in ix86_expand_prologue () at ../../gcc/gcc/config/i386/i386.cc:8580 #7 0x011df0fb in gen_prologue () at ../../gcc/gcc/config/i386/i386.md:16674 #8 target_gen_prologue () at ../../gcc/gcc/config/i386/i386.md:24241 #9 0x00b504ec in make_prologue_seq () at ../../gcc/gcc/function.cc:5841 #10 0x00b60154 in thread_prologue_and_epilogue_insns () at ../../gcc/gcc/function.cc:6073 happens when stack_realign_drap, for example for gcc.dg/stack-usage-2.c
[Bug modula2/108956] [13 regression] SEGV in M2RTS_RegisterModule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108956 --- Comment #6 from Gaius Mulley --- Do the above fixes resolve this PR ?
[Bug modula2/108956] [13 regression] SEGV in M2RTS_RegisterModule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108956 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #6 from Gaius Mulley --- > Do the above fixes resolve this PR ? The revised version did indeed. I'd included it in last night's bootstraps and everything is fine again. Thanks for the quick fix.
[Bug driver/108865] gcc on Windows fails with Unicode path to source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 --- Comment #11 from Costas Argyris --- Capturing another data point: I hex-compared an executable before and after applying the UTF-8 manifest with mt.exe just to try and see what it does, and I noticed a few things: 1) The executable size was almost cut in half.It was compiled with gcc in the first place so maybe it stripped the debug symbols perhaps? 2) There were various changes throughout it, not just the part of the xml manifest that was embedded. 3) The format changed to the point that gdb was no longer able to understand it.Before applying the manifest with mt.exe, I was able to load it into gdb and debug it, not after though as it complains about unknown format. Of course, it still runs fine after those changes. So clearly mt.exe does a lot more to the executable than just link in the manifest.I would expect that something similar happens when the manifest gets integrated at build time with MSVC. It doesn't look like it's a simple "just compile and link the resource file" case, as that seems to be only part of what is necessary, not the entire procedure. So with my current understanding of the situation I think that the plan of integrating the UTF-8 manifest at gcc build time with GNU tools is simply not possible. I would love to be proven wrong, but if it's not happening we either have to go for another approach, or just accept that gcc will not support Unicode paths on Windows (in which case we could at least copy the instructions to do it with mt.exe in some wiki guide).
[Bug c++/108971] [13 Regression] ICE in tree_profiling, at tree-profile.cc:724
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108971 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I bet really dup of PR107897. At least until that one is fixed, there is not much point analyzing other PRs with similar problems.
[Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
Richard Biener changed:
What|Removed |Added
Target||x86_64-linux
Keywords||lto
Target Milestone|--- |13.0
--- Comment #1 from Richard Biener ---
It does look like a wrong-code issue, the GEN_INT (-align_bytes) argument is
percieved as NULL.
0x011fcf92 <+578>: mov$0x40,%eax
0x011fcf97 <+583>: sub%r12d,%eax
0x011fcf9a <+586>: cltq
0x011fcf9c <+588>: mov0x2c9ada0(,%rax,8),%rsi
0x011fcfa4 <+596>: mov0x196302d(%rip),%rax# 0x2b5ffd8
0x011fcfab <+603>: mov(%rax),%rdi
0x011fcfae <+606>: call 0x11fcca0
and %rsi is indeed NULL at the call. %rax is -448. gdb locates the computed
address at
$9 = (rtx *) 0x2c99fa0 <_ZL13ix86_builtins.lto_priv.0+22848>
so it looks like we run into
rtx
gen_rtx_CONST_INT (machine_mode mode ATTRIBUTE_UNUSED, HOST_WIDE_INT arg)
{
if (arg >= - MAX_SAVED_CONST_INT && arg <= MAX_SAVED_CONST_INT)
return const_int_rtx[arg + MAX_SAVED_CONST_INT];
but MAX_SAVED_CONST_INT is 64 and gdb says align_bytes is 512. So
something seems to have elided the range check.
[Bug c++/108975] Internal compiler error on constexpr variable used as nontype template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-03-01
Keywords|needs-reduction |
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #6 from Andrew Pinski ---
Reduced:
int h(int);
template
auto get_derivative_type1() { return 0; }
template
void generate_kernels1() {
const unsigned num_elements = 1;
constexpr int dim = 1;
[&](auto index) {
using derivative_type = decltype(get_derivative_type1());
h(num_elements * 1);
};
}
void thermal_test() {
generate_kernels1();
}
[Bug c++/108975] [10/11/12/13 Regression] Internal compiler error on constexpr variable used as nontype template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975 Andrew Pinski changed: What|Removed |Added Known to work||8.2.0 Keywords||ice-on-valid-code, ||needs-bisection Target Milestone|--- |10.5 Known to fail||8.3.0 Summary|Internal compiler error on |[10/11/12/13 Regression] |constexpr variable used as |Internal compiler error on |nontype template|constexpr variable used as ||nontype template --- Comment #7 from Andrew Pinski --- >but g++ (10.4.0) and clang (14.0.0) compile the same code without any issues. Interesting because my reduced testcase also ICEs with GCC 10.4.0. Anyways it is still a regression between GCC 8.2.0 and GCC 8.3.0.
[Bug c++/108975] [10/11/12/13 Regression] Internal compiler error on constexpr variable used as nontype template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975
--- Comment #8 from Andrew Pinski ---
A slightly more reduced:
int h(int);
template
auto hh() { return 0; }
template
void mm() {
const unsigned num_elements = 1;
constexpr int dim = 1;
[&]() {
typedef decltype(hh()) derivative_type;
h(num_elements * 1);
};
}
void u() {
mm<1>();
}
[Bug c++/108975] [10/11/12/13 Regression] Internal compiler error on constexpr variable used as nontype template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975 --- Comment #9 from Andrew Pinski --- The trunk ICE is definitely lambda related: /* Lambda closures are regenerated in tsubst_lambda_expr, not instantiated here. */ gcc_assert (!LAMBDA_TYPE_P (template_type));
[Bug c++/105839] internal compiler error: in tsubst_omp_for_iterator with openmp and structured bindings in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105839 Jakub Jelinek changed: What|Removed |Added Keywords|ice-on-valid-code | --- Comment #2 from Jakub Jelinek --- Actually, I don't see how it can be valid. x (or b1) is const int[10] & and structured binding on int is clearly invalid. The ICE got fixed in r13-4460-gee4f25999f6832a1c, except that since r13-5379-gd427407a199a0c276cb02 we ICE again with -fopenmp -std=c++11 (error recovery after emitting some errors).
[Bug c++/105839] internal compiler error: in tsubst_omp_for_iterator with openmp and structured bindings in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105839 --- Comment #3 from Jakub Jelinek --- Created attachment 54564 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54564&action=edit gcc13-pr105839.patch Untested fix for the error recovery issue.
[Bug c++/105839] internal compiler error: in tsubst_omp_for_iterator with openmp and structured bindings in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105839
--- Comment #4 from northon_patrick3 at yahoo dot ca ---
Actually is still crash even on valid code:
```
template
void
foo (const T &x)
{
[&] (auto&& y)
{
#pragma omp parallel for
for (auto&& [v1, v2] : x)
;
} ([]{});
}
struct A { int a, b; };
void
bar ()
{
A a[10];
foo (a);
}
```
[Bug c++/105839] internal compiler error: in tsubst_omp_for_iterator with openmp and structured bindings in a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105839 --- Comment #5 from Jakub Jelinek --- Not on the trunk. Note, the r13-4460, r13-4461, r13-5379 changes PR84469 changes weren't backported to older branches intentionally, it is quite risky and had multiple follow-ups.
[Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Richard Biener --- .optimized of LTRANS unit 60 has # DEBUG BEGIN_STMT # DEBUG D#456 => -align_bytes_448 # DEBUG D#453 => (long int) D#456 # DEBUG D#245 => 0 # DEBUG arg => D#453 # DEBUG INLINE_ENTRY gen_rtx_CONST_INT # DEBUG D#246 => D#245 # DEBUG mode => D#246 _1005 = 64 - align_bytes_448; _1045 = (long int) _1005; _1046 = const_int_rtx[_1045]; # DEBUG mode => NULL # DEBUG arg => NULL _95 = this_target_rtl; _96 = _95->x_global_rtl[0]; _97 = gen_and2_insn (_96, _1046); and after IPA we see # DEBUG BEGIN_STMT _92 = -align_bytes_448; _93 = (long int) _92; # DEBUG D#245ptD.0 => 0 arg_1327 = _93; # DEBUG arg => arg_1327 # DEBUG arg => arg_1327 # DEBUG INLINE_ENTRY gen_rtx_CONST_INT # DEBUG D#246ptD.0 => D#245ptD.0 # DEBUG mode => D#246ptD.0 _1042 = arg_1327; _1043 = (unsigned long) _1042; _1044 = _1043 + 64; if (_1044 <= 128) goto ; [51.12%] else goto ; [48.88%] [local count: 67075190]: _1045 = _1042 + 64; _1046 = const_int_rtx[_1045]; _1258 = _1046; # DEBUG arg => NULL # DEBUG mode => NULL # DEBUG arg => NULL _94 = _1258; _95 = this_target_rtl; _96 = _95->x_global_rtl[0]; # USE = anything # CLB = anything _97 = gen_and2_insn (_96, _94); # USE = anything # CLB = anything insn_472 = emit_insn (_97); # DEBUG insn => insn_472 # DEBUG BEGIN_STMT # DEBUG BEGIN_STMT # DEBUG _rtx => insn_472 # DEBUG BEGIN_STMT _98 = insn_472->code; _99 = _98 + 65528; switch (_98) [0.00%], case 8 ... 11: [100.00%], case 13: [100.00%], case 25: [100.00%]> [local count: 64136059]: _1047 = const_int_htab; _1048 = (unsigned int) _1042; # USE = anything # CLB = anything __builtin_unreachable (); so it looks like the else path materialized to be unreachable for some reason. Before IPA we have _92 = -align_bytes_448; _93 = (long int) _92; _94 = gen_rtx_CONST_INT (0, _93); IPA CP knows callsite ix86_expand_prologue/1286343 -> gen_rtx_CONST_INT/244924 : param 0: CONST: 0 value: 0x0, mask: 0x0 Unknown VR param 1: UNKNOWN value: 0x0, mask: 0x VR [-536870911, -5] callsite ix86_expand_prologue/1286343 -> gen_rtx_CONST_INT/244924 : param 0: CONST: 0 value: 0x0, mask: 0x0 Unknown VR param 1: UNKNOWN value: 0x0, mask: 0x VR [-536870911, 0] and it at least creates a constprop clone for VOIDmode. Considering gen_rtx_CONST_INT.constprop/2274667 with 38 size to be inlined into ix86_expand_prologue/1286343 in unknown:-1 Estimated badness is -0.00, frequency 0.12. Badness calculation for ix86_expand_prologue/1286343 -> gen_rtx_CONST_INT.constprop/2274667 size growth 2, time 4.533600 unspec 7.533600 IPA hints: cross_module -0.00: guessed profile. frequency 0.122200, count -1 caller count -1 time saved 1.955200 overall growth 62692 (current) 39603 (original) 104883 (compensated) Adjusted by hints -0.00 Parm map: -5 -5 I'm somewhat lost as to where to look for why that unreachable () is created. It looks like the inliner redirects things this way.
[Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- There is redirect_to_unreachable and a couple of other places (though at least half of them are related to devirtualization which shouldn't be happening here): grep builtin_decl_unreachable ipa* ipa.cc: target = cgraph_node::get_create (builtin_decl_unreachable ()); ipa-fnsummary.cc:= cgraph_node::get_create (builtin_decl_unreachable ()); ipa-prop.cc: target = builtin_decl_unreachable (); ipa-prop.cc: tree new_target = builtin_decl_unreachable (); So, I'd add a breakpoint on builtin_decl_unreachable and see where it is called for this code.
[Bug middle-end/108546] [11/12/13 Regression] ICE in expand_expr_real_1, at expr.cc:10910 since r10-4531-ga2c26c50310a3363
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108546 --- Comment #3 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:96ff97ff6574666a5509ae9fa596e7f2b6ad4f88 commit r13-6390-g96ff97ff6574666a5509ae9fa596e7f2b6ad4f88 Author: Tobias Burnus Date: Wed Mar 1 13:53:09 2023 +0100 OpenMP/Fortran: Fix handling of optional is_device_ptr + bind(C) [PR108546] For is_device_ptr, optional checks should only be done before calling libgomp, afterwards they are NULL either because of absent or, by chance, because it is unallocated or unassociated (for pointers/allocatables). Additionally, it fixes an issue with explicit mapping for 'type(c_ptr)'. PR middle-end/108546 gcc/fortran/ChangeLog: * trans-openmp.cc (gfc_trans_omp_clauses): Fix mapping of type(C_ptr) variables. gcc/ChangeLog: * omp-low.cc (lower_omp_target): Remove optional handling on the receiver side, i.e. inside target (data), for use_device_ptr. libgomp/ChangeLog: * testsuite/libgomp.fortran/is_device_ptr-3.f90: New test. * testsuite/libgomp.fortran/use_device_ptr-optional-4.f90: New test.
[Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984 --- Comment #4 from Richard Biener --- So there's interesting IPA summary on gen_rtx_CONST_INT.constprop/2274667 find_slot_with_hash.constprop/2274668 function not considered for inlining freq:0.49 loop depth: 0 size: 6 time: 15 callee size:41 stack: 0 predicate: (op1,((unsigned long) #),(# + 64) > 128) op1 is compile time invariant op1 points to local or readonly memory op3 is compile time invariant it looks like the parameter removal does not adjust the parameter number? for the constprop clone the first parameter is constant VOIDmode (0), but the second is unknown. Not sure what '#' and op1 refer to for the predicate though. The above is from the IPA inline dump at WPA time. Note I do not see redirect_to_unreachable being called with e->callee->m_uid == 2274668 during WPA. The function is called a lot, but too many times to watch all of them (it's not called at LTRANS time at all).
[Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
--- Comment #5 from Richard Biener ---
But
void foo ();
int data[128];
static int bar (int i, int j)
{
if (j > -64 && j < 64)
return data[j+64];
foo ();
}
int baz (int j)
{
return bar (0, j);
}
seems to work fine with -O2 -fno-early-inlining -fipa-cp-clone, we create
a similar clone and have a similar inlining predicate. But still the
predicate looks exactly the same whether we IPA CP or not ...
calls:
foo/3 function body not available
freq:0.49 loop depth: 0 size: 1 time: 10 predicate: (op1,((unsigned int)
#),(# + 63) > 126)
But with IPA CP we get
Parm map: -5 0
I suspect -5 is for "removed" and 1 is mapped to 0. But with the original
case we see
Parm map: -5 -5
so no remaining parameter but op1 is referenced in the predicate?
[Bug target/106101] [12 Regression] ICE in reg_bitfield_target_p since r12-4428-g147ed0184f403b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #27 from Richard Biener --- Fixed.
[Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984 --- Comment #6 from Richard Biener --- Estimating body: gen_rtx_CONST_INT.constprop/2274667 Known to be false: not inlined, op1,((unsigned long) #),(# + 64) > 128 size:6 time:4.533600 nonspec time:7.533600 loops with known iterations:0.00 known strides:0.00 enqueuing call ix86_expand_prologue/1286343 -> gen_rtx_CONST_INT.constprop/2274667, badness -0.00 there are a few calls to the cprop clone but the above is likely the offending one.
[Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984
--- Comment #7 from Jakub Jelinek ---
Isn't what happens in i386.cc more like:
void foo (long);
int data[128];
static int bar (int i, long j)
{
if (j >= -64 && j <= 64)
return data[j+64];
foo (j);
}
int baz (unsigned int j)
{
int k = j / 8;
return bar (0, -k);
}
? Because we know in the caller it is [-0x1fff, 0] ...
[Bug pch/14940] PCH largefile test fails on various platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14940 --- Comment #58 from CVS Commits --- The master branch has been updated by Jonathan Yong : https://gcc.gnu.org/g:f769d22ab685671095525d09ef29d0ae3cee commit r13-6392-gf769d22ab685671095525d09ef29d0ae3cee Author: LIU Hao Date: Tue May 10 13:19:07 2022 +0800 gcc: Remove size limit of PCH for *-*-mingw32 hosts PCHs can now be relocated, so the size limit makes no sense any more. This patch was submited to MSYS2 9 months ago for GCC 12. No issue has been reported so far. Reference: https://github.com/msys2/MINGW-packages/blob/717d5a5a09e2370e3bd7e12b393a26dbfbe48921/mingw-w64-gcc/0010-Fix-using-large-PCH.patch Signed-off-by: LIU Hao gcc/ChangeLog: PR pch/14940 * config/i386/host-mingw32.cc (mingw32_gt_pch_get_address): Remove the size limit `pch_VA_max_size` Signed-off-by: Jonathan Yong <10wa...@gmail.com>
[Bug analyzer/108935] Incorrect warning for infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108935 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:070523b9d4c6cfa69060255893006efaf39bf617 commit r13-6393-g070523b9d4c6cfa69060255893006efaf39bf617 Author: David Malcolm Date: Wed Mar 1 08:54:43 2023 -0500 analyzer: fix infinite recursion false +ves [PR108935] gcc/analyzer/ChangeLog: PR analyzer/108935 * infinite-recursion.cc (contains_unknown_p): New. (sufficiently_different_region_binding_p): New function, splitting out inner loop from... (sufficiently_different_p): ...here. Extend detection of unknown svalues to also include svalues that contain unknown. Treat changes in frames below the entry to the recursion as being sufficiently different to reject being an infinite recursion. gcc/testsuite/ChangeLog: PR analyzer/108935 * gcc.dg/analyzer/infinite-recursion-pr108935-1.c: New test. * gcc.dg/analyzer/infinite-recursion-pr108935-1a.c: New test. * gcc.dg/analyzer/infinite-recursion-pr108935-2.c: New test. Signed-off-by: David Malcolm
[Bug target/108984] [13 Regression] LTO bootstrap causes testsuite ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108984 --- Comment #8 from Richard Biener --- I realized I have some value-range patches in the tree where I ran into this (besides the pending dwarf2out change). I'm now trying to reproduce on r13-6384-ge3837b6f6c28a1 without changes.
[Bug analyzer/108935] Incorrect warning for infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108935 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from David Malcolm --- Should be fixed by the above commit; marking this as resolved.
[Bug modula2/108956] [13 regression] SEGV in M2RTS_RegisterModule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108956 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Gaius Mulley --- Many thanks for the bug report - I think it also helped the armv7l and aarch64 - timeout in runtests. The calls to RegisterModule were generically wrong of course on all targets. Thanks for testing!
[Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #15 from Richard Biener ---
(In reply to Jonathan Wakely from comment #13)
> (In reply to Richard Biener from comment #11)
> > We can again work around this in libstdc++ by CSEing ->_M_size ourselves.
> > The following helps:
> >
> > diff --git a/libstdc++-v3/include/std/valarray
> > b/libstdc++-v3/include/std/valarray
> > index 7a23c27a0ce..7383071f98d 100644
> > --- a/libstdc++-v3/include/std/valarray
> > +++ b/libstdc++-v3/include/std/valarray
> > @@ -647,8 +647,13 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> > inline
> > valarray<_Tp>::valarray(const valarray<_Tp>& __v)
> > : _M_size(__v._M_size),
> > _M_data(__valarray_get_storage<_Tp>(__v._M_size))
> > -{ std::__valarray_copy_construct(__v._M_data, __v._M_data + _M_size,
> > -_M_data); }
> > +{
> > + auto __v_M_size = __v._M_size;
> > + _M_size = __v_M_size;
> > + _M_data = __valarray_get_storage<_Tp>(__v_M_size);
> > + std::__valarray_copy_construct(__v._M_data, __v._M_data + __v_M_size,
> > +_M_data);
> > +}
> >
> > #if __cplusplus >= 201103L
> >template
>
> Ugh, gross.
>
> This makes no sense to me. this->_M_size is already a local copy of
> __v._M_size that cannot have escaped, because its enclosing object hasn't
> been constructed yet. Why do we need another "more local" copy of it?
>
> _M_size is a copy of __v._M_size, which is passed to the get_storage
> function. The compiler thinks that the get_storage call might modify __v,
> but it can't modify this->_M_size. So then _M_size still has the same value
> when passed to the copy_construct call.
>
>
> Since it would be undefined for users to modify this->_M_size or __v._M_size
> from operator new (because they cannot access an object under construction,
> and cannot modify an object while it's in the process of being copied), I
> wish we could say that a specific call to operator new does not modify
> anything reachable from the enclosing function's arguments, including `this`.
>
> Or maybe we just teach the compiler that operator new will not touch
> anything defined in namespace std, on pain of death.
The compiler doesn't know that the allocation function cannot clobber *this.
The C++ frontend tries to communicate this by making 'this' restrict qualified
and we make use of that info, but for calls we do not know how to use the
info.
Maybe we can special-case directly the actual parameter case and compute
the restrictness info for the call arguments. The canonical example is
void bar (void);
struct X {
X (int);
int i;
int j;
};
X::X(int k)
{
i = k;
bar ();
j = i != k;
}
where if I understand you correctly, bar () is not allowed to modify *this
(unless I pass it an argument to it, of course), even if *this is for
example
char *storage;
void bar ()
{
((X *)storage)->i = 0; // the cast is invalid, no object of type X yet there?
}
int main()
{
storage = new char[8];
new (storage) X (1);
}
[Bug middle-end/108545] [13 Regression] ICE in install_var_field, at omp-low.cc:799 since r13-2665-g23baa717c991d77f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545 --- Comment #6 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:3843dc1460259fbca1f336b0259f0b6b527d77ae commit r13-6394-g3843dc1460259fbca1f336b0259f0b6b527d77ae Author: Tobias Burnus Date: Wed Mar 1 15:11:53 2023 +0100 OpenMP: Ignore side-effects when finding struct comps [PR108545] With volatile, two 'x.data' comp refs aren't regarded as identical, causing that the two items in the first map of map(to:x.a, x.a.data) map(pset: x.a.data) end up in separate 'map(struct:x)', which will cause a later ICE. Solution: Ignore side effects when checking the operands in the hash for being equal. (Do so by creating a variant of tree_operand_hash that calls operand_equal_p with OEP_MATCH_SIDE_EFFECTS.) gcc/ChangeLog: PR middle-end/108545 * gimplify.cc (struct tree_operand_hash_no_se): New. (omp_index_mapping_groups_1, omp_index_mapping_groups, omp_reindex_mapping_groups, omp_mapped_by_containing_struct, omp_tsort_mapping_groups_1, omp_tsort_mapping_groups, oacc_resolve_clause_dependencies, omp_build_struct_sibling_lists, gimplify_scan_omp_clauses): Use tree_operand_hash_no_se instead of tree_operand_hash. gcc/testsuite/ChangeLog: PR middle-end/108545 * c-c++-common/gomp/map-8.c: New test. * gfortran.dg/gomp/map-9.f90: New test.
[Bug middle-end/108545] [13 Regression] ICE in install_var_field, at omp-low.cc:799 since r13-2665-g23baa717c991d77f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Tobias Burnus --- FIXED on mainline (GCC 13). Thanks for this any many other reports!
[Bug analyzer/107565] [12/13 Regression] -Wanalyzer-use-of-uninitialized-value false positive with rdrand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107565 --- Comment #4 from David Malcolm --- Created attachment 54565 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54565&action=edit Patch that reworks builtin handling I've been testing this patch, but it might be too invasive at this point in GCC 13; attaching here to back it up while I try a less invasive approach.
[Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #16 from Jakub Jelinek ---
(In reply to Richard Biener from comment #15)
> The compiler doesn't know that the allocation function cannot clobber *this.
> The C++ frontend tries to communicate this by making 'this' restrict
> qualified
> and we make use of that info, but for calls we do not know how to use the
> info.
>
> Maybe we can special-case directly the actual parameter case and compute
> the restrictness info for the call arguments. The canonical example is
>
> void bar (void);
> struct X {
> X (int);
> int i;
> int j;
> };
>
> X::X(int k)
> {
> i = k;
> bar ();
> j = i != k;
> }
>
> where if I understand you correctly, bar () is not allowed to modify *this
> (unless I pass it an argument to it, of course), even if *this is for
> example
Why? Because it is a constructor and the object isn't fully constructed yet at
that point? For normal methods I certainly don't see anything that would
preclude such modifications.
[Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #17 from Richard Biener ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to Richard Biener from comment #15)
> > The compiler doesn't know that the allocation function cannot clobber *this.
> > The C++ frontend tries to communicate this by making 'this' restrict
> > qualified
> > and we make use of that info, but for calls we do not know how to use the
> > info.
> >
> > Maybe we can special-case directly the actual parameter case and compute
> > the restrictness info for the call arguments. The canonical example is
> >
> > void bar (void);
> > struct X {
> > X (int);
> > int i;
> > int j;
> > };
> >
> > X::X(int k)
> > {
> > i = k;
> > bar ();
> > j = i != k;
> > }
> >
> > where if I understand you correctly, bar () is not allowed to modify *this
> > (unless I pass it an argument to it, of course), even if *this is for
> > example
>
> Why? Because it is a constructor and the object isn't fully constructed yet
> at that point? For normal methods I certainly don't see anything that would
> preclude such modifications.
The canonical C example would be
void bar (void);
void foo (struct X * restrict this, int k)
{
this->i = k;
bar ();
this->j = i != k;
}
where as I understand bar () cannot modify what *this points to since it
cannot build a proper derived access from 'this' (unless I pass it to bar).
The C++ frontend annotates 'this' with restrict. For my example I get
void X::X (struct X * const this, int k)
{
# PT = { D.2806 } (nonlocal, restrict)
struct X * const this_5(D) = this;
int k_7(D) = k;
int _1;
bool _2;
int _3;
:
MEM[(struct X *)this_5(D) clique 1 base 1] ={v} {CLOBBER};
MEM[(struct X *)this_5(D) clique 1 base 1].i = k_7(D);
# USE = nonlocal escaped
# CLB = nonlocal escaped
bar ();
_1 = MEM[(struct X *)this_5(D) clique 1 base 1].i;
_2 = _1 != k_7(D);
# RANGE [irange] int [0, 1] NONZERO 0x1
_3 = (int) _2;
MEM[(struct X *)this_5(D) clique 1 base 1].j = _3;
return;
}
[Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #18 from Jakub Jelinek ---
Does the FE really do that?
I certainly don't see it in the gimple dump:
void X::X (struct X * const this, int k)
{
*this = {CLOBBER};
{
this->i = k;
# USE = anything
# CLB = anything
bar ();
_1 = this->i;
_2 = k != _1;
_3 = (int) _2;
this->j = _3;
}
}
While if I compile the C variant after fixing it up:
struct X { int i, j; };
void bar (void);
void foo (struct X * restrict this, int k)
{
this->i = k;
bar ();
this->j = this->i != k;
}
it is there:
void foo (struct X * restrict this, int k)
{
this->i = k;
bar ();
_1 = this->i;
_2 = k != _1;
_3 = (int) _2;
this->j = _3;
}
[Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
--- Comment #19 from Jakub Jelinek ---
And on
void bar (void);
struct X {
X (int);
int i;
int j;
void baz (int);
};
X::X(int k)
{
i = k;
bar ();
j = i != k;
}
void
X::baz(int k)
{
i = k;
bar ();
j = i != k;
}
while I see
# PT = { D.2822 } (nonlocal, restrict)
struct X * const this_5(D) = this;
later on in the dumps (not really sure what exactly causes it), in baz it is
not there:
# PT = nonlocal
struct X * const this_5(D) = this;
[Bug c++/81675] [6 Regression] attribute(noreturn) of destructor in :? not honored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81675 Marcin Kowalczyk changed: What|Removed |Added CC||qrczakmk at gmail dot com --- Comment #7 from Marcin Kowalczyk --- The bug is actually present in gcc-12.2.0 if foo() is a template (add "template " before "int foo()").
[Bug ipa/108959] [13 Regression] ice in modify_assignment, at ipa-param-manipulation.cc:1905 since r13-5681-ge8109bd87766be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959 Martin Jambor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/108975] [10/11/12/13 Regression] Internal compiler error on constexpr variable used as nontype template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975 --- Comment #10 from Sam Mish --- Great-- thanks for finding such a small reproducer, Andrew.
[Bug testsuite/108985] New: new test case gcc.dg/vect/pr108950.c from r13-6384-ge3837b6f6c28a1 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108985 Bug ID: 108985 Summary: new test case gcc.dg/vect/pr108950.c from r13-6384-ge3837b6f6c28a1 fails Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- Tried g:e3837b6f6c28a1d2cea3a69efbda795ea3fb8816, r13-6384-ge3837b6f6c28a1 make -k check-gcc RUNTESTFLAGS="vect.exp=gcc.dg/vect/pr108950.c" # of expected passes2 # of unresolved testcases 2 spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/vect/pr108950.c -fdiagnostics-plain-output -maltivec -mpower9-vector -ftree-vectorize -fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -S -o pr108950.s^M PASS: gcc.dg/vect/pr108950.c (test for excess errors) gcc.dg/vect/pr108950.c: dump file does not exist UNRESOLVED: gcc.dg/vect/pr108950.c scan-tree-dump-not vect "widen_sum" commit e3837b6f6c28a1d2cea3a69efbda795ea3fb8816 (HEAD) Author: Richard Biener Date: Tue Feb 28 15:34:27 2023 +0100 tree-optimization/108950 - widen-sum reduction ICE
[Bug c++/108975] [10/11/12/13 Regression] Internal compiler error on constexpr variable used as nontype template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975 Patrick Palka changed: What|Removed |Added Keywords|needs-bisection | CC||ppalka at gcc dot gnu.org --- Comment #11 from Patrick Palka --- Started with r268016
[Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561 --- Comment #20 from Jonathan Wakely --- (In reply to Jakub Jelinek from comment #16) > (In reply to Richard Biener from comment #15) > > where if I understand you correctly, bar () is not allowed to modify *this > > (unless I pass it an argument to it, of course), even if *this is for > > example > > Why? Because it is a constructor and the object isn't fully constructed yet > at that point? Yes, exactly. The object's lifetime has not started until the constructor completes, so accessing it is only allowed in very limited ways, described in [basic.life] p6. However, it looks like for a non-trivial constructor the results are just unspecified, not undefined, see [class.cdtor] p2. Still, I don't see how operator new could meaningfully do anything to an object under construction if the object is in an unspecified state. And frankly, if anybody did write an operator new like that, they deserve what they get. Could we have a flag that says "assume operator new is not stupid"?
[Bug c++/108934] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
If you are complaining about:
struct S { unsigned long long a[2]; };
struct T { unsigned long long b[6]; };
struct U { unsigned long long c[2]; long double d; unsigned long long e[2]; };
#if __SIZEOF_LONG_DOUBLE__ == 16 && __LDBL_MANT_DIG__ == 64 &&
__SIZEOF_LONG_LONG__ == 8
constexpr long double
foo (S x)
{
return __builtin_bit_cast (long double, x);
}
constexpr S a = { 0ULL, 0xULL };
constexpr long double b = foo (a);
static_assert (b == 0.0L, "");
constexpr U
bar (T x)
{
return __builtin_bit_cast (U, x);
}
constexpr T c = { 0ULL, 0ULL, 0ULL, 0xULL, 0ULL, 0ULL };
constexpr U d = bar (c);
static_assert (d.d == 0.0L, "");
#endif
which is an unintended side-effects of the PR104522 changes, then that can be
fixed e.g. with
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 9aaea71a2fc..99882ef820a 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -8873,11 +8873,13 @@ native_interpret_expr (tree type, const unsigned char
*ptr, int len)
valid values that GCC can't really represent accurately.
See PR95450. Even for other modes, e.g. x86 XFmode can have some
bit combinationations which GCC doesn't preserve. */
- unsigned char buf[24];
+ unsigned char buf[24 * 2];
scalar_float_mode mode = SCALAR_FLOAT_TYPE_MODE (type);
int total_bytes = GET_MODE_SIZE (mode);
+ memcpy (buf + 24, ptr, total_bytes);
+ clear_type_padding_in_mask (type, buf + 24);
if (native_encode_expr (ret, buf, total_bytes, 0) != total_bytes
- || memcmp (ptr, buf, total_bytes) != 0)
+ || memcmp (buf + 24, buf, total_bytes) != 0)
return NULL_TREE;
return ret;
}
The intent of the PR104522 change was to verify that the interpreted floating
point value represents the in memory value correctly, but padding bits
shouldn't be considered in that, they can contain anything. That said, for IBM
double double format or e.g. x86
extended format there are still many values which can't be interpretted
correctly,
for the latter e.g. pseudo denormals, pseudo infinities, pseudo NaNs and
unnormal values.
[Bug c++/108934] [12/13 Regression] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-03-01 Summary|bit_cast'ing to long double |[12/13 Regression] |errors out with "the|bit_cast'ing to long double |argument cannot be |errors out with "the |interpreted" since gcc-12 |argument cannot be ||interpreted" since gcc-12 Status|UNCONFIRMED |NEW
[Bug c++/108934] [12/13 Regression] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |12.3
[Bug c++/106259] [10/11/12/13 Regression] ICE in diag_mismatched_tags, at cp/parser.cc:33896
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106259 --- Comment #4 from Marek Polacek --- I know, in principle, how to fix it, but currently I'm struggling with getting struct A::W from struct A::W That we haven't found struct A::W in class2loc is actually OK, we don't have a A specialization, so we should see if W in the primary template A was defined with class or struct.
[Bug c++/108934] [12/13 Regression] bit_cast'ing to long double errors out with "the argument cannot be interpreted" since gcc-12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108934 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Created attachment 54566 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54566&action=edit gcc13-pr108934.patch Untested fix.
[Bug ipa/108959] [13 Regression] ice in modify_assignment, at ipa-param-manipulation.cc:1905 since r13-5681-ge8109bd87766be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108959
--- Comment #7 from Martin Jambor ---
The situation is that in func_61 we have an unused parameter which
IPA-SRA wants to remove. It's caller constructs the unused parameter
with the following sequence (shortened):
int func_43 (int * p_44)
{
int _1;
_1 = *p_44_3(D);
func_61 (_1);
}
Caller of func_43 however stores a long at that address and this is
what IPA-CP wants to pass down, while IPA-SRA knows that p_44 is used
only to create an argument for an unused formal parameter and would
like to remove both.
This means that the code in ipa-param-manipulation.cc kicks in, trying
to replace loads from the disappearing parameter with known constants
because once the parameter is gone there this can no longer be done.
But it attempts to create an invalid VIEW_CONVERT_EXPR in the process.
The simplest way of avoiding it is to disable the removal of the
parameter in these situations too extending the patch from e8109bd8776
with:
diff --git a/gcc/ipa-sra.cc b/gcc/ipa-sra.cc
index 3de7d426b7e..e9c47c0d852 100644
--- a/gcc/ipa-sra.cc
+++ b/gcc/ipa-sra.cc
@@ -4235,6 +4235,7 @@ adjust_parameter_descriptions (cgraph_node *node,
isra_func_summary *ifs)
!= pa->unit_size))
{
desc->split_candidate = false;
+ desc->locally_unused = false;
if (dump_file && (dump_flags & TDF_DETAILS))
dump_dead_indices.safe_push (i);
break;
But since this is all code that will be eliminated anyway, perhaps we
could be aggressive here and use force_value_to_type from
tree-inline.cc?
[Bug c++/106259] [10/11/12/13 Regression] ICE in diag_mismatched_tags, at cp/parser.cc:33896
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106259
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot
gnu.org
--- Comment #5 from Marek Polacek ---
Ah, this does what I want:
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -34473,6 +34473,12 @@ class_decl_loc_t::diag_mismatched_tags (tree
type_decl)
be (and inevitably is) at index zero. */
tree spec = specialization_of (type);
cdlguide = class2loc.get (spec);
+ if (!cdlguide)
+ {
+ spec = most_general_template (spec);
+ spec = TYPE_MAIN_DECL (TREE_TYPE (spec));
+ cdlguide = class2loc.get (spec);
+ }
gcc_assert (cdlguide != NULL);
}
else
[Bug driver/108865] gcc on Windows fails with Unicode path to source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108865 --- Comment #12 from Costas Argyris --- Sent email to binutils about possible windres issue/limitation: https://sourceware.org/pipermail/binutils/2023-March/126361.html
[Bug c/108982] While recompiling when even we modify any line in got its giving error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982 vinay kumar changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #9 from vinay kumar --- Hi could you please provide the latest versions to support oracle 19c, pro*c language if possible provide the steps to install the binaries for our AIX 7.2 server. is there any chance to get some help from your team to resolve compile time issues.
[Bug c/108982] While recompiling when even we modify any line in got its giving error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #10 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gcc-help/2023-March/142317.html
[Bug c/108982] While recompiling when even we modify any line in got its giving error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982 vinay kumar changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #11 from vinay kumar --- Hi Andrew, As you provided, we downloaded latest snapshot from below link. https://gcc.gnu.org/pub/gcc/snapshots/13-20220918/ Could you please provide any specific steps to install this in AIX server?.
[Bug c/108982] While recompiling when even we modify any line in got its giving error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #12 from Andrew Pinski --- https://gcc.gnu.org/install/
[Bug fortran/92639] Error: Integer too big for its kind at (1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639 --- Comment #2 from Olivier Cessenat --- integer(kind=4) valid range is -2147483648_4 to +2147483647_4. So I consider this is a gfortran bug. Moreover, if -2147483648_4 is considered out of range, why -2147483647_4 - 1_4 is not ? Constant elimination makes it evaluated to -2147483648_4. I disagree with the term "there are no negative integers" [-2147483648_4 is equal to +2147483648_4] Other compilers, such as aocc, nvfortran, ifort, oneapi are OK with that Thanks
[Bug c/108982] While recompiling when even we modify any line in got its giving error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982 vinay kumar changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|UNCONFIRMED --- Comment #13 from vinay kumar --- Hi If possible can we get call and can we install latest version one of DEV server ??
[Bug tree-optimization/108980] [13 Regression] Warning text missing the warning itself (GCC 13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980 --- Comment #6 from Thiago Macieira --- Testing.
[Bug c/108982] While recompiling when even we modify any line in got its giving error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #14 from Andrew Pinski --- Again we don't provide binary builds of GCC. Folks build on AIX all the time, some have used XLC to do the compiling too.
[Bug c/108982] While recompiling when even we modify any line in got its giving error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108982 --- Comment #15 from Jakub Jelinek --- And please stop reopening this bugzilla bug. There is no bug on the GCC side, and this should be handled on gcc-help mailing list, not here.
[Bug fortran/92639] Error: Integer too big for its kind at (1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #3 from Jerry DeLisle --- Please observe: program demonstrate integer :: i i = huge(i) print *, i i= -huge(i) print *, i end program $ gfc demonstrate.f90 $ ./a.out 2147483647 -2147483647 This is by the fortran standard definition for a 32 bit integer. You cannot represent 2147483648 in 32 bits because you need bit 32 to represent the sign of the value. How other compilers are storing the sign I can not speak to.
[Bug fortran/92639] Error: Integer too big for its kind at (1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639 --- Comment #4 from Steve Kargl --- On Wed, Mar 01, 2023 at 05:51:29PM +, cessenat at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639 > > --- Comment #2 from Olivier Cessenat --- > integer(kind=4) valid range is -2147483648_4 to +2147483647_4. > So I consider this is a gfortran bug. > > Moreover, if -2147483648_4 is considered out of range, why > -2147483647_4 - 1_4 is not ? Constant elimination makes it evaluated to > -2147483648_4. > > I disagree with the term "there are no negative integers" > [-2147483648_4 is equal to +2147483648_4] exceeds huge(1) % cat a.f90 print *, huge(1) end % gfortran -o z a.f90 && ./z 2147483647 I've already explained the issue. But, I'll go over it one more time. -2147483648_4 is parsed as unary minus operator and an operand of 2147483648_4. 2147483648_4 exceeds huge(1). Fortunately, gfortran can save you, and the error message even tells you. 1 | i = -2147483648_4 | 1 Error: Integer too big for its kind at (1). This check can be disabled with the option '-fno-range-check' So, let me amend the quote above "there are no negative integer-literal constants."
[Bug tree-optimization/108980] [13 Regression] Warning text missing the warning itself (GCC 13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980 --- Comment #7 from Thiago Macieira --- The duplicate "note:" disappeared. But now there's no warning at all on the same file, with the same options. Was that intended?
[Bug c/108986] New: Incorrect warning for [static] array parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986
Bug ID: 108986
Summary: Incorrect warning for [static] array parameter
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Keith.S.Thompson at gmail dot com
Target Milestone: ---
When a parameter is declared with the (new in C99) [static] syntax, and
the argument is a null pointer, the warning incorrectly refers to the
expected size in bytes of the parameter rather than to its length.
That by itself might be annoying but not incorrect, but the warning
includes C syntax that is inconsistent with the actual declaration.
(When the argument is an array object that's too short, the warning
is different. It also refers to a size in bytes, and IMHO referring
to the length would be clearer. Details to follow in a comment.)
$ cat c.c
#include
void f(int a[static 7]) { }
int main(void) {
f(NULL);
}
$ gcc --version | head -n 1
gcc (GCC) 12.2.0
$ gcc -Wall -c c.c
c.c: In function ‘main’:
c.c:6:5: warning: argument 1 to ‘int[static 28]’ is null where non-null
expected [-Wnonnull]
6 | f(NULL);
| ^~~
c.c:3:6: note: in a call to function ‘f’
3 | void f(int a[static 7]) { }
| ^
c.c:6:5: warning: argument 1 to ‘int[static 28]’ is null where non-null
expected [-Wnonnull]
6 | f(NULL);
| ^~~
c.c:3:6: note: in a call to function ‘f’
3 | void f(int a[static 7]) { }
| ^
$
[Bug c/108986] Incorrect warning for [static] array parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986
--- Comment #1 from Keith Thompson ---
A similar case. The warning refers to the size in bytes, but unlike
the first case it's not incorrect, though referring to the length
would IMHO be clearer.
Note also that the warning appears twice. It only appears once in gcc 11.2.0.
Let me know if I should submit a new bug report for this.
$ cat c.c
#include
void f(int a[static 7]) { }
int main(void) {
f(NULL);
}
$ /o/apps/gcc-12.2.0/bin/gcc --version | head -n 1
gcc (GCC) 12.2.0
$ /o/apps/gcc-12.2.0/bin/gcc -Wall -c c.c
c.c: In function ‘main’:
c.c:6:5: warning: argument 1 to ‘int[static 28]’ is null where non-null
expected [-Wnonnull]
6 | f(NULL);
| ^~~
c.c:3:6: note: in a call to function ‘f’
3 | void f(int a[static 7]) { }
| ^
c.c:6:5: warning: argument 1 to ‘int[static 28]’ is null where non-null
expected [-Wnonnull]
6 | f(NULL);
| ^~~
c.c:3:6: note: in a call to function ‘f’
3 | void f(int a[static 7]) { }
| ^
$
[Bug tree-optimization/108980] [13 Regression] Warning text missing the warning itself (GCC 13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980 --- Comment #8 from Andrew Pinski --- (In reply to Thiago Macieira from comment #7) > The duplicate "note:" disappeared. But now there's no warning at all on the > same file, with the same options. Was that intended? Yes that was the intent of the patch. There is not supposed to be any warning here at all. It was a mistake that an note (inform call) was emitted in the first place.
[Bug tree-optimization/108980] [13 Regression] Warning text missing the warning itself (GCC 13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980 --- Comment #9 from Thiago Macieira --- Ah, got it. That also explains why I couldn't find anything wrong with my code, and nothing I did that could likely be it made the warning go away. Thanks for the quick turnaround.
[Bug c++/108219] [12/13 Regression] requirement fails on a valid expression since r12-5253-g4df7f8c79835d569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108219 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:096f034a8f5df41f610e62c1592fb90a3f551cd5 commit r13-6395-g096f034a8f5df41f610e62c1592fb90a3f551cd5 Author: Patrick Palka Date: Wed Mar 1 14:09:37 2023 -0500 c++: unevaluated array new-expr size constantness [PR108219] Here we're mishandling the unevaluated array new-expressions due to a supposed non-constant array size ever since r12-5253-g4df7f8c79835d569 made us no longer perform constant evaluation of non-manifestly-constant expressions within unevaluated contexts. This shouldn't make a difference here since the array sizes are constant literals, except they're expressed as NON_LVALUE_EXPR location wrappers around INTEGER_CST, wrappers which used to get stripped as part of constant evaluation and now no longer do. Moreover it means build_vec_init can't constant fold the MINUS_EXPR 'maxindex' passed from build_new_1 when in an unevaluated context (since it tries reducing it via maybe_constant_value called with mce_unknown). This patch fixes these issues by making maybe_constant_value (and fold_non_dependent_expr) try folding an unevaluated non-manifestly-constant operand via fold(), as long as it simplifies to a simple constant, rather than doing no simplification at all. This covers e.g. simple arithmetic and casts including stripping of location wrappers around INTEGER_CST. In passing, this patch also fixes maybe_constant_value to avoid constant evaluating an unevaluated operand when called with mce_false, by adjusting the early exit test appropriately. Co-authored-by: Jason Merrill PR c++/108219 PR c++/108218 gcc/cp/ChangeLog: * constexpr.cc (fold_to_constant): Define. (maybe_constant_value): Move up early exit test for unevaluated operands. Try reducing an unevaluated operand to a constant via fold_to_constant. (fold_non_dependent_expr_template): Add early exit test for CONSTANT_CLASS_P nodes. Try reducing an unevaluated operand to a constant via fold_to_constant. * cp-tree.h (fold_to_constant): Declare. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/new6.C: New test. * g++.dg/cpp2a/concepts-new1.C: New test.
[Bug c++/108218] [12/13 Regression] Constant arguments in the new expression is not checked in unevaluated operand since r12-5253-g4df7f8c79835d569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108218 --- Comment #14 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:096f034a8f5df41f610e62c1592fb90a3f551cd5 commit r13-6395-g096f034a8f5df41f610e62c1592fb90a3f551cd5 Author: Patrick Palka Date: Wed Mar 1 14:09:37 2023 -0500 c++: unevaluated array new-expr size constantness [PR108219] Here we're mishandling the unevaluated array new-expressions due to a supposed non-constant array size ever since r12-5253-g4df7f8c79835d569 made us no longer perform constant evaluation of non-manifestly-constant expressions within unevaluated contexts. This shouldn't make a difference here since the array sizes are constant literals, except they're expressed as NON_LVALUE_EXPR location wrappers around INTEGER_CST, wrappers which used to get stripped as part of constant evaluation and now no longer do. Moreover it means build_vec_init can't constant fold the MINUS_EXPR 'maxindex' passed from build_new_1 when in an unevaluated context (since it tries reducing it via maybe_constant_value called with mce_unknown). This patch fixes these issues by making maybe_constant_value (and fold_non_dependent_expr) try folding an unevaluated non-manifestly-constant operand via fold(), as long as it simplifies to a simple constant, rather than doing no simplification at all. This covers e.g. simple arithmetic and casts including stripping of location wrappers around INTEGER_CST. In passing, this patch also fixes maybe_constant_value to avoid constant evaluating an unevaluated operand when called with mce_false, by adjusting the early exit test appropriately. Co-authored-by: Jason Merrill PR c++/108219 PR c++/108218 gcc/cp/ChangeLog: * constexpr.cc (fold_to_constant): Define. (maybe_constant_value): Move up early exit test for unevaluated operands. Try reducing an unevaluated operand to a constant via fold_to_constant. (fold_non_dependent_expr_template): Add early exit test for CONSTANT_CLASS_P nodes. Try reducing an unevaluated operand to a constant via fold_to_constant. * cp-tree.h (fold_to_constant): Declare. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/new6.C: New test. * g++.dg/cpp2a/concepts-new1.C: New test.
[Bug c++/108219] [12 Regression] requirement fails on a valid expression since r12-5253-g4df7f8c79835d569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108219 Patrick Palka changed: What|Removed |Added Known to work||13.0 Summary|[12/13 Regression] |[12 Regression] requirement |requirement fails on a |fails on a valid expression |valid expression since |since |r12-5253-g4df7f8c79835d569 |r12-5253-g4df7f8c79835d569 --- Comment #4 from Patrick Palka --- Fixed for GCC 13 so far
[Bug target/108987] New: [13 Regression] RISC-V: shiftadd cost model bug needlessly preferring syth_multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108987
Bug ID: 108987
Summary: [13 Regression] RISC-V: shiftadd cost model bug
needlessly preferring syth_multiply
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: vineetg at rivosinc dot com
Target Milestone: ---
gcc trunk is preferring synthetic multiply using shift+add even when they are
costlier than multiply.
unsigned long long f5(unsigned long long i)
{
return i * 0x0202020202020202ULL;
}
riscv64-unknown-linux-gnu-gcc -c -O2 -march=rv64gc_zba
f5:
sllia5,a0,8
add a0,a5,a0
sllia5,a0,16
add a0,a0,a5
sllia5,a0,32
add a0,a0,a5
sllia0,a0,1
ret
With gcc 12.2 this used to be
f5:
lui a5,%hi(.LC0)
ld a5,%lo(.LC0)(a5)
mul a0,a0,a5
ret
This is a regression introduced by commit f90cb39235c4 ("RISC-V: costs: support
shift-and-add in strength-reduction"). It introduced the cost for
shift[1-3]+add (to favor SH*ADD) but due to a coding bug ended up doing this
for all shift values, affecting synth multiply among others.
This showed up as dynamic icount regression in SPEC 531.deepsjeng.
[Bug target/108987] [13 Regression] RISC-V: shiftadd cost model bug needlessly preferring syth_multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108987
--- Comment #1 from Vineet Gupta ---
Fix posted here
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613106.html
Essentially:
case PLUS:
if (TARGET_ZBA
&& mode == word_mode
&& GET_CODE (XEXP (x, 0)) == MULT
&& REG_P (XEXP (XEXP (x, 0), 0))
&& CONST_INT_P (XEXP (XEXP (x, 0), 1))
- && IN_RANGE (pow2p_hwi (INTVAL (XEXP (XEXP (x, 0), 1))), 1, 3))
+ && pow2p_hwi (INTVAL (XEXP (XEXP (x, 0), 1)))
+ && IN_RANGE (exact_log2 (INTVAL (XEXP (XEXP (x, 0), 1))), 1, 3))
{
*total = COSTS_N_INSNS (1);
return true;
}
[Bug tree-optimization/108980] [13 Regression] Warning text missing the warning itself (GCC 13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org --- Comment #10 from Andrew Pinski --- Mine, the patch which I am testing (and will be submitting) is different from the attached one because there could be a case were the inner warning could return false but we still want to emit the note as we did a warning before hand.
[Bug testsuite/108973] Sufficiently narrow terminal window causes selftest failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108973 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic, ||ice-on-valid-code, ||internal-improvement Status|UNCONFIRMED |NEW Last reconfirmed||2023-03-01 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- selftests should be as indepedent from the environment variables as much as it can be ...
[Bug testsuite/108973] [13 Regression] Sufficiently narrow terminal window causes selftest failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108973 Andrew Pinski changed: What|Removed |Added Summary|Sufficiently narrow |[13 Regression] |terminal window causes |Sufficiently narrow |selftest failure|terminal window causes ||selftest failure Target Milestone|--- |13.0 --- Comment #2 from Andrew Pinski --- This is a regression since selftests are newish but I don't know which releases are broken though.
[Bug fortran/106856] [12/13 Regression][OOP] CLASS attribute handling / ICE in gfc_conv_expr_present, at fortran/trans-expr.cc:1977 since r12-4346-geb92cd57a1ebe7cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106856 --- Comment #4 from anlauf at gcc dot gnu.org --- Created attachment 54567 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54567&action=edit Updated patch The original patches started to bit-rot, so here is an updated version. The current situation is as follows: - it fixes a couple of ice-on-valid, ice-on-invalid, rejects-valid cases, see below - testcase interface_41.f90 turns out to be actually valid Fortran and is now correctly accepted (-> testsuite needs adjustment) - testcase pr69398.f90 ICE's - as expected, see comment in new testcase class_75.f90. Shall we mark this one as XFAIL for the time being and reopen pr69398? - it appears that the following PRs are addressed or fixed with this patch: pr53951, pr101101, pr104229, pr107380 So applying the patch would be a big achievement over the current situation. @Thomas: do you think this path should/could be followed?
[Bug middle-end/108988] New: gimple_fold_builtin_fputs doesn't preserve gimple_builtin_call_types_compatible_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988
Bug ID: 108988
Summary: gimple_fold_builtin_fputs doesn't preserve
gimple_builtin_call_types_compatible_p
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Whilst working on PR analyzer/107565, I noticed that in this function:
~~
typedef struct FILE FILE;
FILE* fopen (const char*, const char*);
int fprintf (FILE *, const char *, ...);
#define NULL ((void *)0)
void
test_2 (void)
{
int i;
for (i = 0; i < 2; ++i) {
FILE *fp = fopen ("/tmp/test", "w");
fprintf (fp, "hello");
}
} // should report a leak here
~~
the fprintf (fp, "hello"); is optimized to:
__builtin_fwrite ("hello", 1, 5, fp);
but this call has:
(gdb) p gimple_builtin_call_types_compatible_p (repl, gimple_call_fndecl
(repl))
$23 = false
Specifically, the fprintf is optimized to:
__builtin_fputs ("hello", fp);
Within gimple_fold_builtin_fprintf this has:
(gdb) call debug(stmt)
__builtin_fputs ("hello", fp);
(gdb) p gimple_builtin_call_types_compatible_p (stmt, gimple_call_fndecl
(stmt))
$19 = true
which is optimized to:
(gdb) call debug(repl)
__builtin_fwrite ("hello", 1, 5, fp);
(gdb) p gimple_builtin_call_types_compatible_p (repl, gimple_call_fndecl
(repl))
$23 = false
Note how the resulting call has "false" for
gimple_builtin_call_types_compatible_p; this is due to argument idx 2 (the 5):
(gdb) p i
$13 = 2
(gdb) p arg
$14 =
(gdb) call debug_tree(arg)
constant 5>
In the analyzer I'm checking that gimple_builtin_call_types_compatible_p is
true when handling a builtin that it "knows" how to handle, otherwise the
analyzer falls back to assuming that the call could have arbitrary side-effects
(e.g. fclose-ing the file, hence it stops reporting the leak).
Is this a bug in gimple_fold_builtin_fprintf?
[Bug middle-end/108988] gimple_fold_builtin_fputs doesn't preserve gimple_builtin_call_types_compatible_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988 --- Comment #1 from David Malcolm --- Replacement stmt is created here: (gdb) bt #0 gimple_set_op (gs=, i=1, op=) at ../../src/gcc/gimple.h:2629 #1 0x01093a6f in gimple_build_call_1 (fn=, nargs=4) at ../../src/gcc/gimple.cc:234 #2 0x01093bfd in gimple_build_call (fn=, nargs=4) at ../../src/gcc/gimple.cc:270 #3 0x010b1a0b in gimple_fold_builtin_fputs (gsi=0x7fffd740, arg0=, arg1=, unlocked=false) at ../../src/gcc/gimple-fold.cc:2993 #4 0x010b884f in gimple_fold_builtin (gsi=0x7fffd740) at ../../src/gcc/gimple-fold.cc:5060 #5 0x010baf8a in gimple_fold_call (gsi=0x7fffd740, inplace=false) at ../../src/gcc/gimple-fold.cc:5575 #6 0x010be650 in fold_stmt_1 (gsi=0x7fffd740, inplace=false, valueize=0x10be840 ) at ../../src/gcc/gimple-fold.cc:6327 #7 0x010be8ca in fold_stmt (gsi=0x7fffd740) at ../../src/gcc/gimple-fold.cc:6410 #8 0x010aa554 in replace_call_with_call_and_fold (gsi=0x7fffd740, repl=) at ../../src/gcc/gimple-fold.cc:842 #9 0x010b3c93 in gimple_fold_builtin_fprintf (gsi=0x7fffd740, fp=, fmt=, arg=, fcode=BUILT_IN_FPRINTF) at ../../src/gcc/gimple-fold.cc:3796 #10 0x010b8a66 in gimple_fold_builtin (gsi=0x7fffd740) at ../../src/gcc/gimple-fold.cc:5100 #11 0x010baf8a in gimple_fold_call (gsi=0x7fffd740, inplace=false) at ../../src/gcc/gimple-fold.cc:5575 #12 0x010be650 in fold_stmt_1 (gsi=0x7fffd740, inplace=false, valueize=0x10be840 ) at ../../src/gcc/gimple-fold.cc:6327 #13 0x010be8ca in fold_stmt (gsi=0x7fffd740) at ../../src/gcc/gimple-fold.cc:6410 #14 0x02c93123 in lower_stmt (gsi=0x7fffd740, data=0x7fffd950) at ../../src/gcc/gimple-low.cc:793 #15 0x02c910ee in lower_sequence (seq=0x7fffea65d1b8, data=0x7fffd950) at ../../src/gcc/gimple-low.cc:229 #16 0x02c935ff in lower_gimple_bind (gsi=0x7fffd860, data=0x7fffd950) at ../../src/gcc/gimple-low.cc:882 #17 0x02c92d28 in lower_stmt (gsi=0x7fffd860, data=0x7fffd950) at ../../src/gcc/gimple-low.cc:650 #18 0x02c910ee in lower_sequence (seq=0x7fffea65d178, data=0x7fffd950) at ../../src/gcc/gimple-low.cc:229 #19 0x02c935ff in lower_gimple_bind (gsi=0x7fffd930, data=0x7fffd950) at ../../src/gcc/gimple-low.cc:882 #20 0x02c90cf1 in lower_function_body () at ../../src/gcc/gimple-low.cc:119 #21 0x02c9104f in (anonymous namespace)::pass_lower_cf::execute (this=0x3f43e20) at ../../src/gcc/gimple-low.cc:206 #22 0x0140ff5a in execute_one_pass (pass=) at ../../src/gcc/passes.cc:2644 2993gimple *repl = gimple_build_call (fn_fwrite, 4, arg0, 2994 size_one_node, len, arg1); 2995replace_call_with_call_and_fold (gsi, repl);
[Bug tree-optimization/108988] gimple_fold_builtin_fputs doesn't preserve gimple_builtin_call_types_compatible_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988 Andrew Pinski changed: What|Removed |Added Keywords||internal-improvement Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-03-01 Component|middle-end |tree-optimization --- Comment #2 from Andrew Pinski --- /* Get the length of the string passed to fputs. If the length can't be determined, punt. */ tree len = get_maxval_strlen (arg0, SRK_STRLEN); if (!len || TREE_CODE (len) != INTEGER_CST) return false; And before we had a call to c_strlen. In both cases, they both always returned a size in ssizetype. As far as I can tell this has been broken since the merge of the tree-ssa branch into the trunk. I have not done a "git blame" on the tree-ssa branch to see which revision introduced this without a cast. Confirmed. gimple *repl = gimple_build_call (fn_fwrite, 4, arg0, size_one_node, len, arg1); replace_call_with_call_and_fold (gsi, repl); Basically you need to add a fold_convert of len to size_type_node and do a temporary if needed.
[Bug tree-optimization/108988] gimple_fold_builtin_fputs doesn't preserve gimple_builtin_call_types_compatible_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108988
--- Comment #3 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:24ebc5404b88b765221b551dc5288f6d64ba3dc7
commit r13-6398-g24ebc5404b88b765221b551dc5288f6d64ba3dc7
Author: David Malcolm
Date: Wed Mar 1 17:24:32 2023 -0500
analyzer: fixes to side-effects for built-in functions [PR107565]
Previously, if the analyzer saw a call to a non-pure and non-const
built-in function that it didn't have explicit knowledge of the behavior
of, it would fall back to assuming that the builtin could have arbitrary
behavior, similar to a function defined outside of the current TU.
However, this only worked for BUILTIN_NORMAL functions that matched
gimple_builtin_call_types_compatible_p; for BUILT_IN_FRONTEND and
BUILT_IN_MD, and for mismatched types the analyzer would erroneously
assume that the builtin had no side-effects, leading e.g. to
PR analyzer/107565, where the analyzer falsely reported that x
was still uninitialized after this target-specific builtin:
_1 = __builtin_ia32_rdrand64_step (&x);
This patch generalizes the handling to cover all classes of builtin,
fixing the above false positive.
Unfortunately this patch regresses gcc.dg/analyzer/pr99716-1.c due to
the:
fprintf (fp, "hello");
being optimized to:
__builtin_fwrite ("hello", 1, (ssizetype)5, fp_6);
and the latter has gimple_builtin_call_types_compatible_p return false,
whereas the original call had it return true. I'm assuming that this is
an optimization bug, and have filed it as PR middle-end/108988. The
effect on the analyzer is that it fails to recognize the call to
__builtin_fwrite and instead assumes arbitraty side-effects (including
that it could call fclose on fp, hence the report about the leak goes
away).
I tried various more involved fixes with new heuristics for handling
built-ins that aren't explicitly covered by the analyzer, but those
fixes tended to introduce many more regressions, so I'm going with this
simpler fix.
gcc/analyzer/ChangeLog:
PR analyzer/107565
* region-model.cc (region_model::on_call_pre): Flatten logic by
returning early. Consolidate logic for detecting const and pure
functions. When considering whether an unhandled built-in
function has side-effects, consider all kinds of builtin, rather
than just BUILT_IN_NORMAL, and don't require
gimple_builtin_call_types_compatible_p.
gcc/testsuite/ChangeLog:
PR analyzer/107565
* gcc.dg/analyzer/builtins-pr107565.c: New test.
* gcc.dg/analyzer/pr99716-1.c (test_2): Mark the leak as xfailing.
Signed-off-by: David Malcolm
[Bug analyzer/107565] [12/13 Regression] -Wanalyzer-use-of-uninitialized-value false positive with rdrand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107565
--- Comment #5 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:24ebc5404b88b765221b551dc5288f6d64ba3dc7
commit r13-6398-g24ebc5404b88b765221b551dc5288f6d64ba3dc7
Author: David Malcolm
Date: Wed Mar 1 17:24:32 2023 -0500
analyzer: fixes to side-effects for built-in functions [PR107565]
Previously, if the analyzer saw a call to a non-pure and non-const
built-in function that it didn't have explicit knowledge of the behavior
of, it would fall back to assuming that the builtin could have arbitrary
behavior, similar to a function defined outside of the current TU.
However, this only worked for BUILTIN_NORMAL functions that matched
gimple_builtin_call_types_compatible_p; for BUILT_IN_FRONTEND and
BUILT_IN_MD, and for mismatched types the analyzer would erroneously
assume that the builtin had no side-effects, leading e.g. to
PR analyzer/107565, where the analyzer falsely reported that x
was still uninitialized after this target-specific builtin:
_1 = __builtin_ia32_rdrand64_step (&x);
This patch generalizes the handling to cover all classes of builtin,
fixing the above false positive.
Unfortunately this patch regresses gcc.dg/analyzer/pr99716-1.c due to
the:
fprintf (fp, "hello");
being optimized to:
__builtin_fwrite ("hello", 1, (ssizetype)5, fp_6);
and the latter has gimple_builtin_call_types_compatible_p return false,
whereas the original call had it return true. I'm assuming that this is
an optimization bug, and have filed it as PR middle-end/108988. The
effect on the analyzer is that it fails to recognize the call to
__builtin_fwrite and instead assumes arbitraty side-effects (including
that it could call fclose on fp, hence the report about the leak goes
away).
I tried various more involved fixes with new heuristics for handling
built-ins that aren't explicitly covered by the analyzer, but those
fixes tended to introduce many more regressions, so I'm going with this
simpler fix.
gcc/analyzer/ChangeLog:
PR analyzer/107565
* region-model.cc (region_model::on_call_pre): Flatten logic by
returning early. Consolidate logic for detecting const and pure
functions. When considering whether an unhandled built-in
function has side-effects, consider all kinds of builtin, rather
than just BUILT_IN_NORMAL, and don't require
gimple_builtin_call_types_compatible_p.
gcc/testsuite/ChangeLog:
PR analyzer/107565
* gcc.dg/analyzer/builtins-pr107565.c: New test.
* gcc.dg/analyzer/pr99716-1.c (test_2): Mark the leak as xfailing.
Signed-off-by: David Malcolm
[Bug analyzer/107565] [12/13 Regression] -Wanalyzer-use-of-uninitialized-value false positive with rdrand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107565 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #6 from David Malcolm --- Should be fixed on trunk for GCC 13 by the above patch. Keeping this report open for now to track backporting the fix to GCC 12.
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #5 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #3)
> (In reply to Richard Biener from comment #2)
> > Iff only (GNU) C would accept the following ...
> >
> > struct foo {
> > ...
> > unsigned int count;
> > ...
> > int data[count];
> > };
>
> Well, that I think conflicts with the variable length structures GNU
> extension, where
> if the array size of a field isn't a constant expression, it is an
> expression evaluated at runtime once (SAVE_EXPR) to determine the field size.
VLA is only legal inside function scopes.
but this new extension will be legal at file scope.
will this fact be used to distinguish these two?
> Here we are talking about something similar to what Fortran wants with its
> deferred length arrays, essentially to have the size evaluated each time it
> is accessed.
> With the data[count] form even if it would be disambiguated the question is
> if we want to otherwise treat it like normal flexible array member e.g. for
> sizeof etc. and only treat it specially for __bdos, or if it would affect
> say sizeof too.
the immediate purpose of this new extension is used for __bdos.
is there any benefit if it will affect sizeof()?
> I don't see how sizeof (struct foo) could be treated differently from
> flexible array member, because one doesn't have an object on which count can
> be evaluated, but perhaps
> struct foo f;
> f.count = 24;
> sizeof (f.data) could change.
what's the major purpose of enabling this?
[Bug tree-optimization/108980] [13 Regression] Warning text missing the warning itself (GCC 13)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108980 Andrew Pinski changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2023-March/6 ||13130.html --- Comment #11 from Andrew Pinski --- Patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613130.html
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896 --- Comment #6 from Kees Cook --- I really want to avoid the changes to sizeof() -- this will confuse a lot of other things. Sizeof is expected to be a constant expression, for example. I think the attribute is best since it avoids colliding with anything else.
[Bug c++/107574] [10/11/12/13 Regression] ICE: tree check in cp_fold_convert with ptr to member field cast inside a class not completed and inherent since r9-50-gd760b06868d660bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107574 --- Comment #7 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:de81e06273c613d7e06cbe2c8d9e72826c638056 commit r13-6400-gde81e06273c613d7e06cbe2c8d9e72826c638056 Author: Marek Polacek Date: Thu Feb 2 18:15:37 2023 -0500 c++: can't eval PTRMEM_CST in incomplete class [PR107574] Here we're attempting to evaluate a PTRMEM_CST in a class that hasn't been completed yet, but that doesn't work: /* We can't lower this until the class is complete. */ if (!COMPLETE_TYPE_P (DECL_CONTEXT (member))) return cst; and then this unlowered PTRMEM_CST is used as EXPR in tree op1 = build_nop (ptrdiff_type_node, expr); and we crash in a subsequent cp_fold_convert which gets type=ptrdiff_type_node, expr=PTRMEM_CST and does else if (TREE_CODE (expr) == PTRMEM_CST && same_type_p (TYPE_PTRMEM_CLASS_TYPE (type), PTRMEM_CST_CLASS (expr))) where TYPE_PTRMEM_CLASS_TYPE (type) is going to crash since the type is ptrdiff_type_node. We could just add a TYPE_PTRMEM_P check before accessing TYPE_PTRMEM_CLASS_TYPE but I think it's nicer to explain why we couldn't evaluate the expression. PR c++/107574 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_constant_expression): Emit an error when a PTRMEM_CST cannot be evaluated. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/ptrmem-cst1.C: New test.
