[Bug target/102374] [x86_64] Should ignore spaces in target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102374 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Implemented.
[Bug target/102374] [x86_64] Should ignore spaces in target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102374 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:df592811f950301ed3b10a08e476dad0f2eff26a commit r12-4489-gdf592811f950301ed3b10a08e476dad0f2eff26a Author: Martin Liska Date: Mon Oct 4 14:06:14 2021 +0200 target: support spaces in target attribute. PR target/102374 gcc/ChangeLog: * config/i386/i386-options.c (ix86_valid_target_attribute_inner_p): Strip whitespaces. * system.h (strip_whilespaces): New function. gcc/testsuite/ChangeLog: * gcc.target/i386/pr102374.c: New test.
[Bug target/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 Kewen Lin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org CC||linkw at gcc dot gnu.org --- Comment #4 from Kewen Lin --- I'll have a look first.
[Bug jit/102824] building pdf/dvi documentation for libgccjit fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-19 Summary|building pdf/dvi|building pdf/dvi |documentation for libgccjit |documentation for libgccjit |fails on darwin |fails Ever confirmed|0 |1 Build|darwin |darwin, linux --- Comment #1 from Iain Sandoe --- On linux the make html target succeeds - but it seems to run sphinx - is that now a prerequisite? (running make dvi after make html did not seem to make any difference)
[Bug fortran/102826] Glibc "--disable-mathvec" configure option fail to disable traces to libmvec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102826 --- Comment #3 from haochen.jiang at intel dot com --- (In reply to Andrew Pinski from comment #2) > math-vector-fortran.h comes from glibc so this is a glibc bug and not a GCC > bug. > installed header files from glibc should match --disable-mathvec . >From my perspective, there maybe bug in glibc. However, in the gfortran config part of gcc, it should not has the finclude part for F951 under all circumstances or there should be some option to control that. This is also a bug I believe.
[Bug tree-optimization/102703] [12 Regression] Dead Code Elimination Regression at -O3 since r12-2591-g2e96b5f14e402569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-October ||/581963.html Keywords||patch --- Comment #15 from Andrew Pinski --- Patch series starts here: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581963.html
[Bug tree-optimization/102822] [12 regression] 27_io/ios_base/failure/dual_abi.cc failure after r12-4443
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102822 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- Fixed by r12-4486.
[Bug middle-end/102464] Miss optimization for (_Float16) sqrtf ((float) f16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102464 --- Comment #8 from Hongtao.liu --- (In reply to Richard Biener from comment #3) > There's related optimizations in convert () which should ideally move to > match.pd When i try to mov convert stuffs to match.pd, i find some "mismatch", there's 3 cases 1. math functions are transformed under condition "optimize" 2. math functions are transformed under condition "optimize && flag_unsafe_math_optimizations" 3. math functions are transformed under condition "optimize && flag_unsafe_math_optimizations flag_errno_maths" And for logb, it's case 1, which means it can be transformed w/o !flag_errno_maths, but according to DEF_C99_BUILTIN(BUILT_IN_LOGB, "logb", BT_FN_DOUBLE_DOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO), !flag_errno_maths is needed and the transformation will be prevented by gimple-match-head.c:maybe_push_res_to_seq /* We can't and should not emit calls to non-const functions. */ if (!(flags_from_decl_or_type (decl) & ECF_CONST)) return NULL; /* fabsl (extend(x)) -> extend(fabsf(x)), etc., if x is a float. */ (for froms (BUILT_IN_FABS BUILT_IN_FABSL BUILT_IN_LOGB BUILT_IN_LOGBL) tos (BUILT_IN_FABSF BUILT_IN_FABSF BUILT_IN_LOGBF BUILT_IN_LOGBF) (simplify (froms (convert float_value_p@0)) (if (optimize && canonicalize_math_p () && mathfn_built_in (TREE_TYPE (@0), froms)) (convert (tos @0)
[Bug fortran/102826] Glibc "--disable-mathvec" configure option fail to disable traces to libmvec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102826 Andrew Pinski changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- math-vector-fortran.h comes from glibc so this is a glibc bug and not a GCC bug. installed header files from glibc should match --disable-mathvec .
[Bug fortran/102826] Glibc "--disable-mathvec" configure option fail to disable traces to libmvec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102826 --- Comment #1 from Andrew Pinski --- Isn't this a bug in glibc and not gcc. Gcc is doing what glibc header file is telling it can be done.
[Bug fortran/102826] New: Glibc "--disable-mathvec" configure option fail to disable traces to libmvec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102826 Bug ID: 102826 Summary: Glibc "--disable-mathvec" configure option fail to disable traces to libmvec Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: haochen.jiang at intel dot com Target Milestone: --- When I build Glibc with "--disable-mathvec" and run through this simple testcase: program test_overloaded_intrinsic real(4) :: x4(3200), y4(3200) real(8) :: x8(3200), y8(3200) y4 = sin(x4) print *, y4 end It reports error: undefined reference to `_ZGVeN8v_sin' It is trying to find libmvec functions, while because of the disabling, libmvec.so will not be generated. When I go through gcc file. In gcc/config/gnu-user.h Line 156, we have: #undef TARGET_F951_OPTIONS #define TARGET_F951_OPTIONS "%{!nostdinc:\ %:fortran-preinclude-file(-fpre-include= math-vector-fortran.h finclude%s/)}" , which is maybe the cause of the error. Because when I clear that math-vector-fortran.h, the testcase will pass.
[Bug libstdc++/102825] std::move_only_function's implementation breaking existing code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102825 --- Comment #1 from 康桓瑋 --- (In reply to 康桓瑋 from comment #0) > mofunc_impl.h#L111: > > : _Mofunc_base(nullptr), _M_invoke(&_S_invoke<_Tp>) > > _Mofunc_basede does not have a constructor which accepts a nullptr. > > #include > https://godbolt.org/z/59T4obz4j gcc test: #include struct F { F(std::initializer_list); void operator()() const; }; int main() { std::move_only_function f(std::in_place_type, {0}); } https://godbolt.org/z/8qsEqbh9s
[Bug libstdc++/102825] New: std::move_only_function's implementation breaking existing code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102825 Bug ID: 102825 Summary: std::move_only_function's implementation breaking existing code Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- mofunc_impl.h#L111: : _Mofunc_base(nullptr), _M_invoke(&_S_invoke<_Tp>) _Mofunc_basede does not have a constructor which accepts a nullptr. #include https://godbolt.org/z/59T4obz4j
[Bug target/102812] Unoptimal (and wrong) code for _Float16 insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102812 --- Comment #1 from Hongtao.liu --- ix86_get_ssemov needs to be updated for V8HF/V16HF since they cound be existed under TARGET_SSE2/TARGET_AVX.
[Bug jit/102824] New: building pdf/dvi documentation for libgccjit fails on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824 Bug ID: 102824 Summary: building pdf/dvi documentation for libgccjit fails on darwin Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: egallager at gcc dot gnu.org CC: iains at gcc dot gnu.org Target Milestone: --- Build: darwin Running `make pdf` fails in gcc/jit for me with the following error: !pdfTeX error: pdfetex: cannot find image file libgccjit-figures/sum-of-squares 1. ==> Fatal error occurred, no output PDF file produced! /opt/iains/x86_64-apple-darwin19/gcc-7-5-toolchain/bin/texi2dvi: pdfetex exited with bad status, quitting. make[2]: *** [../../gcc/jit/Make-lang.in:283: doc/libgccjit.pdf] Error 1 make[2]: Leaving directory '/Users/ericgallager/gcc_newgit/abcdefghijklmnopqrstuvwxyz_01234567890.build/gcc' make[1]: *** [Makefile:5361: pdf-gcc] Error 1 make[1]: Leaving directory '/Users/ericgallager/gcc_newgit/abcdefghijklmnopqrstuvwxyz_01234567890.build' make: *** [Makefile:1280: do-pdf] Error 2 I also got a similar error with `make dvi`, the full log for which can be found here: https://github.com/cooljeanius/gcc_bugs/blob/master/doc_logs/libgccjit.log (I originally reported this on IRC while testing a patch for bug 102663)
[Bug classpath/39747] Installation documentation should suggest building libgmp as PIC for building with libjava
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747 Eric Gallager changed: What|Removed |Added Keywords||documentation CC||egallager at gcc dot gnu.org --- Comment #8 from Eric Gallager --- Is this still relevant now that gcc no longer ships with java?
[Bug other/102663] add an install-dvi Makefile target to the toplevel Makefile and all subdirectories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102663 Eric Gallager changed: What|Removed |Added URL|https://gcc.gnu.org/legacy- |https://gcc.gnu.org/piperma |ml/gcc-patches/2016-10/msg0 |il/gcc-patches/2021-October |0380.html |/581960.html Assignee|marxin at gcc dot gnu.org |egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- (In reply to Eric Gallager from comment #4) > (In reply to Martin Liška from comment #3) > > I would install the patch for now. > > OK, I'll need to regenerate it and re-test it first... OK, regenerated and re-tested; new patch is here: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581960.html I'm going to self-assign this since I've been working on it.
[Bug tree-optimization/102822] [12 regression] 27_io/ios_base/failure/dual_abi.cc failure after r12-4443
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102822 Bug 102822 depends on bug 102796, which changed state. Bug 102796 Summary: [12 Regresson] ICE in useless_type_conversion_p at gcc/gimple-expr.c:87 since r12-4443-g93ac832f1846e4867aa6537f76f510fab8e3e87d https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102796 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/102796] [12 Regresson] ICE in useless_type_conversion_p at gcc/gimple-expr.c:87 since r12-4443-g93ac832f1846e4867aa6537f76f510fab8e3e87d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102796 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Andrew Macleod --- Should be fixed.
[Bug c/88727] Diagnostics improvement: Detection of undefined behaviour. Incomplete type in tenative definition with internal linkage. [-Wtentative-definition-incomplete-type]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88727 Joseph S. Myers changed: What|Removed |Added CC||pavel.morozkin at gmail dot com --- Comment #3 from Joseph S. Myers --- *** Bug 102821 has been marked as a duplicate of this bug. ***
[Bug c/102821] Tentative definition of variable with internal linkage has incomplete non-array type: missing diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102821 Joseph S. Myers changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Joseph S. Myers --- This is in a Semantics section of the standard, not Constraints, so no diagnostic is required, but as a quality-of-implementation matter we should diagnose it. *** This bug has been marked as a duplicate of bug 88727 ***
[Bug tree-optimization/102796] [12 Regresson] ICE in useless_type_conversion_p at gcc/gimple-expr.c:87 since r12-4443-g93ac832f1846e4867aa6537f76f510fab8e3e87d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102796 --- Comment #8 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:4d92a69fc5882c86aab63d52382b393d4f20b3ed commit r12-4486-g4d92a69fc5882c86aab63d52382b393d4f20b3ed Author: Andrew MacLeod Date: Mon Oct 18 13:52:18 2021 -0400 Process EH edges again and call get_tree_range on non gimple_range_ssa_p names. PR tree-optimization/102796 gcc/ * gimple-range.cc (gimple_ranger::range_on_edge): Process EH edges normally. Return get_tree_range for non gimple_range_ssa_p names. (gimple_ranger::range_of_stmt): Use get_tree_range for non gimple_range_ssa_p names. gcc/testsuite/ * g++.dg/pr102796.C: New.
[Bug fortran/102787] ICE in new test case gfortran.dg/reshape_shape_2.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102787 --- Comment #6 from anlauf at gcc dot gnu.org --- WIP patch that fixes comment#5 as like comment#0 and regtests cleanly: diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c index 6552eaf3b0c..e1ab2e06fdb 100644 --- a/gcc/fortran/array.c +++ b/gcc/fortran/array.c @@ -1812,6 +1812,29 @@ expand_constructor (gfc_constructor_base base) continue; } + /* Expand constant array within array constructor. */ + if (e->expr_type == EXPR_VARIABLE && e->rank && e->ref + && e->symtree && e->symtree->n.sym + && e->symtree->n.sym->attr.flavor == FL_PARAMETER + && e->symtree->n.sym->value + && e->symtree->n.sym->value->value.constructor) + { + gfc_ref *ref; + for (ref = e->ref; ref; ref = ref->next) + if (ref->type == REF_ARRAY) + break; + + if (ref && ref->u.ar.as && ref->u.ar.as->type == AS_EXPLICIT + && ref->u.ar.type == AR_FULL) + { + gfc_expr *value = e->symtree->n.sym->value; + if (!expand_constructor (value->value.constructor)) + return false; + + continue; + } + } + empty_constructor = false; e = gfc_copy_expr (e); if (!gfc_simplify_expr (e, 1)) It only lacks goodies such as array sections in the constructor.
[Bug target/102783] [powerpc] FPSCR manipulations cannot be relied upon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783 --- Comment #6 from joseph at codesourcery dot com --- Generically (and if the command-line options are such that floating-point control / status bits are to be respected by optimizations), *any* function call might access or modify floating-point control and status bits, subject to e.g. const functions not being able to access them, pure functions not being able to modify them, functions whose body is known having properties based on analysis of that body, built-in functions having semantics based on what the compiler knows about those functions. And then a subset of asms may similarly access or modify them (based on inputs / outputs / clobbers, but maybe on some architectures existing practice doesn't provide a register name that inputs / outputs / clobbers can use to refer to floating-point state). Then you'd need something like Marc Glisse's -ffenv-access patches (August 2020) to represent the other side of things, how floating-point operations also access / modify such bits.
[Bug c/102821] Tentative definition of variable with internal linkage has incomplete non-array type: missing diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102821 --- Comment #2 from Pavel M --- Addition to "Notes" above. 3. C11, 5.1.1.3 Diagnostics, 1: > A conforming implementation shall produce at least one diagnostic message > (identified in an implementation-defined manner) if a preprocessing > translation unit or translation unit contains a violation of any syntax rule > or constraint, even if the behavior is also explicitly specified as undefined > or implementation-defined.
[Bug target/102811] vcvtph2ps and vcvtps2ph should be used to convert _Float16 to SFmode with -mf16c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug tree-optimization/102329] [11/12 Regression] pointer "maybe uninitialized" right after assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102329 Andrew Pinski changed: What|Removed |Added Summary|pointer "maybe |[11/12 Regression] pointer |uninitialized" right after |"maybe uninitialized" right |assignment |after assignment Target Milestone|--- |11.3 --- Comment #8 from Andrew Pinski --- There might be another bug referencing the same.
[Bug c++/102804] [9/10/11/12 Regression] template matching fails w/ false ambiguity on ternary expressions with enums class defined with unsigned typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102804 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Target Milestone|--- |9.5 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=82307
[Bug tree-optimization/102814] [12 regression] quadratique/exponential time complexity for max-jump-thread-duplication-stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102814 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Keywords||compile-time-hog CC||aldyh at gcc dot gnu.org, ||pinskia at gcc dot gnu.org
[Bug target/102761] [10/11/12 Regression] ICE with -O1 and above: in ix86_print_operand_address_as due to %a0 and if_then_else and X constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102761 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:e9c3a7243bf7a4db9b0dec44d278e9bf527f3d9b commit r11-9171-ge9c3a7243bf7a4db9b0dec44d278e9bf527f3d9b Author: Uros Bizjak Date: Mon Oct 18 17:03:28 2021 +0200 i386: Fix ICE in ix86_print_opreand_address [PR 102761] 2021-10-18 Uroš Bizjak PR target/102761 gcc/ChangeLog: * config/i386/i386.c (ix86_print_operand_address): Error out for non-address_operand asm operands. gcc/testsuite/ChangeLog: * gcc.target/i386/pr102761.c: New test.
[Bug middle-end/102823] [11/12 Regression] glm-0.9.9.8 fails on gcc-11 and above (-fno-strict-aliasing)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102823 --- Comment #1 from Andrew Pinski --- Hmm: *reinterpret_cast::type, Q> const *>(&v) That seems like it could be a violation of C/C++ aliasing rules. This is in: template static glm::vec bitCount_bitfield(glm::vec const& v)
[Bug tree-optimization/102796] [12 Regresson] ICE in useless_type_conversion_p at gcc/gimple-expr.c:87 since r12-4443-g93ac832f1846e4867aa6537f76f510fab8e3e87d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102796 --- Comment #7 from H.J. Lu --- (In reply to Andrew Macleod from comment #6) > Created attachment 51624 [details] > Allow EDGE_EH edges to be processed > > range_on_edge needs to continue processing EDGE_EH.. > See if this fixes all the problems. It results ina lot of UNDEFINED values > which caused no end of issues. > Its currently running through tests. If it works, please remove "or EH" from comments.
[Bug middle-end/102823] [11/12 Regression] glm-0.9.9.8 fails on gcc-11 and above (-fno-strict-aliasing)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102823 Andrew Pinski changed: What|Removed |Added Summary|glm-0.9.9.8 fails on gcc-11 |[11/12 Regression] |and above |glm-0.9.9.8 fails on gcc-11 |(-fno-strict-aliasing) |and above ||(-fno-strict-aliasing) Target Milestone|--- |11.3
[Bug c++/102823] New: glm-0.9.9.8 fails on gcc-11 and above (-fno-strict-aliasing)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102823 Bug ID: 102823 Summary: glm-0.9.9.8 fails on gcc-11 and above (-fno-strict-aliasing) Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- Created attachment 51626 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51626&action=edit z.tar.gz On gcc-10 glm test suite worked successfully. On gcc-11 single test fails as: glm> The following tests FAILED: glm> 39 - test-core_func_integer (Failed) I extracted self-contained example that hopefully illustrates the problem: $ g++-10 -I. -O2 core_func_integer.cpp -o a && ./a; echo $? 0 $ g++-11 -I. -O2 core_func_integer.cpp -o a && ./a; echo $? 4 $ g++-12 -I. -O2 core_func_integer.cpp -o a && ./a; echo $? 4 Adding -fno-strict-aliasing makes the test pass. Can you help me understand where alaising violation happens? I tried adding -fopt-info, but there is not much difference in the output.
[Bug tree-optimization/102822] [12 regression] 27_io/ios_base/failure/dual_abi.cc failure after r12-4443
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102822 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-10-18 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102796 Depends on||102796 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Most likely will be fixed with the patch attached to PR 102796. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102796 [Bug 102796] [12 Regresson] ICE in useless_type_conversion_p at gcc/gimple-expr.c:87 since r12-4443-g93ac832f1846e4867aa6537f76f510fab8e3e87d
[Bug tree-optimization/102822] [12 regression] 27_io/ios_base/failure/dual_abi.cc failure after r12-4443
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102822 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |12.0 Component|other |tree-optimization
[Bug other/102822] New: [12 regression] 27_io/ios_base/failure/dual_abi.cc failure after r12-4443
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102822 Bug ID: 102822 Summary: [12 regression] 27_io/ios_base/failure/dual_abi.cc failure after r12-4443 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:93ac832f1846e4867aa6537f76f510fab8e3e87d, r12-4443 make -k check RUNTESTFLAGS="--target_board=unix'{-m32,-m64}' conformance.exp=27_io/ios_base/failure/dual_abi.cc" FAIL: 27_io/ios_base/failure/dual_abi.cc execution test FAIL: 27_io/ios_base/failure/dual_abi.cc execution test /home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/27_io/ios_base/failure/dual_abi.cc:52: void test01(): Assertion 'caught_ios_failure' failed. FAIL: 27_io/ios_base/failure/dual_abi.cc execution test commit 93ac832f1846e4867aa6537f76f510fab8e3e87d Author: Andrew MacLeod Date: Thu Oct 7 10:12:29 2021 -0400 Ranger : Do not process abnormal ssa-names.
[Bug c/102821] Tentative definition of variable with internal linkage has incomplete non-array type: missing diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102821 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-10-18 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c/102821] New: Tentative definition of variable with internal linkage has incomplete non-array type: missing diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102821 Bug ID: 102821 Summary: Tentative definition of variable with internal linkage has incomplete non-array type: missing diagnostics Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pavel.morozkin at gmail dot com Target Milestone: --- Sample code (t940.c): static struct s foo; static struct s {int a;} foo; Invocation: $ gcc t940.c -c -std=c11 -pedantic -Wall -Wextra -Wno-unused-variable Expected diagnostics: t940.c:1:17: warning: tentative definition of variable with internal linkage has incomplete non-array type 'struct s' [-Wtentative-definition-incomplete-type] Actual diagnostics: Notes: 1. C11, 6.9.2 External object definitions, 3: > If the declaration of an identifier for an object is a tentative definition > and has internal linkage, the declared type shall not be an incomplete type. 2. C11, 4. Conformance, 1: > In this International Standard, ‘‘shall’’ is to be interpreted as a > requirement on an implementation or on a program; conversely, ‘‘shall not’’ > is to be interpreted as a prohibition.
[Bug tree-optimization/102819] [11/12 Regression] IFN_COMPLEX_MUL matches things that it shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819 Tamar Christina changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-10-18 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org --- Comment #1 from Tamar Christina --- bad3 is fixed already by my local patch set, I will fix bad1 and bad2 next week and cleanup a bit and make a patch for backport. > (If we don't currently check that the SUB node has the same children as the ADD node then perhaps we should check that too. Now that we have general VEC_PERM_EXPR nodes, the children could in principle be different.) Already done in the new patches.
[Bug c++/102820] Failure to compile void{}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102820 Marek Polacek changed: What|Removed |Added Last reconfirmed||2021-10-18 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/102820] New: Failure to compile void{}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102820 Bug ID: 102820 Summary: Failure to compile void{} Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gabravier at gmail dot com Target Milestone: --- void f() { void{}; } This has been considered valid since http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2351 was accepted as a DR in 2018, but GCC fails to compile it, with this error: : In function 'void f()': :3:10: error: compound literal of non-object type 'void' 3 | void{}; | ^
[Bug c++/92909] [8/9/10 Regression] ICE on incorrect lambda inside variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92909 --- Comment #8 from Patrick Palka --- *** Bug 92911 has been marked as a duplicate of this bug. ***
[Bug c++/92911] Valid lambda inside variadic template does not compile (2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92911 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #3 from Patrick Palka --- dup *** This bug has been marked as a duplicate of bug 92909 ***
[Bug c++/94310] using constructor inheritance breaks the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94310 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||ppalka at gcc dot gnu.org Target Milestone|--- |11.0 --- Comment #4 from Patrick Palka --- This looks fixed in GCC 11/12, ever since r11-6942
[Bug tree-optimization/102819] New: [11/12 Regression] IFN_COMPLEX_MUL matches things that it shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819 Bug ID: 102819 Summary: [11/12 Regression] IFN_COMPLEX_MUL matches things that it shouldn't Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rsandifo at gcc dot gnu.org CC: tnfchris at gcc dot gnu.org Target Milestone: --- Created attachment 51625 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51625&action=edit Examples of correct and incorrect matches complex_mul_pattern::matches() seems to accept too much. IIUC, for the non-conjugate case, it matches if: * the root is an interleaving of a SUB node and an ADD node * the children of the ADD node are two multiplications * the left-hand multiplication includes an EVEN/EVEN permute (i.e. multiplication by real) However, for the non-conjugate case, there don't seem to be any checks for the contents of the right-hand multiplication or how they match up with the left-hand multiplication. The later code then drops one child of this right-hand node. (If we don't currently check that the SUB node has the same children as the ADD node then perhaps we should check that too. Now that we have general VEC_PERM_EXPR nodes, the children could in principle be different.) With -O3 -march=armv8.2-a+sve, all of the functions in the attached test are recognised as complex multiplications, even though only good1 and good2 really are. There are quite a few other cases in which we incorrectly match a COMPLEX_MUL but then bail out due to: Built SLP cancelled: all SLP instances support load/store-lanes (Perhaps we should have a --param to disable that load/store-lanes check?)
[Bug fortran/102818] New: ICE in gfc_resolve_formal_arglist, at fortran/resolve.c:282
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102818 Bug ID: 102818 Summary: ICE in gfc_resolve_formal_arglist, at fortran/resolve.c:282 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- The following error message always shows the symbol name 'ppr@'. Finally found a case with ICE, seems to be older than r5. $ cat z1.f90 module m type t contains procedure :: f end type contains integer function f() procedure(real), pointer :: f end end $ cat z2.f90 # no ICE, same error module m type t contains procedure, nopass :: f end type contains integer function f() procedure(real), pointer :: f end end $ gfortran-12-20211017 -c z1.f90 z1.f90:8:35: 8 | procedure(real), pointer :: f | 1 Error: Symbol 'ppr@' at (1) already has basic type of INTEGER f951: internal compiler error: Segmentation fault 0xeed8df crash_signal ../../gcc/toplev.c:322 0x857700 gfc_resolve_formal_arglist(gfc_symbol*) ../../gcc/fortran/resolve.c:282 0x873672 do_traverse_symtree ../../gcc/fortran/symbol.c:4171 0x8579e3 resolve_formal_arglists ../../gcc/fortran/resolve.c:563 0x8579e3 resolve_contained_functions ../../gcc/fortran/resolve.c:1147 0x8579e3 resolve_types ../../gcc/fortran/resolve.c:17419 0x85307c gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17545 0x83b1c2 gfc_parse_file() ../../gcc/fortran/parse.c:6721 0x8891bf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/102817] [12 Regression] ICE in gfc_clear_shape, at fortran/expr.c:422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102817 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from G. Steinmetz --- This variant still works : $ cat z2.f90 program p type t integer :: a(1,2) = 3 end type type(t), parameter :: x(1) = t(4) integer :: y(1,2) y = x(1)%a print *, y end $ gfortran-12-20211017 z2.f90 && ./a.out 4 4 $
[Bug fortran/102817] New: [12 Regression] ICE in gfc_clear_shape, at fortran/expr.c:422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102817 Bug ID: 102817 Summary: [12 Regression] ICE in gfc_clear_shape, at fortran/expr.c:422 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started between 20211003 and 20211010 : $ cat z1.f90 program p type t integer :: a(1,2) = 3 end type type(t), parameter :: x(1) = t(4) integer :: y(1,2) y = (x(1)%a) print *, y end $ gfortran-12-20211003 -c z1.f90 $ $ gfortran-12-20211017 -c z1.f90 f951: internal compiler error: Segmentation fault 0xd47e4f crash_signal ../../gcc/toplev.c:322 0x798d1b gfc_clear_shape(__mpz_struct (*) [1], int) ../../gcc/fortran/expr.c:422 0x798d1b gfc_free_shape(__mpz_struct (**) [1], int) ../../gcc/fortran/expr.c:432 0x798e3d free_expr0 ../../gcc/fortran/expr.c:513 0x798ff0 gfc_replace_expr(gfc_expr*, gfc_expr*) ../../gcc/fortran/expr.c:626 0x79c768 simplify_const_ref ../../gcc/fortran/expr.c:1999 0x79ce5e gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.c:2312 0x79d0ab simplify_parameter_variable ../../gcc/fortran/expr.c:2141 0x79ce2d gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.c:2279 0x79c9a6 simplify_intrinsic_op ../../gcc/fortran/expr.c:1188 0x79c9a6 gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.c:2268 0x80bb79 resolve_operator ../../gcc/fortran/resolve.c:4470 0x80807f gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7136 0x810aa4 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:11806 0x810aa4 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11908 0x812097 resolve_codes ../../gcc/fortran/resolve.c:17512 0x81215e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17547 0x7fa494 resolve_all_program_units ../../gcc/fortran/parse.c:6519 0x7fa494 gfc_parse_file() ../../gcc/fortran/parse.c:6771 0x8476bf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/102816] New: [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102816 Bug ID: 102816 Summary: [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started between 20211010 and 20211017 : $ cat z1.f90 program p type t integer :: a([2]) end type type(t) :: x = t([3, 4]) end $ gfortran-12-20211017 -c z1.f90 f951: internal compiler error: in resolve_structure_cons, at fortran/resolve.c:1467 0x81a894 resolve_structure_cons ../../gcc/fortran/resolve.c:1466 0x80a31c resolve_generic_f ../../gcc/fortran/resolve.c:2799 0x80a31c resolve_function ../../gcc/fortran/resolve.c:3301 0x80a31c gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7143 0x79c024 gfc_reduce_init_expr(gfc_expr*) ../../gcc/fortran/expr.c:3125 0x79f290 gfc_match_init_expr(gfc_expr**) ../../gcc/fortran/expr.c:3173 0x789a04 variable_decl ../../gcc/fortran/decl.c:3019 0x789a04 gfc_match_data_decl() ../../gcc/fortran/decl.c:6328 0x7f2d63 match_word ../../gcc/fortran/parse.c:67 0x7f2d63 decode_statement ../../gcc/fortran/parse.c:378 0x7f47aa next_free ../../gcc/fortran/parse.c:1388 0x7f47aa next_statement ../../gcc/fortran/parse.c:1620 0x7f5ecb parse_spec ../../gcc/fortran/parse.c:4159 0x7f8c9c parse_progunit ../../gcc/fortran/parse.c:6125 0x7fa421 gfc_parse_file() ../../gcc/fortran/parse.c: 0x8476bf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug tree-optimization/102796] [12 Regresson] ICE in useless_type_conversion_p at gcc/gimple-expr.c:87 since r12-4443-g93ac832f1846e4867aa6537f76f510fab8e3e87d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102796 Andrew Macleod changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |amacleod at redhat dot com --- Comment #6 from Andrew Macleod --- Created attachment 51624 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51624&action=edit Allow EDGE_EH edges to be processed range_on_edge needs to continue processing EDGE_EH.. See if this fixes all the problems. It results ina lot of UNDEFINED values which caused no end of issues. Its currently running through tests.
[Bug fortran/102815] New: gfortran.dg/bind-c-contiguous-5.f90 fails at execution on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102815 Bug ID: 102815 Summary: gfortran.dg/bind-c-contiguous-5.f90 fails at execution on armeb Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- The new test gfortran.dg/bind-c-contiguous-5.f90 fails on armeb (arm big-endian), such as armeb-linux-gnueabihf: The output contains: At line 928 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_assumed_size_f' At line 928 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_assumed_size_f' At line 928 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_assumed_size_f' abcghinop defghijlm At line 946 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_assumed_size_in_f' At line 946 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_assumed_size_in_f' At line 946 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_assumed_size_in_f' abcghinop defghijlm At line 965 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_expl_size_f' At line 965 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_expl_size_f' At line 965 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_expl_size_f' abcghinop defghijlm At line 983 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_expl_size_in_f' At line 983 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_expl_size_in_f' At line 983 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_expl_size_in_f' abcghinop defghijlm abcghinop abcghinop abcghinop defghijlm defghijlm defghijlm abcghinop abcghinop abcghinop defghijlm defghijlm defghijlm At line 1039 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_assumed_rank_cont_f' At line 1039 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_assumed_rank_cont_f' At line 1039 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_assumed_rank_cont_f' abcghinop abcghinop abcghinop defghijlm defghijlm defghijlm At line 1057 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_assumed_rank_cont_in_f' At line 1057 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_assumed_rank_cont_in_f' At line 1057 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_assumed_rank_cont_in_f' abcghinop abcghinop abcghinop defghijlm defghijlm defghijlm abcghinop defghijlm abcghinop defghijlm At line 1113 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_assumed_shape_cont_f' At line 1113 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_assumed_shape_cont_f' At line 1113 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_assumed_shape_cont_f' abcghinop defghijlm At line 1131 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for arg
[Bug tree-optimization/102814] New: [12 regression] quadratique/exponential time complexity for max-jump-thread-duplication-stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102814 Bug ID: 102814 Summary: [12 regression] quadratique/exponential time complexity for max-jump-thread-duplication-stmts Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dimhen at gmail dot com Target Milestone: --- r12-4256 FAST r12- SLOW g++ -fpreprocessed -std=c++98 -O2 --param max-jump-thread-duplication-stmts=NNN -c x.ii r12-4256 r12- 1800.5s 0.21s 1810.8s > 100s 1901.0s 52s cat x.ii # cvise'd from proprietary codebase struct a { a operator+(int); }; void *operator new(unsigned long, void *c) { return c; } struct d { void h(int *j) { new (j) int(); } }; struct k { struct { int e; int f; } g; }; struct n : k { a m_fn2(); a o(); int m_fn4(); int operator[](int); int ae; void s() { if (g.e != g.f) { d l; int *b; l.h(b); } a m = o(); t(m, ae); } template void u(a, af, af); void t(a, unsigned char); }; int ah; struct v { n w(); }; void x() { v p; n ak = p.w(), al, rapdu; int q(ak.m_fn4()); int r; for (int i = 0; q; i++) { if (i == q - 1) { al.s(); r = ak.m_fn4(); } al.s(); al.s(); al.s(); al.s(); a am, an = ak.m_fn2(), ao = an + 1, ap = ak.m_fn2(), aq = ap + ah, ar = aq + r; al.u(am, ao, ar); if (i == q - 1) al.s(); i &&rapdu[1]; } } g++ -v Using built-in specs. COLLECT_GCC=/home/dimhen/arch-gcc/gcc_current/bin/g++ COLLECT_LTO_WRAPPER=/home/dimhen/arch-gcc/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none Target: x86_64-pc-linux-gnu Configured with: /home/dimhen/src/gcc_current/configure --prefix=/home/dimhen/arch-gcc/gcc_current --enable-checking=yes,df,fold,rtl,extra --enable-languages=c,c++,lto --disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune=native --enable-libstdcxx-debug Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20211015 (experimental) [master r12--ga01704fc45a] (GCC)
[Bug target/102768] [feature request] Add support for aarch64 shadow call stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102768 --- Comment #3 from nsz at gcc dot gnu.org --- well, protection mechanisms are rarely equivalent. neither scs nor traditional stack protector are perfect. to me compiler support for freestanding environments such as linux makes sense. i cannot immediately tell if libc support would work. (android is not a good indicator of what can be done in linux userspace: the android abi is broken between releases while glibc is abi stable, bionic can do hacks in longjmp/setcontext that is not acceptable in glibc and android does not have mixed toolchain issues such as old unwinder tries to unwind across a new binary.)
[Bug objc/102537] Objective-C: can't use >= USE_FIXUP_BEFORE paths on non-Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102537 --- Comment #2 from Matt Jacobson --- I certainly haven't spent as much time thinking about this as you, but I think my personal preference would be to add new values to the `flag_objc_abi` argument. It's already the case that "objc-next-runtime-abi-01.c" supports both 0 and 1 values; I think it would be reasonable to have `objc-next-runtime-abi-02.c` support multiple values too. I'd imagine something like: 2 -- "modern" runtime ABI, pre-SnowLeopard (fixup messages, etc.) 3 -- "modern" runtime ABI, SnowLeopard and later (no fixup messages, weak protocol metadata Then the Darwin-target code could (absent an explicit override in the arguments) select the value for `flag_objc_abi` based on `-mmacosx-version-min`. And non-Darwin targets could simply default to the newest ABI (absent an explicit override). Other versions could be added in the future as support for newer runtime-ABI-dependent features (e.g., `objc_autoreleasePoolPush()`, `objc_opt_self()`, `objc_loadWeak()`) is added. Under this scheme, I think it would make sense to switch `flag_next_runtime` to being a simple boolean. === I think I like this better than using the high byte of `flag_next_runtime`, which could be cumbersome to build conditionals for. For example, taking your example of using 0x0100 as the "AVR" platform, a check of whether to use non-fixup messaging might end up look like: #define PLATFORM(r) (((r) >> 24) & 0xFF) #define VERSION(r) ((r) & 0xFF) if ((PLATFORM(flag_next_runtime) == DARWIN && VERSION(flag_next_runtime) >= USE_FIXUP_BEFORE) || PLATFORM(flag_next_runtime) == AVR) { ... } Yeah, the existing `flag_next_runtime >= USE_FIXUP_BEFORE` would technically work, but you could imagine other platforms with ID > 0 that want the pre-USE_FIXUP_BEFORE behavior. === > These two were both thoughts during the development but I suspect that the > mapping to values is a build-time decision and ought to be done in the flags > override code. I'd like to understand better what you mean here. Is it that, under the `flag_objc_abi` scheme I described, the x86_64-Darwin target may want different logic to select `flag_objc_abi` than the AVR target (for example)? If so then I agree -- shouldn't that be similar to how the `flag_next_runtime` override is currently target-dependent? Apologies if I've completely misread that.
[Bug c++/102804] [9/10/11/12 Regression] template matching fails w/ false ambiguity on ternary expressions with enums class defined with unsigned typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102804 --- Comment #7 from Jonathan Wakely --- Oops, sorry the reduced example was missing the first line. Fixed, and further reduced: using int32_t = int; enum: unsigned int32_t { foo }; int f(int); int f(unsigned); auto x = f(1 ? foo : 1);
[Bug c++/102804] [9/10/11/12 Regression] template matching fails w/ false ambiguity on ternary expressions with enums class defined with unsigned typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102804 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|NEW Summary|template matching fails w/ |[9/10/11/12 Regression] |false ambiguity on ternary |template matching fails w/ |expressions with enums |false ambiguity on ternary |class defined with unsigned |expressions with enums |typdef |class defined with unsigned ||typedef CC||mukesh.kapoor at oracle dot com Resolution|INVALID |--- Known to work||7.4.0 Last reconfirmed||2021-10-18 Ever confirmed|0 |1 Keywords||rejects-valid Known to fail||8.1.0 --- Comment #6 from Jonathan Wakely --- This is a bug, we should either reject 'unsigned int32_t' immediately (which we only do with -pedantic-errors) or we should accept it and treat it consistently as unsigned int. Reduced: enum: unsigned int32_t { FOO, BAR } foobar = FOO; int f(int); int f(unsigned); auto x = f(1 ? foobar : 13); With r254043 we just have a pedwarn: 102804.C:2:16: warning: long, short, signed or unsigned used invalidly for 'type name' [-Wpedantic] enum: unsigned int32_t { FOO, BAR } foobar = FOO; ^~~ With r254046 we get the error: 102804.C:2:16: warning: long, short, signed or unsigned used invalidly for 'type name' [-Wpedantic] enum: unsigned int32_t { FOO, BAR } foobar = FOO; ^~~ 102804.C:5:27: error: call of overloaded 'f(unsigned int)' is ambiguous auto x = f(1 ? foobar : 13); ^ 102804.C:3:5: note: candidate: 'int f(int)' int f(int); ^ 102804.C:4:5: note: candidate: 'int f(unsigned int)' int f(unsigned); ^ re PR c++/82307 (unscoped enum-base incorrect cast) /cp 2017-10-24 Mukesh Kapoor Paolo Carlini PR c++/82307 * cvt.c (type_promotes_to): Implement C++17, 7.6/4, about unscoped enumeration type whose underlying type is fixed. So it was actually caused by fixing the promotion rules for enums (PR 82307), not by the handling of 'unsigned' applied to a typedef.
[Bug c++/102804] template matching fails w/ false ambiguity on ternary expressions with enums class defined with unsigned typdef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102804 --- Comment #5 from Todd Rudick --- Richard, is there a way to represent the part of this that is a bug? Presumably accepting the construct but having it break template specialization with an error that can be arbitrarily disconnected from the definition is not a desired behavior. In the production code that I eventually isolated this from, there is in fact no reference at all to the header that contained the enum. Also, it seems likely that the compiler state is bad at that point (?), as the error message indicates an 'unsigned int' ambiguity that doesn't actually exist.
[Bug middle-end/100316] [11/12 Regression] __clear_cache() does not support NULL-pointer arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100316 Kito Cheng changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Kito Cheng --- Fixed are committed to both trunk and gcc-11 branch now :)
[Bug middle-end/100316] [11/12 Regression] __clear_cache() does not support NULL-pointer arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100316 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Kito Cheng : https://gcc.gnu.org/g:aa827fa170d3e61d17c3daaf4d5008a3c674a005 commit r11-9170-gaa827fa170d3e61d17c3daaf4d5008a3c674a005 Author: Kito Cheng Date: Thu Oct 7 16:17:13 2021 +0800 [PR/target 100316] Allow constant address for __builtin___clear_cache. __builtin___clear_cache was able to accept constant address for the argument, but it seems no longer accept recently, and it even not accept constant address which is hold in variable when optimization is enable: ``` void foo3(){ void *yy = (void*)0x1000; __builtin___clear_cache(yy, yy); } ``` So this patch make BEGIN and END accept VOIDmode, like cselib_lookup_mem did per Jim Wilson's suggestion. ``` static cselib_val * cselib_lookup_mem (rtx x, int create) { ... addr_mode = GET_MODE (XEXP (x, 0)); if (addr_mode == VOIDmode) addr_mode = Pmode; ``` Changes v2 -> v3: - Use gcc_assert rather than error, maybe_emit_call_builtin___clear_cache is internal use only, and we already checked the type in other place. Changes v1 -> v2: - Check is CONST_INT intead of cehck mode, no new testcase, since constant value with other type like CONST_DOUBLE will catched by front-end. e.g. Code: ```c void foo(){ __builtin___clear_cache(1.11, 0); } ``` Error message: ``` clearcache-double.c: In function 'foo': clearcache-double.c:2:27: error: incompatible type for argument 1 of '__builtin___clear_cache' 2 | __builtin___clear_cache(1.11, 0); | ^~~~ | | | double clearcache-double.c:2:27: note: expected 'void *' but argument is of type 'double' ``` gcc/ChangeLog: PR target/100316 * builtins.c (maybe_emit_call_builtin___clear_cache): Allow CONST_INT for BEGIN and END, and use gcc_assert rather than error. gcc/testsuite/ChangeLog: PR target/100316 * gcc.c-torture/compile/pr100316.c: New. (cherry picked from commit 4e5bc4e4506a7ae7bb88fc925a425652a1da6b2d)
[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 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-10-18 Component|c |middle-end Summary|Bogus Wstringop-overread|[11/12 Regression] Bogus |warning when special|Wstringop-overread passing |(integer) pointer values|a smaller array to an array |passed to array parameter |parameter without a bound |of a function | Status|UNCONFIRMED |NEW --- Comment #1 from Martin Sebor --- GCC issues the -Wstringop-xxx warnings in this context only because there isn't a more appropriate option yet. One should be added. The warning for argument 2 is a bug. With -Warray-parameter enabled, for the purposes of out-of-bounds access detection, GCC treats function parameters declared using the array form (as in void f (int a[2]);) as an indication that the function expects an array argument with at least as many elements. A bug in the code applies the same logic to an array parameter declared with no bounds, as in the example. I confirm this report for this problem. With the following snippet, a read access warning should only be expected for the third argument: extern int foo(const int *a, const int b[], const int c[1]); int main (void) { foo ((int*)2, (int*)2, (int*2)); } The warning in this instance is issued because functions that take const array parameters with non-zero bound are assumed to read as many elements from the parameters as the bound indicates. Because (int*)2 is not a pointer to an array with at least two elements (or a valid pointer at all), the warning triggers. (Note that using invalid pointers like (int*)2 in any expression, including assigning them to function parameters, is undefined and may be diagnosed in the future regardless of the context they're used in, including in in arguments 1 and 2 above.)
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #67 from Eric Botcazou --- > Note that, as before, .text.startup is present in gcc-10 but missing in > gcc-11 crtend.o. That's expected if you compile with -Og or -O1, i.e. it requires -O2 or above.
[Bug go/102813] gccgo ICE when build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102813 --- Comment #2 from cqwrteur --- Created attachment 51623 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51623&action=edit config.log
[Bug target/102761] [10/11/12 Regression] ICE with -O1 and above: in ix86_print_operand_address_as due to %a0 and if_then_else and X constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102761 --- Comment #3 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:4abc0c196b10251dc80d0743ba9e8ab3e56c61ed commit r12-4484-g4abc0c196b10251dc80d0743ba9e8ab3e56c61ed Author: Uros Bizjak Date: Mon Oct 18 17:03:28 2021 +0200 i386: Fix ICE in ix86_print_opreand_address [PR 102761] 2021-10-18 Uroš Bizjak PR target/102761 gcc/ChangeLog: * config/i386/i386.c (ix86_print_operand_address): Error out for non-address_operand asm operands. gcc/testsuite/ChangeLog: * gcc.target/i386/pr102761.c: New test.
[Bug tree-optimization/102796] [12 Regresson] ICE in useless_type_conversion_p at gcc/gimple-expr.c:87 since r12-4443-g93ac832f1846e4867aa6537f76f510fab8e3e87d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102796 Andrew Pinski changed: What|Removed |Added CC||unlvsur at live dot com --- Comment #5 from Andrew Pinski --- *** Bug 102813 has been marked as a duplicate of this bug. ***
[Bug go/102813] gccgo ICE when build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102813 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 102796 ***
[Bug go/102813] New: gccgo ICE when build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102813 Bug ID: 102813 Summary: gccgo ICE when build Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: unlvsur at live dot com CC: cmang at google dot com Target Milestone: --- inux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -minline-all-stringops -O2 -g -m32 -I . -c -fgo-pkgpath=cmd/go/internal/get ../../../../../../gcc/libgo/go/cmd/go/internal/get/get.go -o cmd/go/internal/get.o during GIMPLE pass: evrp In function 'cmd/go/internal/modget.resolver.resolveQueries': go1: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 0x863cdf tree_class_check_failed(tree_node const*, tree_code_class, char const*, int, char const*) ../../../../gcc/gcc/tree.c:8739 0x791f66 tree_class_check(tree_node*, tree_code_class, char const*, int, char const*) ../../../../gcc/gcc/tree.h:3556 0x791f66 useless_type_conversion_p(tree_node*, tree_node*) ../../../../gcc/gcc/gimple-expr.c:87 0xf742f8 verify_gimple_phi ../../../../gcc/gcc/tree-cfg.c:5128 0xf742f8 verify_gimple_in_cfg(function*, bool) ../../../../gcc/gcc/tree-cfg.c:5457 0xe472a7 execute_function_todo ../../../../gcc/gcc/passes.c:2042 0xe47cce execute_todo ../../../../gcc/gcc/passes.c:2096 Please submit a full bug report, with preprocessed source if appropriate.
[Bug tree-optimization/102329] pointer "maybe uninitialized" right after assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102329 Florian Weimer changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=28458 --- Comment #7 from Florian Weimer --- We need to suppress this warning for pthread_setspecific in glibc because it is incorrect there. There is currently no good way to implement that suppression unfortunately.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #66 from Óscar Fuentes --- (In reply to Eric Botcazou from comment #65) > Thanks. Do you still have this line: > > r .eh_frame > > for crtend.o of the GCC 10 compiler after the grep mess was resolved? Do > you have the same line for the crtend.o of the GCC 11 compiler? The problem with grep didn't affect my gcc 10 install because it was built with grep 3.0, so crtend.o didn't change. Here it is again for completeness: $ for f in `find /mingw32 -name crtend.o` ; do echo $f && nm $f ; done /mingw32/lib/gcc/i686-w64-mingw32/10.3.0/crtend.o b .bss d .ctors.65535 d .data r .eh_frame r .rdata$zzz t .text t .text.startup r ___FRAME_END__ U ___gcc_register_frame t _register_frame_ctor Now, these are the crtend.o created in the gcc 11.2 build directory before it failed at a-except.o (this is also with grep 3.0, while in comment#29 was with the botched grep 3.6, but I see no differences): $ for f in `find /d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32 -name crtend.o` ; do echo $f && nm $f ; done /d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/prev-gcc/crtend.o b .bss d .ctors.65535 d .data r .eh_frame r .rdata$zzz t .text r ___FRAME_END__ U ___gcc_register_frame t _register_frame_ctor /d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/prev-i686-w64-mingw32/libgcc/crtend.o b .bss d .ctors.65535 d .data r .eh_frame r .rdata$zzz t .text r ___FRAME_END__ U ___gcc_register_frame t _register_frame_ctor Note that, as before, .text.startup is present in gcc-10 but missing in gcc-11 crtend.o.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #65 from Eric Botcazou --- > Searching for HAVE_LD_RO_RW_SECTION_MIXING in the build directory used for > extracting the previous gdb backtraces shows this: > > gcc/auto-host.h:1684:11:/* #undef HAVE_LD_RO_RW_SECTION_MIXING */ Thanks. Do you still have this line: r .eh_frame for crtend.o of the GCC 10 compiler after the grep mess was resolved? Do you have the same line for the crtend.o of the GCC 11 compiler?
[Bug gcov-profile/102746] gcov returns 0 un erroneuos incovation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102746 --- Comment #9 from Илья Шипицин --- ok, so we'll migrate to gcc-12 :)
[Bug gcov-profile/102746] gcov returns 0 un erroneuos incovation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102746 --- Comment #8 from Martin Liška --- (In reply to Илья Шипицин from comment #7) > wow. thanks for that. > > btw, will it be "gcc-12 only" or it is going to be backported (I'm > interested in gcc-8) ? No, I'm not planning backporting that as it's quite a change in functionality. Note gcc-8 is out of support: https://gcc.gnu.org/
[Bug gcov-profile/102746] gcov returns 0 un erroneuos incovation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102746 --- Comment #7 from Илья Шипицин --- wow. thanks for that. btw, will it be "gcc-12 only" or it is going to be backported (I'm interested in gcc-8) ?
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #64 from Óscar Fuentes --- Searching for HAVE_LD_RO_RW_SECTION_MIXING in the build directory used for extracting the previous gdb backtraces shows this: gcc/auto-host.h:1684:11:/* #undef HAVE_LD_RO_RW_SECTION_MIXING */
[Bug target/102812] New: Unoptimal (and wrong) code for _Float16 insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102812 Bug ID: 102812 Summary: Unoptimal (and wrong) code for _Float16 insert Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com Target Milestone: --- Following code: --cut here-- typedef _Float16 v8hf __attribute__((__vector_size__ (16))); v8hf t (_Float16 a) { return (v8hf){a, 0, 0, 0, 0, 0, 0, 0}; } --cut here-- compiles with -msse4 to: pxor%xmm15, %xmm15 movaps %xmm15, -56(%rsp) pextrw $0, %xmm0, -56(%rsp) vmovdqa64 -56(%rsp), %xmm0 PBLWNDW with cleared %xmm15 would be much more optimal, and wouldn't use memory. Also, VMOVDQA64 is an AVX512F/AVX512VL, not a SSE4 (not even AVX) instruction.
[Bug target/102811] vcvtph2ps and vcvtps2ph should be used to convert _Float16 to SFmode with -mf16c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811 --- Comment #2 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #1) > vxorps %xmm1, %xmm1, %xmm1 > vblendps %xmm1, %xmm1, %xmm0, $1 > vcvtps2ph %xmm0, %xmm1 vmovss %xmm1, %xmm1, %xmm0 instead of vblendps would also do the trick.
[Bug target/26915] missed sized opt returning -1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26915 --- Comment #8 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:247c407c83f0015f4b92d5f71e45b63192f6757e commit r12-4475-g247c407c83f0015f4b92d5f71e45b63192f6757e Author: Roger Sayle Date: Mon Oct 18 12:15:40 2021 +0100 Try placing RTL folded constants in the constant pool. My recent attempts to come up with a testcase for my patch to evaluate ss_plus in simplify-rtx.c, identified a missed optimization opportunity (that's potentially a long-time regression): The RTL optimizers no longer place constants in the constant pool. The motivating x86_64 example is the simple program: typedef char v8qi __attribute__ ((vector_size (8))); v8qi foo() { v8qi tx = { 1, 0, 0, 0, 0, 0, 0, 0 }; v8qi ty = { 2, 0, 0, 0, 0, 0, 0, 0 }; v8qi t = __builtin_ia32_paddsb(tx, ty); return t; } which (with my previous patch) currently results in: foo:movq.LC0(%rip), %xmm0 movq.LC1(%rip), %xmm1 paddsb %xmm1, %xmm0 ret even though the RTL contains the result in a REG_EQUAL note: (insn 7 6 12 2 (set (reg:V8QI 83) (ss_plus:V8QI (reg:V8QI 84) (reg:V8QI 85))) "ssaddqi3.c":7:12 1419 {*mmx_ssaddv8qi3} (expr_list:REG_DEAD (reg:V8QI 85) (expr_list:REG_DEAD (reg:V8QI 84) (expr_list:REG_EQUAL (const_vector:V8QI [ (const_int 3 [0x3]) (const_int 0 [0]) repeated x7 ]) (nil) Together with the patch below, GCC will now generate the much more sensible: foo:movq.LC2(%rip), %xmm0 ret My first approach was to look in cse.c (where the REG_EQUAL note gets added) and notice that the constant pool handling functionality has been unreachable for a while. A quick search for constant_pool_entries_cost shows that it's initialized to zero, but never set to a non-zero value, meaning that force_const_mem is never called. This functionality used to work way back in 2003, but has been lost over time: https://gcc.gnu.org/pipermail/gcc-patches/2003-October/116435.html The changes to cse.c below restore this functionality (placing suitable constants in the constant pool) with two significant refinements; (i) it only attempts to do this if the function already uses a constant pool (thanks to the availability of crtl->uses_constant_pool since 2003). (ii) it allows different constants (i.e. modes) to have different costs, so that floating point "doubles" and 64-bit, 128-bit, 256-bit and 512-bit vectors don't all have the share the same cost. Back in 2003, the assumption was that everything in a constant pool had the same cost, hence the global variable constant_pool_entries_cost. Although this is a useful CSE fix, it turns out that it doesn't cure my motivating problem above. CSE only considers a single instruction, so determines that it's cheaper to perform the ss_plus (COSTS_N_INSNS(1)) than read the result from the constant pool (COSTS_N_INSNS(2)). It's only when the other reads from the constant pool are also eliminated, that this transformation is a win. Hence a better place to perform this transformation is in combine, where after failing to "recog" the load of a suitable constant, it can retry after calling force_const_mem. This achieves the desired transformation and allows the backend insn_cost call-back to control whether or not using the constant pool is preferrable. Alas, it's rare to change code generation without affecting something in GCC's testsuite. On x86_64-pc-linux-gnu there were two families of new failures (and I'd predict similar benign fallout on other platforms). One failure was gcc.target/i386/387-12.c (aka PR target/26915), where the test is missing an explicit -m32 flag. On i686, it's very reasonable to materialize -1.0 using "fld1; fchs", but on x86_64-pc-linux-gnu we currently generate the awkward: testm1: fld1 fchs fstpl -8(%rsp) movsd -8(%rsp), %xmm0 ret which combine now very reasonably simplifies to just: testm1: movsd .LC3(%rip), %xmm0 ret The other class of x86_64-pc-linux-gnu failure was from materialization of vector constants using vpbroadcast (e.g. gcc.target/i386/pr90773-17.c) where the decision is finely balanced; the load of an integer register with an immediate constant, followed by a vpbroadcast is deemed to be COSTS_N_INSNS(2), whereas a load from the constant pool is also reported as COSTS_N_INSNS(2). My solution is to tweak the i386.c's rtx_costs so that all other things being equal, an instruction (sequence) that accesses memory is fractio
[Bug target/102811] vcvtph2ps and vcvtps2ph should be used to convert _Float16 to SFmode with -mf16c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811 --- Comment #1 from Uroš Bizjak --- Something like (argument and result in %xmm0): vpxor %xmm1, %xmm1, %xmm1 vpblendw %xmm1, %xmm1, %xmm0, $1 vcvtph2ps %xmm0, %xmm1 instead of __extendhfsf2 and: vxorps %xmm1, %xmm1, %xmm1 vblendps %xmm1, %xmm1, %xmm0, $1 vcvtps2ph %xmm0, %xmm1 instead of __truncsfhf2.
[Bug gcov-profile/102747] gcov returns 0 when invoked on gcda generated by previous gcc version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102747 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Martin Liška --- Fixed on master.
[Bug gcov-profile/102746] gcov returns 0 un erroneuos incovation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102746 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Martin Liška --- Fixed on master.
[Bug gcov-profile/102746] gcov returns 0 un erroneuos incovation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102746 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:815f15d3384edbdd73cc54536f30947e15183151 commit r12-4474-g815f15d3384edbdd73cc54536f30947e15183151 Author: Martin Liska Date: Mon Oct 18 11:30:55 2021 +0200 gcov: return proper exit code when error happens PR gcov-profile/102746 PR gcov-profile/102747 gcc/ChangeLog: * gcov.c (main): Return return_code. (output_gcov_file): Mark return_code when error happens. (generate_results): Likewise. (read_graph_file): Likewise. (read_count_file): Likewise.
[Bug gcov-profile/102747] gcov returns 0 when invoked on gcda generated by previous gcc version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102747 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:815f15d3384edbdd73cc54536f30947e15183151 commit r12-4474-g815f15d3384edbdd73cc54536f30947e15183151 Author: Martin Liska Date: Mon Oct 18 11:30:55 2021 +0200 gcov: return proper exit code when error happens PR gcov-profile/102746 PR gcov-profile/102747 gcc/ChangeLog: * gcov.c (main): Return return_code. (output_gcov_file): Mark return_code when error happens. (generate_results): Likewise. (read_graph_file): Likewise. (read_count_file): Likewise.
[Bug tree-optimization/102809] [12 Regression] Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102809 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |12.0 Summary|Some TSVC benchmarks are|[12 Regression] Some TSVC |slower after|benchmarks are slower after |r12-4195-gec0124e0acb556cd |r12-4195-gec0124e0acb556cd
[Bug tree-optimization/102788] [11 Regression] Wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102788 Richard Biener changed: What|Removed |Added Target Milestone|12.0|11.3 Known to work||12.0 Summary|[12 Regression] Wrong code |[11 Regression] Wrong code |with -O3|with -O3 Priority|P1 |P2 --- Comment #8 from Richard Biener --- Fixed on trunk but the issue is latent since the introduction of the forwprop pattern. I'm considering backporting to GCC 11.
[Bug target/102811] New: vcvtph2ps and vcvtps2ph should be used to convert _Float16 to SFmode with -mf16c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811 Bug ID: 102811 Summary: vcvtph2ps and vcvtps2ph should be used to convert _Float16 to SFmode with -mf16c Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com Target Milestone: --- The following testcase: _Float16 test (_Float16 a, _Float16 b) { return a + b; } compiles with -O2 -mf16c to: --cut here-- subq$24, %rsp pextrw $0, %xmm1, 14(%rsp) call__extendhfsf2 pinsrw $0, 14(%rsp), %xmm1 vmovss %xmm0, 8(%rsp) vmovss %xmm1, %xmm1, %xmm0 call__extendhfsf2 vaddss 8(%rsp), %xmm0, %xmm0 call__truncsfhf2 addq$24, %rsp ret --cut here-- Instead of calling __extendhfsf2 and __truncsfhf2, we should use vcvtph2ps and vcvtps2ph (with zeroed elements 1..3) for -m16c targets.
[Bug tree-optimization/102788] [12 Regression] Wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102788 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:eb032893675afea4b01cc6ad06a3e0dcfe9b51cd commit r12-4472-geb032893675afea4b01cc6ad06a3e0dcfe9b51cd Author: Richard Biener Date: Mon Oct 18 10:31:19 2021 +0200 tree-optimization/102788 - avoid spurious bool pattern fails Bool pattern recog is required for correctness since vectorized compares otherwise produce -1 for true so any context where bool is used as value and not as condition or mask needs to be replaced with CMP ? 1 : 0. When we fail to find a vector type for the result of such use we may not simply elide such transform since a new bool result can emerge when for example the cast_forwprop pattern is applied. So the following avoids failing of the bool pattern recog process and instead not assign a vector type for the stmt. 2021-10-18 Richard Biener PR tree-optimization/102788 * tree-vect-patterns.c (vect_init_pattern_stmt): Allow a NULL vectype. (vect_pattern_recog_1): Likewise. (vect_recog_bool_pattern): Continue matching the pattern even if we do not have a vector type for a conversion result. * g++.dg/vect/pr102788.cc: New testcase.
[Bug tree-optimization/102809] Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102809 --- Comment #3 from Aldy Hernandez --- (In reply to Martin Liška from comment #2) > > Does this fix the problem? > > Yes, it helps! Thank you for the patch. Thanks for all your help here, and sorry for all the noise. Getting the jump threading restrictions in the presence of loops has been chore. It seems we have finally agreed on what should be allowed, and Jeff is about to approve the last bits. Unfortunately, the next step is playing with the pipeline to see if we can remove some threading passes. This will probably unsettle things, but hopefully not as much. Again, thanks.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #63 from Arnaud Charlet --- (In reply to Eric Botcazou from comment #62) > > No need to, there are actually several reasons to not rely on exception > > propagation during bootstrap, so let's restore this invariant instead, I'm > > testing a change to that effect. > > Fair enough. In any case, the symptoms are again consistent with a lack of > registration of unwind tables, this time for libgcc, so this might be the > same underlying issue as the grep-induced mess for GCC 10. My hunch would > point to a constructor section merging issue in the linker, maybe related > to the GCC configure check for HAVE_LD_RO_RW_SECTION_MIXING, which should > fail for MinGW and may incorrectly succeed when things go wrong. Right, that's most likely the underlying issue and indeed ensuring we don't use exception propagation during the bootstrap is just a way to hide/avoid this underlying mismatch.
[Bug tree-optimization/102809] Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102809 --- Comment #2 from Martin Liška --- > Does this fix the problem? Yes, it helps! Thank you for the patch.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #62 from Eric Botcazou --- > No need to, there are actually several reasons to not rely on exception > propagation during bootstrap, so let's restore this invariant instead, I'm > testing a change to that effect. Fair enough. In any case, the symptoms are again consistent with a lack of registration of unwind tables, this time for libgcc, so this might be the same underlying issue as the grep-induced mess for GCC 10. My hunch would point to a constructor section merging issue in the linker, maybe related to the GCC configure check for HAVE_LD_RO_RW_SECTION_MIXING, which should fail for MinGW and may incorrectly succeed when things go wrong.
[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675 --- Comment #8 from Jonathan Wakely --- (In reply to Jay Feldblum from comment #7) > The caveat, not to pollute `bits/c++config` with `#include really */>`. Are there more caveats to be aware of? No, that's it. The additional overhead of calling a function defined in the library is not a problem, because we're aborting anyway. > > The suggestion, to export a helper routine that would work like `printf` but > emit to stderr. I can't tell whether that's a strong or weak preference. The > patch I went with - exporting a helper routine that returns the value of > `stderr` - is a bit smaller. But if that's not the preference then I can > change the patch. That seems OK. Another option would be to export the existing __snprintf_lite function and print into a buffer, then use ::write(2, ...) to output that. Either way requires adding a new export to the library. Using write has some other advantages, but means polluting the namespace (and isn't available on all targets) which isn't a problem with __builtin_printf or __builtin_fprintf. > Beyond the question of what helper routine to add, there is where to add it. > I cam e up with a guess but perhaps a better place will be suggested. src/c++98/compatibility.cc is definitely wrong, that's for symbols that are only retained for backwards compatibility with previous releases. Not for new symbols for new features. Patches should be sent to the libstdc++ and gcc-patches mailing lists for review though, rather than attached here. Thanks for working on this!
[Bug c/102810] New: Bogus Wstringop-overread warning when special (integer) pointer values passed to array parameter of a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102810 Bug ID: 102810 Summary: Bogus Wstringop-overread warning when special (integer) pointer values passed to array parameter of a function Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ian at abbott dot org Target Milestone: --- I don't know why this code produces a Wstringop-overread warning since it has nothing to do with string operations. Also, why is there a warning for argument 2, but not for argument 1? extern int foo(const int *a, const int b[]); #define SPECIAL ((int *)2) int main(void) { foo(SPECIAL, SPECIAL); } int foo(const int a[], const int b[]) { return 0; } : In function 'main': :7:5: warning: 'foo' reading 4 bytes from a region of size 0 [-Wstringop-overread] 7 | foo(SPECIAL, SPECIAL); | ^ :7:5: note: referencing argument 2 of type 'const int *' :10:5: note: in a call to function 'foo' 10 | int foo(const int a[], const int b[]) | ^~~
[Bug target/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 --- Comment #3 from Jakub Jelinek --- On the trunk, -O2 -fopenmp -mcpu=power6 -maltivec -m32 works fine, while -O2 -fopenmp -mcpu=power6 -mvsx -m32 is miscompiled too.
[Bug tree-optimization/102809] Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102809 --- Comment #1 from Aldy Hernandez --- There's a pending patch in this area that restricts loop threading: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581894.html Does this fix the problem?
[Bug target/93183] SVE does not use neg as conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93183 --- Comment #4 from CVS Commits --- The master branch has been updated by Prathamesh Kulkarni : https://gcc.gnu.org/g:20dcda98ed376cb61c74b2c71656f99c671ec9ce commit r12-4470-g20dcda98ed376cb61c74b2c71656f99c671ec9ce Author: prathamesh.kulkarni Date: Mon Oct 18 15:44:06 2021 +0530 [sve] PR93183 - Add support for conditional neg. gcc/ChangeLog: PR target/93183 * gimple-match-head.c (try_conditional_simplification): Add case for single operand. * internal-fn.def: Add entry for COND_NEG internal function. * internal-fn.c (FOR_EACH_CODE_MAPPING): Add entry for NEGATE_EXPR, COND_NEG mapping. * optabs.def: Add entry for cond_neg_optab. * match.pd (UNCOND_UNARY, COND_UNARY): New operator lists. (vec_cond COND (foo A) B) -> (IFN_COND_FOO COND A B): New pattern. (vec_cond COND B (foo A)) -> (IFN_COND_FOO ~COND A B): Likewise. gcc/testsuite/ChangeLog: PR target/93183 * gcc.target/aarch64/sve/cond_unary_4.c: Adjust. * gcc.target/aarch64/sve/pr93183.c: New test.
[Bug tree-optimization/102809] Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102809 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-10-18 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug tree-optimization/102809] New: Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102809 Bug ID: 102809 Summary: Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: aldyh at gcc dot gnu.org Target Milestone: --- Tested with https://github.com/UoB-HPC/TSVC_2/pull/2 where one can run a single benchmark. Happens with -Ofast -march=native on znver1 machine: gcc-bisect.py 'gcc *.c -lm -Ofast -march=native -fuse-ld=bfd && timeout 100.7 ./a.out va' -l -e r12-4194-g1f51e9af7b615838 -s r12-4195-gec0124e0acb556cd Bisecting latest revisions ec0124e0acb556cd(05 Oct 2021 18:24)(al...@redhat.com): [took: 7.050s] result: OK LoopTime(sec) Checksum va3.719 1.644725 1f51e9af7b615838(05 Oct 2021 16:47)(jwak...@redhat.com): [took: 5.433s] result: OK LoopTime(sec) Checksum va2.006 1.644725 and can be seen here: https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=14.920.0 https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=14.887.0 https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=14.943.0
[Bug target/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Component|libgomp |target Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-18 CC||dje at gcc dot gnu.org, ||segher at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Ok, I can reproduce, but only with -mcpu=power7. The cost model patch just uncovered a latent power7 vectorization bug (backend or vectorizer) I'd say. I've instrumented the testcase a little bit: // { dg-do run } // { dg-additional-options "-msse2" { target sse2_runtime } } // { dg-additional-options "-mavx" { target avx_runtime } } extern "C" void abort (); int a[1024] __attribute__((aligned (32))) = { 1 }; int b[1024] __attribute__((aligned (32))) = { 1 }; unsigned char c[1024] __attribute__((aligned (32))) = { 1 }; int k, m; __UINTPTR_TYPE__ u, u2, u3; __attribute__((noinline, noclone)) int foo (int *p) { int i, s = 0, s2 = 0, t, t2; #pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s) \ lastprivate (t2) for (i = 0; i < 512; i++) { a[i] *= p[i]; t2 = k + p[i]; k += m + 1; s += p[i] + k; c[i]++; } #pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s2) \ lastprivate (t, u, u2, u3) for (i = 512; i < 1024; i++) { a[i] *= p[i]; k += m + 1; t = k + p[i]; u = (__UINTPTR_TYPE__) &k; u2 = (__UINTPTR_TYPE__) &s2; u3 = (__UINTPTR_TYPE__) &t; s2 += t; c[i]++; } __builtin_printf ("foo %d %d %d %d\n", s, s2, t, t2); return s + s2 + t + t2; } __attribute__((noinline, noclone)) long int bar (int *p, long int n, long int o) { long int i, s = 0, s2 = 0, t, t2; #pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s) \ lastprivate (t2) for (i = 0; i < n; i++) { a[i] *= p[i]; t2 = k + p[i]; k += m + 1; s += p[i] + k; c[i]++; } #pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s2) \ lastprivate (t, u, u2, u3) for (i = n; i < o; i++) { a[i] *= p[i]; k += m + 1; t = k + p[i]; u = (__UINTPTR_TYPE__) &k; u2 = (__UINTPTR_TYPE__) &s2; u3 = (__UINTPTR_TYPE__) &t; s2 += t; c[i]++; } __builtin_printf ("bar %d %d %d %d\n", s, s2, t, t2); return s + s2 + t + t2; } int main () { #if __SIZEOF_INT__ >= 4 int i; k = 4; m = 2; for (i = 0; i < 1024; i++) { a[i] = i - 512; b[i] = (i - 51) % 39; c[i] = (unsigned char) i; } int s = foo (b); for (i = 0; i < 1024; i++) { if (b[i] != (i - 51) % 39 || a[i] != (i - 512) * b[i] || c[i] != (unsigned char) (i + 1)) { __builtin_printf ("#1 %d %d %d %d\n", i, b[i], a[i], c[i]); abort (); } a[i] = i - 512; } if (k != 4 + 3 * 1024 || s != 1596127 + (4 + 3 * 511 + b[511]) + (4 + 3 * 1024 + b[1023])) { __builtin_printf ("#2 %d %d\n", k, s); abort (); } k = 4; s = bar (b, 512, 1024); for (i = 0; i < 1024; i++) { if (b[i] != (i - 51) % 39 || a[i] != (i - 512) * b[i] || c[i] != (unsigned char) (i + 2)) { __builtin_printf ("#3 %d %d %d %d\n", i, b[i], a[i], c[i]); abort (); } a[i] = i - 512; } if (k != 4 + 3 * 1024 || s != 1596127 + (4 + 3 * 511 + b[511]) + (4 + 3 * 1024 + b[1023])) { __builtin_printf ("#4 %d %d\n", k, s); abort (); } k = 4; s = bar (b, 511, 1021); for (i = 0; i < 1021; i++) { if (b[i] != (i - 51) % 39 || a[i] != (i - 512) * b[i] || c[i] != (unsigned char) (i + 3)) { __builtin_printf ("#5 %d %d %d %d\n", i, b[i], a[i], c[i]); abort (); } a[i] = i - 512; } for (i = 1021; i < 1024; i++) if (b[i] != (i - 51) % 39 || a[i] != i - 512 || c[i] != (unsigned char) (i + 2)) { __builtin_printf ("#6 %d %d %d %d\n", i, b[i], a[i], c[i]); abort (); } if (k != 4 + 3 * 1021 || s != 1586803 + (4 + 3 * 510 + b[510]) + (4 + 3 * 1021 + b[1020])) { __builtin_printf ("#7 %d %d %d %d\n", k, s, b[510], b[1020]); abort (); } #endif return 0; } When compiled with -O2 -m32 -fopenmp -mcpu=power6, this prints: foo 403860 1192267 3112 1568 bar 403860 1192267 3112 1568 bar 402289 1184514 3100 1564 while with -O2 -m32 -fopenmp -mcpu=power7 it prints: foo 403860 1192267 3112 1568 bar 403860 1192267 3112 1568 bar 402289 919217 3100 1564 #7 3067 1326170 30 33 Aborted which seems to suggest it is the: #pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s2) \ lastprivate (t, u,
[Bug libstdc++/102807] Simple code using ranges::views::keys does not compile with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102807 Jonathan Wakely changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=44833 --- Comment #5 from Jonathan Wakely --- (In reply to Pilar Latiesa from comment #3) > I believe this is a consequence of Clang bug 44833. Ah yes, that's exactly it. Thanks!
[Bug libstdc++/102807] Simple code using ranges::views::keys does not compile with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102807 --- Comment #4 from Jonathan Wakely --- #include struct Range { int* begin() { return 0; } int* end() { return 0; } }; int main() { static_assert(std::ranges::range); using R = std::ranges::ref_view; static_assert( std::ranges::__cust_access::__member_begin ); } The problem happens when instantiating ref_view for any R. The view_interface> CRTP base class gets instantiated and that checks the constraints of its member functions, which depends on the derived class, which is incomplete at that point. I think this is a clang bug. It should not be checking the constraints for view_interface>::data() when checking satisfaction of range>.