[Bug c++/111169] ICE on auto with may_alias attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 89867 *** This bug has been marked as a duplicate of bug 89867 ***
[Bug c++/89867] internal compiler error: in layout_type, at stor-layout.c:2578
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89867 Andrew Pinski changed: What|Removed |Added CC||stevenxia990430 at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 69 has been marked as a duplicate of this bug. ***
[Bug fortran/102112] Cannot associate with component of associate target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102112 --- Comment #4 from CVS Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:d6997a5aab7aaa325946a6283bfee8ac2bd9f540 commit r13-7761-gd6997a5aab7aaa325946a6283bfee8ac2bd9f540 Author: Paul Thomas Date: Sun Aug 27 09:51:32 2023 +0100 Fortran: Fix some problems blocking associate meta-bug [PR87477] 2023-08-27 Paul Thomas gcc/fortran PR fortran/87477 * parse.cc (parse_associate): Replace the existing evaluation of the target rank with calls to gfc_resolve_ref and gfc_expression_rank. Identify untyped target function results with structure constructors by finding the appropriate derived type. * resolve.cc (resolve_symbol): Allow associate variables to be assumed shape. gcc/testsuite/ PR fortran/87477 * gfortran.dg/associate_54.f90 : Cope with extra error. PR fortran/102109 * gfortran.dg/pr102109.f90 : New test. PR fortran/102112 * gfortran.dg/pr102112.f90 : New test. PR fortran/102190 * gfortran.dg/pr102190.f90 : New test. PR fortran/102532 * gfortran.dg/pr102532.f90 : New test. PR fortran/109948 * gfortran.dg/pr109948.f90 : New test. PR fortran/99326 * gfortran.dg/pr99326.f90 : New test.
[Bug fortran/102109] Associate to construct compound object results in incorrect type inferred
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102109 --- Comment #5 from CVS Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:d6997a5aab7aaa325946a6283bfee8ac2bd9f540 commit r13-7761-gd6997a5aab7aaa325946a6283bfee8ac2bd9f540 Author: Paul Thomas Date: Sun Aug 27 09:51:32 2023 +0100 Fortran: Fix some problems blocking associate meta-bug [PR87477] 2023-08-27 Paul Thomas gcc/fortran PR fortran/87477 * parse.cc (parse_associate): Replace the existing evaluation of the target rank with calls to gfc_resolve_ref and gfc_expression_rank. Identify untyped target function results with structure constructors by finding the appropriate derived type. * resolve.cc (resolve_symbol): Allow associate variables to be assumed shape. gcc/testsuite/ PR fortran/87477 * gfortran.dg/associate_54.f90 : Cope with extra error. PR fortran/102109 * gfortran.dg/pr102109.f90 : New test. PR fortran/102112 * gfortran.dg/pr102112.f90 : New test. PR fortran/102190 * gfortran.dg/pr102190.f90 : New test. PR fortran/102532 * gfortran.dg/pr102532.f90 : New test. PR fortran/109948 * gfortran.dg/pr109948.f90 : New test. PR fortran/99326 * gfortran.dg/pr99326.f90 : New test.
[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477 --- Comment #6 from CVS Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:d6997a5aab7aaa325946a6283bfee8ac2bd9f540 commit r13-7761-gd6997a5aab7aaa325946a6283bfee8ac2bd9f540 Author: Paul Thomas Date: Sun Aug 27 09:51:32 2023 +0100 Fortran: Fix some problems blocking associate meta-bug [PR87477] 2023-08-27 Paul Thomas gcc/fortran PR fortran/87477 * parse.cc (parse_associate): Replace the existing evaluation of the target rank with calls to gfc_resolve_ref and gfc_expression_rank. Identify untyped target function results with structure constructors by finding the appropriate derived type. * resolve.cc (resolve_symbol): Allow associate variables to be assumed shape. gcc/testsuite/ PR fortran/87477 * gfortran.dg/associate_54.f90 : Cope with extra error. PR fortran/102109 * gfortran.dg/pr102109.f90 : New test. PR fortran/102112 * gfortran.dg/pr102112.f90 : New test. PR fortran/102190 * gfortran.dg/pr102190.f90 : New test. PR fortran/102532 * gfortran.dg/pr102532.f90 : New test. PR fortran/109948 * gfortran.dg/pr109948.f90 : New test. PR fortran/99326 * gfortran.dg/pr99326.f90 : New test.
[Bug fortran/99326] [10/11/12/13/14 Regression] ICE in gfc_build_dummy_array_decl, at fortran/trans-decl.c:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99326 --- Comment #8 from CVS Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:d6997a5aab7aaa325946a6283bfee8ac2bd9f540 commit r13-7761-gd6997a5aab7aaa325946a6283bfee8ac2bd9f540 Author: Paul Thomas Date: Sun Aug 27 09:51:32 2023 +0100 Fortran: Fix some problems blocking associate meta-bug [PR87477] 2023-08-27 Paul Thomas gcc/fortran PR fortran/87477 * parse.cc (parse_associate): Replace the existing evaluation of the target rank with calls to gfc_resolve_ref and gfc_expression_rank. Identify untyped target function results with structure constructors by finding the appropriate derived type. * resolve.cc (resolve_symbol): Allow associate variables to be assumed shape. gcc/testsuite/ PR fortran/87477 * gfortran.dg/associate_54.f90 : Cope with extra error. PR fortran/102109 * gfortran.dg/pr102109.f90 : New test. PR fortran/102112 * gfortran.dg/pr102112.f90 : New test. PR fortran/102190 * gfortran.dg/pr102190.f90 : New test. PR fortran/102532 * gfortran.dg/pr102532.f90 : New test. PR fortran/109948 * gfortran.dg/pr109948.f90 : New test. PR fortran/99326 * gfortran.dg/pr99326.f90 : New test.
[Bug fortran/102532] [10/11/12/13/14 Regression] ICE in gfc_get_corank, at fortran/expr.c:5769
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102532 --- Comment #5 from CVS Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:d6997a5aab7aaa325946a6283bfee8ac2bd9f540 commit r13-7761-gd6997a5aab7aaa325946a6283bfee8ac2bd9f540 Author: Paul Thomas Date: Sun Aug 27 09:51:32 2023 +0100 Fortran: Fix some problems blocking associate meta-bug [PR87477] 2023-08-27 Paul Thomas gcc/fortran PR fortran/87477 * parse.cc (parse_associate): Replace the existing evaluation of the target rank with calls to gfc_resolve_ref and gfc_expression_rank. Identify untyped target function results with structure constructors by finding the appropriate derived type. * resolve.cc (resolve_symbol): Allow associate variables to be assumed shape. gcc/testsuite/ PR fortran/87477 * gfortran.dg/associate_54.f90 : Cope with extra error. PR fortran/102109 * gfortran.dg/pr102109.f90 : New test. PR fortran/102112 * gfortran.dg/pr102112.f90 : New test. PR fortran/102190 * gfortran.dg/pr102190.f90 : New test. PR fortran/102532 * gfortran.dg/pr102532.f90 : New test. PR fortran/109948 * gfortran.dg/pr109948.f90 : New test. PR fortran/99326 * gfortran.dg/pr99326.f90 : New test.
[Bug fortran/102190] Syntax error reported in associate construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102190 --- Comment #4 from CVS Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:d6997a5aab7aaa325946a6283bfee8ac2bd9f540 commit r13-7761-gd6997a5aab7aaa325946a6283bfee8ac2bd9f540 Author: Paul Thomas Date: Sun Aug 27 09:51:32 2023 +0100 Fortran: Fix some problems blocking associate meta-bug [PR87477] 2023-08-27 Paul Thomas gcc/fortran PR fortran/87477 * parse.cc (parse_associate): Replace the existing evaluation of the target rank with calls to gfc_resolve_ref and gfc_expression_rank. Identify untyped target function results with structure constructors by finding the appropriate derived type. * resolve.cc (resolve_symbol): Allow associate variables to be assumed shape. gcc/testsuite/ PR fortran/87477 * gfortran.dg/associate_54.f90 : Cope with extra error. PR fortran/102109 * gfortran.dg/pr102109.f90 : New test. PR fortran/102112 * gfortran.dg/pr102112.f90 : New test. PR fortran/102190 * gfortran.dg/pr102190.f90 : New test. PR fortran/102532 * gfortran.dg/pr102532.f90 : New test. PR fortran/109948 * gfortran.dg/pr109948.f90 : New test. PR fortran/99326 * gfortran.dg/pr99326.f90 : New test.
[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948 --- Comment #21 from CVS Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:d6997a5aab7aaa325946a6283bfee8ac2bd9f540 commit r13-7761-gd6997a5aab7aaa325946a6283bfee8ac2bd9f540 Author: Paul Thomas Date: Sun Aug 27 09:51:32 2023 +0100 Fortran: Fix some problems blocking associate meta-bug [PR87477] 2023-08-27 Paul Thomas gcc/fortran PR fortran/87477 * parse.cc (parse_associate): Replace the existing evaluation of the target rank with calls to gfc_resolve_ref and gfc_expression_rank. Identify untyped target function results with structure constructors by finding the appropriate derived type. * resolve.cc (resolve_symbol): Allow associate variables to be assumed shape. gcc/testsuite/ PR fortran/87477 * gfortran.dg/associate_54.f90 : Cope with extra error. PR fortran/102109 * gfortran.dg/pr102109.f90 : New test. PR fortran/102112 * gfortran.dg/pr102112.f90 : New test. PR fortran/102190 * gfortran.dg/pr102190.f90 : New test. PR fortran/102532 * gfortran.dg/pr102532.f90 : New test. PR fortran/109948 * gfortran.dg/pr109948.f90 : New test. PR fortran/99326 * gfortran.dg/pr99326.f90 : New test.
[Bug target/111170] New: Malformed manifest does not allow to run gcc on Windows XP (Accessing a corrupted shared library)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70 Bug ID: 70 Summary: Malformed manifest does not allow to run gcc on Windows XP (Accessing a corrupted shared library) Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jdx at o2 dot pl CC: costas.argyris at gmail dot com Target Milestone: --- Target: i686-w64-mingw32 @ Windows XP Build: i686-w64-mingw32 @ Windows 10 I wanted to build gcc 13.2 with intention to run it on an old Windows XP/Pentium-M machine. My build environment is MSYS2/MinGW32 @ Windows 10. Everything went fine and I could run resulting binaries on the build machine under MinGW32 terminal. However when I tried to run them on the target machine, I got "bash: ./mingw-gcc/bin/gcc: Accessing a corrupted shared library". After a few days of heavy fight I found out that this is due to malformed manifest embedded in some (not all!) gcc executables. Newer version of Windows are more forgiving and can tolerate malformed manifests while Windows XP is not; that's why I could run freshly built gcc on my Windows 10 box. Using a resource editor I have replaced malformed manifests with a default one (taken from https://packages.msys2.org/base/mingw-w64-windows-default-manifest) and now everything runs fine on XP. The malformed manifest comes from https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=d11e088210a551235d3937f867ee1c8b19d02290 related to PR108865. I think the proper solution is to merge default manifest from MSYS and the one mentioned in the diff above.
[Bug target/111170] Malformed manifest does not allow to run gcc on Windows XP (Accessing a corrupted shared library)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70 Costas Argyris changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #1 from Costas Argyris --- Looks like '... @ Windows XP' is the Host, not the Target, in the PR.Target seems irrelevant here. LH, is this the issue you originally mentioned about my change inadvertently replacing the default MSYS2 manifest?
[Bug target/111171] New: [14 Regression] ICE: in decompose, at rtl.h:2297 at -O1 on riscv64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71 Bug ID: 71 Summary: [14 Regression] ICE: in decompose, at rtl.h:2297 at -O1 on riscv64-unknown-linux-gnu Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: riscv64-unknown-linux-gnu Build: x86_64-pc-linux-gnu Created attachment 55802 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55802&action=edit reduced testcase Compiler output: $ riscv64-unknown-linux-gnu-gcc -O testcase.c during RTL pass: combine testcase.c: In function 'foo': testcase.c:9:1: internal compiler error: in decompose, at rtl.h:2297 9 | } | ^ 0x124765c wi::int_traits >::decompose(long*, unsigned int, std::pair const&) /repo/gcc-trunk/gcc/rtl.h:2297 0x124765c wide_int_ref_storage::wide_int_ref_storage >(std::pair const&) /repo/gcc-trunk/gcc/wide-int.h:1030 0x131b806 generic_wide_int >::generic_wide_int >(std::pair const&) /repo/gcc-trunk/gcc/wide-int.h:788 0x131b806 simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*, machine_mode) /repo/gcc-trunk/gcc/simplify-rtx.cc:2131 0x132d54d simplify_context::simplify_unary_operation(rtx_code, machine_mode, rtx_def*, machine_mode) /repo/gcc-trunk/gcc/simplify-rtx.cc:889 0x132d54d simplify_context::simplify_gen_unary(rtx_code, machine_mode, rtx_def*, machine_mode) /repo/gcc-trunk/gcc/simplify-rtx.cc:360 0x2297961 simplify_gen_unary(rtx_code, machine_mode, rtx_def*, machine_mode) /repo/gcc-trunk/gcc/rtl.h:3520 0x2297961 simplify_comparison /repo/gcc-trunk/gcc/combine.cc:13136 0x229ad85 combine_simplify_rtx /repo/gcc-trunk/gcc/combine.cc:6176 0x229cf6b subst /repo/gcc-trunk/gcc/combine.cc:5609 0x229d0cc subst /repo/gcc-trunk/gcc/combine.cc:5536 0x229d0cc subst /repo/gcc-trunk/gcc/combine.cc:5536 0x22a1dac try_combine /repo/gcc-trunk/gcc/combine.cc:3339 0x22a9d2d combine_instructions /repo/gcc-trunk/gcc/combine.cc:1300 0x22a9d2d rest_of_handle_combine /repo/gcc-trunk/gcc/combine.cc:15063 0x22a9d2d execute /repo/gcc-trunk/gcc/combine.cc:15107 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ riscv64-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-3502-20230827001656-g7997f0d35ef-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/14.0.0/lto-wrapper Target: riscv64-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-isa-spec=2.2 --with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu --with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld --with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r14-3502-20230827001656-g7997f0d35ef-checking-yes-rtl-df-extra-riscv64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 14.0.0 20230827 (experimental) (GCC)
[Bug target/111170] Malformed manifest does not allow to run gcc on Windows XP (Accessing a corrupted shared library)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70 --- Comment #2 from LIU Hao --- (In reply to Costas Argyris from comment #1) > Looks like '... @ Windows XP' is the Host, not the Target, in the PR. > Target seems irrelevant here. > > LH, is this the issue you originally mentioned about my change inadvertently > replacing the default MSYS2 manifest? It looks like that the current GCC manifest contains values that their host does not support. In theory it should be ignored; however if it causes errors, it might be worth looking into. The MSYS2 manifest contains a `compatibility` section that is not supported by XP and Vista and is ignored [1], so it has no effect. [1] https://learn.microsoft.com/en-us/windows/win32/win7appqual/compatibility---application-manifest#manifestation-of-change
[Bug libstdc++/111172] New: Dead code in std::get for variant?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72
Bug ID: 72
Summary: Dead code in std::get for variant?
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
In libstdc++'s implementation of variant's std::get, there are static_asserts
that require T not to be void, for example:
template
constexpr _Tp&
get(variant<_Types...>& __v)
{
static_assert(__detail::__variant::__exactly_once<_Tp, _Types...>,
"T must occur exactly once in alternatives");
static_assert(!is_void_v<_Tp>, "_Tp must not be void");
constexpr size_t __n = std::__find_uniq_type_in_pack<_Tp, _Types...>();
return std::get<__n>(__v);
}
But it looks like such static_asserts are *never* fired because the return type
already causes a compile error of forming reference to void when T is void.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #9 from Jerry DeLisle --- I am using this: program teste0es0en0 integer,parameter::p1 = kind(1e0), p2 = kind(1d0), & p3 = selected_real_kind(precision(1.0_p2)+1), & hp = selected_real_kind(precision(1.0_p3)+1), & p4 = merge(hp,p3,hp>0) ! in gfortran p4 /= p3, in ifort p4 == p3 character(*),parameter:: fmt(3) = "(A,1X,"//[" E","ES","EN"]//"0.0E0) " integer ifmt write(*,"(A,4(1X,I0))") 'real kinds',p1,p2,p3,p4 do ifmt = 1,3 write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p1 write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p2 write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p3 if(p3/=p4) write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p4 end do end program teste0es0en0 And I get the following output with some test patching: $ ./a.out real kinds 4 8 10 16 With (A,1X, E0.0E0) 1.E+3 With (A,1X, E0.0E0) 1.E+3 With (A,1X, E0.0E0) 1.E+3 With (A,1X, E0.0E0) 1.E+3 With (A,1X,ES0.0E0) 7.E+2 With (A,1X,ES0.0E0) 7.E+2 With (A,1X,ES0.0E0) 7.E+2 With (A,1X,ES0.0E0) 7.E+2 With (A,1X,EN0.0E0) 666. With (A,1X,EN0.0E0) 666. With (A,1X,EN0.0E0) 666. With (A,1X,EN0.0E0) 666.
[Bug c++/111173] New: G++ allows constinit functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73 Bug ID: 73 Summary: G++ allows constinit functions Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: janschultke at googlemail dot com Target Milestone: --- ## Code to Reproduce using Function = int(); constinit Function f; ## Expected Output (provided by clang trunk) :2:1: error: constinit can only be used in variable declarations 2 | constinit Function f; | ^ 1 error generated. ## Actual Output (https://godbolt.org/z/7rdEhhj1s) This code compiles with any version of GCC that supports C++20 from what I could tell. constinit looks to have no effect.
[Bug analyzer/96395] Generalize gcc.dg/analyzer tests to be run with both C and C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96395 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Benjamin Priour : https://gcc.gnu.org/g:55f6a7d949abc708d1c6ebc01eb3053f96d1472b commit r14-3503-g55f6a7d949abc708d1c6ebc01eb3053f96d1472b Author: benjamin priour Date: Sun Aug 27 14:36:14 2023 +0200 analyzer: Move gcc.dg/analyzer tests to c-c++-common (1) [PR96395] First batch of moving tests from under gcc.dg/analyzer into c-c++-common/analyzer. C builtins are not recognized as such by C++, therefore this patch no longer uses tree.h:fndecl_built_in_p to recognize a builtin function, but rather the function names. Thus functions named as C builtins - such as calloc, sprintf ... - are recognized as such both in C and C++ sources by the analyzer. For user-declared functions named after builtins, the latters' function_decl tree are now preferred over the function_decl the user declared, even when the FE consider their declaration to mismatch (Wbuiltin-declaration-mismatch emitted). This mainly comes into account in the handling of these function attributes : the analyzer uses the builtin's attributes defined in gcc/builtins.def. Signed-off-by: benjamin priour gcc/analyzer/ChangeLog: PR analyzer/96395 * analyzer.h (class known_function): Add virtual casts to builtin_known_function. (class builtin_known_function): New subclass of known_function for builtins. * kf.cc (class kf_alloca): Now derived from builtin_known_function. (class kf_calloc): Likewise. (class kf_free): Likewise. (class kf_malloc): Likewise. (class kf_memcpy_memmove): Likewise. (class kf_memset): Likewise. (class kf_realloc): Likewise. (class kf_strchr): Likewise. (class kf_sprintf): Likewise. (class kf_strcat): Likewise. (class kf_strcpy): Likewise. (class kf_strdup): Likewise. (class kf_strlen): Likewise. (class kf_strndup): Likewise. (register_known_functions): Builtins are now registered as known_functions by name rather than by their BUILTIN_CODE. * known-function-manager.cc (get_normal_builtin): New overload. * known-function-manager.h: New overload declaration. * region-model.cc (region_model::get_builtin_kf): New function. * region-model.h (class region_model): Add declaration of get_builtin_kf. * sm-fd.cc: For called recognized as builtins, use the attributes of that builtin as defined in gcc/builtins.def rather than the user's. * sm-malloc.cc (malloc_state_machine::on_stmt): Likewise. gcc/testsuite/ChangeLog: PR analyzer/96395 * gcc.dg/analyzer/aliasing-3.c: Moved to... * c-c++-common/analyzer/aliasing-3.c: ...here. * gcc.dg/analyzer/aliasing-pr106473.c: Moved to... * c-c++-common/analyzer/aliasing-pr106473.c: ...here. * gcc.dg/analyzer/asm-x86-dyndbg-2.c: Moved to... * c-c++-common/analyzer/asm-x86-dyndbg-2.c: ...here. * gcc.dg/analyzer/asm-x86-lp64-2.c: Moved to... * c-c++-common/analyzer/asm-x86-lp64-2.c: ...here. * gcc.dg/analyzer/atomic-builtins-haproxy-proxy.c: Moved to... * c-c++-common/analyzer/atomic-builtins-haproxy-proxy.c: ...here. * gcc.dg/analyzer/atomic-builtins-qemu-sockets.c: Moved to... * c-c++-common/analyzer/atomic-builtins-qemu-sockets.c: ...here. * gcc.dg/analyzer/attr-malloc-6.c: Moved to... * c-c++-common/analyzer/attr-malloc-6.c: ...here. * gcc.dg/analyzer/attr-malloc-CVE-2019-19078-usb-leak.c: Moved to... * c-c++-common/analyzer/attr-malloc-CVE-2019-19078-usb-leak.c: ...here. * gcc.dg/analyzer/attr-tainted_args-1.c: Moved to... * c-c++-common/analyzer/attr-tainted_args-1.c: ...here. * gcc.dg/analyzer/call-summaries-pr107158.c: Moved to... * c-c++-common/analyzer/call-summaries-pr107158.c: ...here. * gcc.dg/analyzer/calloc-1.c: Moved to... * c-c++-common/analyzer/calloc-1.c: ...here. * gcc.dg/analyzer/compound-assignment-5.c: Moved to... * c-c++-common/analyzer/compound-assignment-5.c: ...here. * gcc.dg/analyzer/coreutils-cksum-pr108664.c: Moved to... * c-c++-common/analyzer/coreutils-cksum-pr108664.c: ...here. * gcc.dg/analyzer/coreutils-sum-pr108666.c: Moved to... * c-c++-common/analyzer/coreutils-sum-pr108666.c: ...here. * gcc.dg/analyzer/deref-before-check-pr108455-1.c: Moved to... * c-c++-common/analyzer/deref-before-check-pr108455-1.c: ...here. * gcc.dg/an
[Bug c++/111173] G++ allows constinit functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-08-27 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||accepts-invalid --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/111173] G++ allows constinit functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=73 --- Comment #2 from Jan Schultke --- I think the problem is that GCC treats "constinit" exactly like "const" for the purpose of diagnostics. In https://eel.is/c++draft/dcl.fct#11, it is said that const applied to functions is ignored. GCC produces error messages like: > :1:1: error: 'constinit' on function return type is not allowed > 1 | constinit void foo(); > | ^ This does not make any sense; "constinit" wouldn't apply to the function return type in the first place, but to the declarator-id. See https://eel.is/c++draft/dcl.meaning.general#4
[Bug c++/111164] The error message for a literal operator accepting an argument of the wrong type is confusing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-08-27 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. using -std=c++20 produce a better error message too: :4:9: error: no matching function for call to 'operator""_x<"abc">()' 4 | int x = "abc"_x; | ^~~ :2:5: note: candidate: 'template > int operator""_x()' 2 | int operator ""_x (); | ^~~~ :2:5: note: template argument deduction/substitution failed: :4:9: error: '"abc"' is not a valid template argument for type 'char' because string literals can never be used in this context 4 | int x = "abc"_x; | ^~~
[Bug c++/111174] New: G++ allows re-declaring function parameters as functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74
Bug ID: 74
Summary: G++ allows re-declaring function parameters as
functions
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: janschultke at googlemail dot com
Target Milestone: ---
## Code to Reproduce
void foo(int x) {
void x(int);
}
## Expected Output
The expected output is emitted in C mode, and also by clang in C/C++ mode
(https://godbolt.org/z/b8Gbj69Kn)
: In function 'foo':
:2:10: error: 'x' redeclared as different kind of symbol
2 | void x(int);
| ^
:1:14: note: previous definition of 'x' with type 'int'
1 | void foo(int x) {
| ^
## Actual Output (only in C++ mode)
Compiles.
## Explanation
There is no wording in the standard that allows function declarations to
redeclare function parameters. This erroneous behavior only occurs for
redeclaring function parameters; local/global variables seem unaffected.
[Bug c++/111174] G++ allows redeclaring function parameters as functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-08-27 Ever confirmed|0 |1 Known to fail||4.1.2 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed. Not a regression.
[Bug c++/52953] function parameter name redeclarations not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52953 Andrew Pinski changed: What|Removed |Added CC||janschultke at googlemail dot com --- Comment #6 from Andrew Pinski --- *** Bug 74 has been marked as a duplicate of this bug. ***
[Bug c++/111174] G++ allows redeclaring function parameters as functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 52953. *** This bug has been marked as a duplicate of bug 52953 ***
[Bug fortran/110720] [13 Regression] Internal compiler error (segmentation fault) in gfc_expression_rank
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110720 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Known to fail||13.1.0, 13.2.0 --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on mainline by r14-2022-g577223aebc7acd, and on 13-branch by r13-7761-gd6997a5aab7aaa. Thanks, Paul!
[Bug fortran/110595] Documentation: typo in the docs for -Wmissing-include-dirs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110595 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #10 from anlauf at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #9) > I am using this: > > program teste0es0en0 > integer,parameter::p1 = kind(1e0), p2 = kind(1d0), & >p3 = selected_real_kind(precision(1.0_p2)+1), & >hp = selected_real_kind(precision(1.0_p3)+1), & >p4 = merge(hp,p3,hp>0) ! in gfortran p4 /= p3, in ifort p4 == p3 > character(*),parameter:: fmt(3) = "(A,1X,"//[" E","ES","EN"]//"0.0E0) " > integer ifmt > write(*,"(A,4(1X,I0))") 'real kinds',p1,p2,p3,p4 > do ifmt = 1,3 > write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p1 > write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p2 > write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p3 > if(p3/=p4) write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p4 > end do > end program teste0es0en0 > > And I get the following output with some test patching: > > $ ./a.out > real kinds 4 8 10 16 > With (A,1X, E0.0E0) 1.E+3 > With (A,1X, E0.0E0) 1.E+3 > With (A,1X, E0.0E0) 1.E+3 > With (A,1X, E0.0E0) 1.E+3 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. Intel does not like E0.0E0, thus running with do ifmt = 2,3 gives: real kinds 4 8 16 16 With (A,1X,ES0.0E0) 7.+2 With (A,1X,ES0.0E0) 7.+2 With (A,1X,ES0.0E0) 7.+2 With (A,1X,EN0.0E0) 666.+0 With (A,1X,EN0.0E0) 666.+0 With (A,1X,EN0.0E0) 666.+0
[Bug fortran/99585] ICE with SIZE intrinsic on nested derived type components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99585 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Known to work||11.3.0, 12.3.0, 13.1.0, ||14.0 Status|NEW |RESOLVED --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed.
[Bug c/111175] New: Initialization of a structure with a flexible array member with c23 storage class specifier causes corruption, and ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=75
Bug ID: 75
Summary: Initialization of a structure with a flexible array
member with c23 storage class specifier causes
corruption, and ICE
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Araknod at hotmail dot it
Target Milestone: ---
Created attachment 55803
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55803&action=edit
output of gcc -fsanitize=address -Wall -Wextra -std=c2x -Og in.c -S -o in.s
Using the new C23 storage class specifier to allocate a structure with a
flexible array member causes memory corruption (detected with address
sanitizer), and causes an ICE if compiled with -fanalyzer or
-fsanitize=undefined
in.c:
#include
struct T { int size, data[]; };
int main() {
auto v = &(static struct T){ .size = 3, .data = { 1, 2, 3, } };
for (int i = 0; i < v->size; i++) {
printf("%d\n", v->data[i]);
}
}
gcc -fsanitize=address -Wall -Wextra -std=c2x -Og in.c -o main
/tmp/ccseyF4n.s: Assembler messages:
/tmp/ccseyF4n.s:64: Warning: .space repeat count is zero, ignored
Attached is the gcc -S -o in.s output
When run the corruption message is:
=
==29798==ERROR: AddressSanitizer: global-buffer-overflow on address
0x55c6806af064 at pc 0x55c6806ae254 bp 0x7ffe996ceda0 sp 0x7ffe996ced90
READ of size 4 at 0x55c6806af064 thread T0
#0 0x55c6806ae253 in main (/home/lorenzo/dev/sig/cred/main+0x1253)
(BuildId: 9cf4495a35299e33afc1afe22e07ca096fce2722)
#1 0x7f3c4e8e9a8f in __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
#2 0x7f3c4e8e9b48 in __libc_start_main_impl ../csu/libc-start.c:360
#3 0x55c6806ae124 in _start (/home/lorenzo/dev/sig/cred/main+0x1124)
(BuildId: 9cf4495a35299e33afc1afe22e07ca096fce2722)
0x55c6806af064 is located 0 bytes after global variable '__compound_literal.0'
defined in 'vla1.c:6:32' (0x55c6806af060) of size 4
When compiled with -fsanitize=undefined
during GIMPLE pass: ccp
in.c: In function ‘main’:
in.c:10:1: internal compiler error: Segmentation fault
10 | }
| ^
0xc5ed7e crash_signal
../../src/gcc/toplev.cc:314
0x7f17628464af ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x17e9f04 tree_fits_poly_int64_p(tree_node const*)
../../src/gcc/tree.cc:6378
0x17e9f04 tree_to_poly_int64(tree_node const*)
../../src/gcc/tree.cc:3285
0x81450e component_ref_size(tree_node*, special_array_member*)
../../src/gcc/tree.cc:13199
0x7e5cc2 decl_init_size(tree_node*, bool)
../../src/gcc/tree-object-size.cc:493
0x16d50a7 addr_object_size
../../src/gcc/tree-object-size.cc:568
0x6bfbae fold_builtin_object_size
../../src/gcc/builtins.cc:10808
0x6bfbae fold_builtin_2
../../src/gcc/builtins.cc:9841
0x6bfbae fold_builtin_n(unsigned int, tree_node*, tree_node*, tree_node**, int,
bool) [clone .isra.0]
../../src/gcc/builtins.cc:9949
0x12e7e30 gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*),
tree_node* (*)(tree_node*))
../../src/gcc/gimple-fold.cc:7713
0x12dc66b ccp_fold
../../src/gcc/tree-ssa-ccp.cc:1289
0x12dc66b evaluate_stmt
../../src/gcc/tree-ssa-ccp.cc:
0x12d8a32 visit_assignment
../../src/gcc/tree-ssa-ccp.cc:2855
0x12d8a32 ccp_propagate::visit_stmt(gimple*, edge_def**, tree_node**)
../../src/gcc/tree-ssa-ccp.cc:2933
0x12d84ed ssa_propagation_engine::simulate_stmt(gimple*)
../../src/gcc/tree-ssa-propagate.cc:220
0x12d82fa ssa_propagation_engine::simulate_block(basic_block_def*)
../../src/gcc/tree-ssa-propagate.cc:327
0x12d637c ssa_propagation_engine::ssa_propagate()
../../src/gcc/tree-ssa-propagate.cc:477
0x12d31e2 do_ssa_ccp
../../src/gcc/tree-ssa-ccp.cc:2974
0x12d31e2 execute
../../src/gcc/tree-ssa-ccp.cc:3020
And when run with -fanalyzer
during IPA pass: analyzer
in.c: In function ‘main’:
in.c:7:26: internal compiler error: Segmentation fault
7 | for (int i = 0; i < v->size; i++) {
| ~^~
0xc5ed7e crash_signal
../../src/gcc/toplev.cc:314
0x7f6b9e4604af ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x17e9f04 tree_fits_poly_int64_p(tree_node const*)
../../src/gcc/tree.cc:6378
0x17e9f04 tree_to_poly_int64(tree_node const*)
../../src/gcc/tree.cc:3285
0x81450e component_ref_size(tree_node*, special_array_member*)
../../src/gcc/tree.cc:13199
0x7e5cc2 decl_init_size(tree_node*, bool)
../../src/gcc/tree-object-size.cc:493
0xce2e44 ana::region_model::get_capacity(ana::region const*) const
../../src/gcc/analyzer/region-model.cc:2757
0x109335f ana::region_model::check_region_b
[Bug c/111175] Initialization of a structure with a flexible array member with c23 storage class specifier causes corruption, and ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=75 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 109828. *** This bug has been marked as a duplicate of bug 109828 ***
[Bug c/109828] [13/14 Regression] static compound literal with flexible array in initializer leads to invalid size and ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109828 Andrew Pinski changed: What|Removed |Added CC||Araknod at hotmail dot it --- Comment #10 from Andrew Pinski --- *** Bug 75 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/109938] ((a^c) & b) | a is not opimized to (b & c) | a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109938 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- Fixed.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #11 from john.harper at vuw dot ac.nz --- Jerry's test program is identical with mine. Because E format is supposed to give no digits before the decimal point except possibly a leading zero, E0.0 and E0.0E0 are both pointless, and Steve Lionel pointed out in Fortran Discourse that the standard forbids them because they would generate an illegal value of k for the kP edit descriptor (which happens not to be explicitly used here.) So I think gfortran ought to give a run-time error for it. If I compiled the program with ifort and more warning options, the first 2 write statements gave real kinds 4 8 16 16 With (A,1X, E0.0E0) * forrtl: error (63): output conversion error, unit 6, file /dev/pts/1 The ES result from gfortran was correct and standard-conforming. The EN one should have said 666.E+0 not 666. On Sun, 27 Aug 2023, jvdelisle at gcc dot gnu.org wrote: > Date: Sun, 27 Aug 2023 15:38:33 + > From: jvdelisle at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Mon, 28 Aug 2023 03:38:51 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > --- Comment #9 from Jerry DeLisle --- > I am using this: > > program teste0es0en0 > integer,parameter::p1 = kind(1e0), p2 = kind(1d0), & > p3 = selected_real_kind(precision(1.0_p2)+1), & > hp = selected_real_kind(precision(1.0_p3)+1), & > p4 = merge(hp,p3,hp>0) ! in gfortran p4 /= p3, in ifort p4 == p3 > character(*),parameter:: fmt(3) = "(A,1X,"//[" E","ES","EN"]//"0.0E0) " > integer ifmt > write(*,"(A,4(1X,I0))") 'real kinds',p1,p2,p3,p4 > do ifmt = 1,3 > write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p1 > write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p2 > write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p3 > if(p3/=p4) write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p4 > end do > end program teste0es0en0 > > And I get the following output with some test patching: > > $ ./a.out > real kinds 4 8 10 16 > With (A,1X, E0.0E0) 1.E+3 > With (A,1X, E0.0E0) 1.E+3 > With (A,1X, E0.0E0) 1.E+3 > With (A,1X, E0.0E0) 1.E+3 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #12 from Jerry DeLisle --- (In reply to john.harper from comment #11) I have the error check commented out during some of my checking on things. I will revise the test case to test for the correct error.
[Bug tree-optimization/111167] swapping around duplicated conditionals can produce better code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67 --- Comment #2 from Andrew Pinski --- >Take reduced from GCC's sources for lookup_attribute: Note it shows up even not in a reduced version of lookup_attribute too.
[Bug tree-optimization/110891] [14 Regression] Dead Code Elimination Regression since r14-2674-gd0de3bf9175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110891 Andrew Pinski changed: What|Removed |Added URL||patch --- Comment #6 from Andrew Pinski --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2023-August/628525.html It can be improved to do also compare swapping, but that is recorded as PR 67 .
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #13 from john.harper at vuw dot ac.nz --- Hmmm. If I read anlauf correctly, our versions of ifort differ when writing ES0.0E0 and EN0.0E0 with the value 666.0. Both give the same correct numerical values but one version omits the E in the output. Omitting it does write the value in the shortest possible space but disobeys the F2018 and F2023 standards, where 13.7.2.3.4 Table 13.2 and 13.7.2.3.5 Table 13.3 require ENw.dE0 and ESw.dE0 to include E in the output. On Sun, 27 Aug 2023, anlauf at gcc dot gnu.org wrote: > Date: Sun, 27 Aug 2023 19:41:10 + > From: anlauf at gcc dot gnu.org > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Mon, 28 Aug 2023 07:41:23 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > --- Comment #10 from anlauf at gcc dot gnu.org --- > (In reply to Jerry DeLisle from comment #9) >> I am using this: >> >> program teste0es0en0 >> integer,parameter::p1 = kind(1e0), p2 = kind(1d0), & >>p3 = selected_real_kind(precision(1.0_p2)+1), & >>hp = selected_real_kind(precision(1.0_p3)+1), & >>p4 = merge(hp,p3,hp>0) ! in gfortran p4 /= p3, in ifort p4 == p3 >> character(*),parameter:: fmt(3) = "(A,1X,"//[" E","ES","EN"]//"0.0E0) " >> integer ifmt >> write(*,"(A,4(1X,I0))") 'real kinds',p1,p2,p3,p4 >> do ifmt = 1,3 >> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p1 >> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p2 >> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p3 >> if(p3/=p4) write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p4 >> end do >> end program teste0es0en0 >> >> And I get the following output with some test patching: >> >> $ ./a.out >> real kinds 4 8 10 16 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,EN0.0E0) 666. >> With (A,1X,EN0.0E0) 666. >> With (A,1X,EN0.0E0) 666. >> With (A,1X,EN0.0E0) 666. > > Intel does not like E0.0E0, thus running with do ifmt = 2,3 gives: > > real kinds 4 8 16 16 > With (A,1X,ES0.0E0) 7.+2 > With (A,1X,ES0.0E0) 7.+2 > With (A,1X,ES0.0E0) 7.+2 > With (A,1X,EN0.0E0) 666.+0 > With (A,1X,EN0.0E0) 666.+0 > With (A,1X,EN0.0E0) 666.+0 > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug target/111119] maskload and maskstore for integer modes are oddly conditional on AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19
--- Comment #4 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:945217845db7edb499d66ac56480ce569002b83e
commit r14-3509-g945217845db7edb499d66ac56480ce569002b83e
Author: liuhongt
Date: Fri Aug 25 08:46:26 2023 +0800
Use vmaskmov{ps,pd} for VI48_128_256 when TARGET_AVX2 is not available.
vpmaskmov{d,q} is available for TARGET_AVX2, vmaskmov{ps,ps} is
available for TARGET_AVX, w/o TARGET_AVX2, we can use vmaskmov{ps,pd}
for VI48_128_256
gcc/ChangeLog:
PR target/19
* config/i386/sse.md (V48_AVX2): Rename to ..
(V48_128_256): .. this.
(ssefltmodesuffix): Extend to V4SF/V8SF/V2DF/V4DF.
(_maskload): Change
V48_AVX2 to V48_128_256, also generate vmaskmov{ps,pd} for
integral modes when TARGET_AVX2 is not available.
(_maskstore): Ditto.
(maskload): Change V48_AVX2 to
V48_128_256.
(maskstore): Ditto.
[Bug target/111119] maskload and maskstore for integer modes are oddly conditional on AVX2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19 --- Comment #5 from Hongtao.liu --- Fixed in GCC14.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #14 from john.harper at vuw dot ac.nz --- To add to my email copied below, you may find a reference to the standards helpful. k is the scale factor referred to in F2018 or F2023 13.7.2.3.3. The last paragraph of that says that in Ew.d and Ew.dE0 output format, one of these two inequalities must be satisfied: -d < k <= 0 or 0 < k < d+2. With either E0.0 or E0.0E0 the value of k is not permitted. On Sun, 27 Aug 2023, john.harper at vuw dot ac.nz wrote: > Date: Sun, 27 Aug 2023 21:40:58 + > From: john.harper at vuw dot ac.nz > To: John Harper > Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too > high. > Resent-Date: Mon, 28 Aug 2023 09:41:10 +1200 (NZST) > Resent-From: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 > > --- Comment #11 from john.harper at vuw dot ac.nz --- > Jerry's test program is identical with mine. > Because E format is supposed to give no digits before the decimal point > except possibly a leading zero, E0.0 and E0.0E0 are both pointless, and > Steve Lionel pointed out in Fortran Discourse that the standard forbids > them because they would generate an illegal value of k for the kP edit > descriptor (which happens not to be explicitly used here.) So I think > gfortran ought to give a run-time error for it. If I compiled the program > with ifort and more warning options, the first 2 write statements gave > > real kinds 4 8 16 16 > With (A,1X, E0.0E0) * > forrtl: error (63): output conversion error, unit 6, file /dev/pts/1 > > The ES result from gfortran was correct and standard-conforming. The EN > one should have said 666.E+0 not 666. > > On Sun, 27 Aug 2023, jvdelisle at gcc dot gnu.org wrote: > >> Date: Sun, 27 Aug 2023 15:38:33 + >> From: jvdelisle at gcc dot gnu.org >> To: John Harper >> Subject: [Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d >> too >> high. >> Resent-Date: Mon, 28 Aug 2023 03:38:51 +1200 (NZST) >> Resent-From: >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 >> >> --- Comment #9 from Jerry DeLisle --- >> I am using this: >> >> program teste0es0en0 >> integer,parameter::p1 = kind(1e0), p2 = kind(1d0), & >> p3 = selected_real_kind(precision(1.0_p2)+1), & >> hp = selected_real_kind(precision(1.0_p3)+1), & >> p4 = merge(hp,p3,hp>0) ! in gfortran p4 /= p3, in ifort p4 == p3 >> character(*),parameter:: fmt(3) = "(A,1X,"//[" E","ES","EN"]//"0.0E0) " >> integer ifmt >> write(*,"(A,4(1X,I0))") 'real kinds',p1,p2,p3,p4 >> do ifmt = 1,3 >> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p1 >> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p2 >> write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p3 >> if(p3/=p4) write(*, fmt(ifmt)) 'With '//fmt(ifmt), 666.0_p4 >> end do >> end program teste0es0en0 >> >> And I get the following output with some test patching: >> >> $ ./a.out >> real kinds 4 8 10 16 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X, E0.0E0) 1.E+3 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,ES0.0E0) 7.E+2 >> With (A,1X,EN0.0E0) 666. >> With (A,1X,EN0.0E0) 666. >> With (A,1X,EN0.0E0) 666. >> With (A,1X,EN0.0E0) 666. >> >> -- >> You are receiving this mail because: >> You reported the bug. >> > > > -- John Harper, School of Mathematics and Statistics > Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. > e-mail john.har...@vuw.ac.nz > > -- > You are receiving this mail because: > You reported the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz
[Bug target/111076] RISC-V: segmentation fault during RTL pass: shorten (debug build)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111076 xuli1 at eswincomputing dot com changed: What|Removed |Added CC||xuli1 at eswincomputing dot com --- Comment #1 from xuli1 at eswincomputing dot com --- This issue has been resolved. https://github.com/gcc-mirror/gcc/commit/9f8d1d448e6c10fbad3bb41f4d7322fac8df4cd0
[Bug web/111176] New: test summary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76 Bug ID: 76 Summary: test summary Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: tepano5224 at xgh6 dot com Target Milestone: --- test desc
[Bug libbacktrace/111183] New: dsaf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83 Bug ID: 83 Summary: dsaf Product: gcc Version: og13 (devel/omp/gcc-13) Status: UNCONFIRMED Severity: normal Priority: P3 Component: libbacktrace Assignee: unassigned at gcc dot gnu.org Reporter: niteshtiwari.scs21 at avc dot ac.in CC: ian at gcc dot gnu.org Target Milestone: --- dsaf
[Bug libbacktrace/111183] dsaf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83 --- Comment #1 from Nitesh Tiwari --- dsafdsaf
[Bug c++/111186] New: food
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86 Bug ID: 86 Summary: food Product: gcc Version: 11.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: colixim942 at pbridal dot com Target Milestone: --- sedlife
[Bug c++/111186] food
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86 vivek changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from vivek --- hgd6fuytvcjhgbvujhg
[Bug tree-optimization/111154] vect-cost-model=dynamic triggers false warning on array operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54
--- Comment #3 from Tomas Chang ---
(In reply to Richard Biener from comment #2)
> Confirmed. Reproduces with -O3 -march=armv8.3-a and
>
> unsigned char desta[8];
> void copya(unsigned char *src, int size)
> {
> for (int i = 0; i < size; i++)
> desta[i] = src[i];
> }
>
> we end up with a peeled epilogue:
>
> if (_12 == niters_vector_mult_vf.6_39)
> goto ; [12.50%]
> else
> goto ; [87.50%]
>
>[local count: 73583527]:
> _96 = MEM[(unsigned char *)src_8(D) + 8B];
> desta[_36] = _96;
> if (size_7(D) > 9)
> goto ; [85.71%]
> else
> goto ; [14.29%]
>
>[local count: 10511932]:
> goto ; [100.00%]
>
>[local count: 63071596]:
> _103 = MEM[(unsigned char *)src_8(D) + 9B];
> desta[9] = _103;
> if (size_7(D) != 10)
> goto ; [85.71%]
> else
> goto ; [14.29%]
>
>[local count: 9010228]:
> goto ; [100.00%]
>
>[local count: 54061368]:
> _110 = MEM[(unsigned char *)src_8(D) + 10B];
> desta[10] = _110;
> if (size_7(D) != 11)
> goto ; [85.71%]
> else
> goto ; [14.29%]
> ...
Thanks for confirming this bug so quickly!
Does this issue affect the actually generated code ?
Are there any clues about how to fix this issue ?
If there are patches that can fix, I can help test the patch.
[Bug tree-optimization/111209] New: GCC fails to understand adc pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111209
Bug ID: 111209
Summary: GCC fails to understand adc pattern
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: unlvsur at live dot com
Target Milestone: ---
Created attachment 55805
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55805&action=edit
bug example
template
inline constexpr T addc(T a,T b,bool carryin,bool& carryout) noexcept
{
T s;
auto c1 = __builtin_add_overflow(a, b, __builtin_addressof(s));
auto c2 = __builtin_add_overflow(s, carryin, __builtin_addressof(s));
carryout = c1 | c2;
return s;
}
void test_addc(unsigned long long* a,unsigned long long* b,unsigned long long*
r)
{
bool carry{};
r[0]=addc(a[0],b[0],carry,carry);
r[1]=addc(a[1],b[1],carry,carry);
}
I copied the example from gcc documentation
https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
But gcc seems to fail to understand the pattern correctly even with what the
document describes.
gcc:
https://godbolt.org/z/Whaaahn41
clang:
https://godbolt.org/z/Ma6rvaYd6
Looks like a bug here.
[Bug tree-optimization/110891] [14 Regression] Dead Code Elimination Regression since r14-2674-gd0de3bf9175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110891 --- Comment #7 from rguenther at suse dot de --- On Sat, 26 Aug 2023, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110891 > > --- Comment #4 from Andrew Pinski --- > (In reply to Andrew Pinski from comment #3) > > One thing I noticed (I don't know if causes the missed optimization) is that > > we have before PRE: > > ``` > >[local count: 1073531371]: > > if (a.0_1 != 0) > > goto ; [50.00%] > > else > > goto ; [50.00%] > > > >[local count: 536765686]: > > if (_28 == &d) > > goto ; [30.00%] > > else > > goto ; [70.00%] > > > >[local count: 536765685]: > > if (_28 == &d) > > goto ; [30.00%] > > else > > goto ; [70.00%] > > ``` > > Which obvious should just be `if (_28 == &d) goto bb9; else goto bb7;` and > > not check `a.0_1` at all. > > I wonder if ifcombine could optimize that instead of requiring PRE. I think > that might even fix the issue too. Note it's the tail-merging code that optimizes this, not PRE (yeah, those passes should be ripped apart)
