[Bug tree-optimization/108868] [13 Regression] ocaml-dune miscompilation on i686 since r13-5965
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108868
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #6 from Richard Biener ---
Btw, there's also cleanup_call_ctrl_altering_flag in CFG cleanup which cleans
up the flag on the _last_ stmt of blocks. Dependent on whether fork/setjmp
is last it would clean the flag based on outgoing edges not being abnormal.
That's another reason to not abuse the ctrl-altering flag here.
I'm going to do the reversion now - is there a runtime testcase we can add for
this PR or should we solely rely on the abnormal dispatcher presence?
Btw, if the testcase would be just
void foo ()
{
if (!vfork ())
_exit (0);
}
then it's IMHO OK to elide the abnormal edges? There's still the issue
of clobbering if RTL doesn't have a REG_SETJMP note on the vfork (it
lacks the abnormal edges preventing code motion I think).
I'm going to revert the offending rev. now.
[Bug tree-optimization/108691] [13 Regression] ICE with function ptr and setjmp/returns twice at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108691 Richard Biener changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |--- --- Comment #12 from Richard Biener --- The fix was reverted.
[Bug tree-optimization/108855] [13 Regression] ICE in eliminate_unnecessary_stmts, at tree-ssa-dce.cc:1518
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108855 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:e79b9db15e410c4652438ffbbc44b6aa04e1ba61 commit r13-6152-ge79b9db15e410c4652438ffbbc44b6aa04e1ba61 Author: Richard Biener Date: Tue Feb 21 10:31:29 2023 +0100 tree-optimization/108855 - new testcase New testcase for the fixed bug. PR tree-optimization/108855 * gcc.dg/pr108855.c: New testcase.
[Bug tree-optimization/108855] [13 Regression] ICE in eliminate_unnecessary_stmts, at tree-ssa-dce.cc:1518
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108855 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- The offending patch was reverted.
[Bug tree-optimization/108868] [13 Regression] ocaml-dune miscompilation on i686 since r13-5965
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108868 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ecc863e85efe259c799515de0c38c2297b0e3bd7 commit r13-6153-gecc863e85efe259c799515de0c38c2297b0e3bd7 Author: Richard Biener Date: Tue Feb 21 10:32:10 2023 +0100 tree-optimization/108868 - new testcase New testcase for the fixed bug. PR tree-optimization/108868 * gcc.dg/pr108868.c: New testcase.
[Bug tree-optimization/108868] [13 Regression] ocaml-dune miscompilation on i686 since r13-5965
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108868 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Richard Biener --- The offending patch was reverted.
[Bug tree-optimization/108868] [13 Regression] ocaml-dune miscompilation on i686 since r13-5965
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108868 --- Comment #9 from Jakub Jelinek --- (In reply to Richard Biener from comment #5) > (In reply to Jakub Jelinek from comment #4) > > I think the reason why it doesn't work is clear, call_can_make_abnormal_goto > > on the vfork call is false, because it is leaf (and that is how glibc > > declares vfork BTW) and ctrl_altering flag is initialized by > > gimple_call_initialize_ctrl_altering based on that or if it is noreturn etc. > > (nothing applies). > > So, I think as discussed in another PR, I think we really should make if not > > call_can_make_abnormal_goto at least gimple_call_initialize_ctrl_altering be > > true for > > RETURNS_TWICE calls. > > I think I'm going to revert r13-5965 since neither setjmp nor [v]fork alter > control flow. They receive additional control flow. So we could just add GF_CALL_RETURNS_TWICE, there are still bits left. > I'm not sure why we have abnormal edges into fork(), fork simply returns We don't. vfork isn't a builtin but we have handle it by name in special_function_p. fork is a builtin, but just DEF_EXT_LIB_BUILTIN(BUILT_IN_FORK, "fork", BT_FN_PID, ATTR_NOTHROW_LIST) and is a builtin just because of gcov wrappers. And glibc don't declare returns_twice any of them, it just uses nothrow, leaf attributes on vfork and just nothrow attribute on fork.
[Bug tree-optimization/108691] [13 Regression] ICE with function ptr and setjmp/returns twice at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108691 --- Comment #13 from Sam James --- (Revert was for pr108868).
[Bug tree-optimization/108691] [13 Regression] ICE with function ptr and setjmp/returns twice at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108691 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #14 from Jakub Jelinek --- and PR108855.
[Bug c/108869] New: compiling an intrinsic wrapper : gives internal compiler error: in dwarf2out_register_main_translation_unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108869
Bug ID: 108869
Summary: compiling an intrinsic wrapper : gives internal
compiler error: in
dwarf2out_register_main_translation_unit
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jaydesh9 at gmail dot com
Target Milestone: ---
Hi,
I have a generically built binary that needs to include a lookup routine which
gets compiled into vectorized instructions or otherwise based upon whether the
cpu supports avx/avx2.
The lookup routine is same as that explained here :
https://stackoverflow.com/questions/54897297/check-all-bytes-of-a-m128i-for-a-match-of-a-single-byte-using-sse-avx-avx2
Here the (_mm_set1_epi8, __mm_cmpeq_epi8,_mm_movemask_epi8) intrinsic set will
compile into either vectorized instructions if avx/avx2 is supported by the cpu
or just sse based instructions, otherwise.
in a oversimplified main.c : compiled without mavx/mavx2 and with -msse3
-msse4 -o 3
#define __SSE2__
#define SSE_Lookup() \
_mm_set1_epi8; \
__mm_cmpeq_epi8; \
match_bitmap=_mm_movemask_epi8
#endif
static inline __attribute__((always_inline))
uint64_t foo()
{
unsigned int a=1,b,c,d;
uint64_t match_bitmap;
__cpuid(1,a,b,c,d);
if(c & bit_AVX)
{
match_bitmap= avx_lookup();
}else
{
#if __SSE__
SSE_Lookup();
#endif
}
}
foo_avx.c
#include
//mimicing an intrinsic wrapper
//don't want to create any new stack frames so keeping it inline
extern __inline int __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
__avx_lookup (char h, __m128i h)
{
__m128i k = _mm_set1_epi8(h);
__m128i r = _mm_cmpeq_epi8(k,h);
return _mm_movemask_epi8(r);
}
GCC Bug report : Bugzilla :
x86_64_gcc-7.5.0_glibc/bin/x86_64-openwrt-linux-gnu-gcc
Compiled as follows :
/build/openwrt/toolchain-x86_64_gcc-7.5.0_glibc/bin/x86_64-openwrt-linux-gnu-gcc
-fsigned-char -fmerge-constants -fPIC -pipe -MD -MP -Werror -Wall -Wextra
-Wpointer-arith -Wreturn-type -Wwrite-strings -Wno-unused-parameter
-Wunused-variable -Wno-unused-result -Wformat -Wformat-security -Winit-self
-Wno-implicit-fallthrough -Wno-format-truncation -Wno-deprecated-declarations
-Wno-error=deprecated-declarations -mtune=generic -msse3 -msse4 -mpclmul -maes
-mcx16 -g -O0 -DBUILD_UT=1 -std=gnu99 -Wno-missing-field-initializers
-Wmissing-prototypes -mavx -o 2 -o /build/x86_64/common/foo_avx.o foo_avx.c
foo_avx.c:19:1: internal compiler error: in
dwarf2out_register_main_translation_unit, at dwarf2out.c:26628
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c/108869] compiling an intrinsic wrapper : gives internal compiler error: in dwarf2out_register_main_translation_unit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108869
--- Comment #1 from Richard Biener ---
I changed the avx function to
extern __inline int __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
__avx_lookup (char kk, __m128i h)
{
__m128i k = _mm_set1_epi8(kk);
__m128i r = _mm_cmpeq_epi8(k,h);
return _mm_movemask_epi8(r);
}
to make it compile but cannot reproduce with a GCC 7.5.0 native compiler on
x86_64.
Note that GCC 7.5 is no longer supported, the oldest still supported compiler
would be GCC 10.4
[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931 --- Comment #20 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931 > > --- Comment #17 from rguenther at suse dot de --- > On Mon, 20 Feb 2023, jakub at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931 > > > > --- Comment #16 from Jakub Jelinek --- > > As discussed elsewhere, always_inline is used in various ways, in some > > users I > > guess would like to see an error if it wasn't inlined, but e.g. the uses in > > glibc for _FORTIFY_SOURCE where many of the standard C or POSIX APIs have > > extern inline wrappers with always_inline and gnu_inline attributes. In > > that > > case always_inline is used there for security reasons (not inlining it means > > the security checks aren't done) but on the other side C/POSIX requires > > &open > > or &printf to work too. > > With GNU extern inline always_inline it would work to never emit bodies > of always_inline functions to get the errors diagnosed at link time. > Possibly standard C inline plus always_inline would work the same if we > then treat the out of line instantiation as the destination for indirect > calls. > > But I think the cgraph code is still not 100% accurate in reflecting > reality with extern inlines (and possibly C 'inline' and instantiations), > since it doesn't treat the inline copy and the out of line copy > separately. Yep, when inline version is replaced by offline version we forget inline version. THis is remainer from one-definition rule work Zack did many years ago. He changed C and C++ frontned to not produce duplciated VAR/FUNCTION_DECLs with same assembler names and do in-place replacements instead. This was never fully finished and we get duplciates in some scnearios. In meantime cgraph knows how to handle this for LTO and we also support weakrefs and syntactic aliases so keeping both definitions around is not too hard from cgraph point of view. We will however need to convince front-ends to not overwrite the original decl holding the extern inline body. Honza
[Bug target/108840] Aarch64 doesn't optimize away shift counter masking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108840 ktkachov at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from ktkachov at gcc dot gnu.org --- I have a patch to simplify and fix the aarch64 rtx costs for this case. I'll aim it for GCC 14 as it's not a regression.
[Bug debug/108772] [13 Regression] ICE in force_decl_die, at dwarf2out.cc:26751 since r13-4161-g32d16fe9d7e347bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108772
--- Comment #7 from Richard Biener ---
(In reply to Richard Biener from comment #6)
> (In reply to Richard Biener from comment #5)
> > another possibility would be to stream "no DIE" info for not late
> > created decls
>
> like by setting DECL_IGNORED_P on them? Like maybe with the following
> which also fixes the issue:
>
> diff --git a/gcc/lto-streamer-in.cc b/gcc/lto-streamer-in.cc
> index 03cb41cfa16..f91e51b9327 100644
> --- a/gcc/lto-streamer-in.cc
> +++ b/gcc/lto-streamer-in.cc
> @@ -1739,6 +1739,10 @@ lto_read_tree_1 (class lto_input_block *ib, class
> data_in *data_in, tree expr)
> dref_entry e = { expr, str, off };
> dref_queue.safe_push (e);
> }
> + else if (DECL_P (expr))
> + /* Avoid creating a full DIE late for a decl that didn't have
> + it created early. */
> + DECL_IGNORED_P (expr) = 1;
> }
> }
Even using
else if (DECL_P (expr)
&& ! DECL_ABSTRACT_ORIGIN (expr)
&& ! (TARGET_PECOFF || TARGET_COFF))
gets us quite some guality regressions.
The original proposed change feels wrong though.
[Bug c++/108848] [10/11/12/13 Regression] template keyword incorreclty required to access template class static member of non-dependent expression using member syntax in dependent context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108848 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug ipa/108802] [10/11/12/13 Regression] missed inlining of call via pointer to member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108802 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Last reconfirmed||2023-02-21 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #3 from Richard Biener --- That means it was a conscious decision. IPA function summary for f1():: [with auto:1 = int (A::*)(int)]/1 inlinable global time: 30.50 self size: 23 global size: 25 the body is [local count: 1073741824]: _1 = f_18(D)->__pfn; _2 = (long int) _1; _3 = _2 & 1; if (_3 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 536870913]: _4 = __closure_19(D)->__a; _5 = f_18(D)->__delta; _6 = (sizetype) _5; _7 = _4 + _6; _8 = *_7; _9 = _2 + -1; _10 = (sizetype) _9; _11 = _8 + _10; iftmp.0_20 = *_11; [local count: 1073741824]: # iftmp.0_16 = PHI _12 = __closure_19(D)->__a; _13 = f_18(D)->__delta; _14 = (sizetype) _13; _15 = _12 + _14; _22 = iftmp.0_16 (_15, 42); return _22; so it is quite large. While we can give inline incentives in IPA inlining we do not discover the inline target there - the above has it also well obfuscated. Maybe we can still compute the set of functions possibly called here and perform speculative inlining in IPA? Maybe the frontend can also improve the initial IL which looks like < = (((long int) f->__pfn & 1) != 0) ? (int A:: (struct A *, int) *) *(*((int (*) () * *) a + (sizetype) f->__delta) + (sizetype) ((long int) f->__pfn + -1)) : f->__pfn ((struct A *) a + (sizetype) f->__delta, 42)>>;
[Bug debug/108772] [13 Regression] ICE in force_decl_die, at dwarf2out.cc:26751 since r13-4161-g32d16fe9d7e347bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108772 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/108685] [10/11/12/13 Regression] ICE in verify_loop_structure, at cfgloop.cc:1748 since r13-2388-ga651e6d59188da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108685 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/108606] [13 Regression] ICE in potential_constant_expression_1 with friend function declaration inside a local class of a generic/templated lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108606 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/108603] [12/13 Regression] ICE in output_operand_lossage with SVE and ilp32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108603 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/108550] [10/11/12/13 Regression] the type 'const auto' of 'constexpr' variable is not literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108550 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/108546] [11/12/13 Regression] ICE in expand_expr_real_1, at expr.cc:10910 since r10-4531-ga2c26c50310a3363
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108546 Richard Biener changed: What|Removed |Added Component|fortran |middle-end Priority|P3 |P2 --- Comment #2 from Richard Biener --- (gdb) p exp $1 = (gdb) p context $2 = (gdb) p current_function_decl $3 = so we somehow forgot to remap 's'? Looks like a middle-end issue to me.
[Bug middle-end/108545] [13 Regression] ICE in install_var_field, at omp-low.cc:799 since r13-2665-g23baa717c991d77f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108545 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Component|fortran |middle-end
[Bug c++/108542] [13 Regression] ICE in instantiate_type, at cp/class.cc:8833
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108542 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/108517] [11/12/13 Regression] std::sort of empty range yield "warning: 'this' pointer is null"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108517 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/108430] [13 Regression] Wrong code with -msve-vector-bits=512 since r13-707-g68e0063397
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108430 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/108793] [12/13 Regression] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108793 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:a7e706df2280de4a42f68b6c44401e4348d3593c commit r13-6258-ga7e706df2280de4a42f68b6c44401e4348d3593c Author: Richard Biener Date: Mon Feb 20 12:58:50 2023 +0100 tree-optimization/108793 - niter compute type mismatch When computing the number of iterations until wrap types are mixed up, eventually leading to checking ICEs with a pointer bitwise inversion. The following uses niter_type for the calculation. PR tree-optimization/108793 * tree-ssa-loop-niter.cc (number_of_iterations_until_wrap): Use convert operands to niter_type when computing num. * gcc.dg/torture/pr108793.c: New testcase.
[Bug tree-optimization/108793] [12 Regression] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108793 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Known to work||13.0 Summary|[12/13 Regression] ICE: |[12 Regression] ICE: |verify_gimple failed|verify_gimple failed
[Bug target/108429] [13 Regression] FAIL: gcc.target/i386/pr89618.c scan-tree-dump vect "LOOP VECTORIZED"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108429 Richard Biener changed: What|Removed |Added Priority|P3 |P1 --- Comment #5 from Richard Biener --- Honza - the test still fails.
[Bug c++/108422] [13 Regression] ICE: base pointer cycle detected since r13-2661-gb57abd072dd319a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108422 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Priority|P3 |P1
[Bug tree-optimization/108691] [13 Regression] ICE with function ptr and setjmp/returns twice at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108691 --- Comment #15 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:1dd033b8bcb0c50ad80084a3a13a391808b2deb6 commit r13-6259-g1dd033b8bcb0c50ad80084a3a13a391808b2deb6 Author: Richard Biener Date: Tue Feb 21 13:02:31 2023 +0100 tree-optimization/108691 - remove trigger-happy assert The following gets rid of the idea that we should prevent setjmp like calls from popping up in uncontrolled way in the IL for now. The solution is probably to handle it similar as noreturn has the ctrl-altering flag on stmts, but use another flag, for example ctrl-receiving which would also make sure the stmt is first. PR tree-optimization/108691 * tree-ssa-dce.cc (eliminate_unnecessary_stmts): Remove assert about calls_setjmp not becoming true when it was false. * gcc.dg/pr108691.c: New testcase.
[Bug tree-optimization/108691] [13 Regression] ICE with function ptr and setjmp/returns twice at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108691 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #16 from Richard Biener --- Fixed.
[Bug libbacktrace/108870] New: Gather file/line info for file/namespace/static variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108870
Bug ID: 108870
Summary: Gather file/line info for file/namespace/static
variables
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libbacktrace
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: ian at gcc dot gnu.org
Target Milestone: ---
As discussed in PR108834, llvm symbolizer switched to providing detailed
file/line info from debuginfo rather than by the compiler emitting the location
data into sourcefiles.
Currently the libsanitizer libbacktrace based symbolizer for data uses
backtrace_syminfo((backtrace_state *)state_, addr, SymbolizeDataCallback,
ErrorCallback, info);
which fills in (demangled) name from ELF symbol name, start and size (again,
from ELF).
We'd need to look up DWARF DW_TAG_variable DIEs (both at compile_unit/namespace
level and also nested in DW_TAG_subprogram and their children), which have
DW_AT_location of the form DW_OP_addr symbol_addr and map the symbol_addr to
DW_AT_decl_{file,line} and maybe DW_AT_name?
Wonder if we should just walk the whole .debug_info lazily the first time
something like libsanitizer asks for it, or if the current .debug_info walk
(read_function_info/read_function_entry) should gather it with other stuff if
libbacktrace user asks for it during library initialization somehow. Though, I
think
read_function_info is invoked only if read_line_info was successful...
[Bug tree-optimization/108419] [13 Regression] Dead Code Elimination Regression at -O2 since r13-440-g98e475a8f58
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108419 Richard Biener changed: What|Removed |Added Last reconfirmed|2023-01-17 00:00:00 |2023-2-21 --- Comment #1 from Richard Biener --- Re-confirmed but still without analysis.
[Bug libbacktrace/108870] Gather file/line info for file/namespace/static variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108870 Jakub Jelinek changed: What|Removed |Added CC||marxin at gcc dot gnu.org Blocks||108834 --- Comment #1 from Jakub Jelinek --- Ian, any thoughts on this? Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108834 [Bug 108834] LTO: ltrans temporary file is used as module name in ASAN
[Bug c/108375] [10/11/12 Regression] Some variably modified types not detected as such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108375 Richard Biener changed: What|Removed |Added Known to work||13.0 Priority|P3 |P4 Summary|[10/11/12/13 Regression]|[10/11/12 Regression] Some |Some variably modified |variably modified types not |types not detected as such |detected as such --- Comment #10 from Richard Biener --- I assume this is now fixed for C on trunk. Since langhooks are a no-go when doing LTO it would be nice to have this bit in the middle-end - it should be possible to set it when laying out the type via the langhook. Of course what the C frontend calls "variably modified" (and the reasons it tests that) might not be the same as what the middle-end thinks (and why _it_ tests for it).
[Bug tree-optimization/108368] [13 Regression] Dead Code Elimination Regression at -O3 since r13-1759-gdbb093f4f15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108368 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Richard Biener --- It's fixed on trunk now.
[Bug tree-optimization/108367] [12/13 Regression] ICE: verify_ssa failed (error: definition in block 4 does not dominate use in block 3) since r12-5138-ge82c382971664d6f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108367 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/108366] [12/13 Regression] Spurious stringop overflow, possibly alias-related since r12-145-gd1d01a66012a93cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108366 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/108358] [13 Regression] Dead Code Elimination Regression at -Os since r13-3378-gf6c168f8c06047
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108358 Richard Biener changed: What|Removed |Added Last reconfirmed|2023-01-10 00:00:00 |2023-2-21 --- Comment #1 from Richard Biener --- Re-confirmed but not analyzed yet.
[Bug c++/108606] [13 Regression] ICE in potential_constant_expression_1 with friend function declaration inside a local class of a generic/templated lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108606
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
Adjusted #c0 testcase that is accepted up to r13-2164 and ICEs with r13-2165 up
to current trunk:
template
void bar (T) {}
void
foo ()
{
bar ([&](auto x) { class C { friend void baz (); }; });
}
I can confirm #c1 doesn't reproduce for me either.
[Bug debug/108772] [13 Regression] ICE in force_decl_die, at dwarf2out.cc:26751 since r13-4161-g32d16fe9d7e347bc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108772
--- Comment #8 from Richard Biener ---
diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index 1f39df3b1e2..5a2538f80e1 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -27282,7 +27282,7 @@ dwarf2out_late_global_decl (tree decl)
/* We may have to generate full debug late for LTO in case debug
was not enabled at compile-time or the target doesn't support
the LTO early debug scheme. */
- if (! die && in_lto_p)
+ if (! die && in_lto_p && (TARGET_PECOFF || TARGET_COFF))
dwarf2out_decl (decl);
else if (die)
{
tests clean though. Obviously that will cease creating debug info for
all late generated decls, even when done explicitely (like for late
generated clones).
[Bug libstdc++/108861] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108861 --- Comment #5 from Vinícius dos Santos Oliveira --- > Because there is an open defect report against the C++ standard about this. > Basically until that is resolved, GCC's behavior is considered correct. How clueless of me to miss such obvious fact. So it turns out that notify_all_at_thread_exit() does *not* have any bugs and can be used safely? I reverted the GCC workaround I had in my codebase. We can close the issue already. It was dumb of me to even assume that GCC could have bugs.
[Bug c/108375] [10/11/12 Regression] Some variably modified types not detected as such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108375 --- Comment #11 from Martin Uecker --- Yes, for C this is fixed on trunk. This change seems to also fix PR102939. There is only one place in c-common/ left where middle-end function is used, so we could easily separate the C FE understanding of VM-types from the one of the middle-end. I think for C++ it would also be no problem (it even more restrictive). Ada I have no idea. But I suspect that different languages might also have a different idea about this, and it would therefor make sense to decouple this. So the question is: What is the middle-end's idea of a variably modified type? Why does it even have to know? In contrast to types with variable size I think a variably modified type is something which could be a FE only thing. If LTO does not work with lang hooks (what happens? are they just removed?), should we just remove the call to it? (which might require the change in c-/common).
[Bug c++/108243] [10/11/12/13 Regression] Missed optimization for static const std::string_view(const char*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108243
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #10 from Richard Biener ---
I'm not sure if this is supposed to be fixed yet. For the comment#2 testcase
I now get
[local count: 1073741824]:
_1 = __atomic_load_1 (&_ZGVZ4mainE3foo, 2);
if (_1 == 0)
goto ; [33.00%]
else
goto ; [67.00%]
[local count: 956811341]:
goto ; [100.00%]
[local count: 354334800]:
_2 = __cxa_guard_acquire (&_ZGVZ4mainE3foo);
if (_2 != 0)
goto ; [33.00%]
else
goto ; [67.00%]
[local count: 116930483]:
MEM[(struct string_view *)&foo] ={v} {CLOBBER};
MEM[(struct string_view *)&foo].str = "bar";
MEM[(struct string_view *)&foo].len = 3;
__cxa_guard_release (&_ZGVZ4mainE3foo);
[local count: 1073741824]:
_9 = foo.len;
_8 = (int) _9;
return _8;
so we fail to CSE foo.len because __cxa_guard_release possibly clobbers it
(it's global memory).
Note the clobbering is necessary to prevent code motion across the
lock primitives.
Note that __cxa_guard_release also prevents removing the .str initialization
since only the .len member is ever inspected. As noted static initialization
would improve this quite a bit.
[Bug jit/107999] [13 Regression] jit.dg/test-error-array-bounds.c now fails because [-Warray-bounds] was updated to [-Warray-bounds=] in error messages after r13-4410-g7c01d029fca669263b9c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107999 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-02-21 Status|UNCONFIRMED |ASSIGNED
[Bug rtl-optimization/107762] [13 Regression] Recent change causing regressions on s390-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107762 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug libstdc++/108861] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108861 --- Comment #6 from Jonathan Wakely --- Nobody said there's no bug, that's why your previous bug report was suspended, not closed as invalid. The point is that what GCC does today conforms to the standard. If there's a bug in the standard, it should be fixed in the standard, and then GCC will follow. There's no need to be a sarcastic prat about it.
[Bug driver/107448] [11/12/13 Regression] GCC no longer diagnoses missing input file with -MG since r11-6855-g4804de453e7f5f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107448 Richard Biener changed: What|Removed |Added Keywords|accepts-invalid |diagnostic Priority|P3 |P2 --- Comment #2 from Richard Biener --- It's a diagnostic issue, the driver still exits with an error. Supposedly cc1 (as preprocessor) is supposed to diagnose the missing file now.
[Bug c++/108606] [13 Regression] ICE in potential_constant_expression_1 with friend function declaration inside a local class of a generic/templated lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108606 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 54500 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54500&action=edit gcc13-pr108606.patch Untested fix - conditional reversion of the second hunk of the commit for non-VAR_DECLs.
[Bug tree-optimization/107114] [13 Regression] Failure to discover range results in bogus warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107114 Richard Biener changed: What|Removed |Added Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #7 from Richard Biener --- Based on that, closing as invalid.
[Bug sanitizer/106998] [10/11/12/13 Regression] libsanitizer PATH_MAX not defined for linux new targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106998 --- Comment #3 from Richard Biener --- I don't see linux/limits.h included still, but limits.h is - should musl include linux/limits.h by itself? Please link to upstream generated issues.
[Bug testsuite/106879] [13 regression] new test case gcc.dg/vect/bb-slp-layout-19.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106879 Richard Biener changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #2 from Richard Biener --- The testcase is still the same so I suppose so.
[Bug middle-end/106258] [13 Regression] ICE in ipa_verify_edge_has_no_modifications, at ipa-param-manipulation.cc:139 since r13-1204-gd68d366425369649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106258 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 54501 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54501&action=edit gcc13-pr106258.patch I think it actuall should be like this instead.
[Bug tree-optimization/106315] [13 Regression] 7.8% increased codesize on specfp 507.cactuBSSN_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106315 --- Comment #6 from Richard Biener --- Confirmed as triggered by jump threading somehow. Note the RTL unroller is notoriously not tuned.
[Bug target/106282] [10/11/12/13 Regression] m68k: Problem with thread-local storage and -mcpu=5206 since r9-2326-gede9446c26a929
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106282 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c++/108243] [10/11/12/13 Regression] Missed optimization for static const std::string_view(const char*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108243
--- Comment #11 from Patrick Palka ---
The pending patch
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612365.html will fix
that. With that patch we'll statically initialize
static const string_view foo("bar");
as we already do for
static const string_view foo = {"bar"};
[Bug tree-optimization/105834] [13 Regression] Dead Code Elimination Regression at -O2 (trunk vs. 12.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105834 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-02-21 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed. Not analyzed yet.
[Bug tree-optimization/105833] [13 Regression] Dead Code Elimination Regression at -O2 (trunk vs. 12.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105833 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Richard Biener --- Seems to be fixed now.
[Bug tree-optimization/105832] [13 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 12.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105832 Richard Biener changed: What|Removed |Added Last reconfirmed|2022-10-19 00:00:00 |2023-2-21 --- Comment #8 from Richard Biener --- Re-confirmed.
[Bug tree-optimization/105723] [12 Regression] Optimization false positive warning (-Wstringop-overflow)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105723 Richard Biener changed: What|Removed |Added Summary|[12/13 Regression] |[12 Regression] |Optimization false positive |Optimization false positive |warning |warning |(-Wstringop-overflow) |(-Wstringop-overflow) Last reconfirmed||2023-02-21 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Known to work||13.0 --- Comment #2 from Richard Biener --- Confirmed with GCC 12 but it seems that GCC 13 is no longer affected, possibly due to standard library changes.
[Bug rtl-optimization/106041] [12/13 Regression] infinite loop in fast_dce at -O1 with aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106041
--- Comment #10 from Richard Biener ---
Confirmed, it never finishes word-level iteration.
static void
fast_dce (bool word_level)
{
...
while (global_changed)
{
...
}
IMHO that "fast" DCE should hard-limit the iteration count anyway. I'm trying
to reduce the testcase based on that.
[Bug c++/108871] New: attribute nonnull does not spot nullptr O2 and above when function inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108871
Bug ID: 108871
Summary: attribute nonnull does not spot nullptr O2 and above
when function inlined
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
Target Milestone: ---
With Optimizations level 1 it still works.
https://godbolt.org/z/6axdfchr8
-fanalyzer -std=c++23 -O3 -Wnonnull -Wall
-Wno-analyzer-use-of-uninitialized-value
#include
std::string make_std_string(const char * const str) __attribute__ ((nonnull));
std::string make_std_string(const char * const str)
{
return std::string(str);
}
int main()
{
const char * a = NULL;
std::string result = make_std_string(a);
__builtin_puts(result.c_str());
}
[Bug c++/108871] attribute nonnull does not spot nullptr O2 and above when function inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108871 --- Comment #1 from Jonny Grant --- gcc-help mailing list discussion https://gcc.gnu.org/pipermail/gcc-help/2023-February/142279.html
[Bug go/104290] [12/13 Regression] trunk 20220214 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2023-02-21 Ever confirmed|0 |1 --- Comment #32 from Richard Biener --- What's the status?
[Bug middle-end/103637] [12/13 Regression] missing warning writing past the end of one of multiple elements of the same array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103637 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Known to fail||13.0 Last reconfirmed||2023-02-21 --- Comment #3 from Richard Biener --- Confirmed on trunk.
[Bug d/103528] [12/13 regression] d21 doesn't build on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103528 --- Comment #18 from Richard Biener --- What's the status of this bug now?
[Bug tree-optimization/102516] [12/13 regression] pr65947-13.c and vect-alias-check-18.c fail on armeb since r12-3893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102516 Richard Biener changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener --- Thus fixed.
[Bug fortran/108872] New: ICE in main_block_label, missing label when assigning a derived type whose component has a defined assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108872
Bug ID: 108872
Summary: ICE in main_block_label, missing label when assigning
a derived type whose component has a defined
assignment
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: trnka at scm dot com
Target Milestone: ---
gfortran (tested versions 9 through 12.2.1 20221121) crashes when compiling the
following testcase because the "bb" pointer is null in main_block_label()
called from cleanup_dead_labels() in tree-cfg.c:
module TestModule
implicit none
private
type :: A
integer:: i = 0
contains
procedure :: NewCopyOther
generic :: assignment(=) => NewCopyOther
end type
type :: B
type(A) :: aa
end type
type :: C
type(B) :: x
contains
procedure :: Run
end type
contains
subroutine NewCopyOther(self, other)
class(A), intent(out) :: self
class(A), intent(in) :: other
self%i = other%i
end subroutine
subroutine Run(self)
class(C), intent(inout) :: self
type(B) :: y
goto 2
2 y = self%x
end subroutine
end module
Apparently, the Fortran frontend never emits the "2" label as long as it's
placed on a line containing an assignment of a derived type (B) which has a
component with a defined assignment operator (A). The "original" dump for run()
looks like the following:
__attribute__((fn spec (". w ")))
void run (struct __class_testmodule_C_t & restrict self)
{
struct b y;
{
struct b b.2;
b.2.aa.i = 0;
y = b.2;
}
goto __label_02;
y = self->_data->x;
{
struct __class_testmodule_A_t class.0;
struct __class_testmodule_A_t class.1;
class.0._vptr = (struct __vtype_testmodule_A * {ref-all})
&__vtab_testmodule_A;
class.0._data = &y.aa;
class.1._vptr = (struct __vtype_testmodule_A * {ref-all})
&__vtab_testmodule_A;
class.1._data = &self->_data->x.aa;
newcopyother (&class.0, &class.1);
}
}
__label_02 is thus used in a goto even though it's nowhere to be seen.
I guess bug 95613 might be related but probably not a duplicate as that one has
nothing to do with defined assignments.
[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107998 --- Comment #22 from Jakub Jelinek --- Created attachment 54502 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54502&action=edit gcc13-pr107998.patch Let's go with this patch then? Note, I can't really test it.
[Bug testsuite/106879] [13 regression] new test case gcc.dg/vect/bb-slp-layout-19.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106879
--- Comment #3 from seurer at gcc dot gnu.org ---
I just tried this and I am still seeing failures albeit only on power 7 BE.
make -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
vect.exp=gcc.dg/vect/bb-slp-layout-19.c"
FAIL: gcc.dg/vect/bb-slp-layout-19.c scan-tree-dump-times slp1 "add new stmt:
[^\\n\\r]* = VEC_PERM_EXPR" 3
FAIL: gcc.dg/vect/bb-slp-layout-19.c -flto -ffat-lto-objects
scan-tree-dump-times slp1 "add new stmt: [^\\n\\r]* = VEC_PERM_EXPR" 3
# of expected passes2
# of unexpected failures2
Note that while that run was for 32 bits it fails for 64 as well.
[Bug tree-optimization/108873] New: Using the C++ front-end causes no DCE from happening
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108873
Bug ID: 108873
Summary: Using the C++ front-end causes no DCE from happening
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
CC: amacleod at redhat dot com, dimhen at gmail dot com,
theodort at inf dot ethz.ch, unassigned at gcc dot gnu.org,
yinyuefengyi at gmail dot com
Depends on: 105833
Target Milestone: ---
+++ This bug was initially created as a clone of Bug #105833 +++
Testcase from #105833
```
void foo();
static int b;
static int **c;
static int ***d = &c;
static int e = &d;
static char(a)(char g, int h) { return h >= 2 ? g : g << h; }
int main() {
**e == 0;
b = b ? 4 : 0;
if (!a(*e != 0, b))
foo();
}
```
For some reason (I Have not done any anlysis of why), using the C++ front-end
with the above does not get optimized by does when using the C front-end.
This does not seem like a regression either.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105833
[Bug 105833] [13 Regression] Dead Code Elimination Regression at -O2 (trunk vs.
12.1.0)
[Bug c++/108550] [10/11/12/13 Regression] the type 'const auto' of 'constexpr' variable is not literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108550
--- Comment #8 from Marek Polacek ---
Potential fix:
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -10355,6 +10355,7 @@ lookup_and_finish_template_variable (tree templ, tree
targs,
if (TMPL_PARMS_DEPTH (DECL_TEMPLATE_PARMS (templ)) == 1
&& !any_dependent_template_arguments_p (targs))
{
+ complain &= ~tf_partial;
var = finish_template_variable (var, complain);
mark_used (var);
}
but I need to think some more about it.
[Bug tree-optimization/108874] New: [10/11/12/13 Regression] Missing bswap detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108874
Bug ID: 108874
Summary: [10/11/12/13 Regression] Missing bswap detection
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
If we look at the arm testcases in gcc.target/arm/rev16.c
typedef unsigned int __u32;
__u32
__rev16_32_alt (__u32 x)
{
return (((__u32)(x) & (__u32)0xff00ff00UL) >> 8)
| (((__u32)(x) & (__u32)0x00ff00ffUL) << 8);
}
__u32
__rev16_32 (__u32 x)
{
return (((__u32)(x) & (__u32)0x00ff00ffUL) << 8)
| (((__u32)(x) & (__u32)0xff00ff00UL) >> 8);
}
we should be able to generate rev16 instructions for aarch64 (and arm) i.e.
recognise a __builtin_bswap16 essentially.
GCC fails to do so and generates:
__rev16_32_alt:
lsr w1, w0, 8
lsl w0, w0, 8
and w1, w1, 16711935
and w0, w0, -16711936
orr w0, w1, w0
ret
__rev16_32:
lsl w1, w0, 8
lsr w0, w0, 8
and w1, w1, -16711936
and w0, w0, 16711935
orr w0, w1, w0
ret
whereas clang manages to recognise it all into:
__rev16_32_alt: // @__rev16_32_alt
rev16 w0, w0
ret
__rev16_32: // @__rev16_32
rev16 w0, w0
ret
does the bswap pass need some tweaking perhaps?
Looks like this worked fine with GCC 5 but broke in the GCC 6 timeframe so
marking as a regression
[Bug c++/108873] Using the C++ front-end causes no DCE from happening
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108873 Andrew Pinski changed: What|Removed |Added Component|tree-optimization |c++ --- Comment #1 from Andrew Pinski --- For the C++ front-end: The statement/expression: **e == 0; Is not emitted to the gimple, meaning the following statements are not added: e.0_1 = e; _2 = *e.0_1; _3 = *_2; Which means evpr does see the above and then optimizing: _8 = _2 != 0B; as _2 cannot be a null ptr.
[Bug tree-optimization/108874] [10/11/12/13 Regression] Missing bswap detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108874
--- Comment #1 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #0)
> If we look at the arm testcases in gcc.target/arm/rev16.c
> typedef unsigned int __u32;
>
> __u32
> __rev16_32_alt (__u32 x)
> {
> return (((__u32)(x) & (__u32)0xff00ff00UL) >> 8)
> | (((__u32)(x) & (__u32)0x00ff00ffUL) << 8);
> }
>
> __u32
> __rev16_32 (__u32 x)
> {
> return (((__u32)(x) & (__u32)0x00ff00ffUL) << 8)
> | (((__u32)(x) & (__u32)0xff00ff00UL) >> 8);
> }
>
this isn't a simple __builtin_bswap16 as that returns a uint16_t, this is sort
of a __builtin_swap16 in each of the half-words of the u32
[Bug libbacktrace/108870] Gather file/line info for file/namespace/static variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108870 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #2 from Ian Lance Taylor --- Currently libbacktrace builds a mapping from compilation-unit PC ranges to line programs. This would be a completely different mapping, from variable addresses to variable information. As far as I know we would have to build it from a complete scan of the .debug_info section. Most programs don't need this information, so it would be a shame to always build it. Now I wish that there were some sort of options argument to backtrace_create_state. But actually backtrace_create_state does take a threaded argument that almost everybody passes as 0. The only non-zero cases I could find in a web search were passing 1. So we could redefine that as an option. Then programs that want variable information could pass 2 (or 3 for variables plus threading). With that option set, we can build a list of address mapping to variables. The next question would be whether we should unify the function and variable mapping or keep them separate. If we unify them we can use backtrace_pcinfo to get variable information. If we don't we should have another function that does variable lookup. It seems that the DWARF information does not include the size of the variable, so to really get this right we'll have to also use the size information from the symbol table, which is already available via backtrace_syminfo. Any thoughts on whether the function/variable mappings should be unified or distinct?
[Bug go/104290] [12/13 Regression] trunk 20220214 fails to build libgo on i686-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104290 --- Comment #33 from Ian Lance Taylor --- As far as I know nothing is waiting on me. Please let me know if you think otherwise.
[Bug middle-end/108854] tbb-2021.8.0 fails on i686-linux (32-bit), internal compiler error: in expand_expr_real_1, at expr.c:10281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108854 --- Comment #6 from davidak --- I tried to get the preprocessed source for the last 2 hours, but it does not end up in the build directory. Maybe Nix does some clean up at the end. I left a note in the downstream issue that they should provide you the files. The people at Intel should be more capable than me. Sorry
[Bug analyzer/108867] RFE: analyzer could suppress false positives by detecting functions that are likely missing __attribute__((noreturn))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108867 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Keywords||diagnostic --- Comment #1 from Eric Gallager --- Note that GCC already has -Wmissing-noreturn/-Wsuggest-attribute=noreturn as a regular warning flag; I'm guessing the analyzer would help provide improved accuracy with better analysis info, though?
[Bug c++/108422] [13 Regression] ICE: base pointer cycle detected since r13-2661-gb57abd072dd319a7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108422 Tobias Burnus changed: What|Removed |Added Priority|P1 |P3 --- Comment #5 from Tobias Burnus --- As discussed with richi on #gcc IRC: it shouldn't be P1 - and I could/should mark it as P3, which I now did. Reasoning: - With GCC 12, it compiles without an ICE but as with mainline with the patch in comment 4 applied, it will fail (segfault) at runtime (→ testcase in attachment 54491) - If being strict, nested target is not permitted - except with 'reverse offload', which fails in GCC 12 (sorry) as not supported. (Still, we should try to fix the ICE - but best instead of creating invalid code, either a sorry or working code would be good.)
[Bug analyzer/108867] RFE: analyzer could suppress false positives by detecting functions that are likely missing __attribute__((noreturn))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108867 --- Comment #2 from David Malcolm --- Yeah, IIRC -Wmissing-noreturn/-Wsuggest-attribute=noreturn work on a function that we have the implementation of, whereas I'm interested in handling the case where we *don't* have the source. If code paths after such a function tend to show UB based on something that was checked in a condition guarding the call to such a function and doesn't happen on the other path, then maybe such a function isn't meant to return. Perhaps if the function name contains the string "error", "fail" or "assert" with some capitalization also??? (ugly, I know)
[Bug fortran/96025] [10/11/12/13 Regression] ICE in expr_check_typed_help, at fortran/expr.c:5437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96025 --- Comment #10 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:6c1b825b3d6499dfeacf7c79dcf4b56a393ac204 commit r13-6265-g6c1b825b3d6499dfeacf7c79dcf4b56a393ac204 Author: Harald Anlauf Date: Mon Feb 20 21:28:09 2023 +0100 Fortran: improve checking of character length specification [PR96025] gcc/fortran/ChangeLog: PR fortran/96025 * parse.cc (check_function_result_typed): Improve type check of specification expression for character length and return status. (parse_spec): Use status from above. * resolve.cc (resolve_fntype): Prevent use of invalid specification expression for character length. gcc/testsuite/ChangeLog: PR fortran/96025 * gfortran.dg/pr96025.f90: New test.
[Bug fortran/108872] ICE in main_block_label, missing label when assigning a derived type whose component has a defined assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108872 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Last reconfirmed||2023-02-21 Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. All gcc versions tested (>=7) fail. Note that pr95613 is about invalid code, while the testcase in comment#0 appears to be valid Fortran.
[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329 yan12125 <49tbwddbqeazdawz at chyen dot cc> changed: What|Removed |Added CC||49tbwddbqeazdawz at chyen dot cc --- Comment #26 from yan12125 <49tbwddbqeazdawz at chyen dot cc> --- Thanks for the workaround in r13-2618-g723ef5a937dbab5e7a35761fd7f0ff0c76849340, I can confirm it fixes breakage with std::string. Could it be backported to the gcc-12 branch?
[Bug middle-end/108854] tbb-2021.8.0 fails on i686-linux (32-bit), internal compiler error: in expand_expr_real_1, at expr.c:10281
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108854 --- Comment #7 from Jakub Jelinek --- You can e.g. try to pass additional -freport-bug option, then the preprocessed source with command line and other important details should be stored into a /tmp/cc*.out file which the diagnostics will tell you which one it was.
[Bug c++/108873] Using the C++ front-end causes no DCE from happening
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108873 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Well, it doesn't have side-effects, so why would it be emitted? convert_to_void has: 1655 if (! TREE_SIDE_EFFECTS (expr)) 1656expr = void_node;
[Bug c/108875] New: Possible wrong error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108875
Bug ID: 108875
Summary: Possible wrong error message
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jankowski938 at gmail dot com
Target Milestone: ---
If the size of the integer differs from the function pointer size gcc emits
"error: initializer element is not constant". I think it is not the correct one
in this case.
Example code:
#define STACK_START 0x200
void reset_handler(void);
const uint64_t vector_table[] =
{
STACK_START,
(uint64_t)&reset_handler
};
void rest_handler(void)
{
}
It will compile for targets where inter type size is the same as the size of
the function pointer. Examples below:
godbolt.org/z/3cj97YzTd and godbolt.org/z/16YoK433r and godbolt.org/z/YoP9bx86a
[Bug c++/108873] Using the C++ front-end causes no DCE from happening
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108873 --- Comment #3 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #2) > Well, it doesn't have side-effects, so why would it be emitted? Even though the side effect of deferencing here can be optimized away, VRP can notice that *e will be non-null after the statement happens and then later on optimize the "*e != 0" expression to being always true. I am not saying this is an important testcase to optimize but we are starting to get some of these testcases where doing early DCE of unused expressions will not do other optimizations regression testcases too ...
[Bug c/22020] poor error message for invalid cast in constant initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22020 Andrew Pinski changed: What|Removed |Added CC||jankowski938 at gmail dot com --- Comment #6 from Andrew Pinski --- *** Bug 108875 has been marked as a duplicate of this bug. ***
[Bug c/108875] Possible wrong error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108875 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 22020. *** This bug has been marked as a duplicate of bug 22020 ***
[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105329 --- Comment #27 from Jonathan Wakely --- No, the new function requires exporting a new symbol from the shared library, which is not possible for the stable release branch.
[Bug target/108876] New: return address clobbered in sibcalls resulting in gfortran tests failing on xtensa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108876
Bug ID: 108876
Summary: return address clobbered in sibcalls resulting in
gfortran tests failing on xtensa
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jcmvbkbc at gcc dot gnu.org
Target Milestone: ---
A number of gfortran tests built with -O3 fail with segfault on call0 xtensa
config. E.g. gfortran.dg/allocate_with_source_5.f90
It fails because of the following sibcall code in the
__selectors_MOD_selector_init:
.L445:
l32ia0, sp, 300
l32ia2, sp, 192
l32ia4, sp, 204
l32ia12, sp, 296
l32ia13, sp, 292
l32ia14, sp, 288
l32ia15, sp, 284
movia0, 0x130
add.n sp, sp, a0
jx a4
RTL generated for this fragment initially looks like this:
(note 3983 3749 3975 121 NOTE_INSN_EPILOGUE_BEG)
(insn 3975 3983 3976 121 (set (reg:SI 0 a0)
(mem/c:SI (plus:SI (reg/f:SI 1 sp)
(const_int 300 [0x12c])) [31 S4 A32]))
"gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 -1
(nil))
(insn 3976 3975 3977 121 (set (reg:SI 12 a12)
(mem/c:SI (plus:SI (reg/f:SI 1 sp)
(const_int 296 [0x128])) [31 S4 A32]))
"gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 -1
(nil))
(insn 3977 3976 3978 121 (set (reg:SI 13 a13)
(mem/c:SI (plus:SI (reg/f:SI 1 sp)
(const_int 292 [0x124])) [31 S4 A32]))
"gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 -1
(nil))
(insn 3978 3977 3979 121 (set (reg:SI 14 a14)
(mem/c:SI (plus:SI (reg/f:SI 1 sp)
(const_int 288 [0x120])) [31 S4 A32]))
"gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 -1
(nil))
(insn 3979 3978 3980 121 (set (reg:SI 15 a15)
(mem/c:SI (plus:SI (reg/f:SI 1 sp)
(const_int 284 [0x11c])) [31 S4 A32]))
"gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 -1
(nil))
(insn 3980 3979 3981 121 (use (reg:SI 0 a0))
"gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 -1
(nil))
(insn 3981 3980 3982 121 (set (reg:SI 9 a9)
(const_int 304 [0x130]))
"gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 -1
(nil))
(insn 3982 3981 760 121 (set (reg/f:SI 1 sp)
(plus:SI (reg/f:SI 1 sp)
(reg:SI 9 a9)))
"gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 -1
(nil))
(call_insn/j 760 3982 761 121 (call (mem:SI (reg:SI 6 a6) [0 __builtin_free S4
A32])
(const_int 0 [0]))
"gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 discrim 1 106
{sibcall_internal}
(expr_list:REG_CALL_DECL (symbol_ref:SI ("free") [flags 0x41]
)
(expr_list:REG_EH_REGION (const_int 0 [0])
(nil)))
(expr_list:SI (use (reg:SI 2 a2))
(nil)))
but then in the rnreg pass it is changed to the following:
(note 3983 3749 3975 121 NOTE_INSN_EPILOGUE_BEG)
(insn 3975 3983 3976 121 (set (reg:SI 0 a0)
(mem/c:SI (plus:SI (reg/f:SI 1 sp)
(const_int 300 [0x12c])) [31 S4 A32]))
"gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 53
{movsi_internal}
(nil))
(insn 3976 3975 3977 121 (set (reg:SI 12 a12)
(mem/c:SI (plus:SI (reg/f:SI 1 sp)
(const_int 296 [0x128])) [31 S4 A32]))
"gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 53
{movsi_internal}
(nil))
(insn 3977 3976 3978 121 (set (reg:SI 13 a13)
(mem/c:SI (plus:SI (reg/f:SI 1 sp)
(const_int 292 [0x124])) [31 S4 A32]))
"gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 53
{movsi_internal}
(nil))
(insn 3978 3977 3979 121 (set (reg:SI 14 a14)
(mem/c:SI (plus:SI (reg/f:SI 1 sp)
(const_int 288 [0x120])) [31 S4 A32]))
"gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 53
{movsi_internal}
(nil))
(insn 3979 3978 3980 121 (set (reg:SI 15 a15)
(mem/c:SI (plus:SI (reg/f:SI 1 sp)
(const_int 284 [0x11c])) [31 S4 A32]))
"gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 53
{movsi_internal}
(nil))
(insn 3980 3979 3981 121 (use (reg:SI 0 a0))
"gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 -1
(expr_list:REG_DEAD (reg:SI 0 a0)
(nil)))
(insn 3981 3980 3982 121 (set (reg:SI 0 a0)
(const_int 304 [0x130]))
"gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 53
{movsi_internal}
(nil))
(insn 3982 3981 760 121 (set (reg/f:SI 1 sp)
(plus:SI (reg/f:SI 1 sp)
(reg:SI 0 a0)))
"gcc/testsuite/gfortran.dg/allocate_with_source_5.f90":35:30 1 {addsi3}
(expr_list:REG_DEAD (reg:SI 9 a9)
(nil)))
(call_insn/j 760 3982 761 121 (call (mem:SI (reg:SI 4 a4) [0 __builtin_free S4
A32])
[Bug rtl-optimization/106041] [12/13 Regression] infinite loop in fast_dce at -O1 with aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106041
--- Comment #11 from Richard Biener ---
Created attachment 54503
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54503&action=edit
reduced testcase
Reduced testcase (on the GCC 12 branch). Reduced with -O1 and
diff --git a/gcc/dce.cc b/gcc/dce.cc
index 6676cbcd429..8af54a96394 100644
--- a/gcc/dce.cc
+++ b/gcc/dce.cc
@@ -36,6 +36,7 @@ along with GCC; see the file COPYING3. If not see
#include "tree-pass.h"
#include "dbgcnt.h"
#include "rtl-iter.h"
+#include "diagnostic-core.h"
/* -
@@ -1103,9 +1104,13 @@ fast_dce (bool word_level)
dead_debug_global_init (&global_debug, NULL);
+ unsigned iters = 0;
while (global_changed)
{
global_changed = false;
+ ++iters;
+ if (iters > 50)
+ internal_error ("too many iterations");
for (i = 0; i < n_blocks; i++)
{
[Bug rtl-optimization/106041] [12/13 Regression] infinite loop in fast_dce at -O1 with aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106041 Richard Biener changed: What|Removed |Added Keywords|needs-reduction | Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-02-21 --- Comment #12 from Richard Biener --- The reduced testcase doesn't fail on the trunk (but I lack preprocessed source for trunk to re-reduce it). The unreduced testcase doesn't build on trunk due to standard library header portability issues. The reduced testcase is very small - two BBs, one BB with an infinite cycle and no path to exit.
[Bug rtl-optimization/106041] [12/13 Regression] infinite loop in fast_dce at -O1 with aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106041 --- Comment #13 from Andrew Pinski --- (insn 42 41 43 3 (clobber (reg/v:V4x1DF 40 v8 [orig:96 tup ] [96])) -1 (nil))
[Bug rtl-optimization/106041] [12/13 Regression] infinite loop in fast_dce at -O1 with aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106041 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=108681 --- Comment #14 from Andrew Pinski --- (In reply to Richard Biener from comment #12) > The reduced testcase doesn't fail on the trunk (but I lack preprocessed > source for trunk to re-reduce it). The unreduced testcase doesn't build on > trunk due to standard library header portability issues. > > The reduced testcase is very small - two BBs, one BB with an infinite cycle > and no path to exit. I suspect this is a dup of bug 108681
[Bug rtl-optimization/106041] [12/13 Regression] infinite loop in fast_dce at -O1 with aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106041 --- Comment #15 from Andrew Pinski --- (In reply to Richard Biener from comment #12) > The reduced testcase doesn't fail on the trunk Most likely because it was fixed when PR 108681 was fixed .
[Bug rtl-optimization/106041] [12/13 Regression] infinite loop in fast_dce at -O1 with aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106041 --- Comment #16 from Andrew Pinski --- (In reply to Richard Biener from comment #11) > Created attachment 54503 [details] > reduced testcase This reduced testcase looks almost the same as the reduced testcase in bug 108681 comment #4 (when comparing the gimple at optimized stage).
[Bug d/108877] New: Explicit immutable struct import internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108877
Bug ID: 108877
Summary: Explicit immutable struct import internal compiler
error
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: belka at caraus dot de
Target Milestone: ---
We have 2 files. util/Version.d:
```
module util.Version;
immutable struct Ver
{
}
```
and the main file:
```
import util.Version : Ver;
```
Compiling with „gdc-12 -c util/Version.d version_test.d“ results in the error:
> version_test.d:1:8: internal compiler error: in make_import, at
> d/imports.cc:48
> 1 | import util.Version : Ver;
> |^
> 0x1bc1e87 internal_error(char const*, ...)
> ???:0
> 0x7d27f3 fancy_abort(char const*, int, char const*)
> ???:0
> 0x9d4214 ImportVisitor::visit(AggregateDeclaration*)
> ???:0
> 0x9d3cfe build_import_decl(Dsymbol*)
> ???:0
> 0x9ca0ff DeclVisitor::visit(Import*)
> ???:0
> 0x9c70a6 build_decl_tree(Dsymbol*)
> ???:0
> 0x9d6fc0 build_module_tree(Module*)
> ???:0
> 0x9c9f4b DeclVisitor::visit(Module*)
> ???:0
> 0x9c70a6 build_decl_tree(Dsymbol*)
> ???:0
> Please submit a full bug report, with preprocessed source (by using
> -freport-bug).
> Please include the complete backtrace with any bug report.
> See
