[Bug middle-end/105814] [12/13 Regression] 16 "=rm" use in inline-asm is rejected at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105814 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Target Milestone|--- |12.2 Component|target |middle-end Summary|16 "=rm" use in inline-asm |[12/13 Regression] 16 "=rm" |is rejected at -O0 |use in inline-asm is ||rejected at -O0 --- Comment #2 from Andrew Pinski --- I think it accidently worked in GCC 11.x. That is it would do a put it into a pseduo register and then reload it into memory as needed. As I mentioned clang/LLVM also rejects it at -O0.
[Bug target/105814] 16 "=rm" use in inline-asm is rejected at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105814
Andrew Pinski changed:
What|Removed |Added
Summary|operand has impossible |16 "=rm" use in inline-asm
|constraints - worked with |is rejected at -O0
|previous releases |
--- Comment #1 from Andrew Pinski ---
Reduced testcase:
```
void collect_regs(unsigned long *regs)
{
__asm__ __volatile__(""
:"=rm"(regs[0]), "=rm"(regs[1]), "=rm"(regs[2]), "=rm"(regs[3]),
"=rm"(regs[4]), "=rm"(regs[5]), "=rm"(regs[6]), "=rm"(regs[7]),
"=rm"(regs[8]), "=rm"(regs[9]), "=rm"(regs[10]), "=rm"(regs[11]),
"=rm"(regs[12]), "=rm"(regs[13]), "=rm"(regs[14]), "=rm"(regs[15]));
}
```
This fails only at -O0. at -O1 it works. clang even rejects it at -O0 too.
[Bug c/105814] New: operand has impossible constraints - worked with previous releases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105814 Bug ID: 105814 Summary: operand has impossible constraints - worked with previous releases Product: gcc Version: 12.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bruce.fleming at gmail dot com Target Milestone: --- Created attachment 53069 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53069=edit preprocessed file (*.i) an __asm__ __volatile__ x86_64 instruction stream placing all 16 gp regs in consecutive memory locations. Version is 12.1.1 command line: gcc -v -save-temps -c -nostdinc -fmessage-length=0 -fno-builtin -fno-leading-underscore -fno-stack-protector -fno-exceptions -fno-unwind-tables -Wall -Wno-multichar -MT obj/x86_64/debug/arch/x86/dbg/kdbg.o -MMD -MP -MF obj/x86_64/debug/arch/x86/dbg/kdbg.d -Wa,-adhlns=obj/x86_64/debug/arch/x86/dbg/kdbg.lst -O0 -g3 -DDEBUG -mcmodel=large -mno-red-zone -mgeneral-regs-only -I"include" -I"arch/x86/include" -I"/home/bruce/workspace/include" -I"bsos/include" -save-temps -D__MK__ -D__BSOS__ -O0 -g3 -DDEBUG -o"obj/x86_64/debug/arch/x86/dbg/kdbg.o" "arch/x86/dbg/kdbg.c" I have also attached this *.i files. full output of compile (with -v) Using built-in specs. COLLECT_AS_OPTIONS='-adhlns=obj/x86_64/debug/arch/x86/dbg/kdbg.lst' COLLECT_GCC=/usr/bin/gcc OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-gcc-major-version-only --enable-libstdcxx-backtrace --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl=/builddir/build/BUILD/gcc-12.1.1-20220507/obj-x86_64-redhat-linux/isl-install --enable-offload-targets=nvptx-none --without-cuda-driver --enable-offload-defaulted --enable-gnu-indirect-function --enable-cet --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux --with-build-config=bootstrap-lto --enable-link-serialization=1 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.1.1 20220507 (Red Hat 12.1.1-1) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-nostdinc' '-fmessage-length=0' '-fno-builtin' '-fno-leading-underscore' '-fno-stack-protector' '-fno-exceptions' '-fno-unwind-tables' '-Wall' '-Wno-multichar' '-MT' 'obj/x86_64/debug/arch/x86/dbg/kdbg.o' '-MMD' '-MP' '-MF' 'obj/x86_64/debug/arch/x86/dbg/kdbg.d' '-O0' '-g3' '-D' 'DEBUG' '-mcmodel=large' '-mno-red-zone' '-mgeneral-regs-only' '-I' 'include' '-I' 'arch/x86/include' '-I' '/home/bruce/workspace/include' '-I' 'bsos/include' '-save-temps' '-D' '__MK__' '-D' '__BSOS__' '-O0' '-g3' '-D' 'DEBUG' '-o' 'obj/x86_64/debug/arch/x86/dbg/kdbg.o' '-mtune=generic' '-march=x86-64' '-dumpdir' 'obj/x86_64/debug/arch/x86/dbg/' /usr/libexec/gcc/x86_64-redhat-linux/12/cc1 -E -quiet -nostdinc -v -I include -I arch/x86/include -I /home/bruce/workspace/include -I bsos/include -MMD obj/x86_64/debug/arch/x86/dbg/kdbg.d -MF obj/x86_64/debug/arch/x86/dbg/kdbg.d -MP -MT obj/x86_64/debug/arch/x86/dbg/kdbg.o -dD -D DEBUG -D __MK__ -D __BSOS__ -D DEBUG arch/x86/dbg/kdbg.c -mcmodel=large -mno-red-zone -mgeneral-regs-only -mtune=generic -march=x86-64 -Wall -Wno-multichar -fmessage-length=0 -fno-builtin -fno-leading-underscore -fno-stack-protector -fno-exceptions -fno-unwind-tables -g3 -g3 -fworking-directory -O0 -O0 -fpch-preprocess -o obj/x86_64/debug/arch/x86/dbg/kdbg.i #include "..." search starts here: #include <...> search starts here: include arch/x86/include /home/bruce/workspace/include bsos/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-nostdinc' '-fmessage-length=0' '-fno-builtin' '-fno-leading-underscore' '-fno-stack-protector' '-fno-exceptions' '-fno-unwind-tables' '-Wall' '-Wno-multichar' '-MT' 'obj/x86_64/debug/arch/x86/dbg/kdbg.o' '-MMD' '-MP' '-MF' 'obj/x86_64/debug/arch/x86/dbg/kdbg.d' '-O0' '-g3' '-D' 'DEBUG' '-mcmodel=large' '-mno-red-zone' '-mgeneral-regs-only' '-I' 'include' '-I' 'arch/x86/include' '-I' '/home/bruce/workspace/include' '-I' 'bsos/include' '-save-temps' '-D' '__MK__' '-D' '__BSOS__' '-O0' '-g3' '-D' 'DEBUG' '-o' 'obj/x86_64/debug/arch/x86/dbg/kdbg.o' '-mtune=generic' '-march=x86-64' '-dumpdir' 'obj/x86_64/debug/arch/x86/dbg/' /usr/libexec/gcc/x86_64-redhat-linux/12/cc1 -fpreprocessed obj/x86_64/debug/arch/x86/dbg/kdbg.i -quiet -dumpdir obj/x86_64/debug/arch/x86/dbg/ -dumpbase kdbg.c -dumpbase-ext .c -mcmodel=large -mno-red-zone -mgeneral-regs-only -mtune=generic
[Bug fortran/105813] New: ICE in gfc_simplify_unpack, at fortran/simplify.cc:8490
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105813 Bug ID: 105813 Summary: ICE in gfc_simplify_unpack, at fortran/simplify.cc:8490 Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gfortran 13.0.0 20220529 snapshot (g:58a40e76ebadce78639644cd3d56e42b68336927) ICEs when compiling the following testcase, extracted from flang/test/Evaluate/errors01.f90 from the flang 14.0.3 test suite: module m contains subroutine s5 logical, parameter :: mask(2,3) = reshape([.false., .true., .true., .false., .false., .true.], shape(mask)) integer, parameter :: field(3,2) = reshape([(-j,j=1,6)], shape(field)) integer :: x(2,3) x = unpack([1,2], mask, 0) end subroutine end module % powerpc-e300c3-linux-gnu-gfortran-13.0.0 -c q7sa2auy.f90 f951: internal compiler error: in gfc_simplify_unpack, at fortran/simplify.cc:8490 0x5cf7d8 gfc_simplify_unpack(gfc_expr*, gfc_expr*, gfc_expr*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220529/work/gcc-13-20220529/gcc/fortran/simplify.cc:8490 0x831714 do_simplify /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220529/work/gcc-13-20220529/gcc/fortran/intrinsic.cc:4677 0x83d443 gfc_intrinsic_func_interface(gfc_expr*, int) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220529/work/gcc-13-20220529/gcc/fortran/intrinsic.cc:5056 0x8a37b6 resolve_unknown_f /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220529/work/gcc-13-20220529/gcc/fortran/resolve.cc:2990 0x8a37b6 resolve_function /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220529/work/gcc-13-20220529/gcc/fortran/resolve.cc:3347 0x8a37b6 gfc_resolve_expr(gfc_expr*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220529/work/gcc-13-20220529/gcc/fortran/resolve.cc:7187 0x8ab84e gfc_resolve_expr(gfc_expr*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220529/work/gcc-13-20220529/gcc/fortran/resolve.cc:7154 0x8ab84e gfc_resolve_code(gfc_code*, gfc_namespace*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220529/work/gcc-13-20220529/gcc/fortran/resolve.cc:11970 0x8aec17 resolve_codes /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220529/work/gcc-13-20220529/gcc/fortran/resolve.cc:17609 0x8aeb4e resolve_codes /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220529/work/gcc-13-20220529/gcc/fortran/resolve.cc:17592 0x8aecee gfc_resolve(gfc_namespace*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220529/work/gcc-13-20220529/gcc/fortran/resolve.cc:17644 0x88de79 gfc_parse_file() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220529/work/gcc-13-20220529/gcc/fortran/parse.cc:6810 0x8e273f gfc_be_parse_file /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20220529/work/gcc-13-20220529/gcc/fortran/f95-lang.cc:218 (While the target here is powerpc, the ICE is not target-specific.)
[Bug c++/105803] [13 regression] ICE at gcc/cp/pt.cc:27737 after r13-860-gff91735a5b861d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105803 --- Comment #10 from Hongtao.liu --- (In reply to Hongtao.liu from comment #9) > Similar error observed for x86 on ICX. > With option `-march=icx -Ofast -flto` for 510.parest_r. -march=icelake-server
[Bug c++/105803] [13 regression] ICE at gcc/cp/pt.cc:27737 after r13-860-gff91735a5b861d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105803 --- Comment #9 from Hongtao.liu --- Similar error observed for x86 on ICX. With option `-march=icx -Ofast -flto` for 510.parest_r.
[Bug rtl-optimization/105459] [12/13 Regression] ICE: Segmentation fault (in record_operand_costs) since r12-3721-g63c6446f77b9001d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105459 --- Comment #12 from Kewen Lin --- Created attachment 53068 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53068=edit tested patch Once the optimization node of the caller has changed, we need to rebuild the target node in the context of new optimization node, and update the target node if it changes as well.
[Bug rtl-optimization/105459] [12/13 Regression] ICE: Segmentation fault (in record_operand_costs) since r12-3721-g63c6446f77b9001d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105459 --- Comment #11 from Kewen Lin --- (In reply to Kewen Lin from comment #9) > inline_call will force reload global optimization. > > /* Reload global optimization flags. */ > if (reload_optimization_node && DECL_STRUCT_FUNCTION (to->decl) == cfun) > set_cfun (cfun, true); > > It looks that ix86_set_current_function can create one new target option > node even if fndecl == ix86_previous_fndecl but > flag_unsafe_math_optimizations (or flag_excess_precision) != the > corresponding values in the associated target node. We can't do this during the target hook ix86_set_current_function since at that time (WPA phase) the cfun is NULL, even if we want to update the target option node for to->decl, but the passed down fndecl is NULL. I made a patch to rebuild the target option node for to->decl DECL once reload_optimization_node is true. For this failure case, the opts.x_flag_unsafe_math_optimizations has changed, we have to sync it to x_ix86_unsafe_math_optimizations and rebuild.
[Bug jit/105812] type mismatch in binary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105812 --- Comment #1 from Antoni --- Created attachment 53067 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53067=edit Patch
[Bug jit/105812] New: type mismatch in binary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105812 Bug ID: 105812 Summary: type mismatch in binary expression Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- When using a combination of unary and binary expressions on a boolean value, we can trigger the error "type mismatch in binary expression". I'm about to post a patch for this issue.
[Bug c++/105811] New: Diagnostics for template class member call with missing template parameters can be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105811
Bug ID: 105811
Summary: Diagnostics for template class member call with
missing template parameters can be improved
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: llvm at rifkin dot dev
Target Milestone: ---
The following code:
namespace ns {
template
struct S {
void foo() {}
};
}
void foo(ns::S<1>& s) {
s.ns::S::foo();
s.ns::S::~S();
}
Produces the following diagnostics:
: In function 'void foo(ns::S<1>&)':
:9:11: error: 'template > struct ns::S' used without
template arguments
9 | s.ns::S::foo();
| ^
:10:7: error: 'ns::S' is not a class member
10 | s.ns::S::~S();
| ^~
Compiler returned: 1
https://godbolt.org/z/89fbbWhhh
I'm not sure why the destructor call is being treated differently, it would be
great if it would also specify the issue is missing template arguments.
[Bug target/105782] [sparc64] Emission of questionable movxtod/movdtox with -mvis3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105782 --- Comment #2 from Koakuma --- Created attachment 53066 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53066=edit Vectorization log from -fopt-info-vec-all (In reply to Richard Biener from comment #1) > You can check -fopt-info-vec for vectorization. I tried recompiling it with -fopt-info-vec-all and I got a long message that ends with: > blake2b-monocypher-standalone.c:75:18: note: Cost model analysis: > blake2b-monocypher-standalone.c:75:18: note: Cost model analysis for part in > loop 0: > Vector cost: 2282 > Scalar cost: 181 > blake2b-monocypher-standalone.c:75:18: missed: not vectorized: vectorization > is not profitable. So I dont think that GCC vectorized that function. Also, I tried recompiling with -fno-tree-optimize and it doesn't improve anything. Seems like the problem isn't in the vectorizer? (it still produces the same slow code with many `movxtod`/`movdtox`s)
[Bug c++/105734] [12/13 Regression]: Incorrect "error: invalid use of 'auto'" for explicit destructor inside a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105734 --- Comment #14 from Jeremy R. --- Thank you for the quick patch :)
[Bug c++/105798] Add new -Wshadow for data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105798 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Keywords||diagnostic Blocks||87403 --- Comment #1 from Eric Gallager --- I'm thinking it's probably time to make a -Wshadow meta-bug to group all of these together; I think I saw a similar bug but can't remember which... Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug libgcc/27576] The .eh_frame section in crtend.o has wrong aligment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27576
--- Comment #4 from CVS Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:2d546ff69455f7deadab65309de89d19380a8864
commit r13-923-g2d546ff69455f7deadab65309de89d19380a8864
Author: H.J. Lu
Date: Mon Jan 17 16:18:56 2022 -0800
libgcc: Align __EH_FRAME_BEGIN__ to pointer size
Aligne __EH_FRAME_BEGIN__ to pointer size since gcc/unwind-dw2-fde.h has
/* The first few fields of a CIE. The CIE_id field is 0 for a CIE,
to distinguish it from a valid FDE. FDEs are aligned to an addressing
unit boundary, but the fields within are unaligned. */
struct dwarf_cie
{
uword length;
sword CIE_id;
ubyte version;
unsigned char augmentation[];
} __attribute__ ((packed, aligned (__alignof__ (void *;
/* The first few fields of an FDE. */
struct dwarf_fde
{
uword length;
sword CIE_delta;
unsigned char pc_begin[];
} __attribute__ ((packed, aligned (__alignof__ (void *;
which indicates that CIE/FDE should be aligned at the pointer size.
PR libgcc/27576
* crtstuff.c (__EH_FRAME_BEGIN__): Aligned to pointer size.
[Bug c++/105809] [10/11/12/13 Regression] GCC ICE when deal with __PRETTY_FUNCTION__ inside macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105809
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code,
||rejects-valid
--- Comment #4 from Andrew Pinski ---
(In reply to Marek Polacek from comment #2)
> The ICE started with
But the 7.x ICEd on and rejected the original testcase:
template void hh() { ss t; }
template
struct tt { ss t; };
template
int f(void)
{
constexpr char const* cc = __PRETTY_FUNCTION__;
struct j{ char const* kk=cc; };
tt y;
hh();
}
int t = f<1>();
GCC 8+ accepts the above code though.
So in summary, the ICE is a regression but the rejects valid is not and could
be workaround by using a struct first?
[Bug c++/105809] [10/11/12/13 Regression] GCC ICE when deal with __PRETTY_FUNCTION__ inside macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105809
--- Comment #3 from Andrew Pinski ---
Reduced testcase:
template void hh() { ss t; }
template
int f(void)
{
constexpr char const* cc = __PRETTY_FUNCTION__;
struct j{ char const* kk=cc; };
hh();
}
int t = f<1>();
[Bug libstdc++/105810] __glibcxx_assert can be improved greatly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105810 --- Comment #1 from cqwrteur --- You can see this generates extremely good assembly even under -Os https://godbolt.org/z/oaerzYeo6
[Bug c++/105809] [10/11/12/13 Regression] GCC ICE when deal with __PRETTY_FUNCTION__ inside macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105809 Marek Polacek changed: What|Removed |Added Target Milestone|--- |10.4 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Summary|GCC ICE when deal with |[10/11/12/13 Regression] |__PRETTY_FUNCTION__ inside |GCC ICE when deal with |macro |__PRETTY_FUNCTION__ inside ||macro Last reconfirmed||2022-06-01 Status|UNCONFIRMED |NEW --- Comment #2 from Marek Polacek --- The ICE started with commit 12659e10c78200717fc82ed77892de5059fa44b5 Author: Jason Merrill Date: Tue Aug 29 15:40:08 2017 -0400 Instantiate default arguments/member initializers once. * init.c (get_nsdmi): Remember NSDMI instantiations. * parser.c (inject_this_parameter): Be more picky about current_class_ptr. * pt.c (tsubst_copy): Simplify 'this' handling. (tsubst_default_argument): Remember default argument instantiations. Take parameter number. (tsubst_default_arguments): Pass it. * call.c (convert_default_arg): Likewise. From-SVN: r251422 which is GCC 8.
[Bug libstdc++/105810] New: __glibcxx_assert can be improved greatly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105810 Bug ID: 105810 Summary: __glibcxx_assert can be improved greatly. Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- Every function call has to carry the call which adds a burden. With -Os the function does not even get expanded. The operator[] becomes extremely expensive. https://godbolt.org/z/Gcchdrdxj The situation might get worse when compiling with -fPIC since load/store data from %rip register needs more instructions. It can be improved to something like this. Put all the file, line, and condition information into a separate function. Since the function is an inline function, the entire program only holds one copy of the debugging information. https://godbolt.org/z/xc8jnqh5r https://godbolt.org/z/85M1PE9Te vs https://godbolt.org/z/6fsGo41bj Unfortunately, GCC got ICE. I have submitted the bug report to fix that. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105809
[Bug plugins/95648] gcc/configure: line 26509: objdump: command not found: config/gcc-plugin.m4 uses 'objdump' instead of ${host}-objdump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95648 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||law at gcc dot gnu.org --- Comment #3 from Jeffrey A. Law --- Fixed on the trunk.
[Bug plugins/95648] gcc/configure: line 26509: objdump: command not found: config/gcc-plugin.m4 uses 'objdump' instead of ${host}-objdump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95648 --- Comment #2 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:c4c3cd5ca5fe13724253d4270dc643fbc6b7f557 commit r13-922-gc4c3cd5ca5fe13724253d4270dc643fbc6b7f557 Author: David Seifert Date: Wed Jun 1 17:21:44 2022 -0400 [PATCH] configure: use OBJDUMP determined by libtool [PR95648] $ac_cv_prog_OBJDUMP contains the --host OBJDUMP that libtool has inferred. Current config/gcc-plugin.m4 does not respect the user's choice for OBJDUMP. PR plugins/95648 config/ * gcc-plugin.m4: Use libtool's $ac_cv_prog_OBJDUMP. gcc/ * configure: Regenerate. libcc1/ * configure: Regenerate.
[Bug c++/105809] GCC ICE when deal with __PRETTY_FUNCTION__ inside macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105809 --- Comment #1 from Andrew Pinski --- Created attachment 53065 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53065=edit testcase from the URL
[Bug middle-end/105638] Redundant stores aren't removed by DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105638 --- Comment #2 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:a743a72714fc4a9d7036d28d0cacdf2a3621f629 commit r13-921-ga743a72714fc4a9d7036d28d0cacdf2a3621f629 Author: H.J. Lu Date: Wed May 18 13:00:47 2022 -0700 DSE: Use the constant store source if possible RTL DSE tracks redundant constant stores within a basic block. When RTL loop invariant motion hoists a constant initialization out of the loop into a separate basic block, the constant store value becomes unknown within the original basic block. When recording store for RTL DSE, check if the source register is set only once to a constant by a non-partial unconditional load. If yes, record the constant as the constant store source. It eliminates unrolled zero stores after memset 0 in a loop where a vector register is used as the zero store source. gcc/ PR rtl-optimization/105638 * df-core.cc (df_find_single_def_src): Moved and renamed from find_single_def_src in loop-iv.cc. Change the argument to rtx and use rtx_equal_p. Return null for partial or conditional defs. * df.h (df_find_single_def_src): New prototype. * dse.cc (record_store): Use the constant source if the source register is set only once. * loop-iv.cc (find_single_def_src): Moved to df-core.cc. (replace_single_def_regs): Replace find_single_def_src with df_find_single_def_src. gcc/testsuite/ PR rtl-optimization/105638 * g++.target/i386/pr105638.C: New test.
[Bug c++/105809] New: GCC ICE when deal with __PRETTY_FUNCTION__ inside macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105809 Bug ID: 105809 Summary: GCC ICE when deal with __PRETTY_FUNCTION__ inside macro Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- GCC ICE: https://godbolt.org/z/Gfzov4j3b clang: https://godbolt.org/z/ebdPPK77r
[Bug c++/105808] Internal unsafe integer narrowing conversion during non-type template argument value deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105808
--- Comment #1 from Andrew Pinski ---
Removing the include:
using size_t = decltype(sizeof(0));
template
struct extent
{
static constexpr size_t value = 0;
};
template
struct extent
{
static constexpr size_t value = size;
};
static_assert(extent::value != 0, ""); // fails
- CUT
GCC 7 and before used to error out about the overflow:
: In substitution of 'template struct
extent [with T = char; long unsigned int size = 0]':
:15:39: required from here
:15:39: error: overflow in constant expression
static_assert(extent::value != 0, ""); // fails
^~
clang accepts the code as being valid ...
[Bug c++/105803] [13 regression] ICE at gcc/cp/pt.cc:27737 after r13-860-gff91735a5b861d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105803
--- Comment #8 from Marek Polacek ---
Reduced:
namespace std {
template class shared_ptr;
}
struct S {};
template void build_matrices() {
std::shared_ptr(new S);
}
[Bug c++/105808] New: Internal unsafe integer narrowing conversion during non-type template argument value deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105808 Bug ID: 105808 Summary: Internal unsafe integer narrowing conversion during non-type template argument value deduction Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tomilovanatoliy at yandex dot ru Target Milestone: --- Created attachment 53064 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53064=edit test.cpp GCC version: G++ 11.2.0 system type: Linux 5.10.105-1-MANJARO Mar 2022 x86_64 GNU/Linux g++ -m64 -Wall -Wextra -c test.cpp -o /dev/null No warning or errors reported (except static_assert violation). Affected std::extent and std::extent_v for big arrays. -mcmodel=medium has no effect.
[Bug c++/105734] [12/13 Regression]: Incorrect "error: invalid use of 'auto'" for explicit destructor inside a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105734 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Jason Merrill --- Fixed for 12.2/13.
[Bug c++/105779] [12/13 Regression] static function with auto return type not being resolved correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105779 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jason Merrill --- Fixed for 12.2/13.
[Bug c++/105734] [12/13 Regression]: Incorrect "error: invalid use of 'auto'" for explicit destructor inside a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105734 --- Comment #12 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b090938e61260ce841a0d51de3407881a38e3c52 commit r12-8447-gb090938e61260ce841a0d51de3407881a38e3c52 Author: Jason Merrill Date: Tue May 31 16:31:35 2022 -0400 c++: auto and dependent member name [PR105734] In r12-3643 I improved our handling of type names after . or -> when unqualified lookup doesn't find anything, but it needs to handle auto specially. PR c++/105734 gcc/cp/ChangeLog: * parser.cc (cp_parser_postfix_dot_deref_expression): Use typeof if the expression has auto type. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/auto57.C: New test.
[Bug c++/105779] [12/13 Regression] static function with auto return type not being resolved correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105779 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:819e3fda1e0fc4cc07f5fd9211cdb38cdec1b901 commit r12-8446-g819e3fda1e0fc4cc07f5fd9211cdb38cdec1b901 Author: Jason Merrill Date: Tue May 31 16:17:58 2022 -0400 c++: auto function as function argument [PR105779] This testcase demonstrates that the issue in PR105623 is not limited to templates, so we should do the marking in a less template-specific place. PR c++/105779 gcc/cp/ChangeLog: * call.cc (resolve_args): Call mark_single_function here. * pt.cc (unify_one_argument): Not here. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/auto-fn63.C: New test.
[Bug c++/105803] [13 regression] ICE at gcc/cp/pt.cc:27737 after r13-860-gff91735a5b861d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105803 Marek Polacek changed: What|Removed |Added Target Milestone|--- |13.0 Keywords||ice-on-valid-code Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2022-06-01 --- Comment #7 from Marek Polacek --- Ah, never mind, I can reproduce with -fchecking=2.
[Bug c++/105803] [13 regression] ICE at gcc/cp/pt.cc:27737 after r13-860-gff91735a5b861d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105803 --- Comment #6 from Marek Polacek --- Weird. Can you show your gcc -v output so that I can configure gcc the same? (Yes, checking is enabled in my build.)
[Bug c++/105795] [11/12/13 Regression] Miscompilation with [[no_unique_address]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105795 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug middle-end/104787] [12/13 Regression] False positive -Wreturn-type since r12-5638-ga3e75c1491cd2d50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104787 Jason Merrill changed: What|Removed |Added CC||kamil.sliwak at codepoets dot it --- Comment #4 from Jason Merrill --- *** Bug 105794 has been marked as a duplicate of this bug. ***
[Bug c++/105794] [12/13 Regression] Spurious "control reaches end of non-void function" warning with a combination of destructor, try/catch and if (true)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105794 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||jason at gcc dot gnu.org --- Comment #3 from Jason Merrill --- Dup. *** This bug has been marked as a duplicate of bug 104787 ***
[Bug c++/105806] [concepts] template class specialization using concept issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105806 --- Comment #2 from Joseph --- When getting symbols using readelf for get_meta() in some .o files symbol is FUNC LOCAL DEFAULT and in others FUNC WEAK HIDDEN (we use hidden visibility option).
[Bug c++/105593] avx512 math function raises uninitialized variable warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Keywords|needs-bisection | Summary|[12/13 Regression] avx512 |avx512 math function raises |math function raises|uninitialized variable |uninitialized variable |warning |warning | Priority|P2 |P3 --- Comment #5 from Jason Merrill --- (In reply to Richard Biener from comment #4) > fails to hide the -Wuninitialized with the C++ frontend, works correct with > the C frontend and on the GCC 11 branch. I also get the warning on the 11 branch. And all the way back to the 4.1 branch, which is the oldest I have handy; this doesn't seem like a regression.
[Bug c++/105734] [12/13 Regression]: Incorrect "error: invalid use of 'auto'" for explicit destructor inside a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105734 --- Comment #11 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:e2e471d83d16449a325315c0f33dc52b90ce0fac commit r13-920-ge2e471d83d16449a325315c0f33dc52b90ce0fac Author: Jason Merrill Date: Tue May 31 16:31:35 2022 -0400 c++: auto and dependent member name [PR105734] In r12-3643 I improved our handling of type names after . or -> when unqualified lookup doesn't find anything, but it needs to handle auto specially. PR c++/105734 gcc/cp/ChangeLog: * parser.cc (cp_parser_postfix_dot_deref_expression): Use typeof if the expression has auto type. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/auto57.C: New test.
[Bug c++/105779] [12/13 Regression] static function with auto return type not being resolved correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105779 --- Comment #7 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:72e52b88582e738c8b8bde5f85af63d3a0e15d2b commit r13-919-g72e52b88582e738c8b8bde5f85af63d3a0e15d2b Author: Jason Merrill Date: Tue May 31 16:17:58 2022 -0400 c++: auto function as function argument [PR105779] This testcase demonstrates that the issue in PR105623 is not limited to templates, so we should do the marking in a less template-specific place. PR c++/105779 gcc/cp/ChangeLog: * call.cc (resolve_args): Call mark_single_function here. * pt.cc (unify_one_argument): Not here. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/auto-fn63.C: New test.
[Bug c++/105803] [13 regression] ICE at gcc/cp/pt.cc:27737 after r13-860-gff91735a5b861d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105803 --- Comment #5 from seurer at gcc dot gnu.org --- And it was that revision, too. seurer@muskie:~/gcc/git/build/gcc-test$ whichgcc Now at commit 1ad584d538d349db13cfa8440222d91d5e9aff3f, r13-859-g1ad584d538d349 seurer@muskie:~/gcc/cpu2017/benchspec/CPU/510.parest_r/build/build_peak_none.0002$ /home/seurer/gcc/git/install/gcc-test/bin/g++ -c test.cc seurer@muskie:~/gcc/cpu2017/benchspec/CPU/510.parest_r/build/build_peak_none.0002$
[Bug c++/105803] [13 regression] ICE at gcc/cp/pt.cc:27737 after r13-860-gff91735a5b861d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105803
--- Comment #4 from seurer at gcc dot gnu.org ---
Yes it is:
seurer@muskie:~/gcc/cpu2017/benchspec/CPU/510.parest_r/build/build_peak_none.0002$
whichgcc
Now at commit ff91735a5b861dd6eaf2c1e511f26a9255898e7d, r13-860-gff91735a5b861d
seurer@muskie:~/gcc/cpu2017/benchspec/CPU/510.parest_r/build/build_peak_none.0002$
cat test.cc
#include
#include
class SparsityPattern
{
public:
};
template
class BlockSparsityPatternBase// : public Subscriptor
{
};
class BlockSparsityPattern : public BlockSparsityPatternBase
{
};
class MGTransferBlockBase
{
public:
std::vector >
prolongation_sparsities;
template
void build_matrices ();
};
template
void MGTransferBlockBase::build_matrices ()
{
prolongation_sparsities.push_back (std::shared_ptr (new
BlockSparsityPattern));
}
seurer@muskie:~/gcc/cpu2017/benchspec/CPU/510.parest_r/build/build_peak_none.0002$
/home/seurer/gcc/git/install/gcc-test/bin/g++ -c test.cc
test.cc: In member function 'void MGTransferBlockBase::build_matrices()':
test.cc:31:37: internal compiler error: in type_dependent_expression_p, at
cp/pt.cc:27737
31 | prolongation_sparsities.push_back
(std::shared_ptr (new BlockSparsityPattern));
|
~~^~
0x1063cb33 type_dependent_expression_p(tree_node*)
/home/seurer/gcc/git/gcc-test/gcc/cp/pt.cc:27737
0x1063d6f3 value_dependent_expression_p(tree_node*)
/home/seurer/gcc/git/gcc-test/gcc/cp/pt.cc:27465
0x1063df77 value_dependent_expression_p(tree_node*)
/home/seurer/gcc/git/gcc-test/gcc/cp/pt.cc:27707
0x106447cf any_value_dependent_elements_p(tree_node const*)
/home/seurer/gcc/git/gcc-test/gcc/cp/pt.cc:28184
0x103a7257 is_nondependent_constant_expression(tree_node*)
/home/seurer/gcc/git/gcc-test/gcc/cp/constexpr.cc:9673
0x103a7913 fold_non_dependent_expr_template
/home/seurer/gcc/git/gcc-test/gcc/cp/constexpr.cc:8172
0x10636ea3 build_non_dependent_expr(tree_node*)
/home/seurer/gcc/git/gcc-test/gcc/cp/pt.cc:28647
0x106379a3 make_args_non_dependent(vec*)
/home/seurer/gcc/git/gcc-test/gcc/cp/pt.cc:28729
0x1033ea53 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/home/seurer/gcc/git/gcc-test/gcc/cp/call.cc:10939
0x105d91e7 cp_parser_postfix_expression
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:7856
0x105fddd3 cp_parser_unary_expression
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:9037
0x105b0307 cp_parser_cast_expression
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:9941
0x105b0e83 cp_parser_binary_expression
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:10043
0x105b1aff cp_parser_assignment_expression
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:10347
0x105b5d33 cp_parser_expression
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:10517
0x105ba46b cp_parser_expression_statement
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:12734
0x105d22ff cp_parser_statement
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:12526
0x105d3803 cp_parser_statement_seq_opt
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:12883
0x105d3957 cp_parser_compound_statement
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:12835
0x1060f613 cp_parser_function_body
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:25186
[Bug fortran/105807] New: ICE / error when defining a class containing polymorphic components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105807 Bug ID: 105807 Summary: ICE / error when defining a class containing polymorphic components Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: bourdin at mcmaster dot ca Target Milestone: --- defining a class whose components are polymorphic variables fails: Consider the following (legal) source code: module Vect_class type, abstract :: Vect_Type end type end module Vect_class module Elem_class use Vect_class type, abstract :: Elem_Type integer :: numDof class(Vect_type),allocatable :: v end type end module Elem_class module Vect use Vect_class type, extends(Vect_Type) :: Vect2D real :: X,Y end type Vect2D type, extends(Vect_Type) :: Vect3D real :: X,Y,Z end type Vect3D end module Vect module Elem use Elem_class type, extends(Elem_type) :: elem2D end type end module Elem program testElem use Vect_class use Vect use Elem_class use Elem type(Vect2D) :: a type(Vect3D) :: b class(Vect_type),allocatable :: c,d class(Elem_type),allocatable :: e real :: x,y,z x = 1.0 y =-2.0 z = 3.0 a = Vect2D(x,y) b = Vect3D(x,y,z) c = Vect2D(x,y) d = Vect3D(x,y,z) e = Elem2D(10,b) write(*,*) e%numDof end program testElem It fails to compile with error message with GNU Fortran (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1) (RHEL7 devtoolset 11) 53 | e = Elem2D(10,b) | 1 Error: Cannot convert TYPE(vect3d) to CLASS(__class_vect_class_Vect_type_a) at (1) Under macOS (monterey, M1 processor) GNU Fortran (Homebrew GCC 11.3.0_1) 11.3.0, I get an ICE: TestNestedClass3.f90:53:20: 53 | e = Elem2D(10,b) |1 internal compiler error: in fold_convert_loc, at fold-const.c:2563
[Bug c++/105806] [concepts] template class specialization using concept issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105806 Vincent changed: What|Removed |Added CC||vincent.lextrait at gmail dot com --- Comment #1 from Vincent --- The bug is present from gcc-9.2 to gcc-12.1.
[Bug c++/105806] New: [concepts] template class specialization using concept issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105806
Bug ID: 105806
Summary: [concepts] template class specialization using concept
issue
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: josephcanedo at hotmail dot com
Target Milestone: ---
We have a simple "trait" template class defining a static function holding a
static variable.
struct meta {};
template
struct type_traits
{
static meta& get_meta() {
static meta m;
return m;
}
};
This is used in several .hpp files among several TUs, without any problems.
We are attempting to use concepts to make specialisations of these type_traits,
e.g.
class root_base {};
template
concept root_type = std::is_base_of_v;
template
struct type_traits;
template
struct type_traits
{
static meta& get_meta() {
static meta m;
return m;
}
};
Using these compiles all fine, but we notice that for a given type_traits
instantiation with some type, we have several instances of get_meta() functions
symbols and hence several meta m variables, which we believe is not expected.
ie for given
class A: root_base {};
We have N type_traits::get_meta() functions symbols (different addresses for
these functions).
This only occurs with -O1 or higher option. -O0 does not exhibit this behavior.
[Bug c++/105803] [13 regression] ICE at gcc/cp/pt.cc:27737 after r13-860-gff91735a5b861d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105803 --- Comment #3 from Marek Polacek --- I still cannot reproduce with GNU C++17 (GCC) version 13.0.0 20220530 (experimental) (powerpc64le-unknown-linux-gnu) Can you please double check that the Comment 2 test is the correct one?
[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 --- Comment #21 from Chengnian Sun --- Thank you, Andrew and Jakub.
[Bug c++/105803] [13 regression] ICE at gcc/cp/pt.cc:27737 after r13-860-gff91735a5b861d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105803
--- Comment #2 from seurer at gcc dot gnu.org ---
With a bit of hacking with a chainsaw I got it to this:
#include
#include
class SparsityPattern
{
public:
};
template
class BlockSparsityPatternBase// : public Subscriptor
{
};
class BlockSparsityPattern : public BlockSparsityPatternBase
{
};
class MGTransferBlockBase
{
public:
std::vector >
prolongation_sparsities;
template
void build_matrices ();
};
template
void MGTransferBlockBase::build_matrices ()
{
prolongation_sparsities.push_back (std::shared_ptr (new
BlockSparsityPattern));
}
/home/seurer/gcc/git/install/gcc-test/bin/g++ -c test.cc
test.cc: In member function 'void MGTransferBlockBase::build_matrices()':
test.cc:31:37: internal compiler error: in type_dependent_expression_p, at
cp/pt.cc:27737
31 | prolongation_sparsities.push_back
(std::shared_ptr (new BlockSparsityPattern));
|
~~^~
0x1063cb33 type_dependent_expression_p(tree_node*)
/home/seurer/gcc/git/gcc-test/gcc/cp/pt.cc:27737
0x1063d6f3 value_dependent_expression_p(tree_node*)
/home/seurer/gcc/git/gcc-test/gcc/cp/pt.cc:27465
0x1063df77 value_dependent_expression_p(tree_node*)
/home/seurer/gcc/git/gcc-test/gcc/cp/pt.cc:27707
0x106447cf any_value_dependent_elements_p(tree_node const*)
/home/seurer/gcc/git/gcc-test/gcc/cp/pt.cc:28184
0x103a7257 is_nondependent_constant_expression(tree_node*)
/home/seurer/gcc/git/gcc-test/gcc/cp/constexpr.cc:9673
0x103a7913 fold_non_dependent_expr_template
/home/seurer/gcc/git/gcc-test/gcc/cp/constexpr.cc:8172
0x10636ea3 build_non_dependent_expr(tree_node*)
/home/seurer/gcc/git/gcc-test/gcc/cp/pt.cc:28647
0x106379a3 make_args_non_dependent(vec*)
/home/seurer/gcc/git/gcc-test/gcc/cp/pt.cc:28729
0x1033ea53 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/home/seurer/gcc/git/gcc-test/gcc/cp/call.cc:10939
0x105d91e7 cp_parser_postfix_expression
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:7856
0x105fddd3 cp_parser_unary_expression
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:9037
0x105b0307 cp_parser_cast_expression
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:9941
0x105b0e83 cp_parser_binary_expression
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:10043
0x105b1aff cp_parser_assignment_expression
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:10347
0x105b5d33 cp_parser_expression
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:10517
0x105ba46b cp_parser_expression_statement
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:12734
0x105d22ff cp_parser_statement
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:12526
0x105d3803 cp_parser_statement_seq_opt
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:12883
0x105d3957 cp_parser_compound_statement
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:12835
0x1060f613 cp_parser_function_body
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:25186
[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 --- Comment #20 from Jakub Jelinek --- (In reply to Andrew Pinski from comment #19) > (In reply to Chengnian Sun from comment #18) > > Hello folks, > > > > While testing gcc with -fcompare-debug, I was asked a question which puzzled > > me as well. > > > > What if we always enable -g, and use 'strip' to remove debug information > > from the binary file? Then we do not need to pay much attention to bugs > > detected by -fcompare-debug. > > because -g has a compile time overhead and even an assembler time overhead; > in some cases the debugging informationg is huge even for small programs. > Plus there are different levels of -g: -g1, -g2, and -g3 (-g is the same as > -g2). So which one would you enable by default? We could just enable -fvar-tracking-assignments and then just throw that info before var-tracking if -g0. But that would still cause significant IL growth and compile time increase when debug info isn't needed.
[Bug middle-end/105805] New: -fstrict-volatile-bitfields can read beyond the end of the bitfield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105805
Bug ID: 105805
Summary: -fstrict-volatile-bitfields can read beyond the end of
the bitfield
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
There are a few PRs related to -fstrict-volatile-bitfields, but this
one didn't seem to be a dup.
For:
---
struct S1 { volatile int a : 16; } __attribute__((packed));
struct S2 { _Alignas(4) struct S1 b; volatile short c; };
_Static_assert (sizeof (struct S2) == 4);
int foo (struct S2 *ptr) { return ptr->b.a; }
---
b and c are both 16-bit fields, but ptr->b.a uses a 32-bit access.
It therefore loads volatile field c despite c not being in the
same bitfield group as b.a:
foo:
ldr w0, [x0]
sxthw0, w0
ret
The problem seems to be that get_inner_reference commits too
early to using the mode of the bitfield's underlying type,
and we rely on:
/* The memory must be sufficiently aligned for a MODESIZE access.
This condition guarantees, that the memory access will not
touch anything after the end of the structure. */
if (MEM_ALIGN (op0) < modesize)
return false;
from strict_volatile_bitfield_p to roll back incorrect decisions.
But in this case, the layout of S2 guarantees 4-byte alignment,
so the opt-out doesn't work.
I was originally looking at the simpler:
---
struct S1 { volatile int a : 16; } __attribute__((packed));
struct S1 s;
int foo () { return s.a; }
---
which also exhibits the problem, but I guess it could be
argued in that case that the extra 2 bytes are guaranteed
to be dead space.
See also the testcase for PR69990.
[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 --- Comment #19 from Andrew Pinski --- (In reply to Chengnian Sun from comment #18) > Hello folks, > > While testing gcc with -fcompare-debug, I was asked a question which puzzled > me as well. > > What if we always enable -g, and use 'strip' to remove debug information > from the binary file? Then we do not need to pay much attention to bugs > detected by -fcompare-debug. because -g has a compile time overhead and even an assembler time overhead; in some cases the debugging informationg is huge even for small programs. Plus there are different levels of -g: -g1, -g2, and -g3 (-g is the same as -g2). So which one would you enable by default?
[Bug middle-end/30314] optimize multiply-by-constant overflow (wrap) test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30314 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cf78d8411d00e21c30512d2af895e70d38bbfb77 commit r13-917-gcf78d8411d00e21c30512d2af895e70d38bbfb77 Author: Jakub Jelinek Date: Wed Jun 1 17:54:39 2022 +0200 match.pd: Optimize __builtin_mul_overflow_p (x, cst, (utype)0) to x > ~(utype)0 / cst [PR30314] A comparison with a constant is most likely always faster than .MUL_OVERFLOW from which we only check whether it overflowed and not the multiplication result, and even if not, it is simpler operation on GIMPLE and even if a target exists where such multiplications with overflow checking are cheaper than comparisons, because comparisons are so much more common than overflow checking multiplications, it would be nice if it simply arranged for comparisons to be emitted like those multiplications on its own... 2022-06-01 Jakub Jelinek PR middle-end/30314 * match.pd (__builtin_mul_overflow_p (x, cst, (utype) 0) -> x > ~(utype)0 / cst): New simplification. * gcc.dg/tree-ssa/pr30314.c: New test.
[Bug rtl-optimization/105577] [12 Regression] ICE in delete_unmarked_insns, at dce.cc:653 since r12-248-gb58dc0b803057c0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105577 --- Comment #17 from Curdeius Curdeius --- Thanks a lot for fixing this quickly!
[Bug c++/105804] New: List-initialized argument in await expression is doubly freed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105804
Bug ID: 105804
Summary: List-initialized argument in await expression is
doubly freed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: blubban at gmail dot com
Target Milestone: ---
#include
#include
struct my_params {
std::unique_ptr ptr; // or any other object with nontrivial dtor
};
static std::suspend_never take_params(my_params params)
{
return {};
}
struct coro_t {
struct promise_type {
coro_t get_return_object() { return {}; }
std::suspend_never initial_suspend() { return {}; }
std::suspend_never final_suspend() noexcept { return {}; }
void unhandled_exception() noexcept {}
};
};
static coro_t my_coro()
{
co_await take_params({ std::make_unique(5) });
}
int main()
{
my_coro();
}
Expected output: Same as /bin/true
Actual: free(): double free detected in tcache 2
https://godbolt.org/z/8f9d3TzYo
Probably same root cause as bug 98056 and/or bug 103871, but since the symptoms
are way different (it's a wrong-code, not just rejects-valid), I think it
warrants a separate report.
[Bug lto/104237] [11 Regression] Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute since r11-3126-ga8f9b4c54cc35062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104237 --- Comment #18 from Chengnian Sun --- Hello folks, While testing gcc with -fcompare-debug, I was asked a question which puzzled me as well. What if we always enable -g, and use 'strip' to remove debug information from the binary file? Then we do not need to pay much attention to bugs detected by -fcompare-debug. Thank you. Chengnian.
[Bug c++/105803] [13 regression] ICE at gcc/cp/pt.cc:27737 after r13-860-gff91735a5b861d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105803 --- Comment #1 from Marek Polacek --- Would there be a chance to get a reduced testcase?
[Bug c++/105803] New: [13 regression] ICE at gcc/cp/pt.cc:27737 after r13-860-gff91735a5b861d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105803 Bug ID: 105803 Summary: [13 regression] ICE at gcc/cp/pt.cc:27737 after r13-860-gff91735a5b861d Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:ff91735a5b861dd6eaf2c1e511f26a9255898e7d, r13-860-gff91735a5b861d This is occurring in one of the spec2017 test cases, 510.parest_r. /home/seurer/gcc/git/install/gcc-test/bin/g++ -c -o source/multigrid/mg_transfer_block.o -DSPEC -DNDEBUG -Iinclude -I. -DSPEC_AUTO_SUPPRESS_OPENMP -m64 -O3 -mcpu=power9 -ffast-math -funroll-loops -fpeel-loops -fvect-cost-model -mpopcntd -mrecip=rsqrt-DSPEC_LP64 -Wno-deprecated-declarations -std=c++14-fpermissive source/multigrid/mg_transfer_block.cc source/multigrid/mg_transfer_block.cc: In member function 'void dealii::MGTransferBlockBase::build_matrices(const dealii::DoFHandler&, const dealii::MGDoFHandler&)': source/multigrid/mg_transfer_block.cc:119:20: internal compiler error: in type_dependent_expression_p, at cp/pt.cc:27737 118 | prolongation_sparsities | ~~~ 119 | .push_back (std_cxx1x::shared_ptr (new BlockSparsityPattern)); | ~~~^~~~ 0x1063cb33 type_dependent_expression_p(tree_node*) /home/seurer/gcc/git/gcc-test/gcc/cp/pt.cc:27737 0x1063d6f3 value_dependent_expression_p(tree_node*) /home/seurer/gcc/git/gcc-test/gcc/cp/pt.cc:27465 0x1063df77 value_dependent_expression_p(tree_node*) /home/seurer/gcc/git/gcc-test/gcc/cp/pt.cc:27707 0x106447cf any_value_dependent_elements_p(tree_node const*) /home/seurer/gcc/git/gcc-test/gcc/cp/pt.cc:28184 0x103a7257 is_nondependent_constant_expression(tree_node*) /home/seurer/gcc/git/gcc-test/gcc/cp/constexpr.cc:9673 0x103a7913 fold_non_dependent_expr_template /home/seurer/gcc/git/gcc-test/gcc/cp/constexpr.cc:8172 0x10636ea3 build_non_dependent_expr(tree_node*) /home/seurer/gcc/git/gcc-test/gcc/cp/pt.cc:28647 0x106379a3 make_args_non_dependent(vec*) /home/seurer/gcc/git/gcc-test/gcc/cp/pt.cc:28729 0x1033ea53 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int) /home/seurer/gcc/git/gcc-test/gcc/cp/call.cc:10939 0x105d91e7 cp_parser_postfix_expression /home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:7856 0x105fddd3 cp_parser_unary_expression /home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:9037 0x105b0307 cp_parser_cast_expression /home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:9941 0x105b0e83 cp_parser_binary_expression /home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:10043 0x105b1aff cp_parser_assignment_expression /home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:10347 0x105b5d33 cp_parser_expression /home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:10517 0x105ba46b cp_parser_expression_statement /home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:12734 0x105d22ff cp_parser_statement /home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:12526 0x105d3803 cp_parser_statement_seq_opt /home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:12883 0x10613277 cp_parser_already_scoped_statement /home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:14513 0x1061378b cp_parser_iteration_statement /home/seurer/gcc/git/gcc-test/gcc/cp/parser.cc:14147 commit ff91735a5b861dd6eaf2c1e511f26a9255898e7d (HEAD) Author: Marek Polacek Date: Fri May 13 20:09:53 2022 -0400 c++: Add !TYPE_P assert to type_dependent_expression_p [PR99080]
[Bug tree-optimization/105802] [13 Regression] ICE: in irange_intersect, at value-range.cc:1955 with -funswitch-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105802 --- Comment #4 from Andrew Macleod --- The reason for the precision check is because doing a union or intersection with ranges of different precisions is problematic, and being sure what the user expects would be a guess normally in this sort of situation, we pick the one we care about, and cast the other one if we are sure they need to be compatible... if they already are, it wont do anything. ie range_cast (path_range, r.type ()) r.intersect (path_range); or vice versa.
[Bug tree-optimization/105802] [13 Regression] ICE: in irange_intersect, at value-range.cc:1955 with -funswitch-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105802 Richard Biener changed: What|Removed |Added Known to work|12.1.1 | --- Comment #3 from Richard Biener --- I'm testing a fix.
[Bug tree-optimization/105802] [13 Regression] ICE: in irange_intersect, at value-range.cc:1955 with -funswitch-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105802
Andrew Macleod changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment #2 from Andrew Macleod ---
Its trapoping on
irange::irange_intersect (const irange )
{
gcc_checking_assert (!legacy_mode_p () && !r.legacy_mode_p ());
gcc_checking_assert (undefined_p () || r.undefined_p ()
|| range_compatible_p (type (), r.type ()));
on the range_compatible_p() call returning false.
688 if (!ranger->gori ().outgoing_edge_range_p (r, e, idx,
689
*get_global_range_query ()))
690 continue;
691 r.intersect (path_range);
(gdb) p path_range.dump(stderr)
[irange] E [0, 0]$5 = void
(gdb) p r.dump(stderr)
[irange] int [-INF, -1][2, +INF]
I guess E and int are not compatible types ? for ranges we check:
return (TYPE_PRECISION (type1) == TYPE_PRECISION (type2)
&& TYPE_SIGN (type1) == TYPE_SIGN (type2));
[Bug tree-optimization/105802] [13 Regression] ICE: in irange_intersect, at value-range.cc:1955 with -funswitch-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105802 Richard Biener changed: What|Removed |Added Last reconfirmed||2022-06-01 Status|UNCONFIRMED |ASSIGNED Target Milestone|--- |13.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I will have a look.
[Bug sanitizer/105697] GCC trunk failed to detect a stack buffer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105697 --- Comment #2 from Li Shaohua --- I think the volatile keyword in function parameters is critical to this bug.
[Bug tree-optimization/105786] [12/13 Regression] ICE in compute_distributive_range, at tree-data-ref.cc:593 since r12-4283-g6f966f06146be7689af471d152e18ff50c609d99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105786 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:57a8fb92ac4161ebbf9381b009e8c5af843e3e5f commit r13-913-g57a8fb92ac4161ebbf9381b009e8c5af843e3e5f Author: Richard Biener Date: Wed Jun 1 14:13:01 2022 +0200 tree-optimization/105786 - avoid strlen replacement for pointers This avoids matching strlen to a pointer result, avoiding ICEing because of an integer adjustment using PLUS_EXPR on pointers. 2022-06-01 Richard Biener PR tree-optimization/105786 * tree-loop-distribution.cc (loop_distribution::transform_reduction_loop): Only do strlen replacement for integer type reductions. * gcc.dg/torture/pr105786.c: New testcase.
[Bug c++/105797] [11/12/13 Regression] Internal compiler error: Segmentation fault ( fn_type_unification -> satisfaction_cache::satisfaction_cache -> iterative_hash_template_arg )
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105797 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c/93631] [10/11/12/13 Regression] ICE on an invalid strcmp call in gimple_call_arg, at gimple.h:3258
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93631 Richard Biener changed: What|Removed |Added Keywords||needs-bisection Status|NEW |WAITING --- Comment #10 from Richard Biener --- I can't reproduce with GCC 10+
[Bug debug/47819] [meta-bug] LTO debug information issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47819 Bug 47819 depends on bug 93865, which changed state. Bug 93865 Summary: .debug_line with LTO refers to bogus file-names https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug debug/93865] .debug_line with LTO refers to bogus file-names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.3 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Known to fail||10.2.0 --- Comment #8 from Richard Biener --- Fixed in GCC 10.3.
[Bug c++/105491] [10/11 Regression] Usage of __constinit with -std=c++11 does is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105491 Patrick Palka changed: What|Removed |Added Summary|[10/11/12 Regression] Usage |[10/11 Regression] Usage of |of __constinit with |__constinit with -std=c++11 |-std=c++11 does is rejected |does is rejected --- Comment #11 from Patrick Palka --- Now fixed for 12.2 as well.
[Bug c++/105491] [10/11/12 Regression] Usage of __constinit with -std=c++11 does is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105491
--- Comment #10 from CVS Commits ---
The releases/gcc-12 branch has been updated by Patrick Palka
:
https://gcc.gnu.org/g:e30b73bad9486f11b6b0022ae4a3edfc0f9da4bb
commit r12-8445-ge30b73bad9486f11b6b0022ae4a3edfc0f9da4bb
Author: Patrick Palka
Date: Wed Jun 1 08:47:25 2022 -0400
c++: constexpr init of union sub-aggr w/ base [PR105491]
Here ever since r10-7313-gb599bf9d6d1e18, reduced_constant_expression_p
in C++11/14 is rejecting the marked sub-aggregate initializer (of type S)
W w = {.D.2445={.s={.D.2387={.m=0}, .b=0}}};
^
ultimately because said initializer has CONSTRUCTOR_NO_CLEARING set,
hence the function must verify that all fields of S are initialized.
And before C++17 it doesn't expect to see base class fields (since
next_initializable_field skips over them), so the presence thereof
causes r_c_e_p to return false.
The reason r10-7313-gb599bf9d6d1e18 causes this is because in that
commit we began using CONSTRUCTOR_NO_CLEARING to precisely track whether
we're in middle of activating a union member. This ends up affecting
clear_no_implicit_zero, which recurses into sub-aggregate initializers
only if the outer initializer has CONSTRUCTOR_NO_CLEARING set. After
that commit, the outer union initializer above no longer has the flag
set at this point and so clear_no_implicit_zero no longer recurses into
the marked inner initializer.
But arguably r_c_e_p should be able to accept the marked initializer
regardless of whether CONSTRUCTOR_NO_CLEARING is set. The primary bug
therefore seems to be that r_c_e_p relies on next_initializable_field
which skips over base class fields in C++11/14. To fix this, this patch
introduces a new helper function next_subobject_field which is like
next_initializable_field except that it never skips base class fields,
and makes r_c_e_p use it. This patch then renames next_initializable_field
to next_aggregate_field (and makes it skip over vptr fields again).
NB: This minimal backport of r13-211-g0c7bce0ac184c0 for 12.2 just adds
next_subobject_field and makes reduced_constant_expression_p use it.
PR c++/105491
gcc/cp/ChangeLog:
* constexpr.cc (reduced_constant_expression_p): Use
next_subobject_field instead.
* cp-tree.h (next_subobject_field): Declare.
* decl.cc (next_subobject_field): Define.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-union7.C: New test.
* g++.dg/cpp0x/constexpr-union7a.C: New test.
* g++.dg/cpp2a/constinit17.C: New test.
(cherry picked from commit 0c7bce0ac184c057bacad9c8e615ce82923835fd)
[Bug tree-optimization/105802] New: [13 Regression] ICE: in irange_intersect, at value-range.cc:1955 with -funswitch-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105802 Bug ID: 105802 Summary: [13 Regression] ICE: in irange_intersect, at value-range.cc:1955 with -funswitch-loops Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Created attachment 53063 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53063=edit reduced testcase This happens even after the PR105770 fix. Compiler output: $ x86_64-pc-linux-gnu-gcc -O -funswitch-loops testcase.C during GIMPLE pass: unswitch testcase.C: In function 'void foo(int)': testcase.C:9:1: internal compiler error: in irange_intersect, at value-range.cc:1955 9 | foo (int i) | ^~~ 0x8f7931 irange::irange_intersect(irange const&) /repo/gcc-trunk/gcc/value-range.cc:1955 0x182adaf irange::intersect(vrange const&) /repo/gcc-trunk/gcc/value-range.h:820 0x182adaf evaluate_control_stmt_using_entry_checks /repo/gcc-trunk/gcc/tree-ssa-loop-unswitch.cc:691 0x182b9c1 evaluate_bbs > /repo/gcc-trunk/gcc/tree-ssa-loop-unswitch.cc:832 0x182c573 evaluate_loop_insns_for_predicate /repo/gcc-trunk/gcc/tree-ssa-loop-unswitch.cc:878 0x182c573 operator() /repo/gcc-trunk/gcc/tree-ssa-loop-unswitch.cc:915 0x182c573 evaluate_bbs > /repo/gcc-trunk/gcc/tree-ssa-loop-unswitch.cc:808 0x182c573 tree_unswitch_single_loop /repo/gcc-trunk/gcc/tree-ssa-loop-unswitch.cc:946 0x182cec3 tree_unswitch_single_loop /repo/gcc-trunk/gcc/tree-ssa-loop-unswitch.cc:1006 0x182de41 tree_ssa_unswitch_loops(function*) /repo/gcc-trunk/gcc/tree-ssa-loop-unswitch.cc:339 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. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-912-20220601140049-g0d5cc976a36-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --disable-bootstrap --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r13-912-20220601140049-g0d5cc976a36-checking-yes-rtl-df-extra-nobootstrap-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 13.0.0 20220601 (experimental) (GCC)
[Bug tree-optimization/105793] Missed vectorisation with conditional-select inside loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105793 Richard Biener changed: What|Removed |Added Version|unknown |13.0 Target||aarch64 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-06-01 --- Comment #3 from Richard Biener --- There's already some code in if-conversion to deal with the vectorizers restrictions with respect to how reductions have to appear. Basically the vectorizer currently does not accept for (..) a = b < 10. ? a + b : a - b; because there are two uses of 'a' here. Re-writing this to for (..) a = a + (b < 10. ? b : -b) would indeed work. See is_cond_scalar_reduction for the existing special casing.
[Bug tree-optimization/105770] [13 Regression] ICE in decompose, at wide-int.h:984 since r13-754
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105770 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug target/105791] [13 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -mxop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105791 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug tree-optimization/105770] [13 Regression] ICE in decompose, at wide-int.h:984 since r13-754
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105770
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0d5cc976a36af07c9790c38a99a0b98110c89795
commit r13-912-g0d5cc976a36af07c9790c38a99a0b98110c89795
Author: Jakub Jelinek
Date: Wed Jun 1 14:00:49 2022 +0200
unswitch: Fold case label lo/hi values to index type [PR105770]
The following testcase ICEs because we use different types in comparison,
idx has int type, while CASE_LOW has char type.
While I believe all CASE_{LOW,HIGH} in the same switch have to use the same
or compatible type, the index expression can have a promoted type as
happens
in this testcase. Other spots that handle switches do such foldings too.
2022-06-01 Jakub Jelinek
PR tree-optimization/105770
* tree-ssa-loop-unswitch.cc (find_unswitching_predicates_for_bb):
Cast
CASE_LOW and CASE_HIGH to TREE_TYPE (idx) before comparisons with
idx.
* gcc.dg/pr105770.c: New test.
[Bug tree-optimization/105786] [12/13 Regression] ICE in compute_distributive_range, at tree-data-ref.cc:593 since r12-4283-g6f966f06146be7689af471d152e18ff50c609d99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105786 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Priority|P3 |P2 Target Milestone|--- |12.2 --- Comment #4 from Richard Biener --- Confirmed. Testing patch.
[Bug fortran/105785] DIEs for local types are emitted at wrong scope in DWARF debug info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105785 --- Comment #1 from Richard Biener --- probably missing TYPE_CONTEXT here
[Bug target/105782] [sparc64] Emission of questionable movxtod/movdtox with -mvis3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105782 --- Comment #1 from Richard Biener --- You can check -fopt-info-vec for vectorization. Note the sparc backend doesn't implement any of GCCs vectorizer cost modeling hooks.
[Bug middle-end/105781] GCC does not unroll auto-vectorized loops.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105781 --- Comment #6 from Richard Biener --- The issue is cost modeling which is what the existing -funroll-[all-]loops RTL unrolling lacks. The vectorizer meanwhile can unroll vectorized loops by means of increasing the vectorization factor which the target can suggest by adjusting m_suggested_unroll_factor in the finish_cost hook. See the aarch64 port for an example.
[Bug c/105775] GCC uses an invalid assumption in numeric limits of char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105775 Richard Biener changed: What|Removed |Added Version|og11 (devel/omp/gcc-11) |11.3.1 --- Comment #1 from Richard Biener --- It's only an "error" if you use -Werror. If you use system headers then the diagnostic should also be suppressed automatically.
[Bug c++/105774] Bogus overflow in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105774 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||rejects-valid Last reconfirmed||2022-06-01 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Confirmed.
[Bug tree-optimization/105801] New: Missed CCP with -ftrivial-auto-var-init=zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105801
Bug ID: 105801
Summary: Missed CCP with -ftrivial-auto-var-init=zero
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
int foo (int flag)
{
int i;
if (flag)
i = 1;
return i;
}
CCP used to optimize this to 'return 1;' but with -ftrivial-auto-var-init=zero
only FRE does this now.
[Bug libfortran/59227] [4.9 regression] FAIL: gfortran.dg/erf_3.F90 -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59227 Bug 59227 depends on bug 59230, which changed state. Bug 59230 Summary: __divtf3@@GCC_4.4.0 missing from libgcc_s.so.1 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59230 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/59230] __divtf3@@GCC_4.4.0 missing from libgcc_s.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59230 Andreas Schwab changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andreas Schwab --- Fixed.
[Bug fortran/105800] New: Segfault deallocating a class, dimension(:) array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105800 Bug ID: 105800 Summary: Segfault deallocating a class, dimension(:) array Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mscfd at gmx dot net Target Milestone: --- Created attachment 53062 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53062=edit test class_dealloc.f90 Creating an array in a function with return value "type(t), dimension(:)", and assigning it to a "class(t), dimension(:)" variable eventually leads to a segfault when deallocating the array. See attached test. valgrind shows invalid read due to uninitialised value (presumably the type-descriptor of the "class(t), dimension(:)" variable is not completely initialised). If the "type(t)" is changed to "class(t)" in the create function, then it works fine, without any complains from valgrind.
[Bug tree-optimization/105786] [12/13 Regression] ICE in compute_distributive_range, at tree-data-ref.cc:593 since r12-4283-g6f966f06146be7689af471d152e18ff50c609d99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105786 Alex Coplan changed: What|Removed |Added CC||stefansf at linux dot ibm.com --- Comment #3 from Alex Coplan --- And with -fno-checking I indeed see the original ICE in compute_distributive_range instead.
[Bug tree-optimization/105786] ICE in compute_distributive_range, at tree-data-ref.cc:593 since r12-4283-g6f966f06146be7689af471d152e18ff50c609d99
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105786 Alex Coplan changed: What|Removed |Added Summary|ICE in |ICE in |compute_distributive_range, |compute_distributive_range, |at tree-data-ref.cc:593 |at tree-data-ref.cc:593 ||since ||r12-4283-g6f966f06146be7689 ||af471d152e18ff50c609d99 --- Comment #2 from Alex Coplan --- The above ICE started with r12-4283-g6f966f06146be7689af471d152e18ff50c609d99
[Bug tree-optimization/105643] [13 Regression] Code-Size regression for specrate 538.imagick_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643 --- Comment #9 from rguenther at suse dot de --- On Tue, 31 May 2022, crazylht at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105643 > > --- Comment #8 from Hongtao.liu --- > Looks like codesize decreased after > r13-754-ga1c9f779f75283427316b5c670c1e01ff8ce9ced. > > Now we have cost model for unswitching loop > > decorate.c:605:25: note: not unswitching condition, cost too big (37 insns > copied to 35 and 37) Yes, I noticed that when comparing opt-info before/after on SPEC as well. Note the actual cost limit wasn't adjusted in any way, there's still some planned improvements pending and adjusting the cost limit is one of that.
[Bug tree-optimization/105763] [13 Regression] ICE in outgoing_edge_range_p, at gimple-range-gori.cc:1253 since r13-754-ga1c9f779f7528342
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105763 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Fixed.
[Bug tree-optimization/105763] [13 Regression] ICE in outgoing_edge_range_p, at gimple-range-gori.cc:1253 since r13-754-ga1c9f779f7528342
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105763 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ae575e93b6f7fb7077940cb7410f899da184ec2d commit r13-873-gae575e93b6f7fb7077940cb7410f899da184ec2d Author: Richard Biener Date: Mon May 30 13:19:38 2022 +0200 tree-optimization/105763 - avoid abnormals with ranger queries In unswitching we use ranger to simplify switch statements so we have to avoid doing anything for abnormals. 2022-05-30 Richard Biener PR tree-optimization/105763 * tree-ssa-loop-unswitch.cc (find_unswitching_predicates_for_bb): Check gimple_range_ssa_p. * gcc.dg/pr105763.c: New testcase.
