[Bug tree-optimization/102798] [9/10/11/12 Regression] wrong code with -O3 -fno-tree-pta by r9-2475
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102798 --- Comment #11 from Richard Biener --- The issue is that the vectorizer should only duplicate pointer-info to SSA names it created itself, not to _any_ existing ones.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 Arnaud Charlet changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |charlet at gcc dot gnu.org Status|WAITING |ASSIGNED CC||charlet at gcc dot gnu.org --- Comment #56 from Arnaud Charlet --- Thanks for the log, exception propagation crept in again in the bootstrap causing the same kind of issues as last time, investigating how to get rid of exception propagation when compiling a-except.adb
[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 #1 from Andrew Pinski --- This could be a bug in clang considering it uses concepts and all. clang does not say why this concept evulates to false even: /opt/compiler-explorer/gcc-snapshot/lib/gcc/x86_64-linux-gnu/12.0.0/../../../../include/c++/12.0.0/bits/iterator_concepts.h:964:16: note: because 'is_array_v > >' evaluated to false
[Bug driver/102803] Bug: -no-canonical-prefixes not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803 --- Comment #4 from Carlos Galvez --- Thanks a lot for the detailed answer! That's very interesting, so it can actually have to do with how the Ubuntu version has been built. I'll definitely give it a try building locally. Your output looks like exactly what I would expect. The remaining /usr/include and /usr/local/include are due to the Linux system headers, which are GCC-agnostic (I think), so it makes sense that it picks them from there.
[Bug tree-optimization/102796] [12 Regresson] ICE in useless_type_conversion_p at gcc/gimple-expr.c:87 since r12-4443-g93ac832f1846e4867aa6537f76f510fab8e3e87d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102796 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #4 from Christophe Lyon --- (In reply to H.J. Lu from comment #3) > On Linux/x86, it also caused: > > FAIL: 27_io/ios_base/failure/dual_abi.cc execution test Same on arm and aarch64
[Bug target/102767] [12 Regression] ICE in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:5216
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102767 Richard Biener changed: What|Removed |Added Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #8 from Richard Biener --- the backend says it can support misaligned V1TI via rs6000_builtin_support_vector_misalignment: rs6000_builtin_support_vector_misalignment (mode=E_V1TImode, type=, misalignment=8, is_packed=false) at ../../src/trunk/gcc/config/rs6000/rs6000.c:5069 ... /* VSX supports word-aligned vector. */ if (misalignment % 4 == 0) return true; so the vectorizer classifies it as dr_unaligned_supported and we of course are then allowed to cost the supported unaligned store but the cost hook doesn't consider elements == 1. Now, we probably should avoid 1-lane vector vectorization in BB vect but that's a different story.
[Bug middle-end/102808] New: [12 regression] sve/mask_gather_load_1.c fails since g:9b2ad21ab3ebc21a3408108327fa1a7cbedaf217
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102808 Bug ID: 102808 Summary: [12 regression] sve/mask_gather_load_1.c fails since g:9b2ad21ab3ebc21a3408108327fa1a7cbedaf217 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- Hi, Since g:9b2ad21ab3ebc21a3408108327fa1a7cbedaf217, I have noticed a few regressions in the aarch64 tests: FAIL: gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/mask_gather_load_1.c scan-assembler-times \\tld1d\\tz[0-9]+\\.d, p[0-7]/z, \\[x[0-9]+, z[0-9]+\\.d, lsl 3\\]\\n 9 FAIL: gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/mask_gather_load_2.c scan-assembler-times \\tld1d\\tz[0-9]+\\.d, p[0-7]/z, \\[x[0-9]+, z[0-9]+\\.d, lsl 3\\]\\n 9 FAIL: gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/mask_gather_load_3.c scan-assembler-times \\tld1d\\tz[0-9]+\\.d, p[0-7]/z, \\[x[0-9]+, z[0-9]+\\.d\\]\\n 9 FAIL: gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/mask_gather_load_4.c scan-assembler-times \\tld1d\\tz[0-9]+\\.d, p[0-7]/z, \\[x[0-9]+, z[0-9]+\\.d\\]\\n 9 FAIL: gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/mask_gather_load_7.c scan-assembler-times \\tld1d\\tz[0-9]+\\.d, p[0-7]/z, \\[x[0-9]+, z[0-9]+\\.d, lsl 3\\]\\n 36 FAIL: gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/mask_scatter_store_1.c scan-assembler-times \\tst1d\\tz[0-9]+\\.d, p[0-7], \\[x[0-9]+, z[0-9]+\\.d, lsl 3\\]\\n 9 FAIL: gcc:gcc.target/aarch64/sve/aarch64-sve.exp=gcc.target/aarch64/sve/mask_scatter_store_2.c scan-assembler-times \\tst1d\\tz[0-9]+\\.d, p[0-7], \\[x[0-9]+, z[0-9]+\\.d, lsl 3\\]\\n 9
[Bug driver/102803] Bug: -no-canonical-prefixes not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803 Andrew Pinski changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 --- Comment #5 from Andrew Pinski --- Ubuntu's GCC is built with --with-sysroot=/ which sounds like the issue here really. So when you install it a different directory, it uses a new sysroot of that directory. And GCC calls realpath on the "./usr/bin/../../" for the sysroot. Here is the configure line for Ubuntu 1804 (aarch64)'s GCC: Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 7.4.0-1ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --with-system-zlib --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu So you can see the --with-sysroot=/ option. try this: ./usr/bin/gcc -no-canonical-prefixes -print-sysroot See what it prints.
[Bug fortran/102745] CLASS → TYPE check fails after RESHAPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102745 --- Comment #1 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:017665f63047ce47b087b0b283548a60e5abf3d2 commit r12-4464-g017665f63047ce47b087b0b283548a60e5abf3d2 Author: Tobias Burnus Date: Mon Oct 18 09:49:05 2021 +0200 Fortran: Fix CLASS conversion check [PR102745] PR fortran/102745 gcc/fortran/ChangeLog * intrinsic.c (gfc_convert_type_warn): Fix checks by checking CLASS and do typcheck in correct order for type extension. * misc.c (gfc_typename): Print proper not internal CLASS type name. gcc/testsuite/ChangeLog * gfortran.dg/class_72.f90: New.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #57 from Eric Botcazou --- > Thanks for the log, exception propagation crept in again in the bootstrap > causing the same kind of issues as last time, investigating how to get rid > of exception propagation when compiling a-except.adb Are you referring to PR ada/80590? Note that this was an exception propagation during the build of the runtime for a --disable-bootstrap build.
[Bug driver/102803] Bug: -no-canonical-prefixes not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803 --- Comment #6 from Carlos Galvez --- Hmm I don't see that in the x86 version of Ubuntu GCC: Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --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 --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 Running your command prints nothing: /path/to/gcc# ./usr/bin/gcc-7 -print-sysroot /path/to/gcc# Same with: /path/to/gcc# ./usr/bin/gcc-7 -no-canonical-prefixes -print-sysroot /path/to/gcc#
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #58 from Eric Botcazou --- So we have the dreaded mix of 11.x Ada exception code and 10.x unwind code: #0 0x773bb68b in msvcrt!abort () from C:\WINDOWS\SysWOW64\msvcrt.dll #1 0x02074f7d in uw_init_context_1 (context=context@entry=0x1070c890, outer_cfa=outer_cfa@entry=0x1070ca70, outer_ra=0x406f8a <__gnat_Unwind_RaiseException(_Unwind_Exception*)+17>) at ../../../gcc-10.3.0/libgcc/unwind-dw2.c:1593 #2 0x01e2ba3d in _Unwind_RaiseException (exc=0x132d8a90) at ../../../gcc-10.3.0/libgcc/unwind.inc:93 #3 0x00406f8a in __gnat_Unwind_RaiseException (e=e@entry=0x132d8a90) at ../../gcc-11.2.0/gcc/ada/raise-gcc.c:1391 On the one hand, this should no longer exist on the mainline but, on the other hand, this has never been problematic for AdaCore's internal builds.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #59 from Arnaud Charlet --- Right, PR ada/80590. And yes, the previous PR was more of a special case while this PR is in the middle of the bootstrap path (triggers as part of compiling a-except.adb).
[Bug c++/102784] ICE in synthesize_implicit_template_parm after errors since r10-3735-gcb57504a55015891
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102784 Martin Liška changed: What|Removed |Added Summary|ICE in |ICE in |synthesize_implicit_templat |synthesize_implicit_templat |e_parm after errors |e_parm after errors since ||r10-3735-gcb57504a55015891 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Likely started with r10-3735-gcb57504a55015891.
[Bug driver/102803] Bug: -no-canonical-prefixes not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803 --- Comment #7 from Andrew Pinski --- The next different is multiarch .
[Bug target/102767] [12 Regression] ICE in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:5216
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102767 Kewen Lin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org --- Comment #9 from Kewen Lin --- (In reply to Richard Biener from comment #8) > the backend says it can support misaligned V1TI via > rs6000_builtin_support_vector_misalignment: > > rs6000_builtin_support_vector_misalignment (mode=E_V1TImode, > type=, > misalignment=8, is_packed=false) at > ../../src/trunk/gcc/config/rs6000/rs6000.c:5069 > ... > /* VSX supports word-aligned vector. */ > if (misalignment % 4 == 0) > return true; > > so the vectorizer classifies it as dr_unaligned_supported and we of course > are then allowed to cost the supported unaligned store but the cost > hook doesn't consider elements == 1. > > Now, we probably should avoid 1-lane vector vectorization in BB vect but > that's > a different story. Yes, it's inconsistent between the hook and costing query. I'll make a patch.
[Bug tree-optimization/102798] [9/10/11/12 Regression] wrong code with -O3 -fno-tree-pta by r9-2475
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102798 --- Comment #12 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:a5b1b2a186d94b31a522395e9d02c9cec1b928cb commit r12-4466-ga5b1b2a186d94b31a522395e9d02c9cec1b928cb Author: Richard Biener Date: Mon Oct 18 09:10:43 2021 +0200 tree-optimization/102798 - avoid copying PTA info to old SSA names The vectorizer duplicates pointer-info to created pointer bases but it has to avoid changing points-to info on existing SSA names because there's now flow-sensitive info in there (pt->pt_null as set from VRP). 2021-10-18 Richard Biener PR tree-optimization/102798 * tree-vect-data-refs.c (vect_create_addr_base_for_vector_ref): Only copy points-to info to newly generated SSA names. * gcc.dg/pr102798.c: New testcase.
[Bug tree-optimization/102798] [9/10/11 Regression] wrong code with -O3 -fno-tree-pta by r9-2475
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102798 Richard Biener changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10/11 Regression] wrong |wrong code with -O3 |code with -O3 -fno-tree-pta |-fno-tree-pta by r9-2475|by r9-2475 Known to fail|12.0| Known to work||12.0 Priority|P3 |P2
[Bug fortran/102086] [F2008][TS29113] Accepts invalid scalar TYPE(*) as actual argument to assumed-rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102086
--- Comment #1 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:64f9623765da3306b0ab6a47997dc5d62c2ea261
commit r12-4467-g64f9623765da3306b0ab6a47997dc5d62c2ea261
Author: Tobias Burnus
Date: Mon Oct 18 09:51:36 2021 +0200
Fortran: Fix Bind(C) Array-Descriptor Conversion
gfortran uses internally a different array descriptor ("gfc") as
Fortran 2018 alias TS291113 defines for C interoperability via
ISO_Fortran_binding.h ("CFI"). Hence, when calling a C function
from Fortran, it has to be converted in the callee - and if a
BIND(C) procedure is written in Fortran, the CFI argument has
to be converted to gfc in order work with the rest of the FE
code and the library calls.
Before this patch, part was handled in the FE generated code and
other parts in libgfortran. With this patch, all code is generated
and CFI is defined as proper type - visible in the debugger and to
the middle end - avoiding both alias issues and missed optimization
issues.
This patch also fixes issues like: intent(out) deallocation in
the bind(C) callee, using the CFI descriptor also for allocatable
and pointer scalars and for len=* character strings.
For 'select rank', it also optimizes the code + avoid accessing
uninitialized memory if the dummy argument is allocatable/a pointer.
It additionally rejects passing a descriptorless type(*) to an
assumed-rank dummy argument. [F2018:C711]
PR fortran/102086
PR fortran/92189
PR fortran/92621
PR fortran/101308
PR fortran/101309
PR fortran/101635
PR fortran/92482
gcc/fortran/ChangeLog:
* decl.c (gfc_verify_c_interop_param): Remove 'sorry' for
scalar allocatable/pointer and len=*.
* expr.c (is_CFI_desc): Return true for for those.
* gfortran.h (CFI_type_kind_shift, CFI_type_mask,
CFI_type_from_type_kind, CFI_VERSION, CFI_MAX_RANK,
CFI_attribute_pointer, CFI_attribute_allocatable,
CFI_attribute_other, CFI_type_Integer, CFI_type_Logical,
CFI_type_Real, CFI_type_Complex, CFI_type_Character,
CFI_type_ucs4_char, CFI_type_struct, CFI_type_cptr,
CFI_type_cfunptr, CFI_type_other): New #define.
* trans-array.c (CFI_FIELD_BASE_ADDR, CFI_FIELD_ELEM_LEN,
CFI_FIELD_VERSION, CFI_FIELD_RANK, CFI_FIELD_ATTRIBUTE,
CFI_FIELD_TYPE, CFI_FIELD_DIM, CFI_DIM_FIELD_LOWER_BOUND,
CFI_DIM_FIELD_EXTENT, CFI_DIM_FIELD_SM,
gfc_get_cfi_descriptor_field, gfc_get_cfi_desc_base_addr,
gfc_get_cfi_desc_elem_len, gfc_get_cfi_desc_version,
gfc_get_cfi_desc_rank, gfc_get_cfi_desc_type,
gfc_get_cfi_desc_attribute, gfc_get_cfi_dim_item,
gfc_get_cfi_dim_lbound, gfc_get_cfi_dim_extent,
gfc_get_cfi_dim_sm):
New define/functions to access the CFI array descriptor.
(gfc_conv_descriptor_type): New function for the GFC descriptor.
(gfc_get_array_span): Handle expr of CFI descriptors and
assumed-type descriptors.
(gfc_trans_array_bounds): Remove 'static'.
(gfc_conv_expr_descriptor): For assumed type, use the dtype of
the actual argument.
(structure_alloc_comps): Remove ' ' inside tabs.
* trans-array.h (gfc_trans_array_bounds, gfc_conv_descriptor_type,
gfc_get_cfi_desc_base_addr, gfc_get_cfi_desc_elem_len,
gfc_get_cfi_desc_version, gfc_get_cfi_desc_rank,
gfc_get_cfi_desc_type, gfc_get_cfi_desc_attribute,
gfc_get_cfi_dim_lbound, gfc_get_cfi_dim_extent,
gfc_get_cfi_dim_sm):
New prototypes.
* trans-decl.c (gfor_fndecl_cfi_to_gfc, gfor_fndecl_gfc_to_cfi):
Remove global vars.
(gfc_build_builtin_function_decls): Remove their initialization.
(gfc_get_symbol_decl, create_function_arglist,
gfc_trans_deferred_vars): Update for CFI.
(convert_CFI_desc): Remove and replace by ...
(gfc_conv_cfi_to_gfc): ... this function
(gfc_generate_function_code): Call it; create local GFC var for
CFI.
* trans-expr.c (gfc_maybe_dereference_var): Handle CFI.
(gfc_conv_subref_array_arg): Handle the if-noncontigous-only copy
in
when the result should be a descriptor.
(gfc_conv_gfc_desc_to_cfi_desc): Completely rewritten.
(gfc_conv_procedure_call): CFI fixes.
* trans-openmp.c (gfc_omp_is_optional_argument,
gfc_omp_check_optional_argument): Handle optional
CFI.
* trans-stmt.c (gfc_trans_select_rank_cases): Cleanup, avoid
invalid
code for allocatable/pointer dummies, which cannot be assumed size.
[Bug fortran/92189] Fortran-written bind(C) function with allocatable argument does not update C descriptor on exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92189
--- Comment #4 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:64f9623765da3306b0ab6a47997dc5d62c2ea261
commit r12-4467-g64f9623765da3306b0ab6a47997dc5d62c2ea261
Author: Tobias Burnus
Date: Mon Oct 18 09:51:36 2021 +0200
Fortran: Fix Bind(C) Array-Descriptor Conversion
gfortran uses internally a different array descriptor ("gfc") as
Fortran 2018 alias TS291113 defines for C interoperability via
ISO_Fortran_binding.h ("CFI"). Hence, when calling a C function
from Fortran, it has to be converted in the callee - and if a
BIND(C) procedure is written in Fortran, the CFI argument has
to be converted to gfc in order work with the rest of the FE
code and the library calls.
Before this patch, part was handled in the FE generated code and
other parts in libgfortran. With this patch, all code is generated
and CFI is defined as proper type - visible in the debugger and to
the middle end - avoiding both alias issues and missed optimization
issues.
This patch also fixes issues like: intent(out) deallocation in
the bind(C) callee, using the CFI descriptor also for allocatable
and pointer scalars and for len=* character strings.
For 'select rank', it also optimizes the code + avoid accessing
uninitialized memory if the dummy argument is allocatable/a pointer.
It additionally rejects passing a descriptorless type(*) to an
assumed-rank dummy argument. [F2018:C711]
PR fortran/102086
PR fortran/92189
PR fortran/92621
PR fortran/101308
PR fortran/101309
PR fortran/101635
PR fortran/92482
gcc/fortran/ChangeLog:
* decl.c (gfc_verify_c_interop_param): Remove 'sorry' for
scalar allocatable/pointer and len=*.
* expr.c (is_CFI_desc): Return true for for those.
* gfortran.h (CFI_type_kind_shift, CFI_type_mask,
CFI_type_from_type_kind, CFI_VERSION, CFI_MAX_RANK,
CFI_attribute_pointer, CFI_attribute_allocatable,
CFI_attribute_other, CFI_type_Integer, CFI_type_Logical,
CFI_type_Real, CFI_type_Complex, CFI_type_Character,
CFI_type_ucs4_char, CFI_type_struct, CFI_type_cptr,
CFI_type_cfunptr, CFI_type_other): New #define.
* trans-array.c (CFI_FIELD_BASE_ADDR, CFI_FIELD_ELEM_LEN,
CFI_FIELD_VERSION, CFI_FIELD_RANK, CFI_FIELD_ATTRIBUTE,
CFI_FIELD_TYPE, CFI_FIELD_DIM, CFI_DIM_FIELD_LOWER_BOUND,
CFI_DIM_FIELD_EXTENT, CFI_DIM_FIELD_SM,
gfc_get_cfi_descriptor_field, gfc_get_cfi_desc_base_addr,
gfc_get_cfi_desc_elem_len, gfc_get_cfi_desc_version,
gfc_get_cfi_desc_rank, gfc_get_cfi_desc_type,
gfc_get_cfi_desc_attribute, gfc_get_cfi_dim_item,
gfc_get_cfi_dim_lbound, gfc_get_cfi_dim_extent,
gfc_get_cfi_dim_sm):
New define/functions to access the CFI array descriptor.
(gfc_conv_descriptor_type): New function for the GFC descriptor.
(gfc_get_array_span): Handle expr of CFI descriptors and
assumed-type descriptors.
(gfc_trans_array_bounds): Remove 'static'.
(gfc_conv_expr_descriptor): For assumed type, use the dtype of
the actual argument.
(structure_alloc_comps): Remove ' ' inside tabs.
* trans-array.h (gfc_trans_array_bounds, gfc_conv_descriptor_type,
gfc_get_cfi_desc_base_addr, gfc_get_cfi_desc_elem_len,
gfc_get_cfi_desc_version, gfc_get_cfi_desc_rank,
gfc_get_cfi_desc_type, gfc_get_cfi_desc_attribute,
gfc_get_cfi_dim_lbound, gfc_get_cfi_dim_extent,
gfc_get_cfi_dim_sm):
New prototypes.
* trans-decl.c (gfor_fndecl_cfi_to_gfc, gfor_fndecl_gfc_to_cfi):
Remove global vars.
(gfc_build_builtin_function_decls): Remove their initialization.
(gfc_get_symbol_decl, create_function_arglist,
gfc_trans_deferred_vars): Update for CFI.
(convert_CFI_desc): Remove and replace by ...
(gfc_conv_cfi_to_gfc): ... this function
(gfc_generate_function_code): Call it; create local GFC var for
CFI.
* trans-expr.c (gfc_maybe_dereference_var): Handle CFI.
(gfc_conv_subref_array_arg): Handle the if-noncontigous-only copy
in
when the result should be a descriptor.
(gfc_conv_gfc_desc_to_cfi_desc): Completely rewritten.
(gfc_conv_procedure_call): CFI fixes.
* trans-openmp.c (gfc_omp_is_optional_argument,
gfc_omp_check_optional_argument): Handle optional
CFI.
* trans-stmt.c (gfc_trans_select_rank_cases): Cleanup, avoid
invalid
code for allocatable/pointer dummies, which cannot be assumed size.
[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621
--- Comment #20 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:64f9623765da3306b0ab6a47997dc5d62c2ea261
commit r12-4467-g64f9623765da3306b0ab6a47997dc5d62c2ea261
Author: Tobias Burnus
Date: Mon Oct 18 09:51:36 2021 +0200
Fortran: Fix Bind(C) Array-Descriptor Conversion
gfortran uses internally a different array descriptor ("gfc") as
Fortran 2018 alias TS291113 defines for C interoperability via
ISO_Fortran_binding.h ("CFI"). Hence, when calling a C function
from Fortran, it has to be converted in the callee - and if a
BIND(C) procedure is written in Fortran, the CFI argument has
to be converted to gfc in order work with the rest of the FE
code and the library calls.
Before this patch, part was handled in the FE generated code and
other parts in libgfortran. With this patch, all code is generated
and CFI is defined as proper type - visible in the debugger and to
the middle end - avoiding both alias issues and missed optimization
issues.
This patch also fixes issues like: intent(out) deallocation in
the bind(C) callee, using the CFI descriptor also for allocatable
and pointer scalars and for len=* character strings.
For 'select rank', it also optimizes the code + avoid accessing
uninitialized memory if the dummy argument is allocatable/a pointer.
It additionally rejects passing a descriptorless type(*) to an
assumed-rank dummy argument. [F2018:C711]
PR fortran/102086
PR fortran/92189
PR fortran/92621
PR fortran/101308
PR fortran/101309
PR fortran/101635
PR fortran/92482
gcc/fortran/ChangeLog:
* decl.c (gfc_verify_c_interop_param): Remove 'sorry' for
scalar allocatable/pointer and len=*.
* expr.c (is_CFI_desc): Return true for for those.
* gfortran.h (CFI_type_kind_shift, CFI_type_mask,
CFI_type_from_type_kind, CFI_VERSION, CFI_MAX_RANK,
CFI_attribute_pointer, CFI_attribute_allocatable,
CFI_attribute_other, CFI_type_Integer, CFI_type_Logical,
CFI_type_Real, CFI_type_Complex, CFI_type_Character,
CFI_type_ucs4_char, CFI_type_struct, CFI_type_cptr,
CFI_type_cfunptr, CFI_type_other): New #define.
* trans-array.c (CFI_FIELD_BASE_ADDR, CFI_FIELD_ELEM_LEN,
CFI_FIELD_VERSION, CFI_FIELD_RANK, CFI_FIELD_ATTRIBUTE,
CFI_FIELD_TYPE, CFI_FIELD_DIM, CFI_DIM_FIELD_LOWER_BOUND,
CFI_DIM_FIELD_EXTENT, CFI_DIM_FIELD_SM,
gfc_get_cfi_descriptor_field, gfc_get_cfi_desc_base_addr,
gfc_get_cfi_desc_elem_len, gfc_get_cfi_desc_version,
gfc_get_cfi_desc_rank, gfc_get_cfi_desc_type,
gfc_get_cfi_desc_attribute, gfc_get_cfi_dim_item,
gfc_get_cfi_dim_lbound, gfc_get_cfi_dim_extent,
gfc_get_cfi_dim_sm):
New define/functions to access the CFI array descriptor.
(gfc_conv_descriptor_type): New function for the GFC descriptor.
(gfc_get_array_span): Handle expr of CFI descriptors and
assumed-type descriptors.
(gfc_trans_array_bounds): Remove 'static'.
(gfc_conv_expr_descriptor): For assumed type, use the dtype of
the actual argument.
(structure_alloc_comps): Remove ' ' inside tabs.
* trans-array.h (gfc_trans_array_bounds, gfc_conv_descriptor_type,
gfc_get_cfi_desc_base_addr, gfc_get_cfi_desc_elem_len,
gfc_get_cfi_desc_version, gfc_get_cfi_desc_rank,
gfc_get_cfi_desc_type, gfc_get_cfi_desc_attribute,
gfc_get_cfi_dim_lbound, gfc_get_cfi_dim_extent,
gfc_get_cfi_dim_sm):
New prototypes.
* trans-decl.c (gfor_fndecl_cfi_to_gfc, gfor_fndecl_gfc_to_cfi):
Remove global vars.
(gfc_build_builtin_function_decls): Remove their initialization.
(gfc_get_symbol_decl, create_function_arglist,
gfc_trans_deferred_vars): Update for CFI.
(convert_CFI_desc): Remove and replace by ...
(gfc_conv_cfi_to_gfc): ... this function
(gfc_generate_function_code): Call it; create local GFC var for
CFI.
* trans-expr.c (gfc_maybe_dereference_var): Handle CFI.
(gfc_conv_subref_array_arg): Handle the if-noncontigous-only copy
in
when the result should be a descriptor.
(gfc_conv_gfc_desc_to_cfi_desc): Completely rewritten.
(gfc_conv_procedure_call): CFI fixes.
* trans-openmp.c (gfc_omp_is_optional_argument,
gfc_omp_check_optional_argument): Handle optional
CFI.
* trans-stmt.c (gfc_trans_select_rank_cases): Cleanup, avoid
invalid
code for allocatable/pointer dummies, which cannot be assumed size.
[Bug fortran/101308] Bind(C): gfortran does not create C descriptors for scalar pointer/allocatable arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101308
--- Comment #2 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:64f9623765da3306b0ab6a47997dc5d62c2ea261
commit r12-4467-g64f9623765da3306b0ab6a47997dc5d62c2ea261
Author: Tobias Burnus
Date: Mon Oct 18 09:51:36 2021 +0200
Fortran: Fix Bind(C) Array-Descriptor Conversion
gfortran uses internally a different array descriptor ("gfc") as
Fortran 2018 alias TS291113 defines for C interoperability via
ISO_Fortran_binding.h ("CFI"). Hence, when calling a C function
from Fortran, it has to be converted in the callee - and if a
BIND(C) procedure is written in Fortran, the CFI argument has
to be converted to gfc in order work with the rest of the FE
code and the library calls.
Before this patch, part was handled in the FE generated code and
other parts in libgfortran. With this patch, all code is generated
and CFI is defined as proper type - visible in the debugger and to
the middle end - avoiding both alias issues and missed optimization
issues.
This patch also fixes issues like: intent(out) deallocation in
the bind(C) callee, using the CFI descriptor also for allocatable
and pointer scalars and for len=* character strings.
For 'select rank', it also optimizes the code + avoid accessing
uninitialized memory if the dummy argument is allocatable/a pointer.
It additionally rejects passing a descriptorless type(*) to an
assumed-rank dummy argument. [F2018:C711]
PR fortran/102086
PR fortran/92189
PR fortran/92621
PR fortran/101308
PR fortran/101309
PR fortran/101635
PR fortran/92482
gcc/fortran/ChangeLog:
* decl.c (gfc_verify_c_interop_param): Remove 'sorry' for
scalar allocatable/pointer and len=*.
* expr.c (is_CFI_desc): Return true for for those.
* gfortran.h (CFI_type_kind_shift, CFI_type_mask,
CFI_type_from_type_kind, CFI_VERSION, CFI_MAX_RANK,
CFI_attribute_pointer, CFI_attribute_allocatable,
CFI_attribute_other, CFI_type_Integer, CFI_type_Logical,
CFI_type_Real, CFI_type_Complex, CFI_type_Character,
CFI_type_ucs4_char, CFI_type_struct, CFI_type_cptr,
CFI_type_cfunptr, CFI_type_other): New #define.
* trans-array.c (CFI_FIELD_BASE_ADDR, CFI_FIELD_ELEM_LEN,
CFI_FIELD_VERSION, CFI_FIELD_RANK, CFI_FIELD_ATTRIBUTE,
CFI_FIELD_TYPE, CFI_FIELD_DIM, CFI_DIM_FIELD_LOWER_BOUND,
CFI_DIM_FIELD_EXTENT, CFI_DIM_FIELD_SM,
gfc_get_cfi_descriptor_field, gfc_get_cfi_desc_base_addr,
gfc_get_cfi_desc_elem_len, gfc_get_cfi_desc_version,
gfc_get_cfi_desc_rank, gfc_get_cfi_desc_type,
gfc_get_cfi_desc_attribute, gfc_get_cfi_dim_item,
gfc_get_cfi_dim_lbound, gfc_get_cfi_dim_extent,
gfc_get_cfi_dim_sm):
New define/functions to access the CFI array descriptor.
(gfc_conv_descriptor_type): New function for the GFC descriptor.
(gfc_get_array_span): Handle expr of CFI descriptors and
assumed-type descriptors.
(gfc_trans_array_bounds): Remove 'static'.
(gfc_conv_expr_descriptor): For assumed type, use the dtype of
the actual argument.
(structure_alloc_comps): Remove ' ' inside tabs.
* trans-array.h (gfc_trans_array_bounds, gfc_conv_descriptor_type,
gfc_get_cfi_desc_base_addr, gfc_get_cfi_desc_elem_len,
gfc_get_cfi_desc_version, gfc_get_cfi_desc_rank,
gfc_get_cfi_desc_type, gfc_get_cfi_desc_attribute,
gfc_get_cfi_dim_lbound, gfc_get_cfi_dim_extent,
gfc_get_cfi_dim_sm):
New prototypes.
* trans-decl.c (gfor_fndecl_cfi_to_gfc, gfor_fndecl_gfc_to_cfi):
Remove global vars.
(gfc_build_builtin_function_decls): Remove their initialization.
(gfc_get_symbol_decl, create_function_arglist,
gfc_trans_deferred_vars): Update for CFI.
(convert_CFI_desc): Remove and replace by ...
(gfc_conv_cfi_to_gfc): ... this function
(gfc_generate_function_code): Call it; create local GFC var for
CFI.
* trans-expr.c (gfc_maybe_dereference_var): Handle CFI.
(gfc_conv_subref_array_arg): Handle the if-noncontigous-only copy
in
when the result should be a descriptor.
(gfc_conv_gfc_desc_to_cfi_desc): Completely rewritten.
(gfc_conv_procedure_call): CFI fixes.
* trans-openmp.c (gfc_omp_is_optional_argument,
gfc_omp_check_optional_argument): Handle optional
CFI.
* trans-stmt.c (gfc_trans_select_rank_cases): Cleanup, avoid
invalid
code for allocatable/pointer dummies, which cannot be assumed size.
[Bug fortran/101309] Bind(C): gfortran creates invalid C descriptor for result of TRANSPOSE intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101309
--- Comment #2 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:64f9623765da3306b0ab6a47997dc5d62c2ea261
commit r12-4467-g64f9623765da3306b0ab6a47997dc5d62c2ea261
Author: Tobias Burnus
Date: Mon Oct 18 09:51:36 2021 +0200
Fortran: Fix Bind(C) Array-Descriptor Conversion
gfortran uses internally a different array descriptor ("gfc") as
Fortran 2018 alias TS291113 defines for C interoperability via
ISO_Fortran_binding.h ("CFI"). Hence, when calling a C function
from Fortran, it has to be converted in the callee - and if a
BIND(C) procedure is written in Fortran, the CFI argument has
to be converted to gfc in order work with the rest of the FE
code and the library calls.
Before this patch, part was handled in the FE generated code and
other parts in libgfortran. With this patch, all code is generated
and CFI is defined as proper type - visible in the debugger and to
the middle end - avoiding both alias issues and missed optimization
issues.
This patch also fixes issues like: intent(out) deallocation in
the bind(C) callee, using the CFI descriptor also for allocatable
and pointer scalars and for len=* character strings.
For 'select rank', it also optimizes the code + avoid accessing
uninitialized memory if the dummy argument is allocatable/a pointer.
It additionally rejects passing a descriptorless type(*) to an
assumed-rank dummy argument. [F2018:C711]
PR fortran/102086
PR fortran/92189
PR fortran/92621
PR fortran/101308
PR fortran/101309
PR fortran/101635
PR fortran/92482
gcc/fortran/ChangeLog:
* decl.c (gfc_verify_c_interop_param): Remove 'sorry' for
scalar allocatable/pointer and len=*.
* expr.c (is_CFI_desc): Return true for for those.
* gfortran.h (CFI_type_kind_shift, CFI_type_mask,
CFI_type_from_type_kind, CFI_VERSION, CFI_MAX_RANK,
CFI_attribute_pointer, CFI_attribute_allocatable,
CFI_attribute_other, CFI_type_Integer, CFI_type_Logical,
CFI_type_Real, CFI_type_Complex, CFI_type_Character,
CFI_type_ucs4_char, CFI_type_struct, CFI_type_cptr,
CFI_type_cfunptr, CFI_type_other): New #define.
* trans-array.c (CFI_FIELD_BASE_ADDR, CFI_FIELD_ELEM_LEN,
CFI_FIELD_VERSION, CFI_FIELD_RANK, CFI_FIELD_ATTRIBUTE,
CFI_FIELD_TYPE, CFI_FIELD_DIM, CFI_DIM_FIELD_LOWER_BOUND,
CFI_DIM_FIELD_EXTENT, CFI_DIM_FIELD_SM,
gfc_get_cfi_descriptor_field, gfc_get_cfi_desc_base_addr,
gfc_get_cfi_desc_elem_len, gfc_get_cfi_desc_version,
gfc_get_cfi_desc_rank, gfc_get_cfi_desc_type,
gfc_get_cfi_desc_attribute, gfc_get_cfi_dim_item,
gfc_get_cfi_dim_lbound, gfc_get_cfi_dim_extent,
gfc_get_cfi_dim_sm):
New define/functions to access the CFI array descriptor.
(gfc_conv_descriptor_type): New function for the GFC descriptor.
(gfc_get_array_span): Handle expr of CFI descriptors and
assumed-type descriptors.
(gfc_trans_array_bounds): Remove 'static'.
(gfc_conv_expr_descriptor): For assumed type, use the dtype of
the actual argument.
(structure_alloc_comps): Remove ' ' inside tabs.
* trans-array.h (gfc_trans_array_bounds, gfc_conv_descriptor_type,
gfc_get_cfi_desc_base_addr, gfc_get_cfi_desc_elem_len,
gfc_get_cfi_desc_version, gfc_get_cfi_desc_rank,
gfc_get_cfi_desc_type, gfc_get_cfi_desc_attribute,
gfc_get_cfi_dim_lbound, gfc_get_cfi_dim_extent,
gfc_get_cfi_dim_sm):
New prototypes.
* trans-decl.c (gfor_fndecl_cfi_to_gfc, gfor_fndecl_gfc_to_cfi):
Remove global vars.
(gfc_build_builtin_function_decls): Remove their initialization.
(gfc_get_symbol_decl, create_function_arglist,
gfc_trans_deferred_vars): Update for CFI.
(convert_CFI_desc): Remove and replace by ...
(gfc_conv_cfi_to_gfc): ... this function
(gfc_generate_function_code): Call it; create local GFC var for
CFI.
* trans-expr.c (gfc_maybe_dereference_var): Handle CFI.
(gfc_conv_subref_array_arg): Handle the if-noncontigous-only copy
in
when the result should be a descriptor.
(gfc_conv_gfc_desc_to_cfi_desc): Completely rewritten.
(gfc_conv_procedure_call): CFI fixes.
* trans-openmp.c (gfc_omp_is_optional_argument,
gfc_omp_check_optional_argument): Handle optional
CFI.
* trans-stmt.c (gfc_trans_select_rank_cases): Cleanup, avoid
invalid
code for allocatable/pointer dummies, which cannot be assumed size.
[Bug fortran/101635] FAIL: gfortran.dg/PR93963.f90 – alias-handling issue with BIND(C)'s _gfortran_cfi_desc_to_gfc_desc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101635
--- Comment #2 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:64f9623765da3306b0ab6a47997dc5d62c2ea261
commit r12-4467-g64f9623765da3306b0ab6a47997dc5d62c2ea261
Author: Tobias Burnus
Date: Mon Oct 18 09:51:36 2021 +0200
Fortran: Fix Bind(C) Array-Descriptor Conversion
gfortran uses internally a different array descriptor ("gfc") as
Fortran 2018 alias TS291113 defines for C interoperability via
ISO_Fortran_binding.h ("CFI"). Hence, when calling a C function
from Fortran, it has to be converted in the callee - and if a
BIND(C) procedure is written in Fortran, the CFI argument has
to be converted to gfc in order work with the rest of the FE
code and the library calls.
Before this patch, part was handled in the FE generated code and
other parts in libgfortran. With this patch, all code is generated
and CFI is defined as proper type - visible in the debugger and to
the middle end - avoiding both alias issues and missed optimization
issues.
This patch also fixes issues like: intent(out) deallocation in
the bind(C) callee, using the CFI descriptor also for allocatable
and pointer scalars and for len=* character strings.
For 'select rank', it also optimizes the code + avoid accessing
uninitialized memory if the dummy argument is allocatable/a pointer.
It additionally rejects passing a descriptorless type(*) to an
assumed-rank dummy argument. [F2018:C711]
PR fortran/102086
PR fortran/92189
PR fortran/92621
PR fortran/101308
PR fortran/101309
PR fortran/101635
PR fortran/92482
gcc/fortran/ChangeLog:
* decl.c (gfc_verify_c_interop_param): Remove 'sorry' for
scalar allocatable/pointer and len=*.
* expr.c (is_CFI_desc): Return true for for those.
* gfortran.h (CFI_type_kind_shift, CFI_type_mask,
CFI_type_from_type_kind, CFI_VERSION, CFI_MAX_RANK,
CFI_attribute_pointer, CFI_attribute_allocatable,
CFI_attribute_other, CFI_type_Integer, CFI_type_Logical,
CFI_type_Real, CFI_type_Complex, CFI_type_Character,
CFI_type_ucs4_char, CFI_type_struct, CFI_type_cptr,
CFI_type_cfunptr, CFI_type_other): New #define.
* trans-array.c (CFI_FIELD_BASE_ADDR, CFI_FIELD_ELEM_LEN,
CFI_FIELD_VERSION, CFI_FIELD_RANK, CFI_FIELD_ATTRIBUTE,
CFI_FIELD_TYPE, CFI_FIELD_DIM, CFI_DIM_FIELD_LOWER_BOUND,
CFI_DIM_FIELD_EXTENT, CFI_DIM_FIELD_SM,
gfc_get_cfi_descriptor_field, gfc_get_cfi_desc_base_addr,
gfc_get_cfi_desc_elem_len, gfc_get_cfi_desc_version,
gfc_get_cfi_desc_rank, gfc_get_cfi_desc_type,
gfc_get_cfi_desc_attribute, gfc_get_cfi_dim_item,
gfc_get_cfi_dim_lbound, gfc_get_cfi_dim_extent,
gfc_get_cfi_dim_sm):
New define/functions to access the CFI array descriptor.
(gfc_conv_descriptor_type): New function for the GFC descriptor.
(gfc_get_array_span): Handle expr of CFI descriptors and
assumed-type descriptors.
(gfc_trans_array_bounds): Remove 'static'.
(gfc_conv_expr_descriptor): For assumed type, use the dtype of
the actual argument.
(structure_alloc_comps): Remove ' ' inside tabs.
* trans-array.h (gfc_trans_array_bounds, gfc_conv_descriptor_type,
gfc_get_cfi_desc_base_addr, gfc_get_cfi_desc_elem_len,
gfc_get_cfi_desc_version, gfc_get_cfi_desc_rank,
gfc_get_cfi_desc_type, gfc_get_cfi_desc_attribute,
gfc_get_cfi_dim_lbound, gfc_get_cfi_dim_extent,
gfc_get_cfi_dim_sm):
New prototypes.
* trans-decl.c (gfor_fndecl_cfi_to_gfc, gfor_fndecl_gfc_to_cfi):
Remove global vars.
(gfc_build_builtin_function_decls): Remove their initialization.
(gfc_get_symbol_decl, create_function_arglist,
gfc_trans_deferred_vars): Update for CFI.
(convert_CFI_desc): Remove and replace by ...
(gfc_conv_cfi_to_gfc): ... this function
(gfc_generate_function_code): Call it; create local GFC var for
CFI.
* trans-expr.c (gfc_maybe_dereference_var): Handle CFI.
(gfc_conv_subref_array_arg): Handle the if-noncontigous-only copy
in
when the result should be a descriptor.
(gfc_conv_gfc_desc_to_cfi_desc): Completely rewritten.
(gfc_conv_procedure_call): CFI fixes.
* trans-openmp.c (gfc_omp_is_optional_argument,
gfc_omp_check_optional_argument): Handle optional
CFI.
* trans-stmt.c (gfc_trans_select_rank_cases): Cleanup, avoid
invalid
code for allocatable/pointer dummies, which cannot be assumed size.
[Bug fortran/92482] BIND(C) with array-descriptor mishandled for type character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92482
--- Comment #7 from CVS Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:64f9623765da3306b0ab6a47997dc5d62c2ea261
commit r12-4467-g64f9623765da3306b0ab6a47997dc5d62c2ea261
Author: Tobias Burnus
Date: Mon Oct 18 09:51:36 2021 +0200
Fortran: Fix Bind(C) Array-Descriptor Conversion
gfortran uses internally a different array descriptor ("gfc") as
Fortran 2018 alias TS291113 defines for C interoperability via
ISO_Fortran_binding.h ("CFI"). Hence, when calling a C function
from Fortran, it has to be converted in the callee - and if a
BIND(C) procedure is written in Fortran, the CFI argument has
to be converted to gfc in order work with the rest of the FE
code and the library calls.
Before this patch, part was handled in the FE generated code and
other parts in libgfortran. With this patch, all code is generated
and CFI is defined as proper type - visible in the debugger and to
the middle end - avoiding both alias issues and missed optimization
issues.
This patch also fixes issues like: intent(out) deallocation in
the bind(C) callee, using the CFI descriptor also for allocatable
and pointer scalars and for len=* character strings.
For 'select rank', it also optimizes the code + avoid accessing
uninitialized memory if the dummy argument is allocatable/a pointer.
It additionally rejects passing a descriptorless type(*) to an
assumed-rank dummy argument. [F2018:C711]
PR fortran/102086
PR fortran/92189
PR fortran/92621
PR fortran/101308
PR fortran/101309
PR fortran/101635
PR fortran/92482
gcc/fortran/ChangeLog:
* decl.c (gfc_verify_c_interop_param): Remove 'sorry' for
scalar allocatable/pointer and len=*.
* expr.c (is_CFI_desc): Return true for for those.
* gfortran.h (CFI_type_kind_shift, CFI_type_mask,
CFI_type_from_type_kind, CFI_VERSION, CFI_MAX_RANK,
CFI_attribute_pointer, CFI_attribute_allocatable,
CFI_attribute_other, CFI_type_Integer, CFI_type_Logical,
CFI_type_Real, CFI_type_Complex, CFI_type_Character,
CFI_type_ucs4_char, CFI_type_struct, CFI_type_cptr,
CFI_type_cfunptr, CFI_type_other): New #define.
* trans-array.c (CFI_FIELD_BASE_ADDR, CFI_FIELD_ELEM_LEN,
CFI_FIELD_VERSION, CFI_FIELD_RANK, CFI_FIELD_ATTRIBUTE,
CFI_FIELD_TYPE, CFI_FIELD_DIM, CFI_DIM_FIELD_LOWER_BOUND,
CFI_DIM_FIELD_EXTENT, CFI_DIM_FIELD_SM,
gfc_get_cfi_descriptor_field, gfc_get_cfi_desc_base_addr,
gfc_get_cfi_desc_elem_len, gfc_get_cfi_desc_version,
gfc_get_cfi_desc_rank, gfc_get_cfi_desc_type,
gfc_get_cfi_desc_attribute, gfc_get_cfi_dim_item,
gfc_get_cfi_dim_lbound, gfc_get_cfi_dim_extent,
gfc_get_cfi_dim_sm):
New define/functions to access the CFI array descriptor.
(gfc_conv_descriptor_type): New function for the GFC descriptor.
(gfc_get_array_span): Handle expr of CFI descriptors and
assumed-type descriptors.
(gfc_trans_array_bounds): Remove 'static'.
(gfc_conv_expr_descriptor): For assumed type, use the dtype of
the actual argument.
(structure_alloc_comps): Remove ' ' inside tabs.
* trans-array.h (gfc_trans_array_bounds, gfc_conv_descriptor_type,
gfc_get_cfi_desc_base_addr, gfc_get_cfi_desc_elem_len,
gfc_get_cfi_desc_version, gfc_get_cfi_desc_rank,
gfc_get_cfi_desc_type, gfc_get_cfi_desc_attribute,
gfc_get_cfi_dim_lbound, gfc_get_cfi_dim_extent,
gfc_get_cfi_dim_sm):
New prototypes.
* trans-decl.c (gfor_fndecl_cfi_to_gfc, gfor_fndecl_gfc_to_cfi):
Remove global vars.
(gfc_build_builtin_function_decls): Remove their initialization.
(gfc_get_symbol_decl, create_function_arglist,
gfc_trans_deferred_vars): Update for CFI.
(convert_CFI_desc): Remove and replace by ...
(gfc_conv_cfi_to_gfc): ... this function
(gfc_generate_function_code): Call it; create local GFC var for
CFI.
* trans-expr.c (gfc_maybe_dereference_var): Handle CFI.
(gfc_conv_subref_array_arg): Handle the if-noncontigous-only copy
in
when the result should be a descriptor.
(gfc_conv_gfc_desc_to_cfi_desc): Completely rewritten.
(gfc_conv_procedure_call): CFI fixes.
* trans-openmp.c (gfc_omp_is_optional_argument,
gfc_omp_check_optional_argument): Handle optional
CFI.
* trans-stmt.c (gfc_trans_select_rank_cases): Cleanup, avoid
invalid
code for allocatable/pointer dummies, which cannot be assumed size.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #60 from Eric Botcazou --- > And yes, the previous PR was more of a special case while this PR is in the > middle of the bootstrap path (triggers as part of compiling a-except.adb). Right. As a last resort, I'm OK to try backporting the improved bootstrap process present on the mainline onto this 11 branch.
[Bug tree-optimization/102788] [12 Regression] Wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102788
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org,
||rsandifo at gcc dot gnu.org
--- Comment #5 from Richard Biener ---
The interesting thing is that the difference starts with pattern recog (for the
epilogue loop) where the main loop recognizes a bool pattern but the epilogue
one
does not. That's because 'long long unsigned int' doesn't have a vector type
with V4QImode.
But then vect_recog_cast_forwprop_pattern makes this cast irrelevant but we
do not re-visit the bool pattern as we only (re-)process the pattern def
sequence stmts but not the stmt itself:
/* If this statement has already been replaced with pattern statements,
leave the original statement alone, since the first match wins.
Instead try to match against the definition statements that feed
the main pattern statement. */
if (STMT_VINFO_IN_PATTERN_P (stmt_info))
{
gimple_stmt_iterator gsi;
for (gsi = gsi_start (STMT_VINFO_PATTERN_DEF_SEQ (stmt_info));
!gsi_end_p (gsi); gsi_next (&gsi))
vect_pattern_recog_1 (vinfo, recog_func,
vinfo->lookup_stmt (gsi_stmt (gsi)));
return;
}
and we're also not expecting to do this:
void
vect_mark_pattern_stmts (vec_info *vinfo,
stmt_vec_info orig_stmt_info, gimple *pattern_stmt,
tree pattern_vectype)
{
...
/* We shouldn't be replacing the main pattern statement. */
gcc_assert (STMT_VINFO_RELATED_STMT (orig_stmt_info)->stmt
!= orig_pattern_stmt);
but bool pattern recog is required for correctness, we are not going to
fail vectorization later.
Richard - you added most of the re-processing of patterns (and also the
forwprop pattern that triggers the failure situation). Can you share
insights and maybe fix this?
It's also really a latent issue. One could use __int128_t to trigger it
for V8QI vectorization, but that's likely it - the trigger is the FAIL
of the bool pattern recog (which should probably a fatal vectorization
FAIL in case the stmt is ending up relevant).
What "works" (for the testcase) is to not terminate vect_recog_bool_pattern
when we have no vector type for the LHS but allow NULL to be propagated
through the pattern machinery (nothing will in the end use that type
for this testcase). As said, since bool patterns are required for
correctness we cannot really early-out here but need to communicate
failure upthread. I'm going to test a patch with this route.
[Bug tree-optimization/102788] [12 Regression] Wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102788 --- Comment #6 from Richard Biener --- Created attachment 51621 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51621&action=edit patch I am testing
[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675 Jay Feldblum changed: What|Removed |Added CC||yfeldblum at gmail dot com --- Comment #7 from Jay Feldblum --- Created attachment 51622 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51622&action=edit [PATCH] print extended assertion failures to stderr It is ordinarily expected that assertion failures go to stderr and that stdout be reserved for output intentionally produced by the application. Testing, deployment, and monitoring infrastructures are often set up to match this expectation. A colleague recently noticed that some testing infrastructure at work does not observe assertion failures from libstdc++ that would be expected to be observed from building with `-D_GLIBCXX_ASSERTIONS`. I have attached a patch - may we do something like it, or at least make progress otherwise? I read through the comments on this bug so far. It seems like there is some desire to address this issue, with a caveat listed and with a suggestion listed. The caveat, not to pollute `bits/c++config` with `#include `. Are there more caveats to be aware of? The suggestion, to export a helper routine that would work like `printf` but emit to stderr. I can't tell whether that's a strong or weak preference. The patch I went with - exporting a helper routine that returns the value of `stderr` - is a bit smaller. But if that's not the preference then I can change the patch. Beyond the question of what helper routine to add, there is where to add it. I cam e up with a guess but perhaps a better place will be suggested.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #61 from Arnaud Charlet --- (In reply to Eric Botcazou from comment #60) > > And yes, the previous PR was more of a special case while this PR is in the > > middle of the bootstrap path (triggers as part of compiling a-except.adb). > > Right. As a last resort, I'm OK to try backporting the improved bootstrap > process present on the mainline onto this 11 branch. No need to, there are actually several reasons to not rely on exception propagation during bootstrap, so let's restore this invariant instead, I'm testing a change to that effect.
[Bug middle-end/102808] [12 regression] sve/mask_gather_load_1.c fails since g:9b2ad21ab3ebc21a3408108327fa1a7cbedaf217
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102808 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 CC||rguenth at gcc dot gnu.org, ||rsandifo at gcc dot gnu.org Keywords||missed-optimization --- Comment #1 from Richard Biener --- Can arm folks please have a look here? Cases like for (int i = 0; i < n; ++i) \ if (cmp1[i] == cmp2[i]) \ dest[i] += src[indices[i]]; involve undefined integer overflow ops conditionally executed which are now rewritten to unsigned. On x86 the only fallout in gather/scatter testcases was with invariants and vect_check_gather_scatter plus/minus handling but I mitigated that. Note the testcases only scan for assembler, not for vectorization results and thus they might simply be too fragile.
[Bug driver/102803] Bug: -no-canonical-prefixes not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102803 Richard Biener changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #8 from Richard Biener --- CCing Matthias.
[Bug target/100208] amdgcn fails to build with llvm-mc from llvm12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100208 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:9552afb2aec54b793d61ce85c93869a2f2a7958f commit r11-9162-g9552afb2aec54b793d61ce85c93869a2f2a7958f Author: Andrew Stubbs Date: Thu Jul 8 15:47:53 2021 +0100 amdgcn: Add -mxnack and -msram-ecc [PR 100208] gcc/ChangeLog: PR target/100208 * config/gcn/gcn-hsa.h (DRIVER_SELF_SPECS): New. (ASM_SPEC): Set -mattr for xnack and sram-ecc. * config/gcn/gcn-opts.h (enum sram_ecc_type): New. * config/gcn/gcn-valu.md: Add a warning comment. * config/gcn/gcn.c (gcn_option_override): Add "sorry" for -mxnack. (output_file_start): Add xnack and sram-ecc state to ".amdgcn_target". * config/gcn/gcn.md: Add a warning comment. * config/gcn/gcn.opt: Add -mxnack and -msram-ecc. * config/gcn/mkoffload.c (EF_AMDGPU_MACH_AMDGCN_GFX908): Remove SRAM-ECC flag. (EF_AMDGPU_XNACK): New. (EF_AMDGPU_SRAM_ECC): New. (elf_flags): New. (copy_early_debug_info): Use elf_flags. (main): Handle -mxnack and -msram-ecc options. * doc/invoke.texi: Document -mxnack and -msram-ecc. gcc/testsuite/ChangeLog: PR target/100208 * gcc.target/gcn/sram-ecc-1.c: New test. * gcc.target/gcn/sram-ecc-2.c: New test. * gcc.target/gcn/sram-ecc-3.c: New test. * gcc.target/gcn/sram-ecc-4.c: New test. * gcc.target/gcn/sram-ecc-5.c: New test. * gcc.target/gcn/sram-ecc-6.c: New test. * gcc.target/gcn/sram-ecc-7.c: New test. * gcc.target/gcn/sram-ecc-8.c: New test. (cherry picked from commit aad32a00b7d2b64ae158b2b167768a9ae3e20f6e)
[Bug target/100208] amdgcn fails to build with llvm-mc from llvm12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100208 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:92aed72a73993607b845651630ba8a48f332097c commit r11-9163-g92aed72a73993607b845651630ba8a48f332097c Author: Andrew Stubbs Date: Tue Jul 27 15:40:21 2021 +0100 amdgcn: Fix attributes for LLVM-12 [PR 100208] This should work for a wider range of LLVM 12 variants now. More work required for LLVM 13 though. gcc/ChangeLog: PR target/100208 * config.in: Regenerate. * config/gcn/gcn-hsa.h (A_FIJI): New define. (A_900): New define. (A_906): New define. (A_908): New define. (ASM_SPEC): Use A_FIJI, A_900, A_906 and A_908. * config/gcn/gcn.c (output_file_start): Adjust attributes according to the assembler capabilities. * config/gcn/mkoffload.c (main): Likewise. * configure: Regenerate. * configure.ac: Add tests for LLVM assembler attribute features.
[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 #2 from Jonathan Wakely ---
It evaluates to false because is_array_v is false for that type.
The next candidate is the problem:
and 'std::ranges::ref_view> &' does not satisfy
'__member_begin'
because '__decay_copy(__t.begin())' would be invalid: no member named 'begin'
in 'std::ranges::ref_view>'
That's wrong. I don't know why ref_view::begin() isn't usable.
Reduced:
#include
struct Range
{
int* begin() { return &i; }
int* end() { return begin() + 1; }
const int* begin() const { return &i; }
const int* end() const { return begin() + 1; }
int i = 0;
};
int main()
{
static_assert(std::ranges::range);
static_assert(std::ranges::range);
using R = std::ranges::ref_view;
static_assert(std::ranges::range);
using I = decltype(std::declval().begin());
}
[Bug libstdc++/102807] Simple code using ranges::views::keys does not compile with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102807 Pilar Latiesa changed: What|Removed |Added CC||pilarlatiesa at gmail dot com --- Comment #3 from Pilar Latiesa --- I believe this is a consequence of Clang bug 44833.
[Bug libstdc++/102807] Simple code using ranges::views::keys does not compile with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102807
--- Comment #4 from Jonathan Wakely ---
#include
struct Range
{
int* begin() { return 0; }
int* end() { return 0; }
};
int main()
{
static_assert(std::ranges::range);
using R = std::ranges::ref_view;
static_assert( std::ranges::__cust_access::__member_begin );
}
The problem happens when instantiating ref_view for any R. The
view_interface> CRTP base class gets instantiated and that checks
the constraints of its member functions, which depends on the derived class,
which is incomplete at that point.
I think this is a clang bug. It should not be checking the constraints for
view_interface>::data() when checking satisfaction of
range>.
[Bug libstdc++/102807] Simple code using ranges::views::keys does not compile with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102807 Jonathan Wakely changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=44833 --- Comment #5 from Jonathan Wakely --- (In reply to Pilar Latiesa from comment #3) > I believe this is a consequence of Clang bug 44833. Ah yes, that's exactly it. Thanks!
[Bug target/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Component|libgomp |target
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-10-18
CC||dje at gcc dot gnu.org,
||segher at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Ok, I can reproduce, but only with -mcpu=power7. The cost model patch just
uncovered a latent power7 vectorization bug (backend or vectorizer) I'd say.
I've instrumented the testcase a little bit:
// { dg-do run }
// { dg-additional-options "-msse2" { target sse2_runtime } }
// { dg-additional-options "-mavx" { target avx_runtime } }
extern "C" void abort ();
int a[1024] __attribute__((aligned (32))) = { 1 };
int b[1024] __attribute__((aligned (32))) = { 1 };
unsigned char c[1024] __attribute__((aligned (32))) = { 1 };
int k, m;
__UINTPTR_TYPE__ u, u2, u3;
__attribute__((noinline, noclone)) int
foo (int *p)
{
int i, s = 0, s2 = 0, t, t2;
#pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s) \
lastprivate (t2)
for (i = 0; i < 512; i++)
{
a[i] *= p[i];
t2 = k + p[i];
k += m + 1;
s += p[i] + k;
c[i]++;
}
#pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s2) \
lastprivate (t, u, u2, u3)
for (i = 512; i < 1024; i++)
{
a[i] *= p[i];
k += m + 1;
t = k + p[i];
u = (__UINTPTR_TYPE__) &k;
u2 = (__UINTPTR_TYPE__) &s2;
u3 = (__UINTPTR_TYPE__) &t;
s2 += t;
c[i]++;
}
__builtin_printf ("foo %d %d %d %d\n", s, s2, t, t2);
return s + s2 + t + t2;
}
__attribute__((noinline, noclone)) long int
bar (int *p, long int n, long int o)
{
long int i, s = 0, s2 = 0, t, t2;
#pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s) \
lastprivate (t2)
for (i = 0; i < n; i++)
{
a[i] *= p[i];
t2 = k + p[i];
k += m + 1;
s += p[i] + k;
c[i]++;
}
#pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s2) \
lastprivate (t, u, u2, u3)
for (i = n; i < o; i++)
{
a[i] *= p[i];
k += m + 1;
t = k + p[i];
u = (__UINTPTR_TYPE__) &k;
u2 = (__UINTPTR_TYPE__) &s2;
u3 = (__UINTPTR_TYPE__) &t;
s2 += t;
c[i]++;
}
__builtin_printf ("bar %d %d %d %d\n", s, s2, t, t2);
return s + s2 + t + t2;
}
int
main ()
{
#if __SIZEOF_INT__ >= 4
int i;
k = 4;
m = 2;
for (i = 0; i < 1024; i++)
{
a[i] = i - 512;
b[i] = (i - 51) % 39;
c[i] = (unsigned char) i;
}
int s = foo (b);
for (i = 0; i < 1024; i++)
{
if (b[i] != (i - 51) % 39
|| a[i] != (i - 512) * b[i]
|| c[i] != (unsigned char) (i + 1))
{
__builtin_printf ("#1 %d %d %d %d\n", i, b[i], a[i], c[i]);
abort ();
}
a[i] = i - 512;
}
if (k != 4 + 3 * 1024
|| s != 1596127 + (4 + 3 * 511 + b[511]) + (4 + 3 * 1024 + b[1023]))
{
__builtin_printf ("#2 %d %d\n", k, s);
abort ();
}
k = 4;
s = bar (b, 512, 1024);
for (i = 0; i < 1024; i++)
{
if (b[i] != (i - 51) % 39
|| a[i] != (i - 512) * b[i]
|| c[i] != (unsigned char) (i + 2))
{
__builtin_printf ("#3 %d %d %d %d\n", i, b[i], a[i], c[i]);
abort ();
}
a[i] = i - 512;
}
if (k != 4 + 3 * 1024
|| s != 1596127 + (4 + 3 * 511 + b[511]) + (4 + 3 * 1024 + b[1023]))
{
__builtin_printf ("#4 %d %d\n", k, s);
abort ();
}
k = 4;
s = bar (b, 511, 1021);
for (i = 0; i < 1021; i++)
{
if (b[i] != (i - 51) % 39
|| a[i] != (i - 512) * b[i]
|| c[i] != (unsigned char) (i + 3))
{
__builtin_printf ("#5 %d %d %d %d\n", i, b[i], a[i], c[i]);
abort ();
}
a[i] = i - 512;
}
for (i = 1021; i < 1024; i++)
if (b[i] != (i - 51) % 39
|| a[i] != i - 512
|| c[i] != (unsigned char) (i + 2))
{
__builtin_printf ("#6 %d %d %d %d\n", i, b[i], a[i], c[i]);
abort ();
}
if (k != 4 + 3 * 1021
|| s != 1586803 + (4 + 3 * 510 + b[510]) + (4 + 3 * 1021 + b[1020]))
{
__builtin_printf ("#7 %d %d %d %d\n", k, s, b[510], b[1020]);
abort ();
}
#endif
return 0;
}
When compiled with -O2 -m32 -fopenmp -mcpu=power6, this prints:
foo 403860 1192267 3112 1568
bar 403860 1192267 3112 1568
bar 402289 1184514 3100 1564
while with -O2 -m32 -fopenmp -mcpu=power7 it prints:
foo 403860 1192267 3112 1568
bar 403860 1192267 3112 1568
bar 402289 919217 3100 1564
#7 3067 1326170 30 33
Aborted
which seems to suggest it is the:
#pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s2) \
lastprivate (t, u,
[Bug tree-optimization/102809] New: Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102809 Bug ID: 102809 Summary: Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: aldyh at gcc dot gnu.org Target Milestone: --- Tested with https://github.com/UoB-HPC/TSVC_2/pull/2 where one can run a single benchmark. Happens with -Ofast -march=native on znver1 machine: gcc-bisect.py 'gcc *.c -lm -Ofast -march=native -fuse-ld=bfd && timeout 100.7 ./a.out va' -l -e r12-4194-g1f51e9af7b615838 -s r12-4195-gec0124e0acb556cd Bisecting latest revisions ec0124e0acb556cd(05 Oct 2021 18:24)(al...@redhat.com): [took: 7.050s] result: OK LoopTime(sec) Checksum va3.719 1.644725 1f51e9af7b615838(05 Oct 2021 16:47)(jwak...@redhat.com): [took: 5.433s] result: OK LoopTime(sec) Checksum va2.006 1.644725 and can be seen here: https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=14.920.0 https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=14.887.0 https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=14.943.0
[Bug tree-optimization/102809] Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102809 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-10-18 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug target/93183] SVE does not use neg as conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93183 --- Comment #4 from CVS Commits --- The master branch has been updated by Prathamesh Kulkarni : https://gcc.gnu.org/g:20dcda98ed376cb61c74b2c71656f99c671ec9ce commit r12-4470-g20dcda98ed376cb61c74b2c71656f99c671ec9ce Author: prathamesh.kulkarni Date: Mon Oct 18 15:44:06 2021 +0530 [sve] PR93183 - Add support for conditional neg. gcc/ChangeLog: PR target/93183 * gimple-match-head.c (try_conditional_simplification): Add case for single operand. * internal-fn.def: Add entry for COND_NEG internal function. * internal-fn.c (FOR_EACH_CODE_MAPPING): Add entry for NEGATE_EXPR, COND_NEG mapping. * optabs.def: Add entry for cond_neg_optab. * match.pd (UNCOND_UNARY, COND_UNARY): New operator lists. (vec_cond COND (foo A) B) -> (IFN_COND_FOO COND A B): New pattern. (vec_cond COND B (foo A)) -> (IFN_COND_FOO ~COND A B): Likewise. gcc/testsuite/ChangeLog: PR target/93183 * gcc.target/aarch64/sve/cond_unary_4.c: Adjust. * gcc.target/aarch64/sve/pr93183.c: New test.
[Bug tree-optimization/102809] Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102809 --- Comment #1 from Aldy Hernandez --- There's a pending patch in this area that restricts loop threading: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581894.html Does this fix the problem?
[Bug target/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 --- Comment #3 from Jakub Jelinek --- On the trunk, -O2 -fopenmp -mcpu=power6 -maltivec -m32 works fine, while -O2 -fopenmp -mcpu=power6 -mvsx -m32 is miscompiled too.
[Bug c/102810] New: Bogus Wstringop-overread warning when special (integer) pointer values passed to array parameter of a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102810
Bug ID: 102810
Summary: Bogus Wstringop-overread warning when special
(integer) pointer values passed to array parameter of
a function
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at abbott dot org
Target Milestone: ---
I don't know why this code produces a Wstringop-overread warning since it has
nothing to do with string operations. Also, why is there a warning for
argument 2, but not for argument 1?
extern int foo(const int *a, const int b[]);
#define SPECIAL ((int *)2)
int main(void)
{
foo(SPECIAL, SPECIAL);
}
int foo(const int a[], const int b[])
{
return 0;
}
: In function 'main':
:7:5: warning: 'foo' reading 4 bytes from a region of size 0
[-Wstringop-overread]
7 | foo(SPECIAL, SPECIAL);
| ^
:7:5: note: referencing argument 2 of type 'const int *'
:10:5: note: in a call to function 'foo'
10 | int foo(const int a[], const int b[])
| ^~~
[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675 --- Comment #8 from Jonathan Wakely --- (In reply to Jay Feldblum from comment #7) > The caveat, not to pollute `bits/c++config` with `#include really */>`. Are there more caveats to be aware of? No, that's it. The additional overhead of calling a function defined in the library is not a problem, because we're aborting anyway. > > The suggestion, to export a helper routine that would work like `printf` but > emit to stderr. I can't tell whether that's a strong or weak preference. The > patch I went with - exporting a helper routine that returns the value of > `stderr` - is a bit smaller. But if that's not the preference then I can > change the patch. That seems OK. Another option would be to export the existing __snprintf_lite function and print into a buffer, then use ::write(2, ...) to output that. Either way requires adding a new export to the library. Using write has some other advantages, but means polluting the namespace (and isn't available on all targets) which isn't a problem with __builtin_printf or __builtin_fprintf. > Beyond the question of what helper routine to add, there is where to add it. > I cam e up with a guess but perhaps a better place will be suggested. src/c++98/compatibility.cc is definitely wrong, that's for symbols that are only retained for backwards compatibility with previous releases. Not for new symbols for new features. Patches should be sent to the libstdc++ and gcc-patches mailing lists for review though, rather than attached here. Thanks for working on this!
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #62 from Eric Botcazou --- > No need to, there are actually several reasons to not rely on exception > propagation during bootstrap, so let's restore this invariant instead, I'm > testing a change to that effect. Fair enough. In any case, the symptoms are again consistent with a lack of registration of unwind tables, this time for libgcc, so this might be the same underlying issue as the grep-induced mess for GCC 10. My hunch would point to a constructor section merging issue in the linker, maybe related to the GCC configure check for HAVE_LD_RO_RW_SECTION_MIXING, which should fail for MinGW and may incorrectly succeed when things go wrong.
[Bug tree-optimization/102809] Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102809 --- Comment #2 from Martin Liška --- > Does this fix the problem? Yes, it helps! Thank you for the patch.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #63 from Arnaud Charlet --- (In reply to Eric Botcazou from comment #62) > > No need to, there are actually several reasons to not rely on exception > > propagation during bootstrap, so let's restore this invariant instead, I'm > > testing a change to that effect. > > Fair enough. In any case, the symptoms are again consistent with a lack of > registration of unwind tables, this time for libgcc, so this might be the > same underlying issue as the grep-induced mess for GCC 10. My hunch would > point to a constructor section merging issue in the linker, maybe related > to the GCC configure check for HAVE_LD_RO_RW_SECTION_MIXING, which should > fail for MinGW and may incorrectly succeed when things go wrong. Right, that's most likely the underlying issue and indeed ensuring we don't use exception propagation during the bootstrap is just a way to hide/avoid this underlying mismatch.
[Bug tree-optimization/102809] Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102809 --- Comment #3 from Aldy Hernandez --- (In reply to Martin Liška from comment #2) > > Does this fix the problem? > > Yes, it helps! Thank you for the patch. Thanks for all your help here, and sorry for all the noise. Getting the jump threading restrictions in the presence of loops has been chore. It seems we have finally agreed on what should be allowed, and Jeff is about to approve the last bits. Unfortunately, the next step is playing with the pipeline to see if we can remove some threading passes. This will probably unsettle things, but hopefully not as much. Again, thanks.
[Bug tree-optimization/102788] [12 Regression] Wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102788 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:eb032893675afea4b01cc6ad06a3e0dcfe9b51cd commit r12-4472-geb032893675afea4b01cc6ad06a3e0dcfe9b51cd Author: Richard Biener Date: Mon Oct 18 10:31:19 2021 +0200 tree-optimization/102788 - avoid spurious bool pattern fails Bool pattern recog is required for correctness since vectorized compares otherwise produce -1 for true so any context where bool is used as value and not as condition or mask needs to be replaced with CMP ? 1 : 0. When we fail to find a vector type for the result of such use we may not simply elide such transform since a new bool result can emerge when for example the cast_forwprop pattern is applied. So the following avoids failing of the bool pattern recog process and instead not assign a vector type for the stmt. 2021-10-18 Richard Biener PR tree-optimization/102788 * tree-vect-patterns.c (vect_init_pattern_stmt): Allow a NULL vectype. (vect_pattern_recog_1): Likewise. (vect_recog_bool_pattern): Continue matching the pattern even if we do not have a vector type for a conversion result. * g++.dg/vect/pr102788.cc: New testcase.
[Bug target/102811] New: vcvtph2ps and vcvtps2ph should be used to convert _Float16 to SFmode with -mf16c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811
Bug ID: 102811
Summary: vcvtph2ps and vcvtps2ph should be used to convert
_Float16 to SFmode with -mf16c
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
The following testcase:
_Float16 test (_Float16 a, _Float16 b)
{
return a + b;
}
compiles with -O2 -mf16c to:
--cut here--
subq$24, %rsp
pextrw $0, %xmm1, 14(%rsp)
call__extendhfsf2
pinsrw $0, 14(%rsp), %xmm1
vmovss %xmm0, 8(%rsp)
vmovss %xmm1, %xmm1, %xmm0
call__extendhfsf2
vaddss 8(%rsp), %xmm0, %xmm0
call__truncsfhf2
addq$24, %rsp
ret
--cut here--
Instead of calling __extendhfsf2 and __truncsfhf2, we should use vcvtph2ps and
vcvtps2ph (with zeroed elements 1..3) for -m16c targets.
[Bug tree-optimization/102788] [11 Regression] Wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102788 Richard Biener changed: What|Removed |Added Target Milestone|12.0|11.3 Known to work||12.0 Summary|[12 Regression] Wrong code |[11 Regression] Wrong code |with -O3|with -O3 Priority|P1 |P2 --- Comment #8 from Richard Biener --- Fixed on trunk but the issue is latent since the introduction of the forwprop pattern. I'm considering backporting to GCC 11.
[Bug tree-optimization/102809] [12 Regression] Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102809 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |12.0 Summary|Some TSVC benchmarks are|[12 Regression] Some TSVC |slower after|benchmarks are slower after |r12-4195-gec0124e0acb556cd |r12-4195-gec0124e0acb556cd
[Bug gcov-profile/102747] gcov returns 0 when invoked on gcda generated by previous gcc version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102747 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:815f15d3384edbdd73cc54536f30947e15183151 commit r12-4474-g815f15d3384edbdd73cc54536f30947e15183151 Author: Martin Liska Date: Mon Oct 18 11:30:55 2021 +0200 gcov: return proper exit code when error happens PR gcov-profile/102746 PR gcov-profile/102747 gcc/ChangeLog: * gcov.c (main): Return return_code. (output_gcov_file): Mark return_code when error happens. (generate_results): Likewise. (read_graph_file): Likewise. (read_count_file): Likewise.
[Bug gcov-profile/102746] gcov returns 0 un erroneuos incovation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102746 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:815f15d3384edbdd73cc54536f30947e15183151 commit r12-4474-g815f15d3384edbdd73cc54536f30947e15183151 Author: Martin Liska Date: Mon Oct 18 11:30:55 2021 +0200 gcov: return proper exit code when error happens PR gcov-profile/102746 PR gcov-profile/102747 gcc/ChangeLog: * gcov.c (main): Return return_code. (output_gcov_file): Mark return_code when error happens. (generate_results): Likewise. (read_graph_file): Likewise. (read_count_file): Likewise.
[Bug gcov-profile/102746] gcov returns 0 un erroneuos incovation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102746 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Martin Liška --- Fixed on master.
[Bug gcov-profile/102747] gcov returns 0 when invoked on gcda generated by previous gcc version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102747 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Martin Liška --- Fixed on master.
[Bug target/102811] vcvtph2ps and vcvtps2ph should be used to convert _Float16 to SFmode with -mf16c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811 --- Comment #1 from Uroš Bizjak --- Something like (argument and result in %xmm0): vpxor %xmm1, %xmm1, %xmm1 vpblendw %xmm1, %xmm1, %xmm0, $1 vcvtph2ps %xmm0, %xmm1 instead of __extendhfsf2 and: vxorps %xmm1, %xmm1, %xmm1 vblendps %xmm1, %xmm1, %xmm0, $1 vcvtps2ph %xmm0, %xmm1 instead of __truncsfhf2.
[Bug target/26915] missed sized opt returning -1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26915
--- Comment #8 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:247c407c83f0015f4b92d5f71e45b63192f6757e
commit r12-4475-g247c407c83f0015f4b92d5f71e45b63192f6757e
Author: Roger Sayle
Date: Mon Oct 18 12:15:40 2021 +0100
Try placing RTL folded constants in the constant pool.
My recent attempts to come up with a testcase for my patch to evaluate
ss_plus in simplify-rtx.c, identified a missed optimization opportunity
(that's potentially a long-time regression): The RTL optimizers no longer
place constants in the constant pool.
The motivating x86_64 example is the simple program:
typedef char v8qi __attribute__ ((vector_size (8)));
v8qi foo()
{
v8qi tx = { 1, 0, 0, 0, 0, 0, 0, 0 };
v8qi ty = { 2, 0, 0, 0, 0, 0, 0, 0 };
v8qi t = __builtin_ia32_paddsb(tx, ty);
return t;
}
which (with my previous patch) currently results in:
foo:movq.LC0(%rip), %xmm0
movq.LC1(%rip), %xmm1
paddsb %xmm1, %xmm0
ret
even though the RTL contains the result in a REG_EQUAL note:
(insn 7 6 12 2 (set (reg:V8QI 83)
(ss_plus:V8QI (reg:V8QI 84)
(reg:V8QI 85))) "ssaddqi3.c":7:12 1419 {*mmx_ssaddv8qi3}
(expr_list:REG_DEAD (reg:V8QI 85)
(expr_list:REG_DEAD (reg:V8QI 84)
(expr_list:REG_EQUAL (const_vector:V8QI [
(const_int 3 [0x3])
(const_int 0 [0]) repeated x7
])
(nil)
Together with the patch below, GCC will now generate the much
more sensible:
foo:movq.LC2(%rip), %xmm0
ret
My first approach was to look in cse.c (where the REG_EQUAL note gets
added) and notice that the constant pool handling functionality has been
unreachable for a while. A quick search for constant_pool_entries_cost
shows that it's initialized to zero, but never set to a non-zero value,
meaning that force_const_mem is never called. This functionality used
to work way back in 2003, but has been lost over time:
https://gcc.gnu.org/pipermail/gcc-patches/2003-October/116435.html
The changes to cse.c below restore this functionality (placing suitable
constants in the constant pool) with two significant refinements;
(i) it only attempts to do this if the function already uses a constant
pool (thanks to the availability of crtl->uses_constant_pool since 2003).
(ii) it allows different constants (i.e. modes) to have different costs,
so that floating point "doubles" and 64-bit, 128-bit, 256-bit and 512-bit
vectors don't all have the share the same cost. Back in 2003, the
assumption was that everything in a constant pool had the same
cost, hence the global variable constant_pool_entries_cost.
Although this is a useful CSE fix, it turns out that it doesn't cure
my motivating problem above. CSE only considers a single instruction,
so determines that it's cheaper to perform the ss_plus (COSTS_N_INSNS(1))
than read the result from the constant pool (COSTS_N_INSNS(2)). It's
only when the other reads from the constant pool are also eliminated,
that this transformation is a win. Hence a better place to perform
this transformation is in combine, where after failing to "recog" the
load of a suitable constant, it can retry after calling force_const_mem.
This achieves the desired transformation and allows the backend insn_cost
call-back to control whether or not using the constant pool is preferrable.
Alas, it's rare to change code generation without affecting something in
GCC's testsuite. On x86_64-pc-linux-gnu there were two families of new
failures (and I'd predict similar benign fallout on other platforms).
One failure was gcc.target/i386/387-12.c (aka PR target/26915), where
the test is missing an explicit -m32 flag. On i686, it's very reasonable
to materialize -1.0 using "fld1; fchs", but on x86_64-pc-linux-gnu we
currently generate the awkward:
testm1: fld1
fchs
fstpl -8(%rsp)
movsd -8(%rsp), %xmm0
ret
which combine now very reasonably simplifies to just:
testm1: movsd .LC3(%rip), %xmm0
ret
The other class of x86_64-pc-linux-gnu failure was from materialization
of vector constants using vpbroadcast (e.g. gcc.target/i386/pr90773-17.c)
where the decision is finely balanced; the load of an integer register
with an immediate constant, followed by a vpbroadcast is deemed to be
COSTS_N_INSNS(2), whereas a load from the constant pool is also reported
as COSTS_N_INSNS(2). My solution is to tweak the i386.c's rtx_costs
so that all other things being equal, an instruction (sequence) that
accesses memory is fractio
[Bug target/102811] vcvtph2ps and vcvtps2ph should be used to convert _Float16 to SFmode with -mf16c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811 --- Comment #2 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #1) > vxorps %xmm1, %xmm1, %xmm1 > vblendps %xmm1, %xmm1, %xmm0, $1 > vcvtps2ph %xmm0, %xmm1 vmovss %xmm1, %xmm1, %xmm0 instead of vblendps would also do the trick.
[Bug target/102812] New: Unoptimal (and wrong) code for _Float16 insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102812
Bug ID: 102812
Summary: Unoptimal (and wrong) code for _Float16 insert
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
Following code:
--cut here--
typedef _Float16 v8hf __attribute__((__vector_size__ (16)));
v8hf t (_Float16 a)
{
return (v8hf){a, 0, 0, 0, 0, 0, 0, 0};
}
--cut here--
compiles with -msse4 to:
pxor%xmm15, %xmm15
movaps %xmm15, -56(%rsp)
pextrw $0, %xmm0, -56(%rsp)
vmovdqa64 -56(%rsp), %xmm0
PBLWNDW with cleared %xmm15 would be much more optimal, and wouldn't use
memory.
Also, VMOVDQA64 is an AVX512F/AVX512VL, not a SSE4 (not even AVX) instruction.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #64 from Óscar Fuentes --- Searching for HAVE_LD_RO_RW_SECTION_MIXING in the build directory used for extracting the previous gdb backtraces shows this: gcc/auto-host.h:1684:11:/* #undef HAVE_LD_RO_RW_SECTION_MIXING */
[Bug gcov-profile/102746] gcov returns 0 un erroneuos incovation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102746 --- Comment #7 from Илья Шипицин --- wow. thanks for that. btw, will it be "gcc-12 only" or it is going to be backported (I'm interested in gcc-8) ?
[Bug gcov-profile/102746] gcov returns 0 un erroneuos incovation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102746 --- Comment #8 from Martin Liška --- (In reply to Илья Шипицин from comment #7) > wow. thanks for that. > > btw, will it be "gcc-12 only" or it is going to be backported (I'm > interested in gcc-8) ? No, I'm not planning backporting that as it's quite a change in functionality. Note gcc-8 is out of support: https://gcc.gnu.org/
[Bug gcov-profile/102746] gcov returns 0 un erroneuos incovation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102746 --- Comment #9 from Илья Шипицин --- ok, so we'll migrate to gcc-12 :)
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #65 from Eric Botcazou --- > Searching for HAVE_LD_RO_RW_SECTION_MIXING in the build directory used for > extracting the previous gdb backtraces shows this: > > gcc/auto-host.h:1684:11:/* #undef HAVE_LD_RO_RW_SECTION_MIXING */ Thanks. Do you still have this line: r .eh_frame for crtend.o of the GCC 10 compiler after the grep mess was resolved? Do you have the same line for the crtend.o of the GCC 11 compiler?
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #66 from Óscar Fuentes --- (In reply to Eric Botcazou from comment #65) > Thanks. Do you still have this line: > > r .eh_frame > > for crtend.o of the GCC 10 compiler after the grep mess was resolved? Do > you have the same line for the crtend.o of the GCC 11 compiler? The problem with grep didn't affect my gcc 10 install because it was built with grep 3.0, so crtend.o didn't change. Here it is again for completeness: $ for f in `find /mingw32 -name crtend.o` ; do echo $f && nm $f ; done /mingw32/lib/gcc/i686-w64-mingw32/10.3.0/crtend.o b .bss d .ctors.65535 d .data r .eh_frame r .rdata$zzz t .text t .text.startup r ___FRAME_END__ U ___gcc_register_frame t _register_frame_ctor Now, these are the crtend.o created in the gcc 11.2 build directory before it failed at a-except.o (this is also with grep 3.0, while in comment#29 was with the botched grep 3.6, but I see no differences): $ for f in `find /d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32 -name crtend.o` ; do echo $f && nm $f ; done /d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/prev-gcc/crtend.o b .bss d .ctors.65535 d .data r .eh_frame r .rdata$zzz t .text r ___FRAME_END__ U ___gcc_register_frame t _register_frame_ctor /d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/prev-i686-w64-mingw32/libgcc/crtend.o b .bss d .ctors.65535 d .data r .eh_frame r .rdata$zzz t .text r ___FRAME_END__ U ___gcc_register_frame t _register_frame_ctor Note that, as before, .text.startup is present in gcc-10 but missing in gcc-11 crtend.o.
[Bug tree-optimization/102329] pointer "maybe uninitialized" right after assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102329 Florian Weimer changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=28458 --- Comment #7 from Florian Weimer --- We need to suppress this warning for pthread_setspecific in glibc because it is incorrect there. There is currently no good way to implement that suppression unfortunately.
[Bug go/102813] New: gccgo ICE when build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102813 Bug ID: 102813 Summary: gccgo ICE when build Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: unlvsur at live dot com CC: cmang at google dot com Target Milestone: --- inux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -minline-all-stringops -O2 -g -m32 -I . -c -fgo-pkgpath=cmd/go/internal/get ../../../../../../gcc/libgo/go/cmd/go/internal/get/get.go -o cmd/go/internal/get.o during GIMPLE pass: evrp In function 'cmd/go/internal/modget.resolver.resolveQueries': go1: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 0x863cdf tree_class_check_failed(tree_node const*, tree_code_class, char const*, int, char const*) ../../../../gcc/gcc/tree.c:8739 0x791f66 tree_class_check(tree_node*, tree_code_class, char const*, int, char const*) ../../../../gcc/gcc/tree.h:3556 0x791f66 useless_type_conversion_p(tree_node*, tree_node*) ../../../../gcc/gcc/gimple-expr.c:87 0xf742f8 verify_gimple_phi ../../../../gcc/gcc/tree-cfg.c:5128 0xf742f8 verify_gimple_in_cfg(function*, bool) ../../../../gcc/gcc/tree-cfg.c:5457 0xe472a7 execute_function_todo ../../../../gcc/gcc/passes.c:2042 0xe47cce execute_todo ../../../../gcc/gcc/passes.c:2096 Please submit a full bug report, with preprocessed source if appropriate.
[Bug go/102813] gccgo ICE when build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102813 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 102796 ***
[Bug tree-optimization/102796] [12 Regresson] ICE in useless_type_conversion_p at gcc/gimple-expr.c:87 since r12-4443-g93ac832f1846e4867aa6537f76f510fab8e3e87d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102796 Andrew Pinski changed: What|Removed |Added CC||unlvsur at live dot com --- Comment #5 from Andrew Pinski --- *** Bug 102813 has been marked as a duplicate of this bug. ***
[Bug target/102761] [10/11/12 Regression] ICE with -O1 and above: in ix86_print_operand_address_as due to %a0 and if_then_else and X constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102761 --- Comment #3 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:4abc0c196b10251dc80d0743ba9e8ab3e56c61ed commit r12-4484-g4abc0c196b10251dc80d0743ba9e8ab3e56c61ed Author: Uros Bizjak Date: Mon Oct 18 17:03:28 2021 +0200 i386: Fix ICE in ix86_print_opreand_address [PR 102761] 2021-10-18 Uroš Bizjak PR target/102761 gcc/ChangeLog: * config/i386/i386.c (ix86_print_operand_address): Error out for non-address_operand asm operands. gcc/testsuite/ChangeLog: * gcc.target/i386/pr102761.c: New test.
[Bug go/102813] gccgo ICE when build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102813 --- Comment #2 from cqwrteur --- Created attachment 51623 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51623&action=edit config.log
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #67 from Eric Botcazou --- > Note that, as before, .text.startup is present in gcc-10 but missing in > gcc-11 crtend.o. That's expected if you compile with -Og or -O1, i.e. it requires -O2 or above.
[Bug middle-end/102810] [11/12 Regression] Bogus Wstringop-overread passing a smaller array to an array parameter without a bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102810
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2021-10-18
Component|c |middle-end
Summary|Bogus Wstringop-overread|[11/12 Regression] Bogus
|warning when special|Wstringop-overread passing
|(integer) pointer values|a smaller array to an array
|passed to array parameter |parameter without a bound
|of a function |
Status|UNCONFIRMED |NEW
--- Comment #1 from Martin Sebor ---
GCC issues the -Wstringop-xxx warnings in this context only because there isn't
a more appropriate option yet. One should be added.
The warning for argument 2 is a bug. With -Warray-parameter enabled, for the
purposes of out-of-bounds access detection, GCC treats function parameters
declared using the array form (as in void f (int a[2]);) as an indication that
the function expects an array argument with at least as many elements. A bug
in the code applies the same logic to an array parameter declared with no
bounds, as in the example. I confirm this report for this problem.
With the following snippet, a read access warning should only be expected for
the third argument:
extern int foo(const int *a, const int b[], const int c[1]);
int main (void)
{
foo ((int*)2, (int*)2, (int*2));
}
The warning in this instance is issued because functions that take const array
parameters with non-zero bound are assumed to read as many elements from the
parameters as the bound indicates. Because (int*)2 is not a pointer to an
array with at least two elements (or a valid pointer at all), the warning
triggers.
(Note that using invalid pointers like (int*)2 in any expression, including
assigning them to function parameters, is undefined and may be diagnosed in the
future regardless of the context they're used in, including in in arguments 1
and 2 above.)
[Bug middle-end/100316] [11/12 Regression] __clear_cache() does not support NULL-pointer arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100316
--- Comment #4 from CVS Commits ---
The releases/gcc-11 branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:aa827fa170d3e61d17c3daaf4d5008a3c674a005
commit r11-9170-gaa827fa170d3e61d17c3daaf4d5008a3c674a005
Author: Kito Cheng
Date: Thu Oct 7 16:17:13 2021 +0800
[PR/target 100316] Allow constant address for __builtin___clear_cache.
__builtin___clear_cache was able to accept constant address for the
argument, but it seems no longer accept recently, and it even not
accept constant address which is hold in variable when optimization is
enable:
```
void foo3(){
void *yy = (void*)0x1000;
__builtin___clear_cache(yy, yy);
}
```
So this patch make BEGIN and END accept VOIDmode, like cselib_lookup_mem
did per
Jim Wilson's suggestion.
```
static cselib_val *
cselib_lookup_mem (rtx x, int create)
{
...
addr_mode = GET_MODE (XEXP (x, 0));
if (addr_mode == VOIDmode)
addr_mode = Pmode;
```
Changes v2 -> v3:
- Use gcc_assert rather than error, maybe_emit_call_builtin___clear_cache
is
internal use only, and we already checked the type in other place.
Changes v1 -> v2:
- Check is CONST_INT intead of cehck mode, no new testcase, since
constant value with other type like CONST_DOUBLE will catched by
front-end.
e.g.
Code:
```c
void foo(){
__builtin___clear_cache(1.11, 0);
}
```
Error message:
```
clearcache-double.c: In function 'foo':
clearcache-double.c:2:27: error: incompatible type for argument 1 of
'__builtin___clear_cache'
2 | __builtin___clear_cache(1.11, 0);
| ^~~~
| |
| double
clearcache-double.c:2:27: note: expected 'void *' but argument is of type
'double'
```
gcc/ChangeLog:
PR target/100316
* builtins.c (maybe_emit_call_builtin___clear_cache): Allow
CONST_INT for BEGIN and END, and use gcc_assert rather than
error.
gcc/testsuite/ChangeLog:
PR target/100316
* gcc.c-torture/compile/pr100316.c: New.
(cherry picked from commit 4e5bc4e4506a7ae7bb88fc925a425652a1da6b2d)
[Bug middle-end/100316] [11/12 Regression] __clear_cache() does not support NULL-pointer arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100316 Kito Cheng changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Kito Cheng --- Fixed are committed to both trunk and gcc-11 branch now :)
[Bug c++/102804] template matching fails w/ false ambiguity on ternary expressions with enums class defined with unsigned typdef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102804 --- Comment #5 from Todd Rudick --- Richard, is there a way to represent the part of this that is a bug? Presumably accepting the construct but having it break template specialization with an error that can be arbitrarily disconnected from the definition is not a desired behavior. In the production code that I eventually isolated this from, there is in fact no reference at all to the header that contained the enum. Also, it seems likely that the compiler state is bad at that point (?), as the error message indicates an 'unsigned int' ambiguity that doesn't actually exist.
[Bug c++/102804] [9/10/11/12 Regression] template matching fails w/ false ambiguity on ternary expressions with enums class defined with unsigned typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102804
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|NEW
Summary|template matching fails w/ |[9/10/11/12 Regression]
|false ambiguity on ternary |template matching fails w/
|expressions with enums |false ambiguity on ternary
|class defined with unsigned |expressions with enums
|typdef |class defined with unsigned
||typedef
CC||mukesh.kapoor at oracle dot com
Resolution|INVALID |---
Known to work||7.4.0
Last reconfirmed||2021-10-18
Ever confirmed|0 |1
Keywords||rejects-valid
Known to fail||8.1.0
--- Comment #6 from Jonathan Wakely ---
This is a bug, we should either reject 'unsigned int32_t' immediately (which we
only do with -pedantic-errors) or we should accept it and treat it consistently
as unsigned int.
Reduced:
enum: unsigned int32_t { FOO, BAR } foobar = FOO;
int f(int);
int f(unsigned);
auto x = f(1 ? foobar : 13);
With r254043 we just have a pedwarn:
102804.C:2:16: warning: long, short, signed or unsigned used invalidly for
'type name' [-Wpedantic]
enum: unsigned int32_t { FOO, BAR } foobar = FOO;
^~~
With r254046 we get the error:
102804.C:2:16: warning: long, short, signed or unsigned used invalidly for
'type name' [-Wpedantic]
enum: unsigned int32_t { FOO, BAR } foobar = FOO;
^~~
102804.C:5:27: error: call of overloaded 'f(unsigned int)' is ambiguous
auto x = f(1 ? foobar : 13);
^
102804.C:3:5: note: candidate: 'int f(int)'
int f(int);
^
102804.C:4:5: note: candidate: 'int f(unsigned int)'
int f(unsigned);
^
re PR c++/82307 (unscoped enum-base incorrect cast)
/cp
2017-10-24 Mukesh Kapoor
Paolo Carlini
PR c++/82307
* cvt.c (type_promotes_to): Implement C++17, 7.6/4, about unscoped
enumeration type whose underlying type is fixed.
So it was actually caused by fixing the promotion rules for enums (PR 82307),
not by the handling of 'unsigned' applied to a typedef.
[Bug c++/102804] [9/10/11/12 Regression] template matching fails w/ false ambiguity on ternary expressions with enums class defined with unsigned typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102804
--- Comment #7 from Jonathan Wakely ---
Oops, sorry the reduced example was missing the first line.
Fixed, and further reduced:
using int32_t = int;
enum: unsigned int32_t { foo };
int f(int);
int f(unsigned);
auto x = f(1 ? foo : 1);
[Bug objc/102537] Objective-C: can't use >= USE_FIXUP_BEFORE paths on non-Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102537
--- Comment #2 from Matt Jacobson ---
I certainly haven't spent as much time thinking about this as you, but I think
my personal preference would be to add new values to the `flag_objc_abi`
argument. It's already the case that "objc-next-runtime-abi-01.c" supports
both 0 and 1 values; I think it would be reasonable to have
`objc-next-runtime-abi-02.c` support multiple values too. I'd imagine
something like:
2 -- "modern" runtime ABI, pre-SnowLeopard (fixup messages, etc.)
3 -- "modern" runtime ABI, SnowLeopard and later (no fixup messages, weak
protocol metadata
Then the Darwin-target code could (absent an explicit override in the
arguments) select the value for `flag_objc_abi` based on
`-mmacosx-version-min`. And non-Darwin targets could simply default to the
newest ABI (absent an explicit override).
Other versions could be added in the future as support for newer
runtime-ABI-dependent features (e.g., `objc_autoreleasePoolPush()`,
`objc_opt_self()`, `objc_loadWeak()`) is added.
Under this scheme, I think it would make sense to switch `flag_next_runtime` to
being a simple boolean.
===
I think I like this better than using the high byte of `flag_next_runtime`,
which could be cumbersome to build conditionals for. For example, taking your
example of using 0x0100 as the "AVR" platform, a check of whether to use
non-fixup messaging might end up look like:
#define PLATFORM(r) (((r) >> 24) & 0xFF)
#define VERSION(r) ((r) & 0xFF)
if ((PLATFORM(flag_next_runtime) == DARWIN && VERSION(flag_next_runtime) >=
USE_FIXUP_BEFORE)
|| PLATFORM(flag_next_runtime) == AVR)
{ ... }
Yeah, the existing `flag_next_runtime >= USE_FIXUP_BEFORE` would technically
work, but you could imagine other platforms with ID > 0 that want the
pre-USE_FIXUP_BEFORE behavior.
===
> These two were both thoughts during the development but I suspect that the
> mapping to values is a build-time decision and ought to be done in the flags
> override code.
I'd like to understand better what you mean here. Is it that, under the
`flag_objc_abi` scheme I described, the x86_64-Darwin target may want different
logic to select `flag_objc_abi` than the AVR target (for example)? If so then
I agree -- shouldn't that be similar to how the `flag_next_runtime` override is
currently target-dependent? Apologies if I've completely misread that.
[Bug target/102768] [feature request] Add support for aarch64 shadow call stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102768 --- Comment #3 from nsz at gcc dot gnu.org --- well, protection mechanisms are rarely equivalent. neither scs nor traditional stack protector are perfect. to me compiler support for freestanding environments such as linux makes sense. i cannot immediately tell if libc support would work. (android is not a good indicator of what can be done in linux userspace: the android abi is broken between releases while glibc is abi stable, bionic can do hacks in longjmp/setcontext that is not acceptable in glibc and android does not have mixed toolchain issues such as old unwinder tries to unwind across a new binary.)
[Bug tree-optimization/102814] New: [12 regression] quadratique/exponential time complexity for max-jump-thread-duplication-stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102814
Bug ID: 102814
Summary: [12 regression] quadratique/exponential time
complexity for max-jump-thread-duplication-stmts
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dimhen at gmail dot com
Target Milestone: ---
r12-4256 FAST
r12- SLOW
g++ -fpreprocessed -std=c++98 -O2 --param max-jump-thread-duplication-stmts=NNN
-c x.ii
r12-4256 r12-
1800.5s 0.21s
1810.8s > 100s
1901.0s 52s
cat x.ii # cvise'd from proprietary codebase
struct a {
a operator+(int);
};
void *operator new(unsigned long, void *c) { return c; }
struct d {
void h(int *j) { new (j) int(); }
};
struct k {
struct {
int e;
int f;
} g;
};
struct n : k {
a m_fn2();
a o();
int m_fn4();
int operator[](int);
int ae;
void s() {
if (g.e != g.f) {
d l;
int *b;
l.h(b);
}
a m = o();
t(m, ae);
}
template void u(a, af, af);
void t(a, unsigned char);
};
int ah;
struct v {
n w();
};
void x() {
v p;
n ak = p.w(), al, rapdu;
int q(ak.m_fn4());
int r;
for (int i = 0; q; i++) {
if (i == q - 1) {
al.s();
r = ak.m_fn4();
}
al.s();
al.s();
al.s();
al.s();
a am, an = ak.m_fn2(), ao = an + 1, ap = ak.m_fn2(), aq = ap + ah,
ar = aq + r;
al.u(am, ao, ar);
if (i == q - 1)
al.s();
i &&rapdu[1];
}
}
g++ -v
Using built-in specs.
COLLECT_GCC=/home/dimhen/arch-gcc/gcc_current/bin/g++
COLLECT_LTO_WRAPPER=/home/dimhen/arch-gcc/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/home/dimhen/arch-gcc/gcc_current
--enable-checking=yes,df,fold,rtl,extra --enable-languages=c,c++,lto
--disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=native
--enable-libstdcxx-debug
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211015 (experimental) [master r12--ga01704fc45a] (GCC)
[Bug fortran/102815] New: gfortran.dg/bind-c-contiguous-5.f90 fails at execution on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102815 Bug ID: 102815 Summary: gfortran.dg/bind-c-contiguous-5.f90 fails at execution on armeb Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- The new test gfortran.dg/bind-c-contiguous-5.f90 fails on armeb (arm big-endian), such as armeb-linux-gnueabihf: The output contains: At line 928 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_assumed_size_f' At line 928 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_assumed_size_f' At line 928 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_assumed_size_f' abcghinop defghijlm At line 946 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_assumed_size_in_f' At line 946 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_assumed_size_in_f' At line 946 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_assumed_size_in_f' abcghinop defghijlm At line 965 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_expl_size_f' At line 965 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_expl_size_f' At line 965 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_expl_size_f' abcghinop defghijlm At line 983 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_expl_size_in_f' At line 983 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_expl_size_in_f' At line 983 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_expl_size_in_f' abcghinop defghijlm abcghinop abcghinop abcghinop defghijlm defghijlm defghijlm abcghinop abcghinop abcghinop defghijlm defghijlm defghijlm At line 1039 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_assumed_rank_cont_f' At line 1039 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_assumed_rank_cont_f' At line 1039 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_assumed_rank_cont_f' abcghinop abcghinop abcghinop defghijlm defghijlm defghijlm At line 1057 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_assumed_rank_cont_in_f' At line 1057 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_assumed_rank_cont_in_f' At line 1057 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_assumed_rank_cont_in_f' abcghinop abcghinop abcghinop defghijlm defghijlm defghijlm abcghinop defghijlm abcghinop defghijlm At line 1113 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_assumed_shape_cont_f' At line 1113 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_assumed_shape_cont_f' At line 1113 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_assumed_shape_cont_f' abcghinop defghijlm At line 1131 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for arg
[Bug tree-optimization/102796] [12 Regresson] ICE in useless_type_conversion_p at gcc/gimple-expr.c:87 since r12-4443-g93ac832f1846e4867aa6537f76f510fab8e3e87d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102796 Andrew Macleod changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |amacleod at redhat dot com --- Comment #6 from Andrew Macleod --- Created attachment 51624 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51624&action=edit Allow EDGE_EH edges to be processed range_on_edge needs to continue processing EDGE_EH.. See if this fixes all the problems. It results ina lot of UNDEFINED values which caused no end of issues. Its currently running through tests.
[Bug fortran/102816] New: [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102816 Bug ID: 102816 Summary: [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started between 20211010 and 20211017 : $ cat z1.f90 program p type t integer :: a([2]) end type type(t) :: x = t([3, 4]) end $ gfortran-12-20211017 -c z1.f90 f951: internal compiler error: in resolve_structure_cons, at fortran/resolve.c:1467 0x81a894 resolve_structure_cons ../../gcc/fortran/resolve.c:1466 0x80a31c resolve_generic_f ../../gcc/fortran/resolve.c:2799 0x80a31c resolve_function ../../gcc/fortran/resolve.c:3301 0x80a31c gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7143 0x79c024 gfc_reduce_init_expr(gfc_expr*) ../../gcc/fortran/expr.c:3125 0x79f290 gfc_match_init_expr(gfc_expr**) ../../gcc/fortran/expr.c:3173 0x789a04 variable_decl ../../gcc/fortran/decl.c:3019 0x789a04 gfc_match_data_decl() ../../gcc/fortran/decl.c:6328 0x7f2d63 match_word ../../gcc/fortran/parse.c:67 0x7f2d63 decode_statement ../../gcc/fortran/parse.c:378 0x7f47aa next_free ../../gcc/fortran/parse.c:1388 0x7f47aa next_statement ../../gcc/fortran/parse.c:1620 0x7f5ecb parse_spec ../../gcc/fortran/parse.c:4159 0x7f8c9c parse_progunit ../../gcc/fortran/parse.c:6125 0x7fa421 gfc_parse_file() ../../gcc/fortran/parse.c: 0x8476bf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/102817] New: [12 Regression] ICE in gfc_clear_shape, at fortran/expr.c:422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102817 Bug ID: 102817 Summary: [12 Regression] ICE in gfc_clear_shape, at fortran/expr.c:422 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started between 20211003 and 20211010 : $ cat z1.f90 program p type t integer :: a(1,2) = 3 end type type(t), parameter :: x(1) = t(4) integer :: y(1,2) y = (x(1)%a) print *, y end $ gfortran-12-20211003 -c z1.f90 $ $ gfortran-12-20211017 -c z1.f90 f951: internal compiler error: Segmentation fault 0xd47e4f crash_signal ../../gcc/toplev.c:322 0x798d1b gfc_clear_shape(__mpz_struct (*) [1], int) ../../gcc/fortran/expr.c:422 0x798d1b gfc_free_shape(__mpz_struct (**) [1], int) ../../gcc/fortran/expr.c:432 0x798e3d free_expr0 ../../gcc/fortran/expr.c:513 0x798ff0 gfc_replace_expr(gfc_expr*, gfc_expr*) ../../gcc/fortran/expr.c:626 0x79c768 simplify_const_ref ../../gcc/fortran/expr.c:1999 0x79ce5e gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.c:2312 0x79d0ab simplify_parameter_variable ../../gcc/fortran/expr.c:2141 0x79ce2d gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.c:2279 0x79c9a6 simplify_intrinsic_op ../../gcc/fortran/expr.c:1188 0x79c9a6 gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.c:2268 0x80bb79 resolve_operator ../../gcc/fortran/resolve.c:4470 0x80807f gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7136 0x810aa4 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:11806 0x810aa4 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11908 0x812097 resolve_codes ../../gcc/fortran/resolve.c:17512 0x81215e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17547 0x7fa494 resolve_all_program_units ../../gcc/fortran/parse.c:6519 0x7fa494 gfc_parse_file() ../../gcc/fortran/parse.c:6771 0x8476bf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/102817] [12 Regression] ICE in gfc_clear_shape, at fortran/expr.c:422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102817 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from G. Steinmetz --- This variant still works : $ cat z2.f90 program p type t integer :: a(1,2) = 3 end type type(t), parameter :: x(1) = t(4) integer :: y(1,2) y = x(1)%a print *, y end $ gfortran-12-20211017 z2.f90 && ./a.out 4 4 $
[Bug fortran/102818] New: ICE in gfc_resolve_formal_arglist, at fortran/resolve.c:282
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102818 Bug ID: 102818 Summary: ICE in gfc_resolve_formal_arglist, at fortran/resolve.c:282 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- The following error message always shows the symbol name 'ppr@'. Finally found a case with ICE, seems to be older than r5. $ cat z1.f90 module m type t contains procedure :: f end type contains integer function f() procedure(real), pointer :: f end end $ cat z2.f90 # no ICE, same error module m type t contains procedure, nopass :: f end type contains integer function f() procedure(real), pointer :: f end end $ gfortran-12-20211017 -c z1.f90 z1.f90:8:35: 8 | procedure(real), pointer :: f | 1 Error: Symbol 'ppr@' at (1) already has basic type of INTEGER f951: internal compiler error: Segmentation fault 0xeed8df crash_signal ../../gcc/toplev.c:322 0x857700 gfc_resolve_formal_arglist(gfc_symbol*) ../../gcc/fortran/resolve.c:282 0x873672 do_traverse_symtree ../../gcc/fortran/symbol.c:4171 0x8579e3 resolve_formal_arglists ../../gcc/fortran/resolve.c:563 0x8579e3 resolve_contained_functions ../../gcc/fortran/resolve.c:1147 0x8579e3 resolve_types ../../gcc/fortran/resolve.c:17419 0x85307c gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17545 0x83b1c2 gfc_parse_file() ../../gcc/fortran/parse.c:6721 0x8891bf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug tree-optimization/102819] New: [11/12 Regression] IFN_COMPLEX_MUL matches things that it shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819 Bug ID: 102819 Summary: [11/12 Regression] IFN_COMPLEX_MUL matches things that it shouldn't Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rsandifo at gcc dot gnu.org CC: tnfchris at gcc dot gnu.org Target Milestone: --- Created attachment 51625 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51625&action=edit Examples of correct and incorrect matches complex_mul_pattern::matches() seems to accept too much. IIUC, for the non-conjugate case, it matches if: * the root is an interleaving of a SUB node and an ADD node * the children of the ADD node are two multiplications * the left-hand multiplication includes an EVEN/EVEN permute (i.e. multiplication by real) However, for the non-conjugate case, there don't seem to be any checks for the contents of the right-hand multiplication or how they match up with the left-hand multiplication. The later code then drops one child of this right-hand node. (If we don't currently check that the SUB node has the same children as the ADD node then perhaps we should check that too. Now that we have general VEC_PERM_EXPR nodes, the children could in principle be different.) With -O3 -march=armv8.2-a+sve, all of the functions in the attached test are recognised as complex multiplications, even though only good1 and good2 really are. There are quite a few other cases in which we incorrectly match a COMPLEX_MUL but then bail out due to: Built SLP cancelled: all SLP instances support load/store-lanes (Perhaps we should have a --param to disable that load/store-lanes check?)
[Bug c++/94310] using constructor inheritance breaks the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94310 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||ppalka at gcc dot gnu.org Target Milestone|--- |11.0 --- Comment #4 from Patrick Palka --- This looks fixed in GCC 11/12, ever since r11-6942
[Bug c++/92911] Valid lambda inside variadic template does not compile (2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92911 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #3 from Patrick Palka --- dup *** This bug has been marked as a duplicate of bug 92909 ***
[Bug c++/92909] [8/9/10 Regression] ICE on incorrect lambda inside variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92909 --- Comment #8 from Patrick Palka --- *** Bug 92911 has been marked as a duplicate of this bug. ***
[Bug c++/102820] New: Failure to compile void{}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102820
Bug ID: 102820
Summary: Failure to compile void{}
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
void f()
{
void{};
}
This has been considered valid since
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2351 was accepted
as a DR in 2018, but GCC fails to compile it, with this error:
: In function 'void f()':
:3:10: error: compound literal of non-object type 'void'
3 | void{};
| ^
[Bug c++/102820] Failure to compile void{}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102820 Marek Polacek changed: What|Removed |Added Last reconfirmed||2021-10-18 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Confirmed.
[Bug tree-optimization/102819] [11/12 Regression] IFN_COMPLEX_MUL matches things that it shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819 Tamar Christina changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-10-18 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org --- Comment #1 from Tamar Christina --- bad3 is fixed already by my local patch set, I will fix bad1 and bad2 next week and cleanup a bit and make a patch for backport. > (If we don't currently check that the SUB node has the same children as the ADD node then perhaps we should check that too. Now that we have general VEC_PERM_EXPR nodes, the children could in principle be different.) Already done in the new patches.
[Bug c/102821] New: Tentative definition of variable with internal linkage has incomplete non-array type: missing diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102821
Bug ID: 102821
Summary: Tentative definition of variable with internal linkage
has incomplete non-array type: missing diagnostics
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pavel.morozkin at gmail dot com
Target Milestone: ---
Sample code (t940.c):
static struct s foo;
static struct s {int a;} foo;
Invocation:
$ gcc t940.c -c -std=c11 -pedantic -Wall -Wextra -Wno-unused-variable
Expected diagnostics:
t940.c:1:17: warning: tentative definition of variable with internal linkage
has incomplete non-array type 'struct s'
[-Wtentative-definition-incomplete-type]
Actual diagnostics:
Notes:
1. C11, 6.9.2 External object definitions, 3:
> If the declaration of an identifier for an object is a tentative definition
> and has internal linkage, the declared type shall not be an incomplete type.
2. C11, 4. Conformance, 1:
> In this International Standard, ‘‘shall’’ is to be interpreted as a
> requirement on an implementation or on a program; conversely, ‘‘shall not’’
> is to be interpreted as a prohibition.
[Bug c/102821] Tentative definition of variable with internal linkage has incomplete non-array type: missing diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102821 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-10-18 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug other/102822] New: [12 regression] 27_io/ios_base/failure/dual_abi.cc failure after r12-4443
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102822
Bug ID: 102822
Summary: [12 regression] 27_io/ios_base/failure/dual_abi.cc
failure after r12-4443
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
g:93ac832f1846e4867aa6537f76f510fab8e3e87d, r12-4443
make -k check RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
conformance.exp=27_io/ios_base/failure/dual_abi.cc"
FAIL: 27_io/ios_base/failure/dual_abi.cc execution test
FAIL: 27_io/ios_base/failure/dual_abi.cc execution test
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/27_io/ios_base/failure/dual_abi.cc:52:
void test01(): Assertion 'caught_ios_failure' failed.
FAIL: 27_io/ios_base/failure/dual_abi.cc execution test
commit 93ac832f1846e4867aa6537f76f510fab8e3e87d
Author: Andrew MacLeod
Date: Thu Oct 7 10:12:29 2021 -0400
Ranger : Do not process abnormal ssa-names.
