[Bug libgcc/104984] New: Use hard-fp for libgcc single-floating-point routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104984
Bug ID: 104984
Summary: Use hard-fp for libgcc single-floating-point routines
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: archicharmer at mail dot ru
Target Milestone: ---
I am currently using gcc-9.2.0 . At it's last building stage it was compiled
using the next configure additions:
--prefix=$PREFIX --enable-languages=c,c++ --includedir=$PREFIX/include
--target=mipsel-unknown-linux-gnu --with-arch=r6000 --with-float=hard
--with-fpu=single --enable-libatomic --with-llsc=yes --disable-multilib
--disable-libsanitizer
It generates the binaries of hard-float single-float ABI=o32 ISA=MIPS-II if
that matters.
I compiled the system from scratch by the cross-compiler which includes that
kind of gcc, and some of the programs - magick (ImageMagick), gdb, groupadd -
has the same segmentation fault in them:
$ gdb magick
$ run import scr.jpg
Program received signal SIGSEGV, Segmentation fault.
0x008c30e4 in __divdf3 (x=0, y=4) at ../../../libgcc/config/hardfp.c:37
37 ../../../libgcc/config/hardfp.c: No such file or directory.
I beleive it is someway related to this:
https://gcc.gnu.org/legacy-ml/gcc-patches/2014-02/msg00420.html
because if to make the next changes in the libgcc's config.host file:
# All MIPS targets provide a full set of FP routines.
cpu_type=mips
tmake_file="mips/t-mips"
- if test "${libgcc_cv_mips_hard_float}" = yes; then
- tmake_file="${tmake_file} t-hardfp-sfdf t-hardfp"
- else
+# if test "${libgcc_cv_mips_hard_float}" = yes; then
+# tmake_file="${tmake_file} t-hardfp-sfdf t-hardfp"
+# else
tmake_file="${tmake_file} t-softfp-sfdf"
- fi
+# fi
- those SegFaults disappears.
I have a mipsel system which have 32bit registers only and do not support
double floating point operations hardwarely (that's r5900). Can you make some
workarounds to such possible files like
libgcc/config/t-hardfp, libgcc/config/t-hardfp-sfdf and libgcc/config/hardfp.c
so it will be using only single-float libgcc functions for it's routines
hardwarely and the rest it will be using softwarely?
[Bug tree-optimization/94809] [8/9 Regression] Different results between gcc-9 and gcc-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94809 Andrew Pinski changed: What|Removed |Added CC||141242068 at smail dot nju.edu.cn --- Comment #10 from Andrew Pinski --- *** Bug 104983 has been marked as a duplicate of this bug. ***
[Bug c/104983] gcc ignore side effect inside CommaExpr and failed to update value variable's value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104983 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Known to fail||7.1.0, 7.5.0 Known to work||6.3.0, 6.4.0 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 94809. Already fixed in GCC 8.5.0+. *** This bug has been marked as a duplicate of bug 94809 ***
[Bug c/104983] New: gcc ignore side effect inside CommaExpr and failed to update value variable's value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104983
Bug ID: 104983
Summary: gcc ignore side effect inside CommaExpr and failed to
update value variable's value
Product: gcc
Version: 8.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: 141242068 at smail dot nju.edu.cn
Target Milestone: ---
The code:
```
int main() {
int a = 0;
unsigned long long one = 1;
unsigned long long crf1 = 0;
unsigned long long crf2 = 0;
unsigned long long crf3 = 0;
unsigned long long *cty1[] = {&crf1};
unsigned long long *cty2[] = {&crf2};
unsigned long long *cty3[] = {&crf3};
((-1ULL / (0xull + (*cty1[0]))) < a++,
((unsigned long long)((*cty2[0]) * (*cty3[0];
if (a != 1) __builtin_abort();
return 0;
}
```
Note that, a is updated only once in the above expression, and -1ull is
unsigned type, it should not trigger integer overflow.
But when compile the above code with -fopen-simd, the generated executable will
abort.
```
$ gcc -fopenmp-simd a.c -o a.out && ./a.out
[1]2409988 abort (core dumped) ./a.out
```
My gcc version is:
```
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 8.4.0-3ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.4.0 (Ubuntu 8.4.0-3ubuntu2)
```
[Bug analyzer/104954] Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954 Bug 104954 depends on bug 104943, which changed state. Bug 104943 Summary: Analyzer fails to purge state for local structs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104943 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug analyzer/104943] Analyzer fails to purge state for local structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104943 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/103533] Enable "taint" state machine with -fanalyzer without requiring -fanalyzer-checker=taint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103533 --- Comment #4 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:faacafd2306ad7ece721a79dedbb6e44e0d65bdb commit r12-7718-gfaacafd2306ad7ece721a79dedbb6e44e0d65bdb Author: David Malcolm Date: Tue Dec 7 19:22:47 2021 -0500 analyzer: extend state-purging to locals [PR104943] The existing analyzer code attempts to purge the state of SSA names where it can in order to minimize the size of program_state instances, and to increase the chances of being able to reuse exploded_node instances whilst exploring the user's code. PR analyzer/104943 identifies that we fail to purge state of local variables, based on behavior seen in PR analyzer/104954 when attempting to profile slow performance of -fanalyzer on a particular file in the Linux kernel, where that testcase has many temporary "boxed" values of structs containing ints, which are never cleaned up, leading to bloat of the program_state instances (specifically, of the store objects). This patch generalizes the state purging from just being on SSA names to also work on local variables. Doing so requires that we detect where addresses to a local variable (or within them) are taken; we assume that once a pointer has been taken, it's not longer safe to purge the value of that decl at any successor point within the function. Doing so speeds up the PR analyzer/104954 Linux kernel analyzer testcase from taking 254 seconds to "just" 186 seconds (and I have a followup patch in development that seems to further reduce this to 37 seconds). The patch may also help with scaling up taint-detection so that it can eventually be turned on by default, but we're not quite there (this is PR analyzer/103533). gcc/analyzer/ChangeLog: PR analyzer/104943 PR analyzer/104954 PR analyzer/103533 * analyzer.h (class state_purge_per_decl): New forward decl. * engine.cc (impl_run_checkers): Pass region_model_manager to state_purge_map ctor. * program-point.cc (function_point::final_stmt_p): New. (function_point::get_next): New. * program-point.h (function_point::final_stmt_p): New decl. (function_point::get_next): New decl. * program-state.cc (program_state::prune_for_point): Generalize to purge local decls as well as SSA names. (program_state::can_purge_base_region_p): New. * program-state.h (program_state::can_purge_base_region_p): New decl. * region-model.cc (struct append_ssa_names_cb_data): Rename to... (struct append_regions_cb_data): ...this. (region_model::get_ssa_name_regions_for_current_frame): Rename to... (region_model::get_regions_for_current_frame): ...this, updating for other renamings. (region_model::append_ssa_names_cb): Rename to... (region_model::append_regions_cb): ...this, and drop the requirement that the subregion be a SSA name. * region-model.h (struct append_ssa_names_cb_data): Rename decl to... (struct append_regions_cb_data): ...this. (region_model::get_ssa_name_regions_for_current_frame): Rename decl to... (region_model::get_regions_for_current_frame): ...this. (region_model::append_ssa_names_cb): Rename decl to... (region_model::append_regions_cb): ...this. * state-purge.cc: Include "tristate.h", "selftest.h", "analyzer/store.h", "analyzer/region-model.h", and "gimple-walk.h". (get_candidate_for_purging): New. (class gimple_op_visitor): New. (my_load_cb): New. (my_store_cb): New. (my_addr_cb): New. (state_purge_map::state_purge_map): Add "mgr" param. Update for renamings. Find uses of local variables. (state_purge_map::~state_purge_map): Update for renaming of m_map to m_ssa_map. Clean up m_decl_map. (state_purge_map::get_or_create_data_for_decl): New. (state_purge_per_ssa_name::state_purge_per_ssa_name): Update for inheriting from state_purge_per_tree. (state_purge_per_ssa_name::add_to_worklist): Likewise. (state_purge_per_decl::state_purge_per_decl): New. (state_purge_per_decl::add_needed_at): New. (state_purge_per_decl::add_pointed_to_at): New. (state_purge_per_decl::process_worklists): New. (state_purge_per_decl::add_to_worklist): New. (same_binding_p): New. (fully_overwrites_p): New. (state_purge_per_decl::process_point_backwards): New. (state_purge_per_decl::process_point_forwards):
[Bug analyzer/104954] Analyzer takes a very long time on Linux kernel drivers/gpu/drm/amd/display/dc/calcs/dce_calcs.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104954 --- Comment #6 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:faacafd2306ad7ece721a79dedbb6e44e0d65bdb commit r12-7718-gfaacafd2306ad7ece721a79dedbb6e44e0d65bdb Author: David Malcolm Date: Tue Dec 7 19:22:47 2021 -0500 analyzer: extend state-purging to locals [PR104943] The existing analyzer code attempts to purge the state of SSA names where it can in order to minimize the size of program_state instances, and to increase the chances of being able to reuse exploded_node instances whilst exploring the user's code. PR analyzer/104943 identifies that we fail to purge state of local variables, based on behavior seen in PR analyzer/104954 when attempting to profile slow performance of -fanalyzer on a particular file in the Linux kernel, where that testcase has many temporary "boxed" values of structs containing ints, which are never cleaned up, leading to bloat of the program_state instances (specifically, of the store objects). This patch generalizes the state purging from just being on SSA names to also work on local variables. Doing so requires that we detect where addresses to a local variable (or within them) are taken; we assume that once a pointer has been taken, it's not longer safe to purge the value of that decl at any successor point within the function. Doing so speeds up the PR analyzer/104954 Linux kernel analyzer testcase from taking 254 seconds to "just" 186 seconds (and I have a followup patch in development that seems to further reduce this to 37 seconds). The patch may also help with scaling up taint-detection so that it can eventually be turned on by default, but we're not quite there (this is PR analyzer/103533). gcc/analyzer/ChangeLog: PR analyzer/104943 PR analyzer/104954 PR analyzer/103533 * analyzer.h (class state_purge_per_decl): New forward decl. * engine.cc (impl_run_checkers): Pass region_model_manager to state_purge_map ctor. * program-point.cc (function_point::final_stmt_p): New. (function_point::get_next): New. * program-point.h (function_point::final_stmt_p): New decl. (function_point::get_next): New decl. * program-state.cc (program_state::prune_for_point): Generalize to purge local decls as well as SSA names. (program_state::can_purge_base_region_p): New. * program-state.h (program_state::can_purge_base_region_p): New decl. * region-model.cc (struct append_ssa_names_cb_data): Rename to... (struct append_regions_cb_data): ...this. (region_model::get_ssa_name_regions_for_current_frame): Rename to... (region_model::get_regions_for_current_frame): ...this, updating for other renamings. (region_model::append_ssa_names_cb): Rename to... (region_model::append_regions_cb): ...this, and drop the requirement that the subregion be a SSA name. * region-model.h (struct append_ssa_names_cb_data): Rename decl to... (struct append_regions_cb_data): ...this. (region_model::get_ssa_name_regions_for_current_frame): Rename decl to... (region_model::get_regions_for_current_frame): ...this. (region_model::append_ssa_names_cb): Rename decl to... (region_model::append_regions_cb): ...this. * state-purge.cc: Include "tristate.h", "selftest.h", "analyzer/store.h", "analyzer/region-model.h", and "gimple-walk.h". (get_candidate_for_purging): New. (class gimple_op_visitor): New. (my_load_cb): New. (my_store_cb): New. (my_addr_cb): New. (state_purge_map::state_purge_map): Add "mgr" param. Update for renamings. Find uses of local variables. (state_purge_map::~state_purge_map): Update for renaming of m_map to m_ssa_map. Clean up m_decl_map. (state_purge_map::get_or_create_data_for_decl): New. (state_purge_per_ssa_name::state_purge_per_ssa_name): Update for inheriting from state_purge_per_tree. (state_purge_per_ssa_name::add_to_worklist): Likewise. (state_purge_per_decl::state_purge_per_decl): New. (state_purge_per_decl::add_needed_at): New. (state_purge_per_decl::add_pointed_to_at): New. (state_purge_per_decl::process_worklists): New. (state_purge_per_decl::add_to_worklist): New. (same_binding_p): New. (fully_overwrites_p): New. (state_purge_per_decl::process_point_backwards): New. (state_purge_per_decl::process_point_forwards):
[Bug analyzer/104943] Analyzer fails to purge state for local structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104943 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:faacafd2306ad7ece721a79dedbb6e44e0d65bdb commit r12-7718-gfaacafd2306ad7ece721a79dedbb6e44e0d65bdb Author: David Malcolm Date: Tue Dec 7 19:22:47 2021 -0500 analyzer: extend state-purging to locals [PR104943] The existing analyzer code attempts to purge the state of SSA names where it can in order to minimize the size of program_state instances, and to increase the chances of being able to reuse exploded_node instances whilst exploring the user's code. PR analyzer/104943 identifies that we fail to purge state of local variables, based on behavior seen in PR analyzer/104954 when attempting to profile slow performance of -fanalyzer on a particular file in the Linux kernel, where that testcase has many temporary "boxed" values of structs containing ints, which are never cleaned up, leading to bloat of the program_state instances (specifically, of the store objects). This patch generalizes the state purging from just being on SSA names to also work on local variables. Doing so requires that we detect where addresses to a local variable (or within them) are taken; we assume that once a pointer has been taken, it's not longer safe to purge the value of that decl at any successor point within the function. Doing so speeds up the PR analyzer/104954 Linux kernel analyzer testcase from taking 254 seconds to "just" 186 seconds (and I have a followup patch in development that seems to further reduce this to 37 seconds). The patch may also help with scaling up taint-detection so that it can eventually be turned on by default, but we're not quite there (this is PR analyzer/103533). gcc/analyzer/ChangeLog: PR analyzer/104943 PR analyzer/104954 PR analyzer/103533 * analyzer.h (class state_purge_per_decl): New forward decl. * engine.cc (impl_run_checkers): Pass region_model_manager to state_purge_map ctor. * program-point.cc (function_point::final_stmt_p): New. (function_point::get_next): New. * program-point.h (function_point::final_stmt_p): New decl. (function_point::get_next): New decl. * program-state.cc (program_state::prune_for_point): Generalize to purge local decls as well as SSA names. (program_state::can_purge_base_region_p): New. * program-state.h (program_state::can_purge_base_region_p): New decl. * region-model.cc (struct append_ssa_names_cb_data): Rename to... (struct append_regions_cb_data): ...this. (region_model::get_ssa_name_regions_for_current_frame): Rename to... (region_model::get_regions_for_current_frame): ...this, updating for other renamings. (region_model::append_ssa_names_cb): Rename to... (region_model::append_regions_cb): ...this, and drop the requirement that the subregion be a SSA name. * region-model.h (struct append_ssa_names_cb_data): Rename decl to... (struct append_regions_cb_data): ...this. (region_model::get_ssa_name_regions_for_current_frame): Rename decl to... (region_model::get_regions_for_current_frame): ...this. (region_model::append_ssa_names_cb): Rename decl to... (region_model::append_regions_cb): ...this. * state-purge.cc: Include "tristate.h", "selftest.h", "analyzer/store.h", "analyzer/region-model.h", and "gimple-walk.h". (get_candidate_for_purging): New. (class gimple_op_visitor): New. (my_load_cb): New. (my_store_cb): New. (my_addr_cb): New. (state_purge_map::state_purge_map): Add "mgr" param. Update for renamings. Find uses of local variables. (state_purge_map::~state_purge_map): Update for renaming of m_map to m_ssa_map. Clean up m_decl_map. (state_purge_map::get_or_create_data_for_decl): New. (state_purge_per_ssa_name::state_purge_per_ssa_name): Update for inheriting from state_purge_per_tree. (state_purge_per_ssa_name::add_to_worklist): Likewise. (state_purge_per_decl::state_purge_per_decl): New. (state_purge_per_decl::add_needed_at): New. (state_purge_per_decl::add_pointed_to_at): New. (state_purge_per_decl::process_worklists): New. (state_purge_per_decl::add_to_worklist): New. (same_binding_p): New. (fully_overwrites_p): New. (state_purge_per_decl::process_point_backwards): New. (state_purge_per_decl::process_point_forwards):
[Bug analyzer/104943] Analyzer fails to purge state for local structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104943 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:1c1daca1cdf7bc0156d57bb2b9083ee70c66b000 commit r12-7717-g1c1daca1cdf7bc0156d57bb2b9083ee70c66b000 Author: David Malcolm Date: Thu Mar 17 18:12:46 2022 -0400 analyzer: add tests of boxed values [PR104943] This patch adds various regression tests as preparatory work for purging irrelevant local decls from state (PR analyzer/104943) gcc/testsuite/ChangeLog: PR analyzer/104943 * gcc.dg/analyzer/boxed-malloc-1-29.c: New test. * gcc.dg/analyzer/boxed-malloc-1.c: New test. * gcc.dg/analyzer/taint-alloc-5.c: New test. * gcc.dg/analyzer/torture/boxed-int-1.c: New test. * gcc.dg/analyzer/torture/boxed-ptr-1.c: New test. Signed-off-by: David Malcolm
[Bug target/104982] New: [12 Regression] FAIL: gcc.target/i386/bt-5.c by r12-7687
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104982 Bug ID: 104982 Summary: [12 Regression] FAIL: gcc.target/i386/bt-5.c by r12-7687 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: crazylht at gmail dot com, rguenth at gcc dot gnu.org, roger at nextmovesoftware dot com Blocks: 46235 Target Milestone: --- On x86-64, r12-7687 caused: FAIL: gcc.target/i386/bt-5.c scan-assembler-not sar[lq][ \t] FAIL: gcc.target/i386/bt-5.c scan-assembler-times bt[lq][ \t] 7 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46235 [Bug 46235] inefficient bittest code generation
[Bug target/104923] [11/12 Regression] MMA __builtin_mma_disassemble_acc test case ICEs in LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104923 Peter Bergner changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Peter Bergner --- Fixed everywhere.
[Bug target/104923] [11/12 Regression] MMA __builtin_mma_disassemble_acc test case ICEs in LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104923 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Peter Bergner : https://gcc.gnu.org/g:114451a67febf2361b8ffa3f1ba6f33790791c09 commit r11-9669-g114451a67febf2361b8ffa3f1ba6f33790791c09 Author: Peter Bergner Date: Tue Mar 15 08:46:47 2022 -0500 rs6000: Fix invalid address passed to __builtin_mma_disassemble_acc [PR104923] The mma_disassemble_output_operand predicate is too lenient on the types of addresses it will accept, leading to combine creating invalid address that eventually lead to ICEs in LRA. The solution is to restrict the addresses to indirect, indexed or those valid for quad memory accesses. 2022-03-15 Peter Bergner gcc/ PR target/104923 * config/rs6000/predicates.md (mma_disassemble_output_operand): Restrict acceptable MEM addresses. gcc/testsuite/ PR target/104923 * gcc.target/powerpc/pr104923.c: New test. (cherry picked from commit b5baf569f77e1f172061642d4d8593e1ea737add)
[Bug fortran/84672] -fcheck=bounds gives runtime error on allocation on assignment with implicit type conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84672 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |8.0 --- Comment #2 from anlauf at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > This seems to have been fixed on trunk (8.0). Closing then.
[Bug fortran/33056] [Meta-bug] Data - statement related bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056 Bug 33056 depends on bug 67817, which changed state. Bug 67817 Summary: Missing compilation error for some wrong conversions in data https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67817 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/67804] ICE on data initialization of type(character) with wrong data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67804 --- Comment #11 from anlauf at gcc dot gnu.org --- *** Bug 67817 has been marked as a duplicate of this bug. ***
[Bug fortran/67817] Missing compilation error for some wrong conversions in data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67817 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from anlauf at gcc dot gnu.org --- Dup. *** This bug has been marked as a duplicate of bug 67804 ***
[Bug fortran/98490] Unexpected out of bounds in array constructor with implied do loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98490 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||physiker at toast2 dot net --- Comment #18 from anlauf at gcc dot gnu.org --- *** Bug 70994 has been marked as a duplicate of this bug. ***
[Bug fortran/70994] gfortran: -fcheck=all implied do loop confusing messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70994 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from anlauf at gcc dot gnu.org --- Duplicate. *** This bug has been marked as a duplicate of bug 98490 ***
[Bug c++/104008] [11 Regression] New g++ folly compile error since r11-7931-ga2531859bf5bf6cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104008 --- Comment #12 from Marek Polacek --- (In reply to Patrick Palka from comment #11) > FWIW it seems the new test g++.dg/cpp0x/variadic-alias3.C crashes when using > --param=hash-table-verification-limit=1000, similar to PR103769. I cannot reproduce that: $ ./cc1plus -quiet variadic-alias3.C --param=hash-table-verification-limit=1000 # OK
[Bug target/104208] -mlong-double-64 should override a previous -mabi=ibmlongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104208 Peter Bergner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Peter Bergner --- The fix was backported to GCC11 and GCC10.
[Bug c++/103299] [11/12 Regression] accessing incorrect storage for designated init of anonymous union at constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103299 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/102740] [10/11/12 Regression] Data member not found in struct inside an unnamed union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102740 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug target/104208] -mlong-double-64 should override a previous -mabi=ibmlongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104208
--- Comment #15 from CVS Commits ---
The releases/gcc-10 branch has been updated by Peter Bergner
:
https://gcc.gnu.org/g:063ef668c716ae0bf9c0f79ae62243e89075b475
commit r10-10504-g063ef668c716ae0bf9c0f79ae62243e89075b475
Author: Peter Bergner
Date: Fri Mar 18 14:09:26 2022 -0500
rs6000: Allow -mlong-double-64 after -mabi={ibm,ieee}longdouble [PR104208,
PR87496]
The glibc build is showing a build error due to extra "error" checking from
my
PR87496 fix. That checking was overeager, disallowing setting the long
double
size to 64-bits if the 128-bit long double ABI had already been specified.
Now we only emit an error if we specify a 128-bit long double ABI if our
long double size is not 128 bits. This also fixes an erroneous error when
-mabi=ieeelongdouble is used and ISA 2.06 is not enabled, but the long
double
size has been changed to 64 bits.
2022-03-04 Peter Bergner
gcc/
PR target/87496
PR target/104208
* config/rs6000/rs6000.c (rs6000_option_override_internal): Make
the
ISA 2.06 requirement for -mabi=ieeelongdouble conditional on
-mlong-double-128.
Move the -mabi=ieeelongdouble and -mabi=ibmlongdouble error
checking
from here...
* common/config/rs6000/rs6000-common.c (rs6000_handle_option):
... to here.
gcc/testsuite/
PR target/87496
PR target/104208
* gcc.target/powerpc/pr104208-1.c: New test.
* gcc.target/powerpc/pr104208-2.c: Likewise.
* gcc.target/powerpc/pr87496-2.c: Swap long double options to
trigger
the expected error.
* gcc.target/powerpc/pr87496-3.c: Likewise.
(cherry picked from commit cb16bc3b5f34733ef9bbf8d2e3acacdecb099a62)
[Bug target/87496] ICE in aggregate_value_p at gcc/function.c:2046
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87496
--- Comment #16 from CVS Commits ---
The releases/gcc-10 branch has been updated by Peter Bergner
:
https://gcc.gnu.org/g:063ef668c716ae0bf9c0f79ae62243e89075b475
commit r10-10504-g063ef668c716ae0bf9c0f79ae62243e89075b475
Author: Peter Bergner
Date: Fri Mar 18 14:09:26 2022 -0500
rs6000: Allow -mlong-double-64 after -mabi={ibm,ieee}longdouble [PR104208,
PR87496]
The glibc build is showing a build error due to extra "error" checking from
my
PR87496 fix. That checking was overeager, disallowing setting the long
double
size to 64-bits if the 128-bit long double ABI had already been specified.
Now we only emit an error if we specify a 128-bit long double ABI if our
long double size is not 128 bits. This also fixes an erroneous error when
-mabi=ieeelongdouble is used and ISA 2.06 is not enabled, but the long
double
size has been changed to 64 bits.
2022-03-04 Peter Bergner
gcc/
PR target/87496
PR target/104208
* config/rs6000/rs6000.c (rs6000_option_override_internal): Make
the
ISA 2.06 requirement for -mabi=ieeelongdouble conditional on
-mlong-double-128.
Move the -mabi=ieeelongdouble and -mabi=ibmlongdouble error
checking
from here...
* common/config/rs6000/rs6000-common.c (rs6000_handle_option):
... to here.
gcc/testsuite/
PR target/87496
PR target/104208
* gcc.target/powerpc/pr104208-1.c: New test.
* gcc.target/powerpc/pr104208-2.c: Likewise.
* gcc.target/powerpc/pr87496-2.c: Swap long double options to
trigger
the expected error.
* gcc.target/powerpc/pr87496-3.c: Likewise.
(cherry picked from commit cb16bc3b5f34733ef9bbf8d2e3acacdecb099a62)
[Bug target/87496] ICE in aggregate_value_p at gcc/function.c:2046
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87496
--- Comment #15 from CVS Commits ---
The releases/gcc-11 branch has been updated by Peter Bergner
:
https://gcc.gnu.org/g:51a34fdff2af99e2bb096436d6872c8ea434d177
commit r11-9668-g51a34fdff2af99e2bb096436d6872c8ea434d177
Author: Peter Bergner
Date: Fri Mar 18 14:08:44 2022 -0500
rs6000: Allow -mlong-double-64 after -mabi={ibm,ieee}longdouble [PR104208,
PR87496]
The glibc build is showing a build error due to extra "error" checking from
my
PR87496 fix. That checking was overeager, disallowing setting the long
double
size to 64-bits if the 128-bit long double ABI had already been specified.
Now we only emit an error if we specify a 128-bit long double ABI if our
long double size is not 128 bits. This also fixes an erroneous error when
-mabi=ieeelongdouble is used and ISA 2.06 is not enabled, but the long
double
size has been changed to 64 bits.
2022-03-04 Peter Bergner
gcc/
PR target/87496
PR target/104208
* config/rs6000/rs6000.c (rs6000_option_override_internal): Make
the
ISA 2.06 requirement for -mabi=ieeelongdouble conditional on
-mlong-double-128.
Move the -mabi=ieeelongdouble and -mabi=ibmlongdouble error
checking
from here...
* common/config/rs6000/rs6000-common.c (rs6000_handle_option):
... to here.
gcc/testsuite/
PR target/87496
PR target/104208
* gcc.target/powerpc/pr104208-1.c: New test.
* gcc.target/powerpc/pr104208-2.c: Likewise.
* gcc.target/powerpc/pr87496-2.c: Swap long double options to
trigger
the expected error.
* gcc.target/powerpc/pr87496-3.c: Likewise.
(cherry picked from commit cb16bc3b5f34733ef9bbf8d2e3acacdecb099a62)
[Bug target/104208] -mlong-double-64 should override a previous -mabi=ibmlongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104208
--- Comment #14 from CVS Commits ---
The releases/gcc-11 branch has been updated by Peter Bergner
:
https://gcc.gnu.org/g:51a34fdff2af99e2bb096436d6872c8ea434d177
commit r11-9668-g51a34fdff2af99e2bb096436d6872c8ea434d177
Author: Peter Bergner
Date: Fri Mar 18 14:08:44 2022 -0500
rs6000: Allow -mlong-double-64 after -mabi={ibm,ieee}longdouble [PR104208,
PR87496]
The glibc build is showing a build error due to extra "error" checking from
my
PR87496 fix. That checking was overeager, disallowing setting the long
double
size to 64-bits if the 128-bit long double ABI had already been specified.
Now we only emit an error if we specify a 128-bit long double ABI if our
long double size is not 128 bits. This also fixes an erroneous error when
-mabi=ieeelongdouble is used and ISA 2.06 is not enabled, but the long
double
size has been changed to 64 bits.
2022-03-04 Peter Bergner
gcc/
PR target/87496
PR target/104208
* config/rs6000/rs6000.c (rs6000_option_override_internal): Make
the
ISA 2.06 requirement for -mabi=ieeelongdouble conditional on
-mlong-double-128.
Move the -mabi=ieeelongdouble and -mabi=ibmlongdouble error
checking
from here...
* common/config/rs6000/rs6000-common.c (rs6000_handle_option):
... to here.
gcc/testsuite/
PR target/87496
PR target/104208
* gcc.target/powerpc/pr104208-1.c: New test.
* gcc.target/powerpc/pr104208-2.c: Likewise.
* gcc.target/powerpc/pr87496-2.c: Swap long double options to
trigger
the expected error.
* gcc.target/powerpc/pr87496-3.c: Likewise.
(cherry picked from commit cb16bc3b5f34733ef9bbf8d2e3acacdecb099a62)
[Bug c++/104008] [11 Regression] New g++ folly compile error since r11-7931-ga2531859bf5bf6cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104008 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103769 CC||ppalka at gcc dot gnu.org --- Comment #11 from Patrick Palka --- FWIW it seems the new test g++.dg/cpp0x/variadic-alias3.C crashes when using --param=hash-table-verification-limit=1000, similar to PR103769.
[Bug go/104973] GCC 11.2.1 build failure with Go support (mv: cannot stat 'cpugen.o': No such file or directory)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104973 --- Comment #4 from Ian Lance Taylor --- The golang.org/x/sys/cpu.o is a different object file. That one uses gcpugen.go, not cpugen.go. The original reporter is not reporting any problems involving gcpugen.go. The cpugen.go (not gcpugen.go) file is an input for internal/cpu.o.
[Bug rtl-optimization/104961] [9/10/11/12 Regression] compilation never (?) finishes at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104961 --- Comment #3 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:0c016888ffd569c4b70722cf7df2efcc003f397b commit r12-7716-g0c016888ffd569c4b70722cf7df2efcc003f397b Author: Vladimir N. Makarov Date: Fri Mar 18 14:23:40 2022 -0400 [PR104961] LRA: split hard reg for reload pseudo with clobber. Splitting hard register live range did not work for subreg of a multi-reg reload pseudo. Reload insns for such pseudo contain clobber of the pseudo and splitting did not take this into account. The patch fixes it. gcc/ChangeLog: PR rtl-optimization/104961 * lra-assigns.cc (find_reload_regno_insns): Process reload pseudo clobber. gcc/testsuite/ChangeLog: PR rtl-optimization/104961 * gcc.target/i386/pr104961.c: New.
[Bug c++/101767] [10/11/12 Regression] Aggregate initialization fails for struct that has both unnamed struct and union fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101767 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org
[Bug c++/104476] [11 Regression] using-decl shadowed by member function when in incomplete-class context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104476 Jason Merrill changed: What|Removed |Added Summary|[11/12 Regression] |[11 Regression] using-decl |using-decl shadowed by |shadowed by member function |member function when in |when in incomplete-class |incomplete-class context|context Known to fail|12.0| Known to work||12.0 --- Comment #7 from Jason Merrill --- Fixed for GCC 12 so far.
[Bug c++/104476] [11/12 Regression] using-decl shadowed by member function when in incomplete-class context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104476 --- Comment #6 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:47da5198766256be658b4c321cecfd6039b0b91b commit r12-7714-g47da5198766256be658b4c321cecfd6039b0b91b Author: Jason Merrill Date: Fri Feb 25 15:07:15 2022 -0400 c++: using lookup within class defn [PR104476] The problem in both PR92918 and PR104476 is overloading of base member functions brought in by 'using' with direct member functions during parsing of the class body. To this point they've had a troublesome coexistence which was resolved by set_class_bindings when the class is complete, but we also need to handle lookup within the class body, such as in a trailing return type. The problem was that push_class_level_binding would either clobber the using-decl with the direct members or vice-versa. In older versions of GCC we only pushed dependent usings, and preferring the dependent using made sense, as it expresses a type-dependent overload set that we can't do anything useful with. But when we started keeping non-dependent usings around, push_class_level_binding in particular wasn't adjusted accordingly. This patch makes that adjustment, and pushes the functions imported by a non-dependent using immediately from finish_member_declaration. This made diagnosing redundant using-decls a bit awkward, since we no longer push the using-decl itself; I handle that by noticing when we try to add the same function again and searching TYPE_FIELDS for the previous using-decl. PR c++/92918 PR c++/104476 gcc/cp/ChangeLog: * class.cc (add_method): Avoid adding the same used function twice. (handle_using_decl): Don't add_method. (finish_struct): Don't using op= if we have one already. (maybe_push_used_methods): New. * semantics.cc (finish_member_declaration): Call it. * name-lookup.cc (diagnose_name_conflict): No longer static. (push_class_level_binding): Revert 92918 patch, limit to dependent using. * cp-tree.h: Adjust. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/pr85070.C: Remove expected error. * g++.dg/lookup/using66a.C: New test. * g++.dg/lookup/using67.C: New test.
[Bug c++/92918] [9/10 Regression] Does not do name lookup when using from base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918 --- Comment #9 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:47da5198766256be658b4c321cecfd6039b0b91b commit r12-7714-g47da5198766256be658b4c321cecfd6039b0b91b Author: Jason Merrill Date: Fri Feb 25 15:07:15 2022 -0400 c++: using lookup within class defn [PR104476] The problem in both PR92918 and PR104476 is overloading of base member functions brought in by 'using' with direct member functions during parsing of the class body. To this point they've had a troublesome coexistence which was resolved by set_class_bindings when the class is complete, but we also need to handle lookup within the class body, such as in a trailing return type. The problem was that push_class_level_binding would either clobber the using-decl with the direct members or vice-versa. In older versions of GCC we only pushed dependent usings, and preferring the dependent using made sense, as it expresses a type-dependent overload set that we can't do anything useful with. But when we started keeping non-dependent usings around, push_class_level_binding in particular wasn't adjusted accordingly. This patch makes that adjustment, and pushes the functions imported by a non-dependent using immediately from finish_member_declaration. This made diagnosing redundant using-decls a bit awkward, since we no longer push the using-decl itself; I handle that by noticing when we try to add the same function again and searching TYPE_FIELDS for the previous using-decl. PR c++/92918 PR c++/104476 gcc/cp/ChangeLog: * class.cc (add_method): Avoid adding the same used function twice. (handle_using_decl): Don't add_method. (finish_struct): Don't using op= if we have one already. (maybe_push_used_methods): New. * semantics.cc (finish_member_declaration): Call it. * name-lookup.cc (diagnose_name_conflict): No longer static. (push_class_level_binding): Revert 92918 patch, limit to dependent using. * cp-tree.h: Adjust. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/pr85070.C: Remove expected error. * g++.dg/lookup/using66a.C: New test. * g++.dg/lookup/using67.C: New test.
[Bug middle-end/99578] [11 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] gcc-11 |[11 Regression] gcc-11 |-Warray-bounds or |-Warray-bounds or |-Wstringop-overread warning |-Wstringop-overread warning |when accessing a pointer|when accessing a pointer |from integer literal|from integer literal --- Comment #37 from Jakub Jelinek --- Fixed on the trunk so far, temporarily by differentiating between < 4KB addresses which are still handled like GCC 11 did for warning purposes, and >= 4KB addresses where we won't warn anymore. For GCC 13 there is a plan for more complete solution.
[Bug c++/104568] [10/11 Regression] ICE [c++20] caused by option "-std=c++20 -Wall" when operand of operator new has size equal to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104568 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] ICE |[10/11 Regression] ICE |[c++20] caused by option|[c++20] caused by option |"-std=c++20 -Wall" when |"-std=c++20 -Wall" when |operand of operator new has |operand of operator new has |size equal to 0 |size equal to 0 --- Comment #7 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/100834] False positive of -Wstringop-overflow= with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100834 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:32ca611c42658948f1b8883994796f35e8b4e74d commit r12-7713-g32ca611c42658948f1b8883994796f35e8b4e74d Author: Jakub Jelinek Date: Fri Mar 18 18:58:06 2022 +0100 Allow (void *) 0xdeadbeef accesses without warnings [PR99578] Starting with GCC11 we keep emitting false positive -Warray-bounds or -Wstringop-overflow etc. warnings on widely used *(type *)0x12345000 style accesses (or memory/string routines to such pointers). This is a standard programming style supported by all C/C++ compilers I've ever tried, used mostly in kernel or DSP programming, but sometimes also together with mmap MAP_FIXED when certain things, often I/O registers but could be anything else too are known to be present at fixed addresses. Such INTEGER_CST addresses can appear in code either because a user used it like that (in which case it is fine) or because somebody used pointer arithmetics (including &((struct whatever *)NULL)->field) on a NULL pointer. The middle-end warning code wrongly assumes that the latter case is what is very likely, while the former is unlikely and users should change their code. The following patch adds a min-pagesize param defaulting to 4KB, and treats INTEGER_CST addresses smaller than that as assumed results of pointer arithmetics from NULL while addresses equal or larger than that as expected user constant addresses. For GCC 13 we can represent results from pointer arithmetics on NULL using &MEM[(void*)0 + offset] instead of (void*)offset INTEGER_CSTs. 2022-03-18 Jakub Jelinek PR middle-end/99578 PR middle-end/100680 PR tree-optimization/100834 * params.opt (--param=min-pagesize=): New parameter. * pointer-query.cc (compute_objsize_r) : Formatting fix. (compute_objsize_r) : Use maximum object size instead of zero for pointer constants equal or larger than min-pagesize. * gcc.dg/tree-ssa/pr99578-1.c: New test. * gcc.dg/pr99578-1.c: New test. * gcc.dg/pr99578-2.c: New test. * gcc.dg/pr99578-3.c: New test. * gcc.dg/pr100680.c: New test. * gcc.dg/pr100834.c: New test.
[Bug middle-end/99578] [11/12 Regression] gcc-11 -Warray-bounds or -Wstringop-overread warning when accessing a pointer from integer literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 --- Comment #36 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:32ca611c42658948f1b8883994796f35e8b4e74d commit r12-7713-g32ca611c42658948f1b8883994796f35e8b4e74d Author: Jakub Jelinek Date: Fri Mar 18 18:58:06 2022 +0100 Allow (void *) 0xdeadbeef accesses without warnings [PR99578] Starting with GCC11 we keep emitting false positive -Warray-bounds or -Wstringop-overflow etc. warnings on widely used *(type *)0x12345000 style accesses (or memory/string routines to such pointers). This is a standard programming style supported by all C/C++ compilers I've ever tried, used mostly in kernel or DSP programming, but sometimes also together with mmap MAP_FIXED when certain things, often I/O registers but could be anything else too are known to be present at fixed addresses. Such INTEGER_CST addresses can appear in code either because a user used it like that (in which case it is fine) or because somebody used pointer arithmetics (including &((struct whatever *)NULL)->field) on a NULL pointer. The middle-end warning code wrongly assumes that the latter case is what is very likely, while the former is unlikely and users should change their code. The following patch adds a min-pagesize param defaulting to 4KB, and treats INTEGER_CST addresses smaller than that as assumed results of pointer arithmetics from NULL while addresses equal or larger than that as expected user constant addresses. For GCC 13 we can represent results from pointer arithmetics on NULL using &MEM[(void*)0 + offset] instead of (void*)offset INTEGER_CSTs. 2022-03-18 Jakub Jelinek PR middle-end/99578 PR middle-end/100680 PR tree-optimization/100834 * params.opt (--param=min-pagesize=): New parameter. * pointer-query.cc (compute_objsize_r) : Formatting fix. (compute_objsize_r) : Use maximum object size instead of zero for pointer constants equal or larger than min-pagesize. * gcc.dg/tree-ssa/pr99578-1.c: New test. * gcc.dg/pr99578-1.c: New test. * gcc.dg/pr99578-2.c: New test. * gcc.dg/pr99578-3.c: New test. * gcc.dg/pr100680.c: New test. * gcc.dg/pr100834.c: New test.
[Bug middle-end/100680] false positive warning for certain __builtin_memcmp() argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100680 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:32ca611c42658948f1b8883994796f35e8b4e74d commit r12-7713-g32ca611c42658948f1b8883994796f35e8b4e74d Author: Jakub Jelinek Date: Fri Mar 18 18:58:06 2022 +0100 Allow (void *) 0xdeadbeef accesses without warnings [PR99578] Starting with GCC11 we keep emitting false positive -Warray-bounds or -Wstringop-overflow etc. warnings on widely used *(type *)0x12345000 style accesses (or memory/string routines to such pointers). This is a standard programming style supported by all C/C++ compilers I've ever tried, used mostly in kernel or DSP programming, but sometimes also together with mmap MAP_FIXED when certain things, often I/O registers but could be anything else too are known to be present at fixed addresses. Such INTEGER_CST addresses can appear in code either because a user used it like that (in which case it is fine) or because somebody used pointer arithmetics (including &((struct whatever *)NULL)->field) on a NULL pointer. The middle-end warning code wrongly assumes that the latter case is what is very likely, while the former is unlikely and users should change their code. The following patch adds a min-pagesize param defaulting to 4KB, and treats INTEGER_CST addresses smaller than that as assumed results of pointer arithmetics from NULL while addresses equal or larger than that as expected user constant addresses. For GCC 13 we can represent results from pointer arithmetics on NULL using &MEM[(void*)0 + offset] instead of (void*)offset INTEGER_CSTs. 2022-03-18 Jakub Jelinek PR middle-end/99578 PR middle-end/100680 PR tree-optimization/100834 * params.opt (--param=min-pagesize=): New parameter. * pointer-query.cc (compute_objsize_r) : Formatting fix. (compute_objsize_r) : Use maximum object size instead of zero for pointer constants equal or larger than min-pagesize. * gcc.dg/tree-ssa/pr99578-1.c: New test. * gcc.dg/pr99578-1.c: New test. * gcc.dg/pr99578-2.c: New test. * gcc.dg/pr99578-3.c: New test. * gcc.dg/pr100680.c: New test. * gcc.dg/pr100834.c: New test.
[Bug c++/104568] [10/11/12 Regression] ICE [c++20] caused by option "-std=c++20 -Wall" when operand of operator new has size equal to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104568
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0a0c2c3f06227d46b5e9542dfdd4e0fd2d67d894
commit r12-7712-g0a0c2c3f06227d46b5e9542dfdd4e0fd2d67d894
Author: Jakub Jelinek
Date: Fri Mar 18 18:49:23 2022 +0100
c++: Fix up constexpr evaluation of new with zero sized types [PR104568]
The new expression constant expression evaluation right now tries to
deduce how many elts the array it uses for the heap or heap [] vars
should have (or how many elts should its trailing array have if it has
cookie at the start). As new is lowered at that point to
(some_type *) ::operator new (size)
or so, it computes it by subtracting cookie size if any from size, then
divides the result by sizeof (some_type).
This works fine for most types, except when sizeof (some_type) is 0,
then we divide by zero; size is then equal to cookie_size (or if there
is no cookie, to 0).
The following patch special cases those cases so that we don't divide
by zero and also recover the original outer_nelts from the expression
by forcing the size not to be folded in that case but be explicit
0 * outer_nelts or cookie_size + 0 * outer_nelts.
Note, we have further issues, we accept-invalid various cases, for both
zero sized elt_type and even non-zero sized elts, we aren't able to
diagnose out of bounds POINTER_PLUS_EXPR like:
constexpr bool
foo ()
{
auto p = new int[2];
auto q1 = &p[0];
auto q2 = &p[1];
auto q3 = &p[2];
auto q4 = &p[3];
delete[] p;
return true;
}
constexpr bool a = foo ();
That doesn't look like a regression so I think we should resolve that for
GCC 13, but there are 2 problems. Figure out why
cxx_fold_pointer_plus_expression doesn't deal with the &heap []
etc. cases, and for the zero sized arrays, I think we really need to
preserve
whether user wrote an array ref or pointer addition, because in the
&p[3] case if sizeof(p[0]) == 0 we know that if it has 2 elements it is
out of bounds, while if we see p p+ 0 the information if it was
p + 2 or p + 3 in the source is lost.
clang++ seems to handle it fine even in the zero sized cases or with
new expressions.
2022-03-18 Jakub Jelinek
PR c++/104568
* init.cc (build_new_constexpr_heap_type): Remove FULL_SIZE
argument and its handling, instead add ITYPE2 argument. Only
support COOKIE_SIZE != NULL.
(build_new_1): If size is 0, change it to 0 * outer_nelts if
outer_nelts is non-NULL. Pass type rather than elt_type to
maybe_wrap_new_for_constexpr.
* constexpr.cc (build_new_constexpr_heap_type): New function.
(cxx_eval_constant_expression) :
If elt_size is zero sized type, try to recover outer_nelts from
the size argument to operator new/new[] and pass that as
arg_size to build_new_constexpr_heap_type. Pass ctx,
non_constant_p and overflow_p to that call too.
* g++.dg/cpp2a/constexpr-new22.C: New test.
[Bug libstdc++/104242] [12 Regression] Class with constructor from std::any is not copyable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104242 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Jonathan Wakely --- Fixed
[Bug middle-end/104971] [9/10/11/12 Regression] Optimisation for __builtin_ia32_readeflags corrupts the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104971 --- Comment #5 from Jakub Jelinek --- Created attachment 52650 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52650&action=edit gcc12-pr104971.patch Here is untested patch with the optimization not to expand the pushf/pop at all if we don't need the result. Though, the LRA bug will remain latent with it and should be fixed anyway.
[Bug c++/104008] [11 Regression] New g++ folly compile error since r11-7931-ga2531859bf5bf6cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104008 Marek Polacek changed: What|Removed |Added Summary|[11/12 Regression] New g++ |[11 Regression] New g++ |folly compile error since |folly compile error since |r11-7931-ga2531859bf5bf6cf |r11-7931-ga2531859bf5bf6cf --- Comment #10 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/104008] [11/12 Regression] New g++ folly compile error since r11-7931-ga2531859bf5bf6cf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104008
--- Comment #9 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:c7a6a32739d62deab03266e2b5449fce261b1ecb
commit r12-7710-gc7a6a32739d62deab03266e2b5449fce261b1ecb
Author: Marek Polacek
Date: Wed Mar 16 09:34:34 2022 -0400
c++: alias template and empty parameter packs [PR104008]
Zero-length pack expansions are treated as if no list were provided
at all, that is, with
template struct S { };
template
void g() {
S...>;
}
g will result in S<>. In the following test we have something
similar:
template
using IsOneOf = disjunction...>;
and then we have "IsOneOf..." where OtherHolders is an
empty pack. Since r11-7931, we strip_typedefs in TYPE_PACK_EXPANSION.
In this test that results in "IsOneOf" being turned into
"disjunction<>". So the whole expansion is now "disjunction<>...". But
then we error in make_pack_expansion because find_parameter_packs_r won't
find the pack OtherHolders.
We strip the alias template because dependent_alias_template_spec_p says
it's not dependent. It it not dependent because this alias is not
TEMPLATE_DECL_COMPLEX_ALIAS_P. My understanding is that currently we
consider an alias complex if it
1) expands a pack from the enclosing class, as in
template typename... TT>
struct S {
template
using X = P...>;
};
where the alias expands TT; or
2) the expansion does *not* name all the template parameters, as in
template struct R;
template
using U = R...>;
where T is not named in the expansion.
But IsOneOf is neither. And it can't know how it's going to be used.
Therefore I think we cannot make it complex (and in turn dependent) to fix
this bug.
After much gnashing of teeth, I think we simply want to avoid stripping
the alias if the new pattern doesn't have any parameter packs to expand.
PR c++/104008
gcc/cp/ChangeLog:
* tree.cc (strip_typedefs): Don't strip an alias template when
doing so would result in losing a parameter pack.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/variadic-alias3.C: New test.
* g++.dg/cpp0x/variadic-alias4.C: New test.
[Bug fortran/103039] [12 Regression] Segfault with openmp block within a select type block since r12-1016-g0e3b3b77e13cac76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103039 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Tobias Burnus --- Should be FIXED (on mainline, which will become 12.1) Thanks for the report, Martin – sorry for fixing it not more quickly. Thanks Richard & Jakub for the debugging!
[Bug fortran/103039] [12 Regression] Segfault with openmp block within a select type block since r12-1016-g0e3b3b77e13cac76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103039 --- Comment #10 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:c133bdfa9e7d9225510d00dbb7270cc052e4e4ee commit r12-7709-gc133bdfa9e7d9225510d00dbb7270cc052e4e4ee Author: Tobias Burnus Date: Fri Mar 18 17:40:22 2022 +0100 Fortran/OpenMP: Fix privatization of associated names gfc_omp_predetermined_sharing cases the associate-name pointer variable to be OMP_CLAUSE_DEFAULT_FIRSTPRIVATE, which is fine. However, the associated selector is shared. Thus, the target of associate-name pointer should not get copied. (It was before but because of gfc_omp_privatize_by_reference returning false, the selector was not only wrongly copied but this was also not done properly.) gcc/fortran/ChangeLog: PR fortran/103039 * trans-openmp.cc (gfc_omp_clause_copy_ctor, gfc_omp_clause_dtor): Only privatize pointer for associate names. libgomp/ChangeLog: PR fortran/103039 * testsuite/libgomp.fortran/associate4.f90: New test.
[Bug c++/100557] [concepts] Internal compiler error: Error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100557
--- Comment #3 from Patrick Palka ---
Reduced:
template _Tp declval();
struct print_tag_;
bool tag_invoke(print_tag_, auto);
bool tag_invoke(print_tag_, auto obj) requires requires { *obj; };
template
auto try_tag_invoke() noexcept(tag_invoke(declval, declval()...))
-> decltype(tag_invoke(CPO(), declval()...));
struct print_tag_ {
void operator()(auto... args) noexcept(noexcept( try_tag_invoke()));
} print;
void foo() {
print(0);
}
[Bug libstdc++/104242] [12 Regression] Class with constructor from std::any is not copyable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104242 --- Comment #4 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:7a42b1fa1a090ead96cc0f94a8060a9650c810d5 commit r12-7708-g7a42b1fa1a090ead96cc0f94a8060a9650c810d5 Author: Jonathan Wakely Date: Fri Mar 18 13:10:01 2022 + libstdc++: Simplify constraints for std::any construction [PR104242] Partially revert r12-4190-g6da36b7d0e43b6f9281c65c19a025d4888a25b2d because using __and_<..., is_copy_constructible> when T is incomplete results in an error about deriving from is_copy_constructible when that is incomplete. I don't know how to fix that, so this simply restores the previous constraint which worked in this case (even though I think it's technically undefined to use is_copy_constructible with incomplete T). This doesn't restore exactly what we had before, but uses the is_copy_constructible_v and __is_in_place_type_v variable templates instead of the ::value member. libstdc++-v3/ChangeLog: PR libstdc++/104242 * include/std/any (any(T&&)): Revert change to constraints. * testsuite/20_util/any/cons/104242.cc: New test.
[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 #7 from Jonathan Wakely --- https://reviews.llvm.org/D119544 should fix this when it lands.
[Bug target/104968] [nvptx][OpenMP] SIGSEGV / ICE in final_scan_insn_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104968 Tom de Vries changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.0 Status|UNCONFIRMED |RESOLVED --- Comment #7 from Tom de Vries --- Fixed by https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=356e2720e9030927579024c2f060d665a0b9080f .
[Bug c++/104981] New: [coroutines] Internal compiler error when promise object's constructor takes a base class of the object parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104981
Bug ID: 104981
Summary: [coroutines] Internal compiler error when promise
object's constructor takes a base class of the object
parameter
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ensadc at mailnesia dot com
CC: iains at gcc dot gnu.org
Target Milestone: ---
#include
class Base {};
struct PromiseType;
struct Result {
using promise_type = PromiseType;
};
struct PromiseType {
PromiseType(const Base& parser, auto&&...) {}
Result get_return_object() { return {}; }
static std::suspend_never initial_suspend() { return {}; }
static std::suspend_always final_suspend() noexcept { return {}; }
[[noreturn]] static void unhandled_exception() { throw; }
void return_value(int) {}
};
struct Derived : Base {
Result f() {
co_return 42;
}
};
int main() {
Derived d;
d.f();
}
test.cpp: In member function ‘Result Derived::f()’:
test.cpp:26:5: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have reference_type in lookup_base, at
cp/search.cc:233
26 | }
| ^
0x8e421c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/gcc/tree.cc:8724
0x751a6a tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code)
../../gcc/gcc/tree.h:3490
0x751a6a lookup_base(tree_node*, tree_node*, int, base_kind*, int)
../../gcc/gcc/cp/search.cc:233
0xa58c38 convert_to_base(tree_node*, tree_node*, bool, bool, int)
../../gcc/gcc/cp/class.cc:627
0xa2cfc2 convert_like_internal
../../gcc/gcc/cp/call.cc:8166
0xa2c5b0 convert_like_internal
../../gcc/gcc/cp/call.cc:8122
0xa316e1 convert_like_with_context
../../gcc/gcc/cp/call.cc:8466
0xa316e1 build_over_call
../../gcc/gcc/cp/call.cc:9579
0xa34d5b build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.cc:11171
0xa36147 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
../../gcc/gcc/cp/call.cc:10645
0xa9375d morph_fn_to_coro(tree_node*, tree_node**, tree_node**)
../../gcc/gcc/cp/coroutines.cc:4912
0xade26f finish_function(bool)
../../gcc/gcc/cp/decl.cc:17718
0xbd22f2 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.cc:31242
0xbd2645 cp_parser_late_parsing_for_member
../../gcc/gcc/cp/parser.cc:32161
0xba8c71 cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.cc:26176
0xba9f7c cp_parser_class_specifier
../../gcc/gcc/cp/parser.cc:26200
0xba9f7c cp_parser_type_specifier
../../gcc/gcc/cp/parser.cc:19344
0xbab06c cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.cc:15903
0xbabc04 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.cc:15151
0xbd9f32 cp_parser_declaration
../../gcc/gcc/cp/parser.cc:14964
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c/33053] adopt accesses through a volatile-casted pointer as a GNU C extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33053 Segher Boessenkool changed: What|Removed |Added CC||msebor at gcc dot gnu.org, ||segher at gcc dot gnu.org --- Comment #3 from Segher Boessenkool --- For C this is DR 476, which is on the way for C2x.
[Bug target/104952] [nvptx][OpenMP] wrong code with OR / AND reduction ('reduction(||:' and '&&') with SIMT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952
--- Comment #11 from CVS Commits ---
The master branch has been updated by Tom de Vries :
https://gcc.gnu.org/g:093cdadbce30ce2d36846a05d979b8afc2eff618
commit r12-7702-g093cdadbce30ce2d36846a05d979b8afc2eff618
Author: Tom de Vries
Date: Thu Mar 17 14:37:28 2022 +0100
[openmp] Fix SIMT reduction using TRUTH_{AND,OR}IF_EXPR
Consider test-case pr104952-1.c, included in this commit, containing:
...
#pragma omp target map(tofrom:result) map(to:arr)
#pragma omp simd reduction(||: result)
...
When run on x86_64 with nvptx accelerator, the test-case either aborts or
hangs.
The reduction clause is translated by the SIMT code (active for nvptx) as a
butterfly reduction loop with this butterfly shuffle / update pair:
...
D.2163 = D.2163 || .GOMP_SIMT_XCHG_BFLY (D.2163, D.2164)
...
in the loop body.
The problem is that the butterfly shuffle is possibly not executed, while
it
needs to be executed unconditionally.
Fix this by translating instead as:
...
D.tmp_bfly = .GOMP_SIMT_XCHG_BFLY (D.2163, D.2164)
D.2163 = D.2163 || D.tmp_bfly
...
Tested on x86_64-linux with nvptx accelerator.
gcc/ChangeLog:
2022-03-17 Tom de Vries
PR target/104952
* omp-low.cc (lower_rec_input_clauses): Make sure
GOMP_SIMT_XCHG_BFLY
is executed unconditionally.
libgomp/ChangeLog:
2022-03-17 Tom de Vries
PR target/104952
* testsuite/libgomp.c/pr104952-1.c: New test.
* testsuite/libgomp.c/pr104952-2.c: New test.
[Bug target/104952] [nvptx][OpenMP] wrong code with OR / AND reduction ('reduction(||:' and '&&') with SIMT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104952
Tom de Vries changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|--- |12.0
Status|UNCONFIRMED |RESOLVED
--- Comment #12 from Tom de Vries ---
Fixed by "[openmp] Fix SIMT reduction using TRUTH_{AND,OR}IF_EXPR".
[Bug middle-end/104854] -Wstringop-overread should not warn for strnlen, strndup and strncmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104854 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #10 from Martin Sebor --- I forgot this strndup pitfall that POSIX cautions about in its APPLICATION USAGE and that the warning helps avoid: Implementations are free to malloc() a buffer containing either (size + 1) bytes or (strnlen(s, size) + 1) bytes. Applications should not assume that strndup() will allocate (size + 1) bytes when strlen(s) is smaller than size. Most implementations, including Glibc, only allocate strnlen (s, size) (i.e., less than size if s is shorter). Since the only motivating test case here is strndup and since it turned out that the patch submitted for this report was based on a misunderstanding of the warning (https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591926.html) and didn't do anything for strndup I'm going to resolve this as invalid. If you want to raise problems about the warning for strnlen or strncmp please open separate bugs and attach test cases, preferably from real code. None of those provided by Steve Grubb appears to have anything to do with strnlen or strncmp.
[Bug target/104901] gcc/config/rs6000/mm_malloc.h:46: incorrectLogicOperator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104901 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #4 from Segher Boessenkool --- Yes, the code is correct as written. There are many ways to avoid this warning of course (and the warning is too smart for its own good, imnsho -- if it read "__alignment == 16 && __alignment == 16" that would be a different thing, but as-is this just invites us to write less clear (i.e, worse!) code to avoid the warning. On the other hand. Paul, is this micro-optimisation useful at all, don't posix_memalign and malloc end up the same under the covers anyway?
[Bug c++/104980] Bad error on variable template instantiation failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104980
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2022-03-18
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #1 from Jonathan Wakely ---
(In reply to Darrell Wright from comment #0)
> The error generated when a variable template instantiation failure happens
> is unhelpful. Clang provides more context in their error output.
>
> With the following code
> https://gcc.godbolt.org/z/KoYf7rhEq
> #include
>
> template
> inline constexpr bool dependent_false_v = false;
>
> struct deleted_t{};
> inline constexpr auto deleted = deleted_t{};
>
> #define DELETED_VARIABLE std::enable_if_t, deleted_t>
>
> template
> inline constexpr DELETED_VARIABLE is_foo = deleted;
>
> template <>
> inline constexpr bool is_foo = true;
>
> auto a = is_foo;
> auto b = is_foo;
>
> gcc outputs only:
> 2614 | using enable_if_t = typename enable_if<_Cond, _Tp>::type;
> | ^~~
And the location where enable_if_t is used:
:4:62: required from here
But you're right it doesn't show where the variable template is instantiated.
Reduced to get rid of the irrelevant parts:
#include
template
inline constexpr std::enable_if_t, T> is_foo = {};
template <>
inline constexpr bool is_foo = true;
auto a = is_foo;
auto b = is_foo;
GCC:
In file included from 104980.C:1:
/home/jwakely/gcc/12/include/c++/12.0.1/type_traits: In substitution of
'template using enable_if_t = typename
std::enable_if::type [with bool _Cond = false; _Tp = bool]':
104980.C:4:62: required from here
/home/jwakely/gcc/12/include/c++/12.0.1/type_traits:2614:11: error: no type
named 'type' in 'struct std::enable_if'
2614 | using enable_if_t = typename enable_if<_Cond, _Tp>::type;
| ^~~
Clang:
/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/type_traits:2585:44:
error: no type named 'type' in 'std::enable_if'; 'enable_if'
cannot be used to disable this declaration
using enable_if_t = typename enable_if<_Cond, _Tp>::type;
^
104980.C:4:23: note: in instantiation of template type alias 'enable_if_t'
requested here
inline constexpr std::enable_if_t, T> is_foo = {};
^
104980.C:10:10: note: in instantiation of variable template specialization
'is_foo' requested here
auto b = is_foo;
^
1 error generated.
EDG:
"/usr/lib/gcc/x86_64-redhat-linux/11/../../../../include/c++/11/type_traits",
line 2585: error: class "std::enable_if" has no member
"type"
using enable_if_t = typename enable_if<_Cond, _Tp>::type;
^
detected during:
instantiation of type "std::enable_if_t" at line 4 of
"104980.C"
instantiation of "const std::enable_if_t is_foo
[with T=bool]" at line 10 of "104980.C"
1 error detected in the compilation of "104980.C".
[Bug c++/104980] New: Bad error on variable template instantiation failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104980
Bug ID: 104980
Summary: Bad error on variable template instantiation failure
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Darrell.Wright at gmail dot com
Target Milestone: ---
The error generated when a variable template instantiation failure happens is
unhelpful. Clang provides more context in their error output.
With the following code
https://gcc.godbolt.org/z/KoYf7rhEq
#include
template
inline constexpr bool dependent_false_v = false;
struct deleted_t{};
inline constexpr auto deleted = deleted_t{};
#define DELETED_VARIABLE std::enable_if_t, deleted_t>
template
inline constexpr DELETED_VARIABLE is_foo = deleted;
template <>
inline constexpr bool is_foo = true;
auto a = is_foo;
auto b = is_foo;
gcc outputs only:
2614 | using enable_if_t = typename enable_if<_Cond, _Tp>::type;
| ^~~
Whereas clang gives both the definition and call site in its output:
using enable_if_t = typename enable_if<_Cond, _Tp>::type;
^
:12:18: note: in instantiation of template type alias 'enable_if_t'
requested here
inline constexpr DELETED_VARIABLE is_foo = deleted;
^
:9:31: note: expanded from macro 'DELETED_VARIABLE'
#define DELETED_VARIABLE std::enable_if_t, deleted_t>
^
:18:10: note: in instantiation of variable template specialization
'is_foo' requested here
auto b = is_foo;
This is more desirable as one can see what is going on. Would it be possible
to output better information so that a developer can more clearly see what
failed?
[Bug fortran/103039] [12 Regression] Segfault with openmp block within a select type block since r12-1016-g0e3b3b77e13cac76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103039 --- Comment #9 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:6393122d271a92d5d9d8656a57ea167e92498871 commit r12-7701-g6393122d271a92d5d9d8656a57ea167e92498871 Author: Tobias Burnus Date: Fri Mar 18 14:50:36 2022 +0100 Fortran/OpenMP: Improve associate-name diagnostic [PR103039] gcc/fortran/ChangeLog: PR fortran/103039 * openmp.cc (resolve_omp_clauses): Improve associate-name diagnostic for select type/rank. gcc/testsuite/ChangeLog: PR fortran/103039 * gfortran.dg/gomp/associate1.f90: Update dg-error. * gfortran.dg/gomp/associate2.f90: New test.
[Bug analyzer/104979] New: False positive from -Wanalyzer-malloc-leak with cast within boxed pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104979
Bug ID: 104979
Summary: False positive from -Wanalyzer-malloc-leak with cast
within boxed pointer
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Given:
#include
typedef struct boxed_ptr { void *value; } boxed_ptr;
boxed_ptr
boxed_malloc (size_t sz)
{
boxed_ptr result;
result.value = malloc (sz);
return result;
}
boxed_ptr
boxed_free (boxed_ptr ptr)
{
free (ptr.value);
}
const boxed_ptr boxed_null = {NULL};
struct link
{
boxed_ptr m_ptr;
};
boxed_ptr test_29 (void)
{
boxed_ptr res = boxed_malloc (sizeof (struct link));
if (!res.value)
return boxed_null;
((struct link *)res.value)->m_ptr = boxed_malloc (sizeof (struct link));
return res;
}
-fanalyzer emits (incorrectly, I think):
: In function 'boxed_malloc':
:10:10: warning: leak of '.value' [CWE-401]
[-Wanalyzer-malloc-leak]
10 | return result;
| ^~
'test_29': events 1-4
|
| 26 | boxed_ptr test_29 (void)
| | ^~~
| | |
| | (1) entry to 'test_29'
|..
| 29 | if (!res.value)
| | ~
| | |
| | (2) following 'false' branch...
| 30 | return boxed_null;
| 31 | ((struct link *)res.value)->m_ptr = boxed_malloc (sizeof (struct
link));
| | ~
~~~
| | ||
| | |(4) calling 'boxed_malloc'
from 'test_29'
| | (3) ...to here
|
+--> 'boxed_malloc': events 5-7
|
|6 | boxed_malloc (size_t sz)
| | ^~~~
| | |
| | (5) entry to 'boxed_malloc'
|..
|9 | result.value = malloc (sz);
| | ~~~
| | |
| | (6) allocated here
| 10 | return result;
| | ~~
| | |
| | (7) '.value' leaks here; was
allocated at (6)
|
https://godbolt.org/z/1e9n8dnvM
[Bug c++/59950] [9/10/11 Regression] Bogus diagnostic "taking address of temporary" taking address of trivial no-op assignment to temporary with empty class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59950 Patrick Palka changed: What|Removed |Added CC||aschepler at gmail dot com --- Comment #7 from Patrick Palka --- *** Bug 54319 has been marked as a duplicate of this bug. ***
[Bug c++/54319] [9/10/11/12 Regression] empty class causes error while non-empty does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #14 from Patrick Palka --- Looks like this is essentially a dup of the recently fixed on trunk PR59950. *** This bug has been marked as a duplicate of bug 59950 ***
[Bug target/104978] [avx512fp16] wrong code for _mm_mask_fcmadd_round_sch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104978
--- Comment #3 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #2)
> (In reply to Hongtao.liu from comment #0)
> > #include
> > __m128h
> > foo (__m128h a, __m128h b, __m128h c, __mmask8 m)
> > {
> > return _mm_mask_fcmadd_round_sch (a, m, b, c, 8);
> > }
> >
> >
> > _Z3fooDv8_DF16_S_S_h:
> > kmovd k1, edi
> > vfcmaddcsh xmm2{k1}, xmm0, xmm1, {rn-sae}
> > vmovaps xmm0{k1}, xmm2
> > ret
> >
> > k1 must & 1 before vmovaps xmm0{k1}, xmm2.
>
> Or just vmovaps xmm0, xmm2 since vfcmaddcsh will copy upper [32:128] from
> src1(xmm0) here.
No, intrinsic guide it using writemask k (elements are copied from a when mask
bit 0 is not set)
[Bug target/104978] [avx512fp16] wrong code for _mm_mask_fcmadd_round_sch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104978
--- Comment #2 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #0)
> #include
> __m128h
> foo (__m128h a, __m128h b, __m128h c, __mmask8 m)
> {
> return _mm_mask_fcmadd_round_sch (a, m, b, c, 8);
> }
>
>
> _Z3fooDv8_DF16_S_S_h:
> kmovd k1, edi
> vfcmaddcsh xmm2{k1}, xmm0, xmm1, {rn-sae}
> vmovaps xmm0{k1}, xmm2
> ret
>
> k1 must & 1 before vmovaps xmm0{k1}, xmm2.
Or just vmovaps xmm0, xmm2 since vfcmaddcsh will copy upper [32:128] from
src1(xmm0) here.
[Bug target/104968] [nvptx][OpenMP] SIGSEGV / ICE in final_scan_insn_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104968 --- Comment #6 from Tom de Vries --- (In reply to Tom de Vries from comment #5) > This patch fixes the ICE at openmp level: > ... > diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc > index 139a0de6100..19af384c634 100644 > --- a/gcc/gimplify.cc > +++ b/gcc/gimplify.cc > @@ -13361,6 +13361,7 @@ gimplify_omp_for (tree *expr_p, gimple_seq *pre_p) >g = gimple_build_bind (NULL_TREE, gfor, NULL_TREE); >g = gimple_build_omp_task (g, task_clauses, NULL_TREE, NULL_TREE, > NULL_TREE, NULL_TREE, NULL_TREE); > + gimple_set_location (g, EXPR_LOCATION (*expr_p)); >gimple_omp_task_set_taskloop_p (g, true); >g = gimple_build_bind (NULL_TREE, g, NULL_TREE); >gomp_for *gforo > ... Submitted a more complete patch here ( https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591954.html ).
[Bug libstdc++/103407] [12 regression] abi_check FAILs on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103407 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #14 from Jonathan Wakely --- Rainer confirmed on the mailing list that this is fixed.
[Bug target/104978] [avx512fp16] wrong code for _mm_mask_fcmadd_round_sch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104978 --- Comment #1 from Hongtao.liu --- Similar for _mm_mask_fmadd_round_sch
[Bug target/104977] [avx512fp16] wrong code for vfmaddcsh when -masm=intel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104977 --- Comment #1 from Hongtao.liu --- Similar for _mm_fmadd_round_sch
[Bug fortran/103039] [12 Regression] Segfault with openmp block within a select type block since r12-1016-g0e3b3b77e13cac76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103039 --- Comment #8 from Jakub Jelinek --- So it means the firstprivate clause is added implicitly during gimplification (with OMP_CLAUSE_FIRSTPRIVATE_IMPLICIT?) for it. If we want to firstprivatize just the pointer and not what it points to, perhaps we should arrange for OMP_CLAUSE_FIRSTPRIVATE_NO_REFERENCE to be set on it and then take it into account in gfc_omp_clause_copy_ctor etc. and just do what we used to do before (i.e. copy the pointer and nothing else).
[Bug fortran/103039] [12 Regression] Segfault with openmp block within a select type block since r12-1016-g0e3b3b77e13cac76
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103039
--- Comment #7 from Tobias Burnus ---
(In reply to Jakub Jelinek from comment #6)
> I think the way to achieve this would be make sure to return true from the
> gfc_omp_privatize_by_reference hook.
What puzzles me is actually the reverse:
class(a), pointer :: x
...
select type (x)
class is (a)
!$omp parallel do default(shared) private(k) reduction(+:s)
Looking at the dump, one sees in the gimple dump:
#pragma omp parallel private(k) reduction(+:s) default(shared)
firstprivate(__tmp_class_a)
I think it is okay that __tmp_class_a is firstprivate – but in any case, no
deep copy should then be done in gfc_omp_clause_copy_ctor.
* * *
Regarding why the firstprivate shows up:
gfc_omp_predetermined_sharing returns OMP_CLAUSE_DEFAULT_FIRSTPRIVATE because
of:
/* Associate names preserve the association established during ASSOCIATE.
As they are implemented either as pointers to the selector or array
descriptor and shouldn't really change in the ASSOCIATE region,
this decl can be either shared or firstprivate. If it is a pointer,
use firstprivate, as it is cheaper that way, otherwise make it shared. */
if (GFC_DECL_ASSOCIATE_VAR_P (decl))
{
if (TREE_CODE (TREE_TYPE (decl)) == POINTER_TYPE)
return OMP_CLAUSE_DEFAULT_FIRSTPRIVATE;
else
return OMP_CLAUSE_DEFAULT_SHARED;
}
Added in commit r5-1190-g92d28cbb59cc5a611af41342c5b224fbf779a44d
* * *
BTW, using: firstprivate(x) fails with
Error: ASSOCIATE name ‘__tmp_class_a’ in FIRSTPRIVATE clause at (1)
While
select type (y => x)
class is (a)
!$omp parallel do default(shared) private(k) reduction(+:s) firstprivate(x)
is accepted but while the original dump has 'firstprivate(x)', it is removed
(as unused) during gimplify, resulting the output above.
Note: Associate names can appear for 'associate', 'select type', 'select rank'
and 'change team'. — For 'select type/rank', the selector name is the same as
the selector (wihch must be a variable) when left out.
* * *
OpenMP has for "predetermined data-sharing attributes":
"An associate name that may appear in a variable definition context is shared
if its association occurs outside of the construct and otherwise it has the
same data-sharing attribute as the selector with which it is associated."
[Bug target/104978] New: [avx512fp16] wrong code for _mm_mask_fcmadd_round_sch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104978
Bug ID: 104978
Summary: [avx512fp16] wrong code for _mm_mask_fcmadd_round_sch
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
#include
__m128h
foo (__m128h a, __m128h b, __m128h c, __mmask8 m)
{
return _mm_mask_fcmadd_round_sch (a, m, b, c, 8);
}
_Z3fooDv8_DF16_S_S_h:
kmovd k1, edi
vfcmaddcsh xmm2{k1}, xmm0, xmm1, {rn-sae}
vmovaps xmm0{k1}, xmm2
ret
k1 must & 1 before vmovaps xmm0{k1}, xmm2.
[Bug c++/104565] [10/11 Regression] constexpr template goes wrong with class and call to constexpr method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104565 Patrick Palka changed: What|Removed |Added CC||davide.gadioli at polimi dot it --- Comment #6 from Patrick Palka --- *** Bug 102980 has been marked as a duplicate of this bug. ***
[Bug c++/102980] [10/11/12 Regression] Fail to get an r-value from std::array::size in a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102980 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #3 from Patrick Palka --- Looks like PR104565, which has recently been fixed on trunk, is a dup of this PR. So I guess let's instead mark this PR a dup of that one. *** This bug has been marked as a duplicate of bug 104565 ***
[Bug target/104977] New: [avx512fp16] wrong code for vfmaddcsh when -masm=intel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104977
Bug ID: 104977
Summary: [avx512fp16] wrong code for vfmaddcsh when
-masm=intel.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
#include
__m128h
foo (__m128h a, __m128h b, __m128h c, __mmask8 m)
{
return _mm_fcmadd_round_sch (a, b, c, 8);
}
with asm=intel generates
_Z3fooDv8_DF16_S_S_h:
vfcmaddcsh xmm2, xmm0, xmm1
vmovdqa xmm0, xmm2
ret
[Bug target/104974] [avx512fp16] Error: operand type mismatch for `vmovw'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104974 Hongtao.liu changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Hongtao.liu --- Fixed in GCC12.
[Bug target/104974] [avx512fp16] Error: operand type mismatch for `vmovw'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104974 --- Comment #2 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:1f5c0e67393e8f67d66150eba8c64edfeb14e11b commit r12-7700-g1f5c0e67393e8f67d66150eba8c64edfeb14e11b Author: liuhongt Date: Fri Mar 18 16:11:04 2022 +0800 Refine HImode movement for "v" to "v". Set attr from HImode to HFmode which uses vmovsh instead of vmovw for movment between sse registers. gcc/ChangeLog: PR target/104974 * config/i386/i386.md (*movhi_internal): Set attr type from HI to HF for alternative 12 under TARGET_AVX512FP16. gcc/testsuite/ChangeLog: * gcc.target/i386/pr104974.c: New test.
[Bug d/103528] [12 regression] d21 doesn't build on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103528 --- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE --- "ro at CeBiTec dot Uni-Bielefeld.DE" writes: > --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- >> --- Comment #10 from Richard Biener --- >> Fixed? > > Not completely. I'd argue we should do two things: > > * Document that older GCC versions need to be built with > --enable-libphobos (SPARC or /bin/as). Doc patch now posted, too: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/591844.html
[Bug libstdc++/92546] Large increase in preprocessed file sizes in C++2a mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546 --- Comment #30 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #29) > Avoiding makes a big difference: > > $ : | g++-11 -std=gnu++17 -P -E -x c++ - -include algorithm | wc -l > 27018 Doh, pasted the wrong line, the first number is g++-10 not g++-11 > $ : | g++-11 -std=gnu++17 -P -E -x c++ - -include algorithm | wc -l > 25188 > $ : | g++-12 -std=gnu++17 -P -E -x c++ - -include algorithm | wc -l > 12268 > > $ : | g++-11 -std=gnu++20 -P -E -x c++ - -include algorithm | wc -l > 45780 Same here > $ : | g++-11 -std=gnu++20 -P -E -x c++ - -include algorithm | wc -l > 42404 > $ : | g++-12 -std=gnu++20 -P -E -x c++ - -include algorithm | wc -l > 20918
[Bug libstdc++/92546] Large increase in preprocessed file sizes in C++2a mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546 --- Comment #29 from Jonathan Wakely --- Avoiding makes a big difference: $ : | g++-11 -std=gnu++17 -P -E -x c++ - -include algorithm | wc -l 27018 $ : | g++-11 -std=gnu++17 -P -E -x c++ - -include algorithm | wc -l 25188 $ : | g++-12 -std=gnu++17 -P -E -x c++ - -include algorithm | wc -l 12268 $ : | g++-11 -std=gnu++20 -P -E -x c++ - -include algorithm | wc -l 45780 $ : | g++-11 -std=gnu++20 -P -E -x c++ - -include algorithm | wc -l 42404 $ : | g++-12 -std=gnu++20 -P -E -x c++ - -include algorithm | wc -l 20918 Improvements still to be done (in stage 1): - Replace std::vector in (comment 19) - Replace std::vector in - Reduce PSTL includes (comment 27)
[Bug driver/13071] no easy way to exclude backward C++ headers from include path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13071 --- Comment #12 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #11) > I'll open an LWG issue to get clarification. LWG agrees that it's ill-formed (no diagnostic required) to include standard headers inside a linkage-specification. Libstdc++ tries to makes it work as QoI, e.g. r12-4367-gc1b6c360fcf3fc
[Bug libstdc++/92546] Large increase in preprocessed file sizes in C++2a mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546 --- Comment #28 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ac73c944eac88f37db2767aa4acc7ff6f4983f21 commit r12-7699-gac73c944eac88f37db2767aa4acc7ff6f4983f21 Author: Jonathan Wakely Date: Thu Mar 17 16:45:43 2022 + libstdc++: Reduce header dependencies from PSTL headers [PR92546] This avoids including the whole of in , as the header only actually needs std::pair. This also avoids including in , which only needs , std::bad_alloc, and std::terminate (which can be repalced with std::__terminate). This matters less, because is only included by the headers and they all use anyway, and are only included by . libstdc++-v3/ChangeLog: PR libstdc++/92546 * include/pstl/glue_algorithm_defs.h: Replace with . * include/pstl/utils.h: Replace with . (__pstl::__internal::__except_handler): Use std::__terminate instead of std::terminate. * src/c++17/fs_path.cc: Include . * testsuite/25_algorithms/adjacent_find/constexpr.cc: Include . * testsuite/25_algorithms/binary_search/constexpr.cc: Likewise. * testsuite/25_algorithms/clamp/constrained.cc: Likewise. * testsuite/25_algorithms/equal/constrained.cc: Likewise. * testsuite/25_algorithms/for_each/constrained.cc: Likewise. * testsuite/25_algorithms/includes/constrained.cc: Likewise. * testsuite/25_algorithms/is_heap/constexpr.cc: Likewise. * testsuite/25_algorithms/is_heap_until/constexpr.cc: Likewise. * testsuite/25_algorithms/is_permutation/constrained.cc: Include . * testsuite/25_algorithms/is_sorted/constexpr.cc: Include . * testsuite/25_algorithms/is_sorted_until/constexpr.cc: Likewise. * testsuite/25_algorithms/lexicographical_compare/constexpr.cc: Likewise. * testsuite/25_algorithms/lexicographical_compare/constrained.cc: Likewise. * testsuite/25_algorithms/lexicographical_compare_three_way/1.cc: Include . * testsuite/25_algorithms/lower_bound/constexpr.cc: Include . * testsuite/25_algorithms/max/constrained.cc: Likewise. * testsuite/25_algorithms/max_element/constrained.cc: Likewise. * testsuite/25_algorithms/min/constrained.cc: Likewise. * testsuite/25_algorithms/min_element/constrained.cc: Likewise. * testsuite/25_algorithms/minmax_element/constrained.cc: Likewise. * testsuite/25_algorithms/mismatch/constexpr.cc: Likewise. * testsuite/25_algorithms/move/93872.cc: Likewise. * testsuite/25_algorithms/move_backward/93872.cc: Include . * testsuite/25_algorithms/nth_element/constexpr.cc: Include . * testsuite/25_algorithms/partial_sort/constexpr.cc: Likewise. * testsuite/25_algorithms/partial_sort_copy/constexpr.cc: Likewise. * testsuite/25_algorithms/search/constexpr.cc: Likewise. * testsuite/25_algorithms/search_n/constrained.cc: Likewise. * testsuite/25_algorithms/set_difference/constexpr.cc: Likewise. * testsuite/25_algorithms/set_difference/constrained.cc: Likewise. * testsuite/25_algorithms/set_intersection/constexpr.cc: Likewise. * testsuite/25_algorithms/set_intersection/constrained.cc: Likewise. * testsuite/25_algorithms/set_symmetric_difference/constexpr.cc: Likewise. * testsuite/25_algorithms/set_union/constexpr.cc: Likewise. * testsuite/25_algorithms/set_union/constrained.cc: Likewise. * testsuite/25_algorithms/sort/constexpr.cc: Likewise. * testsuite/25_algorithms/sort_heap/constexpr.cc: Likewise. * testsuite/25_algorithms/transform/constrained.cc: Likewise. * testsuite/25_algorithms/unique/constexpr.cc: Likewise. * testsuite/25_algorithms/unique/constrained.cc: Likewise. * testsuite/25_algorithms/unique_copy/constexpr.cc: Likewise. * testsuite/25_algorithms/upper_bound/constexpr.cc: Likewise. * testsuite/std/ranges/adaptors/elements.cc: Include . * testsuite/std/ranges/adaptors/lazy_split.cc: Likewise. * testsuite/std/ranges/adaptors/split.cc: Likewise.
[Bug libstdc++/92546] Large increase in preprocessed file sizes in C++2a mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92546 --- Comment #27 from Jonathan Wakely --- pst/algorithm_impl.h includes just because it needs std::not_fn. We could move that to a separate header. Even without that, we could do: --- a/libstdc++-v3/include/pstl/algorithm_impl.h +++ b/libstdc++-v3/include/pstl/algorithm_impl.h @@ -10,11 +10,12 @@ #ifndef _PSTL_ALGORITHM_IMPL_H #define _PSTL_ALGORITHM_IMPL_H -#include #include -#include #include #include +#include +#include +#include #include "execution_impl.h" #include "memory_impl.h" And similarly: --- a/libstdc++-v3/include/pstl/glue_numeric_impl.h +++ b/libstdc++-v3/include/pstl/glue_numeric_impl.h @@ -10,7 +10,7 @@ #ifndef _PSTL_GLUE_NUMERIC_IMPL_H #define _PSTL_GLUE_NUMERIC_IMPL_H -#include +#include #include "utils.h" #include "numeric_fwd.h" And: --- a/libstdc++-v3/include/pstl/memory_impl.h +++ b/libstdc++-v3/include/pstl/memory_impl.h @@ -10,7 +10,8 @@ #ifndef _PSTL_MEMORY_IMPL_H #define _PSTL_MEMORY_IMPL_H -#include +#include +#include #include "unseq_backend_simd.h" However, these headers come from upstream, so this would slightly complicate rebasing on new upstream versions.
[Bug d/104911] [12 regression] Comparison failure in gcc/d/typesem.o etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911 Iain Buclaw changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104738 --- Comment #7 from Iain Buclaw --- Ah, yes, of course. libdruntime/core/stdc/stdint.d: --- alias int8_t = char; alias uint8_t = ubyte; dmd/globals.d: --- alias d_int8 = int8_t; alias d_uns8 = uint8_t; dmd/expression.d: --- case Tint8: result = cast(d_int8)value; break; case Tchar: case Tuns8: result = cast(d_uns8)value; break; --- D sees both char and ubyte as having the same signed-ness.
[Bug target/104957] [nvptx] Use .alias directive (available starting ptx isa version 6.3)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104957 Tom de Vries changed: What|Removed |Added Severity|normal |enhancement
[Bug d/104911] [12 regression] Comparison failure in gcc/d/typesem.o etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104911
--- Comment #6 from Iain Buclaw ---
Created attachment 52649
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52649&action=edit
fdump-tree-original
The corrupt is indeed coming from the front-end.
Attached tree dumps.
--- stage2/typesem.d.005t.original 2022-03-18 10:40:44.087366215 +0100
+++ stage3/typesem.d.005t.original 2022-03-18 10:41:11.776070215 +0100
@@ -2994,7 +2994,7 @@ struct Expression * visitBasic (const st
switch ((int) __frame.mt->ty)
{
case 13:;
- return = integerValue (&__frame, 18446744073709551488);
+ return = integerValue (&__frame, 128);
case 14:;
case 16:;
case 18:;
[Bug go/104973] GCC 11.2.1 build failure with Go support (mv: cannot stat 'cpugen.o': No such file or directory)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104973 --- Comment #3 from PaX Team --- (In reply to Andrew Pinski from comment #1) > Can you attach what is inside cpugen.go? i'm one of the original bug reproducers, this is what i get here: work # find . -name cpugen.go -ls 29921892 4 -rw-r--r-- 1 root root 74 Mar 18 10:13 ./build/x86_64-pc-linux-gnu/libgo/cpugen.go 29922436 4 -rw-r--r-- 1 root root 74 Mar 18 10:13 ./build/x86_64-pc-linux-gnu/32/libgo/cpugen.go work # cat ./build/x86_64-pc-linux-gnu/libgo/cpugen.go package cpu const CacheLinePadSize = 64 const FunctionDescriptors = false work # cat ./build/x86_64-pc-linux-gnu/32/libgo/cpugen.go package cpu const CacheLinePadSize = 64 const FunctionDescriptors = false the relevant build log: libtool: compile: /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/build/./gcc/gccgo -B/tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -fchecking=1 -minline-all-stringops -O2 -g -m32 -I . -c -fgo-pkgpath=golang.org/x/sys/cpu /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/byteorder.go /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/cpu.go /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/cpu_gccgo_x86.go /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/cpu_linux_noinit.go /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/cpu_x86.go /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/hwcap_linux.go gcpugen.go -fPIC -o golang.org/x/sys/.libs/cpu.o libtool: compile: /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/build/./gcc/gccgo -B/tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/build/./gcc/ -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -fchecking=1 -minline-all-stringops -O2 -g -m32 -I . -c -fgo-pkgpath=golang.org/x/sys/cpu /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/byteorder.go /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/cpu.go /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/cpu_gccgo_x86.go /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/cpu_linux_noinit.go /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/cpu_x86.go /tmp/portage/sys-devel/gcc-11.2.1_p20220115/work/gcc-11-20220115/libgo/go/golang.org/x/sys/cpu/hwcap_linux .go gcpugen.go -o golang.org/x/sys/cpu.o >/dev/null 2>&1 note that there's a -o output specified but it's for the 'wrong' file name. i've got these cpu.o files: work # find . -name cpu.o -ls 29922270 60 -rw-r--r-- 1 root root58160 Mar 18 10:13 ./build/x86_64-pc-linux-gnu/libgo/cpu.o 29923192 44 -rw-r--r-- 1 root root41656 Mar 18 10:13 ./build/x86_64-pc-linux-gnu/32/libgo/internal/cpu.o 29922867 44 -rw-r--r-- 1 root root43384 Mar 18 10:13 ./build/x86_64-pc-linux-gnu/32/libgo/internal/.libs/cpu.o 29927256 92 -rw-r--r-- 1 root root92688 Mar 18 10:15 ./build/x86_64-pc-linux-gnu/32/libgo/golang.org/x/sys/cpu.o 29927254 96 -rw-r--r-- 1 root root95608 Mar 18 10:15 ./build/x86_64-pc-linux-gnu/32/libgo/golang.org/x/sys/.libs/cpu.o would you like me to upload anything of the above or any other build files?
[Bug d/104889] [12 Regression] D frontend fails to link on x86_64-linux-gnux32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104889 Matthias Klose changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Matthias Klose --- the bootstrap works for me again.
[Bug target/104963] GCC11/12 -march=sapphirerapids misses some ISAs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104963 Hongtao.liu changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Hongtao.liu --- Fixed in GCC12 and GCC11.3
[Bug target/104963] GCC11/12 -march=sapphirerapids misses some ISAs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104963 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by hongtao Liu : https://gcc.gnu.org/g:67e70a1a48ebf7db44710f3b022465ec38dfe5aa commit r11-9667-g67e70a1a48ebf7db44710f3b022465ec38dfe5aa Author: Cui,Lili Date: Thu Mar 17 14:34:49 2022 +0800 x86: Correct march=sapphirerapids to base on icelake server march=sapphirerapids should be based on icelake server not cooperlake. gcc/ChangeLog: PR target/104963 * config/i386/i386.h (PTA_SAPPHIRERAPIDS): change it to base on ICX. * doc/invoke.texi: Update documents for Intel sapphirerapids. gcc/testsuite/ChangeLog PR target/104963 * gcc.target/i386/pr104963.c: New test case.
[Bug target/104963] GCC11/12 -march=sapphirerapids misses some ISAs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104963 --- Comment #1 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:16fe6e8c9787a3be47bee3dbf094d22a5691c190 commit r12-7697-g16fe6e8c9787a3be47bee3dbf094d22a5691c190 Author: Cui,Lili Date: Thu Mar 17 14:34:49 2022 +0800 x86: Correct march=sapphirerapids to base on icelake server march=sapphirerapids should be based on icelake server not cooperlake. gcc/ChangeLog: PR target/104963 * config/i386/i386.h (PTA_SAPPHIRERAPIDS): change it to base on ICX. * doc/invoke.texi: Update documents for Intel sapphirerapids. gcc/testsuite/ChangeLog: PR target/104963 * gcc.target/i386/pr104963.c: New test case.
[Bug target/104976] [avx512fp16] lowpart_subreg return NULL_RTX cause ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104976 --- Comment #2 from Hongtao.liu --- (In reply to Hongtao.liu from comment #1) > The walkround in the backend is force_reg operand[1] before lowpart_subreg > to avoid NULL_RTX. It would be nice if we extend validate_subreg to avoid wired situation which allows (subreg:V8HF (reg:V2HF ) 0) and (subreg:V2HF (reg:SI) 0) but not (subreg:V8HF (reg:SI) 0)
[Bug target/104976] [avx512fp16] lowpart_subreg return NULL_RTX cause ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104976 Hongtao.liu changed: What|Removed |Added Target||x86_64-*-* i?86-*-* Keywords||ice-on-valid-code --- Comment #1 from Hongtao.liu --- The walkround in the backend is force_reg operand[1] before lowpart_subreg to avoid NULL_RTX.
[Bug target/104976] New: [avx512fp16] lowpart_subreg return NULL_RTX cause ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104976
Bug ID: 104976
Summary: [avx512fp16] lowpart_subreg return NULL_RTX cause ICE
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
void
foo (int a, float b, double* c)
{
union {
_Float16 f[2];
int i;} x;
x.i = a;
c[0] = x.f[0] * 0.2;
c[1] = x.f[1] * 0.2;
}
7165(define_expand "extendv2hfv2df2"
7166 [(set (match_operand:V2DF 0 "register_operand")
7167(float_extend:V2DF
7168 (match_operand:V2HF 1 "nonimmediate_operand")))]
7169 "TARGET_AVX512FP16 && TARGET_AVX512VL"
7170{
7171 if (!MEM_P (operands[1]))
7172{
7173 operands[1] = lowpart_subreg (V8HFmode, operands[1], V2HFmode);
7174 emit_insn (gen_avx512fp16_float_extend_phv2df2
7175 (operands[0], operands[1]));
7176 DONE;
7177}
7178})
here operands[1] is (subreg:V2HF (reg:SI) 0) which is valid, but not for
(subreg:v8hf (reg:SI 0) and return NULL cause invalid rtl.
101(insn 8 7 9 (set (reg:V2DF 88 [ vect__1.3 ])
102(float_extend:V2DF (vec_select:V2HF (nil)
103(parallel [
104(const_int 0 [0])
105(const_int 1 [0x1])
106] "test3.c":8:13 -1
107 (nil))
