[Bug lto/104895] lto1: issue with space in library filename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104895 --- Comment #3 from Andrew Pinski --- White spaces and even special characters will always be a problem with anything that interacts with make or the shell. I am not saying this is not a fixable issue, just fixing this might even require huge changes to way POSIX make works.
[Bug target/96787] rs6000 mcpu=power10 miscompiles libiberty htab_delete() causing bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96787 Andrew Pinski changed: What|Removed |Added Target Milestone|10.2|11.0
[Bug target/104894] [11/12 Regression] ICE with -fno-plt -mcpu=power10 on PowerPC64 LE Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894 Andrew Pinski changed: What|Removed |Added Target||powerpc64le-linux-gnu See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=96787 Target Milestone|--- |11.3 Summary|[ppc64le] gcc11 ICE with|[11/12 Regression] ICE with |-fno-plt|-fno-plt -mcpu=power10 on ||PowerPC64 LE Linux
[Bug fortran/104900] New: segfault with parameterized derived type with kind parameter and allocatable component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104900 Bug ID: 104900 Summary: segfault with parameterized derived type with kind parameter and allocatable component Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: a.shahmoradi at gmail dot com Target Milestone: --- Created attachment 52617 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52617=edit sample source code The attached file contains a is a valid Fortran standard program with parameterized derived types with kind type parameter (no len parameter) and an allocatable component. However, gfortran yields a runtime segfault with this code, ``` use, intrinsic :: iso_fortran_env!, only: real64, int64 integer, parameter :: RK1 = real_kinds(1) integer, parameter :: RK2 = real_kinds(2) type :: Container_type(RK) integer, kind :: RK = RK1 real(RK), allocatable :: value(:) end type type(Container_type(RK1)), allocatable :: List(:) interface wrap procedure :: wrap_RK1, wrap_RK2 end interface List = wrap([1.,2.,3.,4.,5.,6.]) print *, List(1)%value print *, List(2)%value contains function wrap_RK1(array) result(List) real(RK1), intent(in) :: array(:) type(Container_type(RK1)), allocatable :: List(:) allocate(List(2)) List(1)%value = array(1:size(array)/2) List(2)%value = array(size(array)/2 + 1 : size(array)) end function function wrap_RK2(array) result(List) real(RK2), intent(in) :: array(:) type(Container_type(RK2)), allocatable :: List(:) allocate(List(2)) List(1)%value = array(1:size(array)/2) List(2)%value = array(size(array)/2 + 1 : size(array)) end function end ``` Here is the error message, ``` Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7f1e57dcc8d2 in ??? #1 0x7f1e57dcba65 in ??? #2 0x7f1e57a430bf in ??? #3 0x401927 in wrap_rk1 at /app/example.f90:27 #4 0x4012f4 in MAIN__ at /app/example.f90:17 #5 0x401bfc in main at /app/example.f90:19 ``` There segfault happen where the automatic allocation of the `value` component occurs in the procedures. Here is an online test: https://godbolt.org/z/8n5fs44sa
[Bug testsuite/103324] RFE: Add a `make quickcheck` or `make smoketest` Makefile target to allow only running a portion of the testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103324 --- Comment #4 from Eric Gallager --- Another thing that would be useful would be to have (more) comments in the source code saying stuff like "/* this codepath is tested by */" or something... although I guess it could be a problem keeping them in sync...
[Bug target/104890] [12 Regression] fails to build the 32bit libgcc on x86_64-linux-gnu (--enable-default-pie)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104890 --- Comment #4 from Matthias Klose --- about the configure options, apparently pie is not the culprit, configuring with --enable-cet is. note that I didn't use --disable-bootstrap.
[Bug target/104890] [12 Regression] fails to build the 32bit libgcc on x86_64-linux-gnu (--enable-default-pie)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104890 Matthias Klose changed: What|Removed |Added Status|WAITING |NEW
[Bug target/104890] [12 Regression] fails to build the 32bit libgcc on x86_64-linux-gnu (--enable-default-pie)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104890 --- Comment #3 from Matthias Klose --- Created attachment 52616 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52616=edit preprocessed source /home/packages/gcc/12/gcc-12-12-20220313/build/./gcc/cc1 -E -quiet -v -I . -I . -I ../../.././gcc -I ../../../../src/libgcc - I ../../../../src/libgcc/. -I ../../../../src/libgcc/../gcc -I ../../../../src/libgcc/../include -I ../../../../src/libgcc/con fig/libbid -imultilib 32 -imultiarch i386-linux-gnu -iprefix /home/packages/gcc/12/gcc-12-12-20220313/build/gcc/../lib/gcc/x86 _64-linux-gnu/12/ -isystem /home/packages/gcc/12/gcc-12-12-20220313/build/./gcc/include -isystem /home/packages/gcc/12/gcc-12- 12-20220313/build/./gcc/include-fixed -MD unwind-dw2.d -MF unwind-dw2.dep -MP -MT unwind-dw2.o -D IN_GCC -D USE_ELF_SYMVER -D IN_LIBGCC2 -D USE_ELF_SYMVER -D ENABLE_DECIMAL_BID_FORMAT -D HAVE_CC_TLS -D USE_TLS -D HIDE_EXPORTS -isystem /usr/x86_64-linux -gnu/include -isystem /usr/x86_64-linux-gnu/sys-include -isystem /home/packages/gcc/12/gcc-12-12-20220313/build/sys-include -i system ./include ../../../../src/libgcc/unwind-dw2.c -m32 -mlong-double-80 -mshstk -mtune=generic -march=i686 -Wextra -Wall -W no-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -fchecking=1 -fcf-pro tection=full -fbuilding-libgcc -fno-stack-protector -fpic -fcf-protection=full -fexceptions -fvisibility=hidden -g -g -g -fwor king-directory -O2 -O2 -O2 -fpch-preprocess -fasynchronous-unwind-tables -o unwind-dw2.i In file included from /home/packages/gcc/12/gcc-12-12-20220313/build/gcc/include/x86gprintrin.h:45, from ../../../../src/libgcc/config/i386/shadow-stack-unwind.h:25, from ./md-unwind-support.h:27, from ../../../../src/libgcc/unwind-dw2.c:412: /home/packages/gcc/12/gcc-12-12-20220313/build/gcc/include/cetintrin.h: In function ‘_Unwind_RaiseException’: /home/packages/gcc/12/gcc-12-12-20220313/build/gcc/include/cetintrin.h:47:1: error: inlining failed in call to ‘always_inline’ ‘_get_ssp’: target specific option mismatch 47 | _get_ssp (void) | ^~~~ In file included from ../../../../src/libgcc/unwind-dw2.c:1728: ../../../../src/libgcc/unwind.inc:140:217: note: called from here 140 | uw_install_context (_context, _context, frames); | ^ /home/packages/gcc/12/gcc-12-12-20220313/build/gcc/include/cetintrin.h:55:1: error: inlining failed in call to ‘always_inline’ ‘_inc_ssp’: target specific option mismatch 55 | _inc_ssp (unsigned int __B) | ^~~~ ../../../../src/libgcc/unwind.inc:140:295: note: called from here 140 | uw_install_context (_context, _context, frames); | ^ /home/packages/gcc/12/gcc-12-12-20220313/build/gcc/include/cetintrin.h:55:1: error: inlining failed in call to ‘always_inline’ ‘_inc_ssp’: target specific option mismatch 55 | _inc_ssp (unsigned int __B) | ^~~~ ../../../../src/libgcc/unwind.inc:140:325: note: called from here 140 | uw_install_context (_context, _context, frames); | ^
[Bug translation/104552] Mistakes in strings to be translated in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 Eric Gallager changed: What|Removed |Added CC|amacleod at redhat dot com | --- Comment #39 from Eric Gallager --- (In reply to Roland Illig from comment #38) > (In reply to Roland Illig from comment #7) > > From params.opt: > > > --param=ranger-debug=[none|trace|gori|cache|tracegori|all] > > > Specifies the output mode for debugging ranger. > > > > Why " " instead of the usual "\t" after the "]"? > Everything is OK here, I wrongly thought that the usual separator in that > file were a tab. The other similar entries use a space as well. > > @egallager you can remove Andrew MacLeod from the CC list. ok, done
[Bug c++/98767] Function signature lost in concept diagnostic message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98767 Patrick Palka changed: What|Removed |Added Target Milestone|--- |12.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Patrick Palka --- Closing as fixed for GCC 12
[Bug c/104899] New: typo "cannott"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104899 Bug ID: 104899 Summary: typo "cannott" Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de CC: egallager at gcc dot gnu.org Target Milestone: --- in bfin.cc and range-op.cc This typo doesn't appear in any tests so it should be trivial to fix.
[Bug target/104898] New: missing %q in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104898 Bug ID: 104898 Summary: missing %q in diagnostic Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de CC: egallager at gcc dot gnu.org, sje at gcc dot gnu.org Target Milestone: --- Target: aarch64 >From aarch64.cc: > invalid feature modifier %s The %s should be %qs, like in the related messages. The parentheses in "(%qs)" look redundant. They are only used 18 times in total, in the whole tree. For comparison, "%qs" is used more than 2700 times in the whole tree. I would remove the parentheses.
[Bug target/104897] New: wrong plural form in diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104897 Bug ID: 104897 Summary: wrong plural form in diagnostic Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de CC: egallager at gcc dot gnu.org, rsandifo at gcc dot gnu.org Target Milestone: --- Target: aarch64 >From aarch64-sve-builtins.cc: > error_at (location, "passing single vector %qT to argument %d" > " of %qE, which expects a tuple of %d vectors", > actual, argno + 1, fndecl, num_vectors); "%d vectors" must use the correct plural form, for the benefit of Polish, Russian, Arabic and several more. => Richard Sandiford's string (https://gcc.gnu.org/g:624d0f07) "%d vectors" appears twice in this file.
[Bug translation/104552] Mistakes in strings to be translated in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 --- Comment #38 from Roland Illig --- (In reply to Roland Illig from comment #7) > From params.opt: > > --param=ranger-debug=[none|trace|gori|cache|tracegori|all] > > Specifies the output mode for debugging ranger. > > Why " " instead of the usual "\t" after the "]"? Everything is OK here, I wrongly thought that the usual separator in that file were a tab. The other similar entries use a space as well. @egallager you can remove Andrew MacLeod from the CC list.
[Bug c/104896] New: Messages use %<%s%> instead of the idiomatic %qs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104896 Bug ID: 104896 Summary: Messages use %<%s%> instead of the idiomatic %qs Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de CC: egallager at gcc dot gnu.org, msebor at gcc dot gnu.org Target Milestone: --- As of 2022-03-12, the GCC tree contains 44 instances of the string "%<%s%>". Please have a look whether they can be replaced with the idiomatic %qs, and if not, document them.
[Bug lto/104895] lto1: issue with space in library filename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104895 --- Comment #2 from Christoph Müllner --- Further analysis shows that '-flto=1' works as well and '-flto=16' fails as well. This brings us right to the spot: Bad: [...] make -f /tmp/ccyzs8VX.mk -j16 all Using built-in specs. [...] Good: [...] gcc @/tmp/cclqDb0Y Using built-in specs. [...] Let's look deeper: $ mkdir tmpdir $ export TEMP=$(pwd)/tmpdir/ $ gcc -v -fPIC -flto=16 -shared -Wl,-soname,"lib'do it'.so" -o "lib'do it'.so" doit.o -save-temps $ cat tmpdir/ccM8aNK8.mk ./lib'do it'.so.ltrans0.ltrans.o: @gcc '-xlto' '-c' '-fno-openmp' '-fno-openacc' '-fcf-protection=none' '-mtune=generic' '-march=x86-64' '-fPIC' '-v' '-fPIC' '-shared' '-save-temps' '-mtune=generic' '-march=x86-64' '-dumpdir' 'lib'do it'.so.' '-dumpbase' './lib'do it'.so.ltrans0.ltrans' '-fltrans' '-o' './lib'do it'.so.ltrans0.ltrans.o' './lib'do it'.so.ltrans0.o' .PHONY: all all: \ ./lib'do it'.so.ltrans0.ltrans.o The invocation of GCC will be: gcc '-xlto' '-c' '-fno-openmp' '-fno-openacc' '-fcf-protection=none' '-mtune=generic' '-march=x86-64' '-fPIC' '-v' '-fPIC' '-save-temps' '-shared' '-mtune=generic' '-march=x86-64' '-dumpdir' 'libdon't do it.so.' '-dumpbase' './libdon't do it.so.ltrans0.ltrans' '-fltrans' '-o' './libdon't do it.so.ltrans0.ltrans.o' './libdon't do it.so.ltrans0.o' And here we see the issue! The options are each quoted with '-characters. But the filename itself contains these characters as well, which will terminate the string. The space between the '-characters will therefore be interpreted as a separator. One thing to mention is that GNU Make has limitations how to handle spaces: http://savannah.gnu.org/bugs/?712
[Bug c++/104641] Deduction guide for member template class rejected at class scope when used with typename dependant type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104641 Patrick Palka changed: What|Removed |Added Target Milestone|--- |12.0 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Patrick Palka --- Fixed for GCC 12.
[Bug c++/104622] [12 Regression] ICE in compare_ics, at cp/call.cc:11419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104622 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Patrick Palka --- Fixed.
[Bug c++/104527] [11 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104527 Patrick Palka changed: What|Removed |Added Summary|[11/12 Regression] ICE: |[11 Regression] ICE: tree |tree check: accessed elt 1 |check: accessed elt 1 of |of 'tree_vec' with 0 elts |'tree_vec' with 0 elts in |in hash, at |hash, at |cp/constraint.cc:2486 |cp/constraint.cc:2486 --- Comment #3 from Patrick Palka --- Fixed for GCC 12 so far.
[Bug c++/98644] [10/11 Regression] [concepts] ICE in satisfaction_value, at cp/constraint.cc:2825
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98644 Patrick Palka changed: What|Removed |Added Summary|[10/11/12 Regression] |[10/11 Regression] |[concepts] ICE in |[concepts] ICE in |satisfaction_value, at |satisfaction_value, at |cp/constraint.cc:2825 |cp/constraint.cc:2825 --- Comment #5 from Patrick Palka --- Fixed (finally) for GCC 12 so far.
[Bug c++/104641] Deduction guide for member template class rejected at class scope when used with typename dependant type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104641 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:d3b0dc686c00bfe9e7f4fe0490def68e9b92157a commit r12-7633-gd3b0dc686c00bfe9e7f4fe0490def68e9b92157a Author: Patrick Palka Date: Sat Mar 12 15:00:51 2022 -0500 c++: naming a dependently-scoped template for CTAD [PR104641] In order to be able to perform CTAD for a dependently-scoped template (such as A::B in the testcase below), we need to permit a typename-specifier to resolve to a template as per [dcl.type.simple]/3, at least when it appears in a CTAD-enabled context. This patch implements this using a new tsubst flag tf_tst_ok to control when a TYPENAME_TYPE is allowed to name a template, and sets this flag when substituting into the type of a CAST_EXPR, CONSTRUCTOR or VAR_DECL (each of which is a CTAD-enabled context). PR c++/104641 gcc/cp/ChangeLog: * cp-tree.h (tsubst_flags::tf_tst_ok): New flag. * decl.cc (make_typename_type): Allow a typename-specifier to resolve to a template when tf_tst_ok, in which case return a CTAD placeholder for the template. * pt.cc (tsubst_decl) : Set tf_tst_ok when substituting the type. (tsubst): Clear tf_tst_ok and remember if it was set. : Pass tf_tst_ok to make_typename_type appropriately. (tsubst_copy) : Set tf_tst_ok when substituting the type. (tsubst_copy_and_build) : Likewise. : Likewise. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/class-deduction107.C: New test.
[Bug c++/104622] [12 Regression] ICE in compare_ics, at cp/call.cc:11419
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104622
--- Comment #3 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:03c83cf7aa1110e427beb00ea95767dfaf50d694
commit r12-7632-g03c83cf7aa1110e427beb00ea95767dfaf50d694
Author: Patrick Palka
Date: Sat Mar 12 15:00:49 2022 -0500
c++: ICE with bad conversion shortcutting [PR104622]
When shortcutting bad argument conversions during overload resolution,
we assume conversions get computed in sequential order and that therefore
the conversion array is incomplete iff the last conversion is missing.
But this assumption turns out to be wrong for templates, because during
deduction check_non_deducible_conversion can compute an argument
conversion out of order.
So in the testcase below, at the end of add_template_candidate the
conversion array looks like {bad_conv, NULL, good_conv} where the last
conversion was computed during deduction and the first one later from
add_function_candidate. We need to add this candidate to bad_fns since
not all of its argument conversions were computed, but we don't do so
because the last conversion isn't missing.
This patch fixes this by checking for a missing conversion exhaustively
instead. In passing, this cleans up check_non_deducible_conversion given
that the only values of 'strict' we expect to see here the enumerators
of unification_kind_t.
PR c++/104622
gcc/cp/ChangeLog:
* call.cc (missing_conversion_p): Define.
(add_candidates): Use it.
* pt.cc (check_non_deducible_conversion): Change type of strict
parameter to unification_kind_t and directly test for DEDUCE_CALL.
gcc/testsuite/ChangeLog:
* g++.dg/template/conv18.C: New test.
[Bug c++/104527] [11/12 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104527 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:9413bb55185b9e88d84e91d5145d59f9f83b884a commit r12-7631-g9413bb55185b9e88d84e91d5145d59f9f83b884a Author: Patrick Palka Date: Sat Mar 12 15:00:40 2022 -0500 c++: return-type-req in constraint using only outer tparms [PR104527] Here the template context for the atomic constraint has two levels of template parameters, but since it depends only on the innermost parameter T we use a single-level argument vector (built by get_mapped_args) during substitution into the atom. We eventually pass this vector to do_auto_deduction as part of checking the return-type-requirement within the atom, but do_auto_deduction expects outer_targs to be a full set of arguments for sake of satisfaction. This patch fixes this by making get_mapped_args always return an argument vector whose depth corresponds to the template depth of the context in which the atomic constraint expression was written, instead of the highest parameter level that the expression happens to use. PR c++/104527 gcc/cp/ChangeLog: * constraint.cc (normalize_atom): Set ATOMIC_CONSTR_EXPR_FROM_CONCEPT_P appropriately. (get_mapped_args): Make static, adjust parameters. Always return a vector whose depth corresponds to the template depth of the context of the atomic constraint expression. Micro-optimize by passing false as exact to safe_grow_cleared and by collapsing a multi-level depth-one argument vector. (satisfy_atom): Adjust call to get_mapped_args and diagnose_atomic_constraint. (diagnose_atomic_constraint): Replace map parameter with an args parameter. * cp-tree.h (ATOMIC_CONSTR_EXPR_FROM_CONCEPT_P): Define. (get_mapped_args): Remove declaration. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-return-req4.C: New test.
[Bug c++/98644] [10/11/12 Regression] [concepts] ICE in satisfaction_value, at cp/constraint.cc:2825
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98644 --- Comment #4 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:ab71d3fe4b23af4c29a8d6fcf1e914fed4393e3b commit r12-7630-gab71d3fe4b23af4c29a8d6fcf1e914fed4393e3b Author: Patrick Palka Date: Sat Mar 12 14:57:59 2022 -0500 c++: ICE with non-constant satisfaction value [PR98644] Here during satisfaction, the expression of the atomic constraint after substitution is (int *) NON_LVALUE_EXPR <1> != 0B, which is not a C++ constant expression due to the reinterpret_cast, but TREE_CONSTANT is set since its value is otherwise effectively constant. We then call maybe_constant_value on it, which proceeds via its fail-fast path to exit early without clearing TREE_CONSTANT. But satisfy_atom relies on checking TREE_CONSTANT of the result of maybe_constant_value in order to detect non-constant satisfaction. This patch fixes this by making the fail-fast path of maybe_constant_value clear TREE_CONSTANT in this case, like cxx_eval_outermost_constant_expr in the normal path would have done. PR c++/98644 gcc/cp/ChangeLog: * constexpr.cc (mark_non_constant): Define, split out from ... (cxx_eval_outermost_constant_expr): ... here. (maybe_constant_value): Use it. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-pr98644.C: New test. * g++.dg/parse/array-size2.C: Remove expected diagnostic about a narrowing conversion. Co-authored-by: Jason Merrill
[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104853 --- Comment #7 from rvalue --- Well, I've found something that could be problematic here: https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/riscv/arch-canonicalize;h=49a6204b9cb64cb0e375c6003c423bf115a0a8a6;hb=HEAD#l60 It's never updated in ISA spec version bumping.
[Bug middle-end/104885] ICE in compiling new test case g++.dg/other/pr84964.C after r12-7607-ga717376e99fb33
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104885 Roger Sayle changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-03-12 CC||roger at nextmovesoftware dot com Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com --- Comment #1 from Roger Sayle --- Patch proposed. https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591665.html
[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104853 --- Comment #6 from rvalue --- I've got some verbose output from gcc, and it seems that a duplicate `-march` is passed to `as` $ gcc -c test.c -march=rv64g --verbose Using built-in specs. COLLECT_GCC=/usr/sbin/gcc Target: riscv64-unknown-linux-gnu Configured with: /build/gcc/src/gcc/configure --enable-languages=c,c++,fortran,go,lto,objc,obj-c++,d --enable-bootstrap --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-linker-build-id --enable-lto --disable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-werror --with-build-config=bootstrap-lto --enable-link-serialization=1 gdc_include_dir=/usr/include/dlang/gdc Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.2.0 (GCC) COLLECT_GCC_OPTIONS='-c' '-march=rv64g' '-v' '-mabi=lp64d' '-march=rv64imafd' /usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/cc1 -quiet -v test.c -quiet -dumpbase test.c -dumpbase-ext .c -march=rv64g -mabi=lp64d -march=rv64imafd -version -o /tmp/ccCK3sIZ.s GNU C17 (GCC) version 11.2.0 (riscv64-unknown-linux-gnu) compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version 4.1.0-p13, MPC version 1.2.1, isl version isl-0.24-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/../../../../riscv64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/include /usr/local/include /usr/lib/gcc/riscv64-unknown-linux-gnu/11.2.0/include-fixed /usr/include End of search list. GNU C17 (GCC) version 11.2.0 (riscv64-unknown-linux-gnu) compiled by GNU C version 11.2.0, GMP version 6.2.1, MPFR version 4.1.0-p13, MPC version 1.2.1, isl version isl-0.24-GMP GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 42e88359d8058cfa8524073dbb277472 COLLECT_GCC_OPTIONS='-c' '-march=rv64g' '-v' '-mabi=lp64d' '-march=rv64imafd' as -v --traditional-format -fpic -march=rv64g -march=rv64imafd -mabi=lp64d -o test.o /tmp/ccCK3sIZ.s GNU assembler version 2.38 (riscv64-unknown-linux-gnu) using BFD version (GNU Binutils) 2.38 test.c: Assembler messages: test.c:2: Error: unrecognized opcode `fence.i'
[Bug lto/104895] lto1: issue with space in library filename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104895 --- Comment #1 from Christoph Müllner --- Compiling with '-v' shows the following differences: BAD: gcc -v -fPIC -flto=auto -shared -Wl,-soname,"lib'do it'.so" -o "lib'do it'.so" doit.o [...] COLLECT_GCC_OPTIONS='-v' '-fPIC' '-flto=auto' '-shared' '-o' 'lib'\''do it'\''.so' '-mtune=generic' '-march=x86-64' '-dumpdir' 'lib'\''do it'\''.so.' [...] COLLECT_GCC_OPTIONS='-c' '-fno-openmp' '-fno-openacc' '-fcf-protection=none' '-v' '-fPIC' '-shared' '-mtune=generic' '-march=x86-64' '-fltrans-output-list=/tmp/ccfiSKsT.ltrans.out' '-fwpa=16' '-fresolution=/tmp/ccOyShqf.res' '-flinker-output=dyn' [...] COLLECT_GCC_OPTIONS='-c' '-fno-openmp' '-fno-openacc' '-fcf-protection=none' '-v' '-fPIC' '-shared' '-mtune=generic' '-march=x86-64' '-fltrans-output-list=/tmp/ccfiSKsT.ltrans.out' '-fwpa=16' '-fresolution=/tmp/ccOyShqf.res' '-flinker-output=dyn' '-dumpdir' './lib'\''do it'\''.so.wpa.' make -f /tmp/ccNUrSeQ.mk -j16 all [...] COLLECT_GCC_OPTIONS='-c' '-fno-openmp' '-fno-openacc' '-fcf-protection=none' '-v' '-fPIC' '-shared' '-mtune=generic' '-march=x86-64' '-fltrans' '-o' '/tmp/ccfiSKsT.ltrans0.ltrans.o' '-dumpdir' './libdo-' /usr/libexec/gcc/x86_64-redhat-linux/11/lto1 -quiet -dumpdir ./libdo- -dumpbase ccfiSKsT.ltrans0.ltrans. -dumpbase-ext . -mtune=generic -march=x86-64 -version -fno-openmp -fno-openacc -fcf-protection=none -fPIC -fltrans it.so. it.so.ltrans0.ltrans /tmp/ccfiSKsT.ltrans0.o -o /tmp/ccCtIFo1.s [...] GOOD: gcc -v -fPIC -flto -shared -Wl,-soname,"lib'do it'.so" -o "lib'do it'.so" doit.o [...] COLLECT_GCC_OPTIONS='-v' '-fPIC' '-flto' '-shared' '-o' 'lib'\''do it'\''.so' '-mtune=generic' '-march=x86-64' '-dumpdir' 'lib'\''do it'\''.so.' [...] COLLECT_GCC_OPTIONS='-c' '-fno-openmp' '-fno-openacc' '-fcf-protection=none' '-v' '-fPIC' '-shared' '-mtune=generic' '-march=x86-64' '-fltrans-output-list=/tmp/ccMA9joX.ltrans.out' '-fwpa' '-fresolution=/tmp/cceTYxPV.res' '-flinker-output=dyn' [...] COLLECT_GCC_OPTIONS='-c' '-fno-openmp' '-fno-openacc' '-fcf-protection=none' '-v' '-fPIC' '-shared' '-mtune=generic' '-march=x86-64' '-fltrans-output-list=/tmp/ccMA9joX.ltrans.out' '-fwpa' '-fresolution=/tmp/cceTYxPV.res' '-flinker-output=dyn' '-dumpdir' './lib'\''do it'\''.so.wpa.' [...] COLLECT_GCC_OPTIONS='-c' '-fno-openmp' '-fno-openacc' '-fcf-protection=none' '-v' '-fPIC' '-shared' '-mtune=generic' '-march=x86-64' '-fltrans' '-o' '/tmp/ccMA9joX.ltrans0.ltrans.o' /usr/libexec/gcc/x86_64-redhat-linux/11/lto1 -quiet -dumpbase ./lib'do it'.so.ltrans0.ltrans -mtune=generic -march=x86-64 -version -fno-openmp -fno-openacc -fcf-protection=none -fPIC -fltrans @/tmp/ccpufIq0 -o /tmp/ccyVUMgZ.s The first three differences look ok: In the good case we have '-fwpa', and in the base case '-fwpa=16', which looks sane. In the last diff we can see a wrong behaviour: In the good case we have: * '-dumpbase ./lib'do it'.so.ltrans0.ltrans', and * '-fltrans it.so. it.so.ltrans0.ltrans /tmp/ccfiSKsT.ltrans0.o' In the bad case we have: * '-dumpdir ./libdo- -dumpbase ccfiSKsT.ltrans0.ltrans. -dumpbase-ext .' * '-fltrans @/tmp/ccpufIq0 -o /tmp/ccyVUMgZ.s'
[Bug c++/70536] g++ doesn't emit DW_AT_name for DW_TAG_GNU_formal_parameter_pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70536 --- Comment #3 from Ed Catmur --- Updated: https://github.com/gcc-mirror/gcc/compare/master...ecatmur:pr-70536
[Bug target/104853] [RISC-V] -march=rv64g not including extension Zifencei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104853 --- Comment #5 from rvalue --- (In reply to Kito Cheng from comment #4) > Thanks your info, that cause by the default ISA spec version bump issue, > binutils 2.38 and GCC 11.* using different default ISA spec cause this > issue, I've push a patch to GCC 11 branch [1] for this issue, could you try > this patch? thanks. > > > See more detail for the full story about ISA spec: > > https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/aE1ZeHHCYf4 > > [1] > https://gcc.gnu.org/git/?p=gcc.git;a=commit; > h=9871d39f752bc9c114ed694662a519d04896f491 I've tried this patch just now. Unfortunately, the gcc rebuilt reports the same error as before.
[Bug target/104829] [12 Regression] Pure 32-bit PowerPC build broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104829 Segher Boessenkool changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #17 from Segher Boessenkool --- Fixed.
[Bug target/104829] [12 Regression] Pure 32-bit PowerPC build broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104829 --- Comment #16 from CVS Commits --- The master branch has been updated by Segher Boessenkool : https://gcc.gnu.org/g:80fcc4b6afee72443bef551064826b3b4b6785e6 commit r12-7628-g80fcc4b6afee72443bef551064826b3b4b6785e6 Author: Segher Boessenkool Date: Fri Mar 11 21:15:18 2022 + rs6000: Do not use rs6000_cpu for .machine ppc and ppc64 (PR104829) Fixes: 77eccbf39ed5 rs6000.h has #define PROCESSOR_POWERPC PROCESSOR_PPC604 #define PROCESSOR_POWERPC64 PROCESSOR_RS64A which means that if you use things like -mcpu=powerpc -mvsx it will no longer work after my latest .machine patch. This causes GCC build errors in some cases, not a good idea (even if the errors are actually pre-existing: using -mvsx with a machine that does not have VSX cannot work properly). 2022-03-11 Segher Boessenkool PR target/104829 * config/rs6000/rs6000.cc (rs6000_machine_from_flags): Don't output "ppc" and "ppc64" based on rs6000_cpu.
[Bug target/104890] [12 Regression] fails to build the 32bit libgcc on x86_64-linux-gnu (--enable-default-pie)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104890 H.J. Lu changed: What|Removed |Added Last reconfirmed||2022-03-12 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #2 from H.J. Lu --- I can't reproduce it with --disable-bootstrap --enable-cet --with-demangler-in-ld --prefix=/usr/gcc-12.0.1-x86-64-pie --with-local-prefix=/usr/local --enable-gnu-indirect-function --enable-clocale=gnu --with-system-zlib --with-target-system-zlib --disable-libcc1 --disable-libcilkrts --disable-libsanitizer --enable-default-pie --enable-languages=c,c++ Please provide the prepossessed unwind-dw2.c and show the command-line passed to cc1 with "gcc -v".
[Bug target/104794] arm: use translation pattern for repetitive messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104794 --- Comment #11 from Roland Illig --- Thank you, looks good now.
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 Roger Sayle changed: What|Removed |Added CC||joshua.england@worldprogram ||ming.com --- Comment #18 from Roger Sayle --- *** Bug 78249 has been marked as a duplicate of this bug. ***
[Bug middle-end/78249] In consistent results for 0.0 * inf when optimizer is enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78249 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Roger Sayle --- After a little investigating it turns out that this is a duplicate of PR middle-end/51446. When multiplying 0 * Inf, x86/ia64 chips return -NaN, where other architectures return NaN. Alas IEEE doesn't specify the sign of the NaN, so GCC isn't "wrong", but it's odd that multiplications performed at run-time produce a different result to those computed at compile-time (hence the -O0 vs -O1/2/3 differences). Ideally this should (perhaps) be controlled by a target hook. *** This bug has been marked as a duplicate of bug 51446 ***
[Bug lto/104895] New: lto1: issue with space in library filename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104895
Bug ID: 104895
Summary: lto1: issue with space in library filename
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: christophm30 at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
When building Souffle, I ran into an LTO issue with a library that contains a
space in its filename (see
https://github.com/souffle-lang/souffle/issues/2214).
I've isolated the issue as follows (Fedora 35: gcc (GCC) 11.2.1 20220127 (Red
Hat 11.2.1-9)):
Makefile:
CC=gcc
CFLAGS=-fPIC
CFLAGS:=$(CFLAGS) -flto=auto
RM=rm -f
all: ltomain
"lib do it".so: doit.o
$(CC) $(CFLAGS) $(LDFLAGS) -shared -Wl,-soname,"lib'do it'.so" -o
"lib'do it'.so" doit.o
ltomain: main.o "lib do it".so
$(CC) $(CFLAGS) $(LDFLAGS) -o $@ main.o -L. -l"'do it'"
clean:
$(RM) *.o *.so ltomain
doit.c:
#include
void doit(void)
{
printf("Hello world!\n");
}
void doit();
main.c:
int main()
{
doit();
}
This gives the following error:
$ make clean all
rm -f *.o *.so ltomain
gcc -fPIC -flto=auto -c -o main.o main.c
gcc -fPIC -flto=auto -c -o doit.o doit.c
gcc -fPIC -flto=auto -shared -Wl,-soname,"lib'do it'.so" -o "lib'do it'.so"
doit.o
lto1: error: open it.so. failed: No such file or directory
make[1]: *** [/tmp/ccetIqO9.mk:2: /tmp/ccIqDtkB.ltrans0.ltrans.o] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
make: *** [Makefile:9: "lib] Error 1
Replacing '-flto=auto' by '-flto' works:
$ make clean all
rm -f *.o *.so ltomain
gcc -fPIC -flto -c -o main.o main.c
gcc -fPIC -flto -c -o doit.o doit.c
gcc -fPIC -flto -shared -Wl,-soname,"lib'do it'.so" -o "lib'do it'.so" doit.o
gcc -fPIC -flto -shared -Wl,-soname,"lib'do it'.so" -o "lib'do it'.so" doit.o
gcc -fPIC -flto -shared -Wl,-soname,"lib'do it'.so" -o "lib'do it'.so" doit.o
gcc -fPIC -flto -o ltomain main.o -L. -l"'do it'"
$ LD_LIBRARY_PATH=. ./ltomain
Hello world!
[Bug translation/104552] Mistakes in strings to be translated in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 --- Comment #37 from Roland Illig --- I'm splitting this bug report into multiple bug reports, to clean up the mess that the 36 comments created. It was a bad idea from the beginning. :)
[Bug middle-end/104892] OpenACC 'kernels' decomposition: wrong-code cases unless manually making certain variables addressable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104892 Thomas Schwinge changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Thomas Schwinge --- .
[Bug tree-optimization/100280] ICE in lower_omp_target, at omp-low.c:12287
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100280 --- Comment #8 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:a07b8f4fb756484893b5612cbe9410970dc76db9 commit r12-7627-ga07b8f4fb756484893b5612cbe9410970dc76db9 Author: Thomas Schwinge Date: Fri Mar 11 22:31:51 2022 +0100 OpenACC 'kernels' decomposition: resolve wrong-code cases unless manually making certain variables addressable [PR100280, PR104892] Currently in OpenACC 'kernels' decomposition, there is special handling of 'GOMP_MAP_FORCE_TOFROM', documented to be done to avoid "internal compiler errors in later passes". For performance reasons, the current repetitive to/from device copying for every region is not ideal, compared to using 'present' clauses, as done for almost all other 'GOMP_MAP_*'. Also, the current special handling (incomplete, evidently) is the reason for the PR104892 misbehavior. For PR100280 etc. we've resolved all such known ICEs -- removing the special handling for 'GOMP_MAP_FORCE_TOFROM' now resolves PR104892. PR middle-end/100280 PR middle-end/104892 gcc/ * omp-oacc-kernels-decompose.cc (omp_oacc_kernels_decompose_1): Remove special handling of 'GOMP_MAP_FORCE_TOFROM'. gcc/testsuite/ * c-c++-common/goacc/kernels-decompose-2.c: Adjust. * c-c++-common/goacc/kernels-decompose-pr100400-1-1.c: Likewise. * c-c++-common/goacc/kernels-decompose-pr100400-1-2.c: Likewise. * c-c++-common/goacc/kernels-decompose-pr100400-1-3.c: Likewise. * c-c++-common/goacc/kernels-decompose-pr100400-1-4.c: Likewise. * c-c++-common/goacc/kernels-decompose-pr104061-1-1.c: Likewise. * c-c++-common/goacc/kernels-decompose-pr104061-1-2.c: Likewise. * c-c++-common/goacc/kernels-decompose-pr104061-1-3.c: Likewise. * c-c++-common/goacc/kernels-decompose-pr104061-1-4.c: Likewise. * c-c++-common/goacc/kernels-decompose-pr104132-1.c: Likewise. * c-c++-common/goacc/kernels-decompose-pr104133-1.c: Likewise. * c-c++-common/goacc/kernels-decompose-pr104774-1.c: Likewise. * gfortran.dg/goacc/classify-kernels.f95: Likewise. * gfortran.dg/goacc/kernels-decompose-2.f95: Likewise. libgomp/ * testsuite/libgomp.oacc-c-c++-common/declare-vla.c: Adjust. * testsuite/libgomp.oacc-c-c++-common/default-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-reduction-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/parallel-dims.c: Likewise. * testsuite/libgomp.oacc-fortran/asyncwait-1.f90: Likewise. * testsuite/libgomp.oacc-fortran/kernels-reduction-1.f90: Likewise.
[Bug middle-end/104892] OpenACC 'kernels' decomposition: wrong-code cases unless manually making certain variables addressable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104892 --- Comment #2 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:a07b8f4fb756484893b5612cbe9410970dc76db9 commit r12-7627-ga07b8f4fb756484893b5612cbe9410970dc76db9 Author: Thomas Schwinge Date: Fri Mar 11 22:31:51 2022 +0100 OpenACC 'kernels' decomposition: resolve wrong-code cases unless manually making certain variables addressable [PR100280, PR104892] Currently in OpenACC 'kernels' decomposition, there is special handling of 'GOMP_MAP_FORCE_TOFROM', documented to be done to avoid "internal compiler errors in later passes". For performance reasons, the current repetitive to/from device copying for every region is not ideal, compared to using 'present' clauses, as done for almost all other 'GOMP_MAP_*'. Also, the current special handling (incomplete, evidently) is the reason for the PR104892 misbehavior. For PR100280 etc. we've resolved all such known ICEs -- removing the special handling for 'GOMP_MAP_FORCE_TOFROM' now resolves PR104892. PR middle-end/100280 PR middle-end/104892 gcc/ * omp-oacc-kernels-decompose.cc (omp_oacc_kernels_decompose_1): Remove special handling of 'GOMP_MAP_FORCE_TOFROM'. gcc/testsuite/ * c-c++-common/goacc/kernels-decompose-2.c: Adjust. * c-c++-common/goacc/kernels-decompose-pr100400-1-1.c: Likewise. * c-c++-common/goacc/kernels-decompose-pr100400-1-2.c: Likewise. * c-c++-common/goacc/kernels-decompose-pr100400-1-3.c: Likewise. * c-c++-common/goacc/kernels-decompose-pr100400-1-4.c: Likewise. * c-c++-common/goacc/kernels-decompose-pr104061-1-1.c: Likewise. * c-c++-common/goacc/kernels-decompose-pr104061-1-2.c: Likewise. * c-c++-common/goacc/kernels-decompose-pr104061-1-3.c: Likewise. * c-c++-common/goacc/kernels-decompose-pr104061-1-4.c: Likewise. * c-c++-common/goacc/kernels-decompose-pr104132-1.c: Likewise. * c-c++-common/goacc/kernels-decompose-pr104133-1.c: Likewise. * c-c++-common/goacc/kernels-decompose-pr104774-1.c: Likewise. * gfortran.dg/goacc/classify-kernels.f95: Likewise. * gfortran.dg/goacc/kernels-decompose-2.f95: Likewise. libgomp/ * testsuite/libgomp.oacc-c-c++-common/declare-vla.c: Adjust. * testsuite/libgomp.oacc-c-c++-common/default-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/kernels-reduction-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/parallel-dims.c: Likewise. * testsuite/libgomp.oacc-fortran/asyncwait-1.f90: Likewise. * testsuite/libgomp.oacc-fortran/kernels-reduction-1.f90: Likewise.
[Bug middle-end/104892] OpenACC 'kernels' decomposition: wrong-code cases unless manually making certain variables addressable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104892 --- Comment #1 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:535afbd959bc72de85fca36ba6417f075cca1018 commit r12-7626-g535afbd959bc72de85fca36ba6417f075cca1018 Author: Thomas Schwinge Date: Fri Mar 11 15:11:25 2022 +0100 OpenACC 'kernels' decomposition: wrong-code cases unless manually making certain variables addressable [PR104892] Document a few examples of the status quo. PR middle-end/104892 libgomp/ * testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c: Point to PR104892. * testsuite/libgomp.oacc-c-c++-common/default-1.c: Likewise, enable '--param=openacc-kernels=decompose' and adjust. * testsuite/libgomp.oacc-c-c++-common/kernels-reduction-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/parallel-dims.c: Likewise. * testsuite/libgomp.oacc-fortran/kernels-reduction-1.f90: Likewise.
[Bug c/104894] New: [ppc64le] gcc11 ICE with -fno-plt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104894
Bug ID: 104894
Summary: [ppc64le] gcc11 ICE with -fno-plt
Product: gcc
Version: 11.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: rafaelcfsousa at ibm dot com
Target Milestone: ---
When I use the flag "-fno-plt" together with "-O2 -mcpu=power10" on gcc11, the
compilation fails.
Some important points:
- The ICE shows up only when I use optimization level -O2 or higher
- If I replace "-mcpu=power10" by "-mcpu=power9", the compilation works fine
- The same error does not happen on gcc10
gcc version:
- gcc (GCC) 11.2.1 20220312 [remotes/origin/releases/gcc-11 revision
6f581f90e3:53ab7b79c6:908e612067e42ded881db10d38768f23307bf55e]
- gcc (GCC) 11.2.1 20220211 (Advance-Toolchain 15.0-2) [64575dfb22ae]
- gcc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1)
- gcc (GCC) 12.0.1 20220312 (experimental) [remotes/origin/HEAD
r12-7622-g828335beb7]
The error shows up on all GCCs above.
the system type: ppc64le (powerpc64le-unknown-linux-gnu)
Configured with: /home/gccbuild/gcc_11_git/gcc/configure
--prefix=/opt/gcc-nightly/11 --with-as=/home/gccbuild/binutils/install/bin/as
--with-ld=/home/gccbuild/binutils/install/bin/ld
--enable-languages=c,c++,fortran,objc,obj-c++ --with-cpu=power10
source file:
issue.c
```
void foo();
void bar() {
foo();
}
```
the complete command line that triggers the bug:
gcc -O3 -mcpu=power10 -mtune=power10 -fno-plt -c issue.c -o issue.o
the compiler output (error messages, warnings, etc.):
during RTL pass: expand
issue.c: In function ‘bar’:
issue.c:4:4: internal compiler error: in rs6000_sibcall_aix, at
config/rs6000/rs6000.cc:25654
4 |foo();
|^
0x11073563 rs6000_sibcall_aix(rtx_def*, rtx_def*, rtx_def*, rtx_def*)
/home/gccbuild/gcc_trunk_git/gcc/gcc/config/rs6000/rs6000.cc:25654
0x116acc5f gen_sibcall(rtx_def*, rtx_def*, rtx_def*)
/home/gccbuild/gcc_trunk_git/gcc/gcc/config/rs6000/rs6000.md:11573
0x1104f17f target_gen_sibcall
/home/gccbuild/gcc_trunk_git/gcc/gcc/config/rs6000/rs6000.md:13266
0x10486a0f emit_call_1
/home/gccbuild/gcc_trunk_git/gcc/gcc/calls.cc:469
0x1048f363 expand_call(tree_node*, rtx_def*, int)
/home/gccbuild/gcc_trunk_git/gcc/gcc/calls.cc:3608
0x106614eb expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/gccbuild/gcc_trunk_git/gcc/gcc/expr.cc:11539
0x104b0887 expand_expr
/home/gccbuild/gcc_trunk_git/gcc/gcc/expr.h:301
0x104b0887 expand_call_stmt
/home/gccbuild/gcc_trunk_git/gcc/gcc/cfgexpand.cc:2831
0x104b0887 expand_gimple_stmt_1
/home/gccbuild/gcc_trunk_git/gcc/gcc/cfgexpand.cc:3869
0x104b0887 expand_gimple_stmt
/home/gccbuild/gcc_trunk_git/gcc/gcc/cfgexpand.cc:4033
0x104b850b expand_gimple_tailcall
/home/gccbuild/gcc_trunk_git/gcc/gcc/cfgexpand.cc:4079
0x104b850b expand_gimple_basic_block
/home/gccbuild/gcc_trunk_git/gcc/gcc/cfgexpand.cc:6054
0x104ba5d7 execute
/home/gccbuild/gcc_trunk_git/gcc/gcc/cfgexpand.cc:6806
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
using --save-temps:
issue.s
```
.file "issue.c"
.machinepower10
.abiversion 2
.section".text"
```
issue.i
```
# 0 "issue.c"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "issue.c"
void foo();
void bar() {
foo();
}
```
[Bug target/104893] New: [nvptx] Handle Independent Thread Scheduling for sm_70+ with -msoft-stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104893 Bug ID: 104893 Summary: [nvptx] Handle Independent Thread Scheduling for sm_70+ with -msoft-stack Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- We use -msoft-stack for openmp programs: ... '-msoft-stack' Generate code that does not use '.local' memory directly for stack storage. Instead, a per-warp stack pointer is maintained explicitly. This enables variable-length stack allocation (with variable-length arrays or 'alloca'), and when global memory is used for underlying storage, makes it possible to access automatic variables from other threads, or with atomic instructions. ... Starting with sm_70, we have Independent Thread Scheduling: "the GPU maintains execution state per thread, including a program counter and call stack". The per-thread call stack is handled for .local memory by the CUDA driver. For the 'soft stack' that's not the case. So, it's possible that different threads start to read and write values to a stack address that is meant to be thread private, but which in reality is shared between all threads in the warp.
[Bug middle-end/90115] OpenACC: predetermined private levels for variables declared in blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90115 --- Comment #16 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:2e53fa7bb2ae9fe1152c27e423be9e261da82ddc commit r12-7625-g2e53fa7bb2ae9fe1152c27e423be9e261da82ddc Author: Thomas Schwinge Date: Fri Mar 11 15:10:59 2022 +0100 Enhance further testcases to verify handling of OpenACC privatization level [PR90115] As originally introduced in commit 11b8286a83289f5b54e813f14ff56d730c3f3185 "[OpenACC privatization] Largely extend diagnostics and corresponding testsuite coverage [PR90115]". PR middle-end/90115 libgomp/ * testsuite/libgomp.oacc-c-c++-common/default-1.c: Enhance. * testsuite/libgomp.oacc-c-c++-common/kernels-reduction-1.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/parallel-dims.c: Likewise. * testsuite/libgomp.oacc-fortran/kernels-reduction-1.f90: Likewise.
[Bug middle-end/104892] New: OpenACC 'kernels' decomposition: wrong-code cases unless manually making certain variables addressable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104892 Bug ID: 104892 Summary: OpenACC 'kernels' decomposition: wrong-code cases unless manually making certain variables addressable Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: openacc, wrong-code Severity: normal Priority: P3 Component: middle-end Assignee: tschwinge at gcc dot gnu.org Reporter: tschwinge at gcc dot gnu.org Target Milestone: --- Even with the PR100280 etc. ICEs fixed, we still have the problem that we generate wrong code in certain scenarios. For example, see the remark in current 'libgomp.oacc-c-c++-common/kernels-decompose-1.c' that "Without making '[...]' addressable, [...] we will not see the expected value copied out".
[Bug middle-end/104086] ICE in lower_omp_target, at omp-low.c:13075
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104086 Thomas Schwinge changed: What|Removed |Added Keywords||ice-on-valid-code Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org Component|tree-optimization |middle-end Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Thomas Schwinge --- .
[Bug debug/104891] New: Possibly wrong location definition in DWARF with -fschedule-insns2 at -O2/-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104891
Bug ID: 104891
Summary: Possibly wrong location definition in DWARF with
-fschedule-insns2 at -O2/-O3
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: assaiante at diag dot uniroma1.it
Target Milestone: ---
In this minimized C example variables l_29 and l_30, which are defined and used
in the scope within brackets spanning lines 4-8, are associated to DWARF
symbols having a possibly wrong location definition, which causes variables to
not be available during debugging, despite their DIEs being correctly defined.
We observe the bug at -O2 and -O3 with the cause likely being
-fschedule-insns2. Please find below a detailed analysis for -O3 on x64,
including a comparison with prior gcc versions where the bug is sometimes not
present.
$ cat a.c
volatile char a;
int main() {
int print_hash_value = 0;
{
int l_29 = 7, l_30 = 9551615;
a = l_30 >= l_29;
printf("%X\n", 0);
}
}
GCC and GDB version (GCC commit id: 500d3f0a302):
$ gcc --version
gcc (GCC) 12.0.0 20211227 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gdb --version
GNU gdb (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
GDB trace:
$ gcc -O3 -g a.c -o opt
$ gdb -q opt
Reading symbols from opt...
(gdb) b 6
Breakpoint 1 at 0x400410: file a.c, line 6.
(gdb) r
Starting program: /home/stepping/debuginfo-analysis/dd-mismatches/66/reduce/opt
Breakpoint 1, main () at a.c:6
6 a = l_30 >= l_29;
(gdb) info locals
print_hash_value = 0
By dumping the DWARF info, we can see how the location of the lexical block
associated to the inner scope is defined by ranges where the first one is empty
(400410-400410), while the values for l_29 and l_30 are correctly specified:
ASM:
00400410 :
400410: 48 83 ec 08 sub$0x8,%rsp
400414: 31 f6 xor%esi,%esi
400416: bf a4 05 40 00 mov$0x4005a4,%edi
40041b: 31 c0 xor%eax,%eax
40041d: c6 05 0d 0c 20 00 01movb $0x1,0x200c0d(%rip)#
601031
400424: e8 d7 ff ff ff call 400400
400429: 31 c0 xor%eax,%eax
40042b: 48 83 c4 08 add$0x8,%rsp
40042f: c3 ret
DWARF info:
0x007d: DW_TAG_lexical_block
DW_AT_ranges (0x000c
[0x00400410, 0x00400410)
[0x00400414, 0x00400429))
0x0082: DW_TAG_variable
DW_AT_name ("l_29")
DW_AT_decl_file ("/home/test/dd/66/reduce/a.c")
DW_AT_decl_line (5)
DW_AT_decl_column (0x09)
DW_AT_type (0x00d6 "int")
DW_AT_const_value (0x07)
0x008e: DW_TAG_variable
DW_AT_name ("l_30")
DW_AT_decl_file ("/home/test/dd/66/reduce/a.c")
DW_AT_decl_line (5)
DW_AT_decl_column (0x13)
DW_AT_type (0x00d6 "int")
DW_AT_const_value (0x0091beff)
When we manually patch the first range to be (400410-400414), the variables are
displayed correctly in gdb.
Through some testing we found out that the optimization flag that introduces
the bug is likely -fschedule-insns2. If we add -fno-schedule-insns2 to the
compilation command line used above, variables l_29 and l_30 appear in the
current frame with their values correctly available at line 6. The location of
the lexical block appears now to be correctly defined (see low pc and high pc
attributes):
ASM with -fno-schedule-insns2:
00400410 :
400410: 48 83 ec 08 sub$0x8,%rsp
400414: c6 05 16 0c 20 00 01movb $0x1,0x200c16(%rip)#
601031
40041b: 31 f6 xor%esi,%esi
40041d: bf a4 05 40 00 mov$0x4005a4,%edi
400422: 31 c0 xor%eax,%eax
400424: e8 d7 ff ff ff call 400400
400429: 31 c0 xor%eax,%eax
40042b: 48 83 c4 08 add$0x8,%rsp
40042f: c3 ret
DWARF info with -fno-schedule-insns2:
0x007d: DW_TAG_lexical_block
DW_AT_low_pc
[Bug tree-optimization/104086] ICE in lower_omp_target, at omp-low.c:13075
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104086
--- Comment #2 from CVS Commits ---
The master branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:337ed336d7dd83526891bdb436f0bfe9e351f69d
commit r12-7624-g337ed336d7dd83526891bdb436f0bfe9e351f69d
Author: Thomas Schwinge
Date: Thu Feb 17 14:18:57 2022 +0100
OpenACC 'kernels' decomposition: Mark variables used in 'present' clauses
as addressable [PR100280, PR104086]
... like in recent commit 9b32c1669aad5459dd053424f9967011348add83
"OpenACC 'kernels' decomposition: Mark variables used in synthesized
data clauses as addressable [PR100280]". Otherwise, we may run into
'gcc/omp-low.cc:lower_omp_target':
13125 else if (is_gimple_reg (var))
13126 {
13127 gcc_assert (offloaded);
PR middle-end/100280
PR middle-end/104086
gcc/
* omp-oacc-kernels-decompose.cc (omp_oacc_kernels_decompose_1):
Mark variables used in 'present' clauses as addressable.
* omp-low.cc (scan_sharing_clauses) : Gracefully
handle duplicate 'OMP_CLAUSE_MAP_DECL_MAKE_ADDRESSABLE'.
gcc/testsuite/
* c-c++-common/goacc/kernels-decompose-pr104086-1.c: Adjust,
extend.
libgomp/
*
testsuite/libgomp.oacc-c-c++-common/declare-vla-kernels-decompose-ice-1.c:
Merge this...
*
testsuite/libgomp.oacc-c-c++-common/declare-vla-kernels-decompose.c:
..., and this...
* testsuite/libgomp.oacc-c-c++-common/declare-vla.c: ... into
this, and adjust.
* testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c:
Extend.
[Bug tree-optimization/100280] ICE in lower_omp_target, at omp-low.c:12287
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100280
--- Comment #7 from CVS Commits ---
The master branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:337ed336d7dd83526891bdb436f0bfe9e351f69d
commit r12-7624-g337ed336d7dd83526891bdb436f0bfe9e351f69d
Author: Thomas Schwinge
Date: Thu Feb 17 14:18:57 2022 +0100
OpenACC 'kernels' decomposition: Mark variables used in 'present' clauses
as addressable [PR100280, PR104086]
... like in recent commit 9b32c1669aad5459dd053424f9967011348add83
"OpenACC 'kernels' decomposition: Mark variables used in synthesized
data clauses as addressable [PR100280]". Otherwise, we may run into
'gcc/omp-low.cc:lower_omp_target':
13125 else if (is_gimple_reg (var))
13126 {
13127 gcc_assert (offloaded);
PR middle-end/100280
PR middle-end/104086
gcc/
* omp-oacc-kernels-decompose.cc (omp_oacc_kernels_decompose_1):
Mark variables used in 'present' clauses as addressable.
* omp-low.cc (scan_sharing_clauses) : Gracefully
handle duplicate 'OMP_CLAUSE_MAP_DECL_MAKE_ADDRESSABLE'.
gcc/testsuite/
* c-c++-common/goacc/kernels-decompose-pr104086-1.c: Adjust,
extend.
libgomp/
*
testsuite/libgomp.oacc-c-c++-common/declare-vla-kernels-decompose-ice-1.c:
Merge this...
*
testsuite/libgomp.oacc-c-c++-common/declare-vla-kernels-decompose.c:
..., and this...
* testsuite/libgomp.oacc-c-c++-common/declare-vla.c: ... into
this, and adjust.
* testsuite/libgomp.oacc-c-c++-common/kernels-decompose-1.c:
Extend.
[Bug tree-optimization/104086] ICE in lower_omp_target, at omp-low.c:13075
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104086
--- Comment #1 from CVS Commits ---
The master branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:9781ae3a254a8c17ef4ffa70f21ed1728ff3c707
commit r12-7623-g9781ae3a254a8c17ef4ffa70f21ed1728ff3c707
Author: Thomas Schwinge
Date: Tue Jan 18 17:22:14 2022 +0100
Add 'c-c++-common/goacc/kernels-decompose-pr104086-1.c' [PR104086]
..., currently XFAILed with 'dg-ice', as it runs into
'gcc/omp-low.cc:lower_omp_target':
13125 else if (is_gimple_reg (var))
13126 {
13127 gcc_assert (offloaded);
This means, the recent PR100280 etc. changes are still not sufficient.
gcc/testsuite/
PR middle-end/104086
* c-c++-common/goacc/kernels-decompose-pr104086-1.c: New file.
[Bug target/104890] [12 Regression] fails to build the 32bit libgcc on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104890 --- Comment #1 from Matthias Klose --- that is only seen when configuring with --enable-default-pie
[Bug target/104890] New: [12 Regression] fails to build the 32bit libgcc on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104890 Bug ID: 104890 Summary: [12 Regression] fails to build the 32bit libgcc on x86_64-linux-gnu Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- trunk 20220312 fails to build the 32bit libgcc on x86_64-linux-gnu: /home/packages/gcc/12/gcc-12-12-20220312/build/./gcc/xgcc -B/home/packages/gcc/12/gcc-12-12-20220312/build/./gcc/ -B/usr/x86_6 4-linux-gnu/bin/ -B/usr/x86_64-linux-gnu/lib/ -isystem /usr/x86_64-linux-gnu/include -isystem /usr/x86_64-linux-gnu/sys-includ e -isystem /home/packages/gcc/12/gcc-12-12-20220312/build/sys-include -fchecking=1 -g -O2 -m32 -O2 -g -O2 -DIN_GCC-W -W all -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./inc lude -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fpic -mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -I. -I. -I../../.././gcc -I../../../../src/libgcc -I../../../. ./src/libgcc/. -I../../../../src/libgcc/../gcc -I../../../../src/libgcc/../include -I../../../../src/libgcc/config/libbid -DEN ABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c ../../../../src/libgcc/unwind-dw2.c -fvisibility=hidden -DHIDE_EXPORTS In file included from /home/packages/gcc/12/gcc-12-12-20220312/build/gcc/include/x86gprintrin.h:45, from ../../../../src/libgcc/config/i386/shadow-stack-unwind.h:25, from ./md-unwind-support.h:27, from ../../../../src/libgcc/unwind-dw2.c:412: /home/packages/gcc/12/gcc-12-12-20220312/build/gcc/include/cetintrin.h: In function '_Unwind_RaiseException': /home/packages/gcc/12/gcc-12-12-20220312/build/gcc/include/cetintrin.h:47:1: error: inlining failed in call to 'always_inline' '_get_ssp': target specific option mismatch 47 | _get_ssp (void) | ^~~~ ../../../../src/libgcc/config/i386/shadow-stack-unwind.h:32:26: note: called from here 32 | _Unwind_Word ssp = _get_ssp (); \ | ^~~ ../../../../src/libgcc/unwind-dw2.c:1654:7: note: in expansion of macro '_Unwind_Frames_Extra' 1654 | _Unwind_Frames_Extra (FRAMES); \ | ^~~~ ../../../../src/libgcc/unwind.inc:140:3: note: in expansion of macro 'uw_install_context' 140 | uw_install_context (_context, _context, frames); | ^~ /home/packages/gcc/12/gcc-12-12-20220312/build/gcc/include/cetintrin.h:55:1: error: inlining failed in call to 'always_inline' '_inc_ssp': target specific option mismatch 55 | _inc_ssp (unsigned int __B) | ^~~~ ../../../../src/libgcc/config/i386/shadow-stack-unwind.h:38:15: note: called from here 38 | _inc_ssp (255); \ | ^~ ../../../../src/libgcc/unwind-dw2.c:1654:7: note: in expansion of macro '_Unwind_Frames_Extra' 1654 | _Unwind_Frames_Extra (FRAMES); \ | ^~~~ ../../../../src/libgcc/unwind.inc:140:3: note: in expansion of macro 'uw_install_context' 140 | uw_install_context (_context, _context, frames); | ^~ /home/packages/gcc/12/gcc-12-12-20220312/build/gcc/include/cetintrin.h:55:1: error: inlining failed in call to 'always_inline' '_inc_ssp': target specific option mismatch 55 | _inc_ssp (unsigned int __B) | ^~~~ ../../../../src/libgcc/config/i386/shadow-stack-unwind.h:41:11: note: called from here 41 | _inc_ssp (tmp); \ | ^~ ../../../../src/libgcc/unwind-dw2.c:1654:7: note: in expansion of macro '_Unwind_Frames_Extra' 1654 | _Unwind_Frames_Extra (FRAMES); \ | ^~~~ ../../../../src/libgcc/unwind.inc:140:3: note: in expansion of macro 'uw_install_context' 140 | uw_install_context (_context, _context, frames); | ^~ make[7]: *** [../../../../src/libgcc/shared-object.mk:14: unwind-dw2.o] Error 1 make[7]: Leaving directory '/home/packages/gcc/12/gcc-12-12-20220312/build/x86_64-linux-gnu/32/libgcc' GCC is configured with: Configured with: -v --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
[Bug c++/97198] __is_constructible(int[], int) should return true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97198 --- Comment #6 from Jonathan Wakely --- I'll add a note to the lwg issue, as I'll never remember there was a comment about it here.
[Bug other/65095] Adapt OpenMP diagnostic messages for OpenACC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65095 --- Comment #2 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:828335beb77676acffb5911e575672cb55beb2e9 commit r12-7622-g828335beb77676acffb5911e575672cb55beb2e9 Author: Thomas Schwinge Date: Thu Feb 17 12:46:57 2022 +0100 Add 'gcc/tree.cc:user_omp_clause_code_name' [PR65095] Re PR65095 "Adapt OpenMP diagnostic messages for OpenACC", move C/C++ front end 'gcc/c-family/c-omp.cc:c_omp_map_clause_name' to generic 'gcc/tree.cc:user_omp_clause_code_name' . No functional change. PR other/65095 gcc/ * tree-core.h (user_omp_claus_code_name): Declare function. * tree.cc (user_omp_clause_code_name): New function. gcc/c/ * c-typeck.cc (handle_omp_array_sections_1) (c_oacc_check_attachments): Call 'user_omp_clause_code_name' instead of 'c_omp_map_clause_name'. gcc/cp/ * semantics.cc (handle_omp_array_sections_1) (cp_oacc_check_attachments): Call 'user_omp_clause_code_name' instead of 'c_omp_map_clause_name'. gcc/c-family/ * c-common.h (c_omp_map_clause_name): Remove. * c-omp.cc (c_omp_map_clause_name): Remove.
[Bug tree-optimization/104475] [12 Regression] Wstringop-overflow + atomics incorrect warning on dynamic object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104475 Aldy Hernandez changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #8 from Aldy Hernandez --- (In reply to Richard Biener from comment #7) > I think we shouldn't do anything on the optimization side - sure, the path > isolation in the end turns out not profitable, but it's likely hard to decide > that. > > Maybe we can somehow avoid threading for a ptr == 0 condition? Why do we > make > the threading profitable? The threaders are mostly blind wrt threading a path. If they see it, they will thread it. There are some minor things we disallow (see calls to cancel_thread throughout) and the big hammer we introduced in this release with cancel_invalid_paths() where we disallow problematic loop transformations. But mostly we thread everything that's possible. Disallowing ptr == 0 as well as highly unlikely paths should be trivial. We could add a simple check in cancel_invalid_paths(). Though, I assume that would affect warning code all over, since we're reducing the amount of threadable paths on which they depend?
[Bug middle-end/98420] Invalid simplification of x - x with -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98420 --- Comment #4 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:72c243017dee611bf3c32ea7bfad6ac538021aaf commit r12-7621-g72c243017dee611bf3c32ea7bfad6ac538021aaf Author: Roger Sayle Date: Sat Mar 12 09:20:52 2022 + PR middle-end/98420: Don't fold x - x to 0.0 with -frounding-math This patch addresses PR middle-end/98420, which is inappropriate constant folding of x - x to 0.0 (in match.pd) when -frounding-math is specified. Specifically, x - x may be -0.0 with FE_DOWNWARD as the rounding mode. To summarize, the desired IEEE behaviour, x - x for floating point x, (1) can't be folded to 0.0 by default, due to the possibility of NaN or Inf (2) can be folded to 0.0 with -ffinite-math-only (3) can't be folded to 0.0 with -ffinite-math-only -frounding-math (4) can be folded with -ffinite-math-only -frounding-math -fno-signed-zeros 2022-03-12 Roger Sayle gcc/ChangeLog PR middle-end/98420 * match.pd (minus @0 @0): Additional checks for -fno-rounding-math (the defaut) or -fno-signed-zeros. gcc/testsuite/ChangeLog PR middle-end/98420 * gcc.dg/pr98420.c: New test case.
