[Bug target/108322] Using __restrict parameter with -ftree-vectorize (default with -O2) results in massive code bloat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108322
Richard Biener changed:
What|Removed |Added
Blocks||53947
Ever confirmed|0 |1
Last reconfirmed||2023-01-10
Status|UNCONFIRMED |NEW
CC||rguenth at gcc dot gnu.org
--- Comment #4 from Richard Biener ---
The vectorizer vectorizes this with a strided store, costing
*pSrc_16 1 times unaligned_load (misalign -1) costs 12 in body
_1 16 times scalar_store costs 192 in body
_1 16 times vec_to_scalar costs 64 in body
t.c:8:44: note: operating only on full vectors.
t.c:8:44: note: Cost model analysis:
Vector inside of loop cost: 268
Vector prologue cost: 0
Vector epilogue cost: 0
Scalar iteration cost: 24
Scalar outside cost: 0
Vector outside cost: 0
prologue iterations: 0
epilogue iterations: 0
Calculated minimum iters for profitability: 0
now later forwprop figures it can replace the element extracts from the
vector load with scalar loads which then results in effective unrolling
of the loop by a factor of 16.
The vectorizer misses the fact that w/o SSE 4.1 it cannot do efficient
lane extracts. With SSE 4.1 and disabling the forwprop you'd get
.L3:
movdqu (%rsi), %xmm0
addq$16, %rsi
addq$32, %rax
pextrb $0, %xmm0, -32(%rax)
pextrb $1, %xmm0, -30(%rax)
pextrb $2, %xmm0, -28(%rax)
pextrb $3, %xmm0, -26(%rax)
pextrb $4, %xmm0, -24(%rax)
pextrb $5, %xmm0, -22(%rax)
pextrb $6, %xmm0, -20(%rax)
pextrb $7, %xmm0, -18(%rax)
pextrb $8, %xmm0, -16(%rax)
pextrb $9, %xmm0, -14(%rax)
pextrb $10, %xmm0, -12(%rax)
pextrb $11, %xmm0, -10(%rax)
pextrb $12, %xmm0, -8(%rax)
pextrb $13, %xmm0, -6(%rax)
pextrb $14, %xmm0, -4(%rax)
pextrb $15, %xmm0, -2(%rax)
cmpq%rdx, %rsi
jne .L3
which is what the vectorizer thinks is going to be generated. But with
just SSE2 we are spilling to memory for the lane extract.
For the case at hand loading two vectors from the destination and then
punpck{h,l}bw and storing them again might be the most efficient thing
to do here.
On the cost model side 'vec_to_scalar' is ambiguous, the x86 backend
tries to compensate with
/* If we do elementwise loads into a vector then we are bound by
latency and execution resources for the many scalar loads
(AGU and load ports). Try to account for this by scaling the
construction cost by the number of elements involved. */
if ((kind == vec_construct || kind == vec_to_scalar)
&& stmt_info
&& (STMT_VINFO_TYPE (stmt_info) == load_vec_info_type
|| STMT_VINFO_TYPE (stmt_info) == store_vec_info_type)
&& STMT_VINFO_MEMORY_ACCESS_TYPE (stmt_info) == VMAT_ELEMENTWISE
&& TREE_CODE (DR_STEP (STMT_VINFO_DATA_REF (stmt_info))) != INTEGER_CST)
{
stmt_cost = ix86_builtin_vectorization_cost (kind, vectype, misalign);
stmt_cost *= (TYPE_VECTOR_SUBPARTS (vectype) + 1);
}
but that doesn't trigger here because the step is constant two.
RTL expansion will eventually use the vec_extract optab and that succeeds
even for SSE2 by spilling, so it isn't useful to query support:
void
ix86_expand_vector_extract (bool mmx_ok, rtx target, rtx vec, int elt)
{
...
if (use_vec_extr)
{
...
}
else
{
rtx mem = assign_stack_temp (mode, GET_MODE_SIZE (mode));
emit_move_insn (mem, vec);
tmp = adjust_address (mem, inner_mode, elt*GET_MODE_SIZE (inner_mode));
emit_move_insn (target, tmp);
}
}
the fallback is eventually done by RTL expansion anyway.
Note fixing that and querying vec_extract support (the vectorizer doesn't
do that - it relies on expands fallback here but could do better costing
and also generate a single spill slot rather than one for each extract).
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug target/108348] ICE in gen_movoo, at config/rs6000/mma.md:292
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
--- Comment #2 from Kewen Lin ---
This is a 32 bit specific issue, the function rs6000_pass_by_reference has:
/* Allow -maltivec -mabi=no-altivec without warning. Altivec vector
modes only exist for GCC vector types if -maltivec. */
if (TARGET_32BIT && !TARGET_ALTIVEC_ABI && ALTIVEC_VECTOR_MODE (arg.mode))
{
if (TARGET_DEBUG_ARG)
fprintf (stderr, "function_arg_pass_by_reference: AltiVec\n");
return 1;
}
It assumes that the altivec is on when we see those altivec vector modes, but
it doesn't hold with the option combination for this case. It returns true for
rs6000_pass_by_reference, then the following logic of generic code tries to
make a copy of the object and pass the address to the function being called, it
invokes store_expr for storing to the copy, then triggers ICE.
And targetm.calls.function_arg is too late to raise the errors.
[Bug c++/108321] [13 regression] g++.dg/contracts/contracts-tmpl-spec2.C fails after r13-4160-g2efb237ffc68ec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108321 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- so fixed
[Bug c++/108321] [13 regression] g++.dg/contracts/contracts-tmpl-spec2.C fails after r13-4160-g2efb237ffc68ec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108321 Richard Biener changed: What|Removed |Added Keywords||testsuite-fail Target Milestone|--- |13.0
[Bug target/108316] [13 Regression] ICE in maybe_gen_insn via expand_SCATTER_STORE when vectorizing for SVE since r13-2737-g4a773bf2f08656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108316 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/108314] [13 Regression] Segfault in gimple-match-head.cc:do_valueize when vectorizing for SVE since r13-707-g68e0063397ba82
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108314 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- I will have a look.
[Bug c++/101687] Scoped enumerators of a member enumeration shall not be referred by a class member access expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101687 Andrew Pinski changed: What|Removed |Added Status|NEW |SUSPENDED --- Comment #4 from Andrew Pinski --- Suspending as the defect report is still considered open but is in the process of drafting: https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2557
[Bug c++/101687] Scoped enumerators of a member enumeration shall not be referred by a class member access expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101687 --- Comment #3 from jim x --- I think CWG2557 is clear with this aspect https://cplusplus.github.io/CWG/issues/2557.html
[Bug target/108339] [11/10 only] riscv64-linux-gnu: fails to link libgcc_s.so on the GCC 10 branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108339 --- Comment #3 from Matthias Klose --- thanks for the pointer. The GCC 11 branch already has the backport.
[Bug target/108348] ICE in gen_movoo, at config/rs6000/mma.md:292
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348 Kewen Lin changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org Last reconfirmed||2023-01-10 Target Milestone|--- |13.0 CC||linkw at gcc dot gnu.org --- Comment #1 from Kewen Lin --- Thanks for reporting, confirmed! Since ppc64le is with 64 bit configuration, it rejects -m32. But this can be reproduced on ppc64 with option: -m32 -mcpu=power10 -mno-altivec Investigating.
[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240 --- Comment #6 from Kewen Lin --- (In reply to Kewen Lin from comment #5) > (In reply to Segher Boessenkool from comment #4) > > (In reply to Kewen Lin from comment #3) > > > With the culprit commit r13-4894, we always implicitly enable powerpc64 > > > for > > > both explicit and implicit 64 bit, it's the same as before for the > > > explicit > > > 64 bit case, but for the implicit 64 bit case, there is no chance for the > > > used cpu to unset powerpc64 (like this case). To keep it consistent with > > > the > > > previous, the fix can be to only enable powerpc64 implicitly for explicit > > > 64 > > > bit, while let it be for implicit 64 bit. > > > > No? If the user says to use a CPU without 64-bit instructions, while the > > user also says we require 64-bit insns (via -m64), we should just error. > > But both the previous behavior (before r13-4894) and the current behavior > (starting from r13-4894) honour the given explicit -m64, it would always > enable -mpowerpc64 at the same time without any errors/warnings. > It's implied that when the user explicitly specify -m64, the handlings would neglect the impact of CPU, I'm not sure if it's intentional but the reason probably is that the underlying CPU is actually 64 bit in most cases, so make -m64 win and the compilation can go forward. If we change the behavior to error for both explicit and implicit 64 bit, some compilations which worked in the past can start to fail (though it's arguable that it's expected). Note that for implicit 64 bit and no powerpc64, we gets errors on Linux but just warnings on darwin/aix (maybe more fallouts come out on them). So considering the current release phase, I'm inclined to just make it consistent with the previous, and try to adjust the behavior (as Segher's proposal) in next release.
[Bug target/108272] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:339
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108272 --- Comment #5 from Arseny Solokha --- (In reply to Kewen Lin from comment #4) > Yes, please file a new one. Thanks again. I've filed PR108348 for that.
[Bug target/108348] New: ICE in gen_movoo, at config/rs6000/mma.md:292
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108348
Bug ID: 108348
Summary: ICE in gen_movoo, at config/rs6000/mma.md:292
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: powerpc-*-linux-gnu
gcc 13.0.0 20230108 snapshot (g:e3a4bd0bbdccdde0cff85f93064b01a44fb10d2a) ICEs
when compiling gcc/testsuite/gcc.target/powerpc/pr96506-1.c w/ -m32 for a
target w/o MMA support:
% powerpc-e300c3-linux-gnu-gcc-13 -m32 -c
gcc/testsuite/gcc.target/powerpc/pr96506-1.c
during RTL pass: expand
gcc/testsuite/gcc.target/powerpc/pr96506-1.c: In function 'foo0':
gcc/testsuite/gcc.target/powerpc/pr96506-1.c:20:3: internal compiler error: in
gen_movoo, at config/rs6000/mma.md:292
20 | bar0 (v); /* { dg-error "invalid use of MMA operand of type
.__vector_pair. as a function parameter" } */
| ^~~~
0x78e467 gen_movoo(rtx_def*, rtx_def*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20230108/work/gcc-13-20230108/gcc/config/rs6000/mma.md:292
0xa8cfa7 rtx_insn* insn_gen_fn::operator()(rtx_def*,
rtx_def*) const
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20230108/work/gcc-13-20230108/gcc/recog.h:407
0xa8cfa7 emit_move_insn_1(rtx_def*, rtx_def*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20230108/work/gcc-13-20230108/gcc/expr.cc:4172
0xa8d3af emit_move_insn(rtx_def*, rtx_def*)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20230108/work/gcc-13-20230108/gcc/expr.cc:4342
0xa9573e store_expr(tree_node*, rtx_def*, int, bool, bool)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20230108/work/gcc-13-20230108/gcc/expr.cc:6522
0x9461fb initialize_argument_information
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20230108/work/gcc-13-20230108/gcc/calls.cc:1463
0x9461fb expand_call(tree_node*, rtx_def*, int)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20230108/work/gcc-13-20230108/gcc/calls.cc:2969
0xa895af expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20230108/work/gcc-13-20230108/gcc/expr.cc:11875
0x95da58 expand_expr
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20230108/work/gcc-13-20230108/gcc/expr.h:310
0x95da58 expand_call_stmt
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20230108/work/gcc-13-20230108/gcc/cfgexpand.cc:2831
0x95da58 expand_gimple_stmt_1
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20230108/work/gcc-13-20230108/gcc/cfgexpand.cc:3880
0x95da58 expand_gimple_stmt
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20230108/work/gcc-13-20230108/gcc/cfgexpand.cc:4044
0x96322e expand_gimple_basic_block
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20230108/work/gcc-13-20230108/gcc/cfgexpand.cc:6096
0x964d57 execute
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-13.0.0_p20230108/work/gcc-13-20230108/gcc/cfgexpand.cc:6822
[Bug target/108272] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:339
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108272 --- Comment #4 from Kewen Lin --- (In reply to Arseny Solokha from comment #3) > (In reply to Kewen Lin from comment #2) > > Created attachment 54192 [details] > > untested patch > > > > Hi @Arseny, I hope this patch can help to clear all the ICEs about > > unexpected uses of MMA opaque types in inline asm, that is to filter those > > noises duplicated to this bug. > > Indeed, I haven't seen such ICEs w/ the patch applied so far. Still get an > ICE in gen_movoo, at config/rs6000/mma.md:292 when compiling > gcc/testsuite/gcc.target/powerpc/pr96506-1.c w/ -m32, though. Do you want me > to file another PR for that one? Thanks @Arseny! Yes, please file a new one. Thanks again.
[Bug modula2/108142] Many empty directories created in the build directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108142 --- Comment #7 from Gaius Mulley --- Updated patch posted to list.
[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240 --- Comment #5 from Kewen Lin --- (In reply to Segher Boessenkool from comment #4) > (In reply to Kewen Lin from comment #3) > > With the culprit commit r13-4894, we always implicitly enable powerpc64 for > > both explicit and implicit 64 bit, it's the same as before for the explicit > > 64 bit case, but for the implicit 64 bit case, there is no chance for the > > used cpu to unset powerpc64 (like this case). To keep it consistent with the > > previous, the fix can be to only enable powerpc64 implicitly for explicit 64 > > bit, while let it be for implicit 64 bit. > > No? If the user says to use a CPU without 64-bit instructions, while the > user also says we require 64-bit insns (via -m64), we should just error. But both the previous behavior (before r13-4894) and the current behavior (starting from r13-4894) honour the given explicit -m64, it would always enable -mpowerpc64 at the same time without any errors/warnings. > Not hide the problem (and cause many more problems!) > The behavior change is for the case without any explicit -m64 but the TARGET_DEFAULT has 64 bit set (implicit -m64). And yes, different from the previous behavior, the current behavior hides the error/warning and force the -mpower64, so I posted one patch at: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609492.html It would allow that powerpc64 gets unset if the user says to use a CPU without 64-bit instructions and with implicit 64 bit.
[Bug tree-optimization/106878] [11/12 Regression] ICE: verify_gimple failed at -O2 with pointers and bitwise calculation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106878 vvinayag at arm dot com changed: What|Removed |Added CC||vvinayag at arm dot com --- Comment #13 from vvinayag at arm dot com --- Will this fix be backported to GCC 12 and GCC 11 ?
[Bug modula2/108261] modula-2 module registration process seems to fail with shared libraries.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261 --- Comment #10 from Iain Sandoe --- Initial questions (still digesting the remainder). when a module has the same name but a different interface are the symbols distinct (i.e. mangled differently)? If not: - then I can see how it works with static archives - because the static linker picks the first one presented. - but multiple shared libraries in the same process, with the same symbol in them would seem to be challenging (I'm not sure how the various dynamic loaders would behave - i.e. the load order might not be sufficient?). If they are: - we could still build a monolithic library; it is up to the FE (presumably in conjunction with the include paths) to ensure that it references the symbol that is relevant to the interface style (iso/pim) chosen.
[Bug c++/108347] Incorrect error: ambiguous template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108347 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > Created attachment 54223 [details] > testcase that removes the C++17isms and convert it over to C++11 The reason why I did this is because I wanted to see if older versions of GCC rejected this code and they do in a similar fashion. (MSVC still ICEs).
[Bug c++/108347] Incorrect error: ambiguous template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108347 --- Comment #2 from Andrew Pinski --- Created attachment 54223 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54223=edit testcase that removes the C++17isms and convert it over to C++11
[Bug c++/108347] Incorrect error: ambiguous template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108347 --- Comment #1 from Andrew Pinski --- Well MSVC has an internal compiler error with this code.
[Bug c++/105838] [10/11/12/13 Regression] g++ 12.1.0 runs out of memory or time when building const std::vector of std::strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105838 --- Comment #21 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:01ea66a6c56e53163d9430f4d87615d570848aa8 commit r13-5075-g01ea66a6c56e53163d9430f4d87615d570848aa8 Author: Jakub Jelinek Date: Mon Jan 9 23:41:20 2023 +0100 c++: Only do maybe_init_list_as_range optimization if !processing_template_decl [PR108047] The last testcase in this patch ICEs, because maybe_init_list_as_range -> maybe_init_list_as_array calls maybe_constant_init in: /* Don't do this if the conversion would be constant. */ first = maybe_constant_init (first); if (TREE_CONSTANT (first)) return NULL_TREE; but maybe_constant_init shouldn't be called when processing_template_decl. While we could replace that call with fold_non_dependent_init, my limited understanding is that this is an optimization and even if we don't optimize it when processing_template_decl, build_user_type_conversion_1 will be called again during instantiation with !processing_template_decl if it is every instantiated and we can do the optimization only then. 2023-01-09 Jakub Jelinek PR c++/105838 PR c++/108047 PR c++/108266 * call.cc (maybe_init_list_as_range): Always return NULL_TREE if processing_template_decl. * g++.dg/tree-ssa/initlist-opt2.C: New test. * g++.dg/tree-ssa/initlist-opt3.C: New test.
[Bug c++/108266] [13 Regression] ICE during cxx_eval_constant_expression on IMPLICIT_CONV_EXPR since r13-4564
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108266 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:01ea66a6c56e53163d9430f4d87615d570848aa8 commit r13-5075-g01ea66a6c56e53163d9430f4d87615d570848aa8 Author: Jakub Jelinek Date: Mon Jan 9 23:41:20 2023 +0100 c++: Only do maybe_init_list_as_range optimization if !processing_template_decl [PR108047] The last testcase in this patch ICEs, because maybe_init_list_as_range -> maybe_init_list_as_array calls maybe_constant_init in: /* Don't do this if the conversion would be constant. */ first = maybe_constant_init (first); if (TREE_CONSTANT (first)) return NULL_TREE; but maybe_constant_init shouldn't be called when processing_template_decl. While we could replace that call with fold_non_dependent_init, my limited understanding is that this is an optimization and even if we don't optimize it when processing_template_decl, build_user_type_conversion_1 will be called again during instantiation with !processing_template_decl if it is every instantiated and we can do the optimization only then. 2023-01-09 Jakub Jelinek PR c++/105838 PR c++/108047 PR c++/108266 * call.cc (maybe_init_list_as_range): Always return NULL_TREE if processing_template_decl. * g++.dg/tree-ssa/initlist-opt2.C: New test. * g++.dg/tree-ssa/initlist-opt3.C: New test.
[Bug c++/108047] [13 Regression] ICE: unexpected expression of kind implicit_conv_expr since r13-4564-gd081807d8d70e3e8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108047 --- Comment #11 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:01ea66a6c56e53163d9430f4d87615d570848aa8 commit r13-5075-g01ea66a6c56e53163d9430f4d87615d570848aa8 Author: Jakub Jelinek Date: Mon Jan 9 23:41:20 2023 +0100 c++: Only do maybe_init_list_as_range optimization if !processing_template_decl [PR108047] The last testcase in this patch ICEs, because maybe_init_list_as_range -> maybe_init_list_as_array calls maybe_constant_init in: /* Don't do this if the conversion would be constant. */ first = maybe_constant_init (first); if (TREE_CONSTANT (first)) return NULL_TREE; but maybe_constant_init shouldn't be called when processing_template_decl. While we could replace that call with fold_non_dependent_init, my limited understanding is that this is an optimization and even if we don't optimize it when processing_template_decl, build_user_type_conversion_1 will be called again during instantiation with !processing_template_decl if it is every instantiated and we can do the optimization only then. 2023-01-09 Jakub Jelinek PR c++/105838 PR c++/108047 PR c++/108266 * call.cc (maybe_init_list_as_range): Always return NULL_TREE if processing_template_decl. * g++.dg/tree-ssa/initlist-opt2.C: New test. * g++.dg/tree-ssa/initlist-opt3.C: New test.
[Bug c++/108347] New: Incorrect error: ambiguous template instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108347 Bug ID: 108347 Summary: Incorrect error: ambiguous template instantiation Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: CoachHagins at gmail dot com Target Milestone: --- Created attachment 54222 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54222=edit C++ source - no include directives The attached code is a single .cpp file, as it contains no #include directives. I have also posted on compiler explorer here: https://godbolt.org/z/jjEPKdx8Y The code compiles fine with all versions of clang from 7 up through the latest branch on CE. The code FAILS to compile with gcc, all versions from 7 up through the latest branch on CE. There are THREE #defines in the included code, which provide three different "fixes" to make the code compile. The command g++ -std=c++17 -DFIX0=0 -DFIX1=0 -DFIX2=0 will fail to compile with an ambiguous template instantiation error. However, all of the following will allow the code to compile. Hopefully, the various "fixes" will help identify the underlying issue(s). g++ -std=c++17 -DFIX0=0 -DFIX1=0 -DFIX2=1 g++ -std=c++17 -DFIX0=0 -DFIX1=1 -DFIX2=0 g++ -std=c++17 -DFIX0=0 -DFIX1=1 -DFIX2=1 g++ -std=c++17 -DFIX0=1 -DFIX1=0 -DFIX2=0 g++ -std=c++17 -DFIX0=1 -DFIX1=0 -DFIX2=1 g++ -std=c++17 -DFIX0=1 -DFIX1=1 -DFIX2=0 g++ -std=c++17 -DFIX0=1 -DFIX1=1 -DFIX2=1
[Bug modula2/108261] modula-2 module registration process seems to fail with shared libraries.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261
--- Comment #9 from Gaius Mulley ---
I wonder if:
0. change link array to contain elements of
{ char *name, (*fn) module_init, (*fn) module_fini }.
1. add new option for gm2 -flibname=foo when creating libraries.
libname is buried inside the object.
So we can build:
gm2 -o iso/Storage.o ../iso/Storage.mod -flibname=iso
build libiso from iso/*
gm2 -o pim/Storage.o ../pim/Storage.mod -flibname=pim
build libpim from pim/*
2. change the per module ctor to pass the libname in the call to
M2RTS_RegisterModule (modname, libname: ADDRESS;
init, fini: ArgCVEnvP;
dependencies: PROC) ;
3. change M2RTS.def/mod:
ConstructModules (applicationmodule, flibs: ADDRESS;
argc: INTEGER; argv, envp: ADDRESS) ;
4. driver passes -flibs=pim,iso,etc to cc1gm2
cc1gm2 emeddeds this string into the main when constructing
scaffold and call M2RTS_ConstructModules with the string
-flibs=... as the extra parameter.
5. M2RTS_ConstructModules uses (in order):
(a) contents of link array (if it exists) as a dictionary
lookup based on name -> init function.
(b) if the module name does not exist in the link array then
it chooses the module which has registered itself and
whose libname is earliest on the flibs path.
the driver will have to link the libraries in flibs order to
choose the dialect specific module versions.
6. I think we have to retain the m2pimlib.a m2isolib.a as there are
a few modules with the same name but different interface
(Storage). However as you mentioned we could split them:
-lm2pim -lm2iso -lm2common. In part this is how they were
designed (but never split up). There are a number of rtName
(runtime) modules: rtCo, rtEntity etc and these could be expanded
as required to provide a better layered approach. The rt modules
were never expected to be presented to users.
I'm encouraged that -fscaffold-static fixes the shared library usage.
-fscaffold-static is in effect a similar solution to (0) above.
[Bug libstdc++/77691] [10/11/12/13 regression] experimental/memory_resource/resource_adaptor.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691 --- Comment #56 from dave.anglin at bell dot net --- On 2023-01-09 6:20 a.m., redi at gcc dot gnu.org wrote: > Maybe like this. Actually, the change i sent was for libstdc++-v3/testsuite/experimental/memory_resource/new_delete_resource.cc. It still fails. No objection to the approach.
[Bug analyzer/108252] false positive: leak detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108252 --- Comment #2 from David Malcolm --- Created attachment 54221 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54221=edit Reduced reproducer Reproduces with trunk, with -fanalyzer: https://godbolt.org/z/x15xdYa57
[Bug tree-optimization/108199] Bitfields, unions and SRA and storage_order_attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199 --- Comment #11 from Eric Botcazou --- > Here is a testcase for the trunk on x86_64-linux-gnu: Thanks. The problem is indeed the BIT_FIELD_REF of a scalar, which is an undocumented extension of GENERIC: /* Reference to a group of bits within an object. Similar to COMPONENT_REF except the position is given explicitly rather than via a FIELD_DECL. Operand 0 is the structure or union expression; operand 1 is a tree giving the constant number of bits being referenced; operand 2 is a tree giving the constant position of the first referenced bit. The result type width has to match the number of bits referenced. If the result type is integral, its signedness specifies how it is extended to its mode width. */ DEFTREECODE (BIT_FIELD_REF, "bit_field_ref", tcc_reference, 3) How are the bits numbered in there, IOW is bit 0 always the LSB or not?
[Bug analyzer/108252] false positive: leak detection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108252 David Malcolm changed: What|Removed |Added Last reconfirmed||2023-01-09 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- Thanks for filing this bug; confirmed. I'm working on minimizing the reproducer.
[Bug c++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108342 --- Comment #12 from Rui Oliveira --- (In reply to Jakub Jelinek from comment #11) > No, if you have the packed ph_fcomplex_t not aligned at alignof (float), you > need > to copy it to a properly aligned variable before trying to reinterpret_cast > it. Some `if constexpr` comparing of the remainder between alignof(std::complex) and (alignof(bb_frame_t) + offsetof(bb_iq_samples)) could perhaps make one avoid that. But that's just a side idea to think of. Main point is, the code is de-serializing a serial stream. I do not expect to find the "magic" word at the right aligment for `bb_frame_t` anyway, so generous memcpy'ing to properly aligned variables will be required anyway.
[Bug c++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108342
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #11 from Jakub Jelinek ---
(In reply to Rui Oliveira from comment #10)
> So my options are to create like a placeholder, say
>
> ```c
> typedef struct __attribute__((__packed__)) // Packed isn't really necessary
> here I think?
> {
> float re, im;
> } ph_fcomplex_t
>
> ```
>
> To silence the warning and get packing to work, and trust
> [complex.numbers.general] for a reinterpret_cast into std::complex I
> guess.
No, if you have the packed ph_fcomplex_t not aligned at alignof (float), you
need
to copy it to a properly aligned variable before trying to reinterpret_cast it.
[Bug c++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108342
--- Comment #10 from Rui Oliveira ---
So my options are to create like a placeholder, say
```c
typedef struct __attribute__((__packed__)) // Packed isn't really necessary
here I think?
{
float re, im;
} ph_fcomplex_t
```
To silence the warning and get packing to work, and trust
[complex.numbers.general] for a reinterpret_cast into std::complex I
guess.
[Bug modula2/108182] gm2 driver mishandles target and multilib options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182
Iain Sandoe changed:
What|Removed |Added
Attachment #54184|0 |1
is obsolete||
Attachment #54208|0 |1
is obsolete||
Attachment #54214|0 |1
is obsolete||
--- Comment #11 from Iain Sandoe ---
Created attachment 54220
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54220=edit
patch version 3.1
This is patch v3 + some specific changes. [hence it is 3.1 :) ]
The main issues with v3 (and v4 on PR108261) are:
- link items are positional (you need to ensure that the runtime libraries
appear after the user's objects).
- adding {f*} to the cc1gm2 line causes f options to be duplicated, this could
(potentially alter the behaviour of the command line when final values of
opposite switches are used - which is the 'usual' mechanism).
- V3 was still adding the '-L' options for the various libraries which are not
needed (v4 fixes this, but not the other issues)
- Supporting the target's ability to handle -Bstatic/dynamic in specs is going
to be hard.
so ...
1. we use the specs now to insert the include paths; this works very nicely.
2. we use the existing sequencing the language-driver to ensure that the link
positional arguments are in the right places (and to handle the Bstatic/dynamic
stuff)
3. We remove the {f*} from the cc1gm2 spec [note it is possible that other
similar entries will cause duplication of their content .. I did not check
this yet]
This means that we can drop the linker-related extra specs and code (and
actually simplify things a bit in the lang-specific driver).
4. We skip options that we will re-insert to avoid duplication there too.
-
NOTE: with specs, it is usually necessary to ensure that they being and/or end
with whitespace because they can be arbitrarily concatenated.
-
This does not fix PR108261 (neither does v4, FWIW) on Darwin.
[Bug tree-optimization/108199] Bitfields, unions and SRA and storage_order_attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #10 from Andrew Pinski ---
Here is a testcase for the trunk on x86_64-linux-gnu:
```
#define BITFIELD_ENDIAN "big-endian"
#define SRC_ENDIAN "big-endian"
#define DST_ENDIAN "big-endian"
typedef unsigned long long u64;
union DST {
unsigned long val;
struct {
u64 x : 1;
u64 y : 1;
u64 r: 62;
} __attribute__((scalar_storage_order("big-endian")));
} __attribute__((scalar_storage_order("big-endian")));
struct SRC {
u64 a;
} __attribute__((scalar_storage_order("big-endian")));
[[gnu::noipa]]
void foo (){__builtin_abort();}
[[gnu::noinline]]
int bar(struct SRC *src)
{
union DST dst;
dst.val = src->a;
if (dst.y) {
foo();
}
return 0;
}
int main(void)
{
struct SRC t = {-1ull & (~(0x01ull<<62))};
bar();
return 0;
}
```
It does not cause an abort at -O0 but does at -O2.
[Bug middle-end/69482] Writing through pointers to volatile not always preserved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69482 Daniel Boles changed: What|Removed |Added CC||dboles.src at gmail dot com --- Comment #12 from Daniel Boles --- Is this the same cause as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71793 ? Thanks!
[Bug tree-optimization/108199] Bitfields, unions and SRA and storage_order_attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199 Eric Botcazou changed: What|Removed |Added Status|NEW |WAITING --- Comment #9 from Eric Botcazou --- Please mention the exact compiler version and the compilation switches.
[Bug target/107453] [13 Regression] New stdarg tests in r13-3549-g4fe34cdcc80ac2 fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107453 --- Comment #8 from Thomas Schwinge --- (In reply to Jakub Jelinek from comment #7) > No testing on nvptx Thanks, confirming fixed for nvptx target, too.
[Bug target/41989] Code optimized for AMD Geode is slower than generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989 Samantha Keen changed: What|Removed |Added CC||pokox38850 at tohup dot com --- Comment #28 from Samantha Keen --- Did this issue gets resolved in the newer version of AMD Geode? https://paradipport.gov.in/en/hotmail-login/
[Bug analyzer/108251] false positive: null dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108251
--- Comment #6 from David Malcolm ---
The analyzer sees the error-handling case in objt_conn, and considers the
execution path where it bails out early due to "t" being NULL i.e.
smp->sess->origin is NULL, and thus conn being initialized to NULL.
At it turns out, ssl_sock_get_ssl_object is defined (in src/ssl_sock.c) as:
SSL *ssl_sock_get_ssl_object(struct connection *conn)
{
struct ssl_sock_ctx *ctx = conn_get_ssl_sock_ctx(conn);
return ctx ? ctx->ssl : NULL;
}
and conn_get_ssl_sock_ctx is defined (in include/haproxy/connection.h) as:
/* retrieves the ssl_sock_ctx for this connection otherwise NULL */
static inline struct ssl_sock_ctx *conn_get_ssl_sock_ctx(struct connection
*conn)
{
if (!conn || !conn->xprt || !conn->xprt->get_ssl_sock_ctx)
return NULL;
return conn->xprt->get_ssl_sock_ctx(conn);
}
Hence it's a false positive: if conn is NULL, then ssl_sock_get_ssl_object will
return NULL.
The TU "sees" the definition of conn_get_ssl_sock_ctx, but only the declaration
of ssl_sock_get_ssl_object, not the latter's declaration.
Without a definition of ssl_sock_get_ssl_object, -fanalyzer can't "know" of the
interaction between "ssl" and "conn" (-fanalyzer doesn't work well with LTO
yet).
Hence it erroneously considers the case that ssl_sock_get_ssl_object could
return non-NULL on a NULL "conn", and sees the deref of conn, which it reports.
[Bug target/108346] gather/scatter loops optimized too often for znver4 (and other zens)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108346 Andrew Pinski changed: What|Removed |Added Component|middle-end |target Blocks||53947 Target||x86_64-linux-gnu Keywords||missed-optimization --- Comment #1 from Andrew Pinski --- This is a cost issue, either not having a decent way of expressing the cost or the backend cost model needs to be improved (or both). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug middle-end/108346] New: gather/scatter loops optimized too often for znver4 (and other zens)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108346
Bug ID: 108346
Summary: gather/scatter loops optimized too often for znver4
(and other zens)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
The following two benchmarks tests gather/scatter codegen:
s4113.c:
#include
#include
//typedef float real_t;
#define iterations 100
#define LEN_1D 32000
#define LEN_2D 256
real_t a[LEN_1D],b[LEN_1D],c[LEN_1D],d[LEN_1D],e[LEN_1D];
real_t aa[LEN_2D][LEN_2D];
real_t bb[LEN_2D][LEN_2D];
real_t cc[LEN_2D][LEN_2D];
real_t qq;
int
main(void)
{
//reductions
//if to max reduction
real_t x;
int * __restrict__ ip = (int *) malloc(LEN_1D*sizeof(real_t));
for (int i = 0; i < LEN_1D; i = i+5){
(ip)[i] = (i+4);
(ip)[i+1] = (i+2);
(ip)[i+2] = (i);
(ip)[i+3] = (i+3);
(ip)[i+4] = (i+1);
}
for (int nl = 0; nl < 2*iterations; nl++) {
for (int i = 1; i < LEN_1D; i += 2) {
a[ip[i]] = b[ip[i]] + c[i];
}
asm("":::"memory");
}
return x;
}
s4115.c:
#include
#include
#define iterations 100
#define LEN_1D 32000
#define LEN_2D 256
real_t a[LEN_1D],b[LEN_1D],c[LEN_1D],d[LEN_1D],e[LEN_1D];
real_t aa[LEN_2D][LEN_2D];
real_t bb[LEN_2D][LEN_2D];
real_t cc[LEN_2D][LEN_2D];
real_t qq;
int
main(void)
{
//reductions
//if to max reduction
real_t x;
int * __restrict__ ip = (int *) malloc(LEN_1D*sizeof(real_t));
for (int i = 0; i < LEN_1D; i = i+5){
(ip)[i] = (i+4);
(ip)[i+1] = (i+2);
(ip)[i+2] = (i);
(ip)[i+3] = (i+3);
(ip)[i+4] = (i+1);
}
for (int nl = 0; nl < 2*iterations; nl++) {
for (int i = 1; i < LEN_1D; i += 2) {
x += a[i] * b[ip[i]];
}
asm("":::"memory");
}
return x;
}
On zver4 I get following times with disabling/enabling vectorization and
disabling/enabling gather use:
runtime
type optimizationoperation scalar nogather gather parts instruction
char avx256_optimal load+store 14.23 N/A N/A
char avx256_optimal load 14.25 N/A N/A
char ^avx256_optimal load+store 14.02 N/A N/A
char ^avx256_optimal load 14.25 N/A N/A
short avx256_optimal load+store*14.23 N/A N/A
short avx256_optimal load *14.23 N/A N/A
short ^avx256_optimal load+store 15.22 N/A N/A
short ^avx256_optimal load 14.23 N/A N/A
int avx256_optimal load+store*16.51 27.6625.96 8 vpgatherdd
ymm,vpscatterdd ymm
int avx256_optimal load 14.13 13.17 *12.71 8 vpgatherdd
ymm
int ^avx256_optimal load+store*16.57 33.2526.06 16vpgatherdd
zmm,vpscatterdd zmm
int ^avx256_optimal load 14.14 16.81 *13.63 16vpgatherdd
zmm
long avx256_optimal load+store*20.59 20.6632.03 4 vpgatherdq
zmm,vpscatterdq zmm
long avx256_optimal load 15.36 *15.3615.82 4 vpgatherdq
zmm
long ^avx256_optimal load+store 22.42 *20.9630.54 8 vpgatherdq
zmm,vpscatterdq zmm
long ^avx256_optimal load *15.87 16.4018.68 8 vpgatherdq
zmm
float avx256_optimal load+store 16.88 27.7826.08 8 vgatherdps
ymm, vscatterdps ymm
float avx256_optimal load 26.01 *13.1913.30 8 vgatherdps
ymm
float ^avx256_optimal load+store*16.89 33.2226.19 16vgatherdps
zmm, vscatterdps zmm
float ^avx256_optimal load 26.01 16.61 *13.85 16vgatherdps
zmm
doubleavx256_optimal load+store 21.94 *20.8131.43 4 vgatherdpd
ymm, vscatterdpd ymm
doubleavx256_optimal load 26.01 26.01 *15.20 4 vgatherdpd
ymm
double^avx256_optimal load+store 21.44 *21.6530.73 8 vgatherdpd
zmm, vscatterdpd zmm
double^avx256_optimal load 26.01 26.01 *18.24 8 vgatherdpd
zmm
We incorrectly vectorize for int load+store loop causing 60% regression.
Vectorizing avx512 long load loop seems to be also slight loss, but not that
important. I will post patch todisable scatter instructions since they does
not seem to be win.
[Bug analyzer/108251] false positive: null dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108251
--- Comment #5 from David Malcolm ---
As per comment #4 (optimization disabled), but adding: -fanalyzer-verbosity=3
makes things clearer:
../../src/null-deref-pr108251-smp_fetch_ssl_fc_has_early.c: In function
‘smp_fetch_ssl_fc_has_early’:
../../src/null-deref-pr108251-smp_fetch_ssl_fc_has_early.c:92:27: warning:
dereference of NULL ‘conn’ [CWE-476] [-Wanalyzer-null-dereference]
92 | smp->data.u.sint = ((conn->flags & CO_FL_EARLY_DATA) &&
| ^~~
‘smp_fetch_ssl_fc_has_early’: events 1-2
|
| 78 | smp_fetch_ssl_fc_has_early(const struct arg *args, struct sample
*smp, const char *kw, void *private)
| | ^~
| | |
| | (1) entry to ‘smp_fetch_ssl_fc_has_early’
|..
| 83 | conn = objt_conn(smp->sess->origin);
| |
| | |
| | (2) calling ‘objt_conn’ from ‘smp_fetch_ssl_fc_has_early’
|
+--> ‘objt_conn’: events 3-6
|
| 61 | static inline struct connection *objt_conn(enum obj_type
*t)
| | ^
| | |
| | (3) entry to ‘objt_conn’
| 62 | {
| 63 | if (!t || *t != OBJ_TYPE_CONN)
| | ~
| | |
| | (4) following ‘true’ branch (when ‘t’ is NULL)...
| 64 |return ((void *)0);
| | ~
| | |
| | (5) ...to here
| | (6) ‘0’ is NULL
|
<--+
|
‘smp_fetch_ssl_fc_has_early’: events 7-10
|
| 83 | conn = objt_conn(smp->sess->origin);
| | ^~~~
| | |
| | (7) return of NULL to ‘smp_fetch_ssl_fc_has_early’ from
‘objt_conn’
| 84 | ssl = ssl_sock_get_ssl_object(conn);
| 85 | if (!ssl)
| | ~
| | |
| | (8) following ‘false’ branch (when ‘ssl’ is non-NULL)...
|..
| 88 | smp->flags = 0;
| | ~~
| | |
| | (9) ...to here
|..
| 92 | smp->data.u.sint = ((conn->flags & CO_FL_EARLY_DATA) &&
| | ~~~
| | |
| | (10) dereference of NULL ‘conn’
|
[Bug analyzer/108251] false positive: null dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108251 --- Comment #4 from David Malcolm --- Without optimization, trunk with just -Wno-address-of-packed-member (and -fanalyzer), I get: ../../src/null-deref-pr108251-smp_fetch_ssl_fc_has_early.c: In function ‘smp_fetch_ssl_fc_has_early’: ../../src/null-deref-pr108251-smp_fetch_ssl_fc_has_early.c:92:27: warning: dereference of NULL ‘conn’ [CWE-476] [-Wanalyzer-null-dereference] 92 | smp->data.u.sint = ((conn->flags & CO_FL_EARLY_DATA) && | ^~~ ‘smp_fetch_ssl_fc_has_early’: events 1-2 | | 78 | smp_fetch_ssl_fc_has_early(const struct arg *args, struct sample *smp, const char *kw, void *private) | | ^~ | | | | | (1) entry to ‘smp_fetch_ssl_fc_has_early’ |.. | 83 | conn = objt_conn(smp->sess->origin); | | | | | | | (2) calling ‘objt_conn’ from ‘smp_fetch_ssl_fc_has_early’ | +--> ‘objt_conn’: events 3-4 | | 61 | static inline struct connection *objt_conn(enum obj_type *t) | | ^ | | | | | (3) entry to ‘objt_conn’ |.. | 64 |return ((void *)0); | | ~ | | | | | (4) ‘0’ is NULL | <--+ | ‘smp_fetch_ssl_fc_has_early’: events 5-8 | | 83 | conn = objt_conn(smp->sess->origin); | | ^~~~ | | | | | (5) return of NULL to ‘smp_fetch_ssl_fc_has_early’ from ‘objt_conn’ | 84 | ssl = ssl_sock_get_ssl_object(conn); | 85 | if (!ssl) | | ~ | | | | | (6) following ‘false’ branch (when ‘ssl’ is non-NULL)... |.. | 88 | smp->flags = 0; | | ~~ | | | | | (7) ...to here |.. | 92 | smp->data.u.sint = ((conn->flags & CO_FL_EARLY_DATA) && | | ~~~ | | | | | (8) dereference of NULL ‘conn’ |
[Bug analyzer/108251] false positive: null dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108251 --- Comment #3 from David Malcolm --- Adding -fanalyzer-verbosity=3 to comment #2, I get: ../../src/null-deref-pr108251-smp_fetch_ssl_fc_has_early.c: In function ‘smp_fetch_ssl_fc_has_early’: ../../src/null-deref-pr108251-smp_fetch_ssl_fc_has_early.c:92:27: warning: dereference of NULL ‘0’ [CWE-476] [-Wanalyzer-null-dereference] 92 | smp->data.u.sint = ((conn->flags & CO_FL_EARLY_DATA) && | ^~~ ‘smp_fetch_ssl_fc_has_early’: events 1-2 | | 78 | smp_fetch_ssl_fc_has_early(const struct arg *args, struct sample *smp, const char *kw, void *private) | | ^~ | | | | | (1) entry to ‘smp_fetch_ssl_fc_has_early’ |.. | 83 | conn = objt_conn(smp->sess->origin); | | ~ | | | | | (2) inlined call to ‘objt_conn’ from ‘smp_fetch_ssl_fc_has_early’ | +--> ‘objt_conn’: event 3 | | 63 | if (!t || *t != OBJ_TYPE_CONN) | | ^ | | | | | (3) following ‘true’ branch... | <--+ | ‘smp_fetch_ssl_fc_has_early’: event 4 | |cc1: | (4): ...to here | ‘smp_fetch_ssl_fc_has_early’: events 5-7 | | 85 | if (!ssl) | | ^ | | | | | (5) following ‘false’ branch (when ‘ssl’ is non-NULL)... |.. | 88 | smp->flags = 0; | | ~~ | | | | | (6) ...to here |.. | 92 | smp->data.u.sint = ((conn->flags & CO_FL_EARLY_DATA) && | | ~~~ | | | | | (7) dereference of NULL ‘’ | which is slightly clearer; arguably we shouldn't have pruned events 2-4 from this at the lower verbosity level, since it's really hard to figure out what the analyzer is "thinking" in comment #2.
[Bug analyzer/108251] false positive: null dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108251 --- Comment #2 from David Malcolm --- With trunk and -Wno-address-of-packed-member -O2, I get: ../../src/null-deref-pr108251-smp_fetch_ssl_fc_has_early.c: In function ‘smp_fetch_ssl_fc_has_early’: ../../src/null-deref-pr108251-smp_fetch_ssl_fc_has_early.c:92:27: warning: dereference of NULL ‘0’ [CWE-476] [-Wanalyzer-null-dereference] 92 | smp->data.u.sint = ((conn->flags & CO_FL_EARLY_DATA) && | ^~~ ‘smp_fetch_ssl_fc_has_early’: events 1-3 | | 85 | if (!ssl) | | ^ | | | | | (1) following ‘false’ branch (when ‘ssl’ is non-NULL)... |.. | 88 | smp->flags = 0; | | ~~ | | | | | (2) ...to here |.. | 92 | smp->data.u.sint = ((conn->flags & CO_FL_EARLY_DATA) && | | ~~~ | | | | | (3) dereference of NULL ‘’ |
[Bug analyzer/108251] false positive: null dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108251 --- Comment #1 from David Malcolm --- Created attachment 54219 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54219=edit Simplified reproducer for smp_fetch_ssl_fc_has_early Thanks for filing this bug. I see the warnings, and have reduced the smp_fetch_ssl_fc_has_early example to the attached.
[Bug tree-optimization/108341] argument to `__builtin_ctz` should be assumed non-zero when CTZ_DEFINED_VALUE_AT_ZERO says it is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108341 Aldy Hernandez changed: What|Removed |Added Severity|normal |enhancement --- Comment #6 from Aldy Hernandez --- Huh. Didn't know you could do that. Thanks. FWIW, the function is actually: gimple_infer_range::gimple_infer_range (gimple *s)
[Bug tree-optimization/108341] argument to `__builtin_ctz` should be assumed non-zero when CTZ_DEFINED_VALUE_AT_ZERO says it is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108341 --- Comment #5 from Andrew Macleod --- (In reply to Aldy Hernandez from comment #2) > (In reply to Martin Liška from comment #1) > > May be an opportunity for Ranger? > > Hmmm... I don't think so: > > : > value.0_1 = (unsigned int) value_4(D); > _2 = __builtin_ctz (value.0_1); > r = _2; > _3 = value_4(D) != 0; > _7 = (int) _3; > return _7; > > We could add an op1_range operator to class cfn_clz to return nonzero for > op1, but that would only work if we knew _2 to be anything...and have no > info on _2. Seems more like a candidate for gimpe_infer::gimple_infer (gimple *s). THe side effect to register would be to check if 's' is a builtin_ctz and if so, call add_nonzero (operand1) if whatever those other conditions are are matched which make it true. That should register a non-zero inferred range on value.0_1 after the assignment of _2. === BB 2 Partial equiv (value.0_1 pe32 value_4(D)) : value.0_1 = (unsigned int) value_4(D); _2 = __builtin_ctz (value.0_1); r = _2; _3 = value_4(D) != 0; _7 = (int) _3; return _7; I see ranger also registers a 32 bit equivalence between value.0_1 and value_4, so in theory we would then be able to determine that value_4 is also non-zero for the comparison.
[Bug tree-optimization/108281] float value range estimation missing (vs. integer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108281 --- Comment #5 from Aldy Hernandez --- (In reply to Jakub Jelinek from comment #4) > (In reply to Aldy Hernandez from comment #3) > > (In reply to Richard Biener from comment #2) > > > GCC 13 got float range tracking but the description isn't clear as what > > > transform you are looking after? It seems you are looking for ranges > > > of standard math functions - I think those are not yet implemented? > > > > Correct. We don't track libm functions. > > Yet. I hope we do that for GCC 14. Yeah. That'd be very nice. It's on our radar for the next releaseat least provide any missing framework and provide a few sample ones.
[Bug target/108272] [13 Regression] ICE in gen_movxo, at config/rs6000/mma.md:339
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108272 --- Comment #3 from Arseny Solokha --- (In reply to Kewen Lin from comment #2) > Created attachment 54192 [details] > untested patch > > Hi @Arseny, I hope this patch can help to clear all the ICEs about > unexpected uses of MMA opaque types in inline asm, that is to filter those > noises duplicated to this bug. Indeed, I haven't seen such ICEs w/ the patch applied so far. Still get an ICE in gen_movoo, at config/rs6000/mma.md:292 when compiling gcc/testsuite/gcc.target/powerpc/pr96506-1.c w/ -m32, though. Do you want me to file another PR for that one?
[Bug middle-end/108278] [13 Regression] runtime error with -O1 -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278 --- Comment #17 from Jakub Jelinek --- We know the commit introduced UB on the compiler side, but what I don't understand is why it triggered on the testcases you've provided. It surely introduced UB when compiling libgcc/unwind-dw2.c or during predefining macros with -fbuilding-libgcc, but I think the problematic code with uninitialized array of poly_ints could happen at different times.
[Bug tree-optimization/108281] float value range estimation missing (vs. integer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108281 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- (In reply to Aldy Hernandez from comment #3) > (In reply to Richard Biener from comment #2) > > GCC 13 got float range tracking but the description isn't clear as what > > transform you are looking after? It seems you are looking for ranges > > of standard math functions - I think those are not yet implemented? > > Correct. We don't track libm functions. Yet. I hope we do that for GCC 14.
[Bug tree-optimization/108281] float value range estimation missing (vs. integer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108281 --- Comment #3 from Aldy Hernandez --- (In reply to Richard Biener from comment #2) > GCC 13 got float range tracking but the description isn't clear as what > transform you are looking after? It seems you are looking for ranges > of standard math functions - I think those are not yet implemented? Correct. We don't track libm functions.
[Bug c++/108285] [13 Regression] error: conversion from ‘long double’ to ‘double’ may change value [-Werror=float-conversion] since r13-3291-g16ec267063c8ce60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108285 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/108281] float value range estimation missing (vs. integer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108281 Richard Biener changed: What|Removed |Added CC||aldyh at gcc dot gnu.org Version|12.2.0 |13.0 --- Comment #2 from Richard Biener --- GCC 13 got float range tracking but the description isn't clear as what transform you are looking after? It seems you are looking for ranges of standard math functions - I think those are not yet implemented?
[Bug middle-end/108278] [13 Regression] runtime error with -O1 -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278 --- Comment #16 from David Binderman --- (In reply to Richard Biener from comment #15) > So this bug is fixed? Jakub and I seem to think so. Good enough ?
[Bug middle-end/108278] [13 Regression] runtime error with -O1 -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2023-01-09 --- Comment #15 from Richard Biener --- So this bug is fixed?
[Bug target/108339] [11/10 only] riscv64-linux-gnu: fails to link libgcc_s.so on the GCC 10 branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108339 Andrew Pinski changed: What|Removed |Added Known to work|11.3.1, 12.2.1 |12.1.0 Summary|[10 only] |[11/10 only] |riscv64-linux-gnu: fails to |riscv64-linux-gnu: fails to |link libgcc_s.so on the GCC |link libgcc_s.so on the GCC |10 branch |10 branch --- Comment #2 from Andrew Pinski --- Which was not backported to GCC 11 branch either.
[Bug target/108339] [10 only] riscv64-linux-gnu: fails to link libgcc_s.so on the GCC 10 branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108339 --- Comment #1 from Andrew Pinski --- r12-5799-g45116f342057b7
[Bug c/108345] New: Mismatch __attribute__((aligned(x))) between declaration and definition does not raise error/warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108345
Bug ID: 108345
Summary: Mismatch __attribute__((aligned(x))) between
declaration and definition does not raise
error/warning
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dumoulin.thibaut at gmail dot com
Target Milestone: ---
If `__attribute__((aligned(x)))` is present in function declaration but NOT
present in function implementation, GCC does not fire any warning/error.
Example:
```
#include
typedef uint32_t _type_unaligned __attribute__((aligned(1)));
/* Prototype with attribute aligned */
void function_a(_type_unaligned* a);
int main(void) {
struct test_t {
uint8_t a;
uint32_t b;
uint32_t c;
} __attribute__((__packed__)) test = {.a = 0, .b = 1, .c = 2};
function_a(&(test.b));
return 0;
}
/* Declaration WITHOUT attribute aligned */
void function_a(uint32_t* a) {
uint32_t _a = *(a + 0);
uint32_t _b = *(a + 1);
*(a + 3) = _a + _b;
}
```
`arm-none-eabi-gcc --specs=nosys.specs -mcpu=cortex-m4 -Wall -Wextra -O3
-mthumb -mlittle-endian`
```
$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (15:10.3-2021.07-4) 10.3.1 20210621 (release)
```
Assembly generated for function_a:
```
811c :
811c: e9d0 3200 ldrdr3, r2, [r0] --> illegal ARM V7
instruction if unaligned!
8120: 4413add r3, r2
8122: 60c3str r3, [r0, #12]
8124: 4770bx lr
8126: bf00nop
```
Header and implementation of the function mismatch about `__attribute__` and
this is misleading. Here, GCC does NOT generate code to align the pointer in
`function_a` implementation.
Correct code would be:
```
/* Declaration with attribute aligned */
void function_a(_type_unaligned* a) {
uint32_t _a = *(a + 0);
uint32_t _b = *(a + 1);
*(a + 3) = _a + _b;
}
```
Usually, when function declaration and definition mismatch, GCC fires a
warning/error.
I think this is a bug here, GCC should not allow to compile this code or at
least should raise a warning.
[Bug target/108339] [10 only] riscv64-linux-gnu: fails to link libgcc_s.so on the GCC 10 branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108339 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.5
[Bug middle-end/107991] [10/11/12/13 Regression] Extra mov instructions with ternary on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107991 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com --- Comment #6 from Roger Sayle --- An x86 peephole2 to workaround the problem was proposed here: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609578.html but improved register allocation (if possible) would be a better solution: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609588.html
[Bug c++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108342 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #9 from Andrew Pinski --- https://gcc.gnu.org/pipermail/gcc-patches/2003-July/110087.html This was done on purpose. GCC also rejects References too while clang accepts that (but I am not sure it gives the correct code for references of packed either which is why GCC started to reject it).
[Bug tree-optimization/108341] argument to `__builtin_ctz` should be assumed non-zero when CTZ_DEFINED_VALUE_AT_ZERO says it is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108341
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
I think 0 argument for __builtin_c[lt]z{,l,ll,imax} is always undefined, 0
argument
to .C[LT]Z (internal calls) is undefined if C[LT]Z_DEFINED_VALUE_AT_ZERO is not
2 and
0 argument to C[LT]Z RTL is undefined if C[LT]Z_DEFINED_VALUE_AT_ZERO is not
non-zero.
[Bug c++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108342 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=13983, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=17519 --- Comment #8 from Andrew Pinski --- r0-51814-ge0d1297c4320ae added the warning and started to ignore the packed (back in 2003).
[Bug modula2/108261] modula-2 module registration process seems to fail with shared libraries.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261 --- Comment #8 from Iain Sandoe --- This is good in that it removes the extra -Ls, but ... 1. This will not work in general for targets with spec substitution for library names - the library names *do* need to be on the driver line, 2. It will probably not work for -static-libgm2 on Bstatic/dynamic targets either because those options need to be inserted in the lang-specific driver. I think it would be quite hard to implement the target-specific changes in the specs .. * The include spec are nicely handled by this change and now they do not appear in parts of the driver output that does not need them. * The library driving I *think* still needs to live in the language-specific driver. .. I'll add an updated patch later, if that's OK Unfortunately, I do not think that the library ordering is enough to fix this PR ..
[Bug c++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108342
--- Comment #7 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #5)
> I don't know whether clang allows packing non-PODs, or just doesn't ever
> warn for them, or has a special case for std::complex, or does something
> smarter like not warn for types that have no padding bytes anyway (so that
> packing them would be a no-op).
clang allows packing of non-PODs:
```
class f
{
public:
f();
private:
int t[2];
};
typedef struct __attribute__((__packed__))
{
/** Every frame starts with BB_FRAME_MAGIC. */
unsigned magic;
unsigned char t;
f bb_iq_samples[100];
} bb_frame_t;
```
[Bug c++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108342
Andrew Pinski changed:
What|Removed |Added
Component|libstdc++ |c++
--- Comment #6 from Andrew Pinski ---
clang:
typedef struct __attribute__((__packed__))
{
/** Every frame starts with BB_FRAME_MAGIC. */
uint32_t magic;
unsigned char t;
fcomplex_t bb_iq_samples[BB_FRAME_IQ_SAMPLES_COUNT];
} bb_frame_t;
int t = sizeof(bb_frame_t);
t:
.long 4101# 0x1005
.size t, 4
it might be the case clang does not implement the ABI
[Bug tree-optimization/108341] argument to `__builtin_ctz` should be assumed non-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108341 --- Comment #3 from Andrew Pinski --- Not always. It depends on the definition of CTZ_DEFINED_VALUE_AT_ZERO. /* The value at zero is only defined for the BMI instructions LZCNT and TZCNT, not the BSR/BSF insns in the original isa. */ #define CTZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) \ ((VALUE) = GET_MODE_BITSIZE (MODE), TARGET_BMI ? 2 : 0) #define CLZ_DEFINED_VALUE_AT_ZERO(MODE, VALUE) \ ((VALUE) = GET_MODE_BITSIZE (MODE), TARGET_LZCNT ? 2 : 0) So assuming !=0 with -mbmi would be an invalid assumitation.
[Bug c++/107616] c++tools: select not found breaks build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107616 John David Anglin changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from John David Anglin --- Fixed on trunk.
[Bug libstdc++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108342 --- Comment #5 from Jonathan Wakely --- I don't think there's anything the library can do here. The layout of std::complex is fixed, as stated above. And the fact it's a non-POD is also fixed. If the front-end warns about trying to pack a non-POD, then the library can't stop it warning about std::complex. I don't know whether clang allows packing non-PODs, or just doesn't ever warn for them, or has a special case for std::complex, or does something smarter like not warn for types that have no padding bytes anyway (so that packing them would be a no-op).
[Bug libstdc++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108342 --- Comment #4 from Rui Oliveira --- (In reply to Andrew Pinski from comment #2) > Hmm: diff.cpp03.numerics I saw you moved the bug to libstdc++ but is the problem libstdc++, or should g++ just accept packing when it encounters it?
[Bug libstdc++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108342 --- Comment #3 from Rui Oliveira --- (In reply to Andrew Pinski from comment #1) > > I know about _Atomic and std::atomic but not std::complex and _Complex. > Because std::complex was part of C++98 which was done before C99's _Complex > ... [complex.numbers.general] mentions: If z is an lvalue of type cv complex then: the expression reinterpret_cast(z) is well-formed, https://eel.is/c++draft/complex.numbers.general Basically stating that std::complex is layouted exactly the same as T[2]. C standard says something similar iirc.
[Bug libstdc++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108342 --- Comment #2 from Andrew Pinski --- Hmm: diff.cpp03.numerics
[Bug c++/108342] std::complex: ignoring packed attribute because of unpacked non-POD field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108342 --- Comment #1 from Andrew Pinski --- >The C++ standard even carves out a guarantee than `_Complex [float|double]` is >memory-layout-compatible with `std::complex<[float|double]>`. I know about _Atomic and std::atomic but not std::complex and _Complex. Because std::complex was part of C++98 which was done before C99's _Complex ...
[Bug tree-optimization/108341] argument to `__builtin_ctz` should be assumed non-zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108341 --- Comment #2 from Aldy Hernandez --- (In reply to Martin Liška from comment #1) > May be an opportunity for Ranger? Hmmm... I don't think so: : value.0_1 = (unsigned int) value_4(D); _2 = __builtin_ctz (value.0_1); r = _2; _3 = value_4(D) != 0; _7 = (int) _3; return _7; We could add an op1_range operator to class cfn_clz to return nonzero for op1, but that would only work if we knew _2 to be anything...and have no info on _2.
[Bug c++/107616] c++tools: select not found breaks build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107616 --- Comment #3 from CVS Commits --- The master branch has been updated by John David Anglin : https://gcc.gnu.org/g:0925a9772960c946440833033423bff41c330154 commit r13-5072-g0925a9772960c946440833033423bff41c330154 Author: John David Anglin Date: Mon Jan 9 15:41:51 2023 + Fix compilation of server.cc on hpux. Select and FD_ISSET are declared in sys/time.h on most versions of hpux. As a result, HAVE_PSELECT and HAVE_SELECT can be 0. 2023-01-08 John David Anglin c++tools/ChangeLog: PR other/107616 * server.cc (server): Don't call FD_ISSET when HAVE_PSELECT and HAVE_SELECT are zero.
[Bug web/88860] Clarify gcc online manual 6.38 Attribute Syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88860 --- Comment #9 from Jonny Grant --- (In reply to Jonathan Wakely from comment #8) > Has it been reviewed and approved? I can't do that for patches outside the > libstdc++-v3 dir. I've not yet received a reply to it on gcc-patches list. https://gcc.gnu.org/pipermail/gcc-patches/2022-December/609132.html
[Bug fortran/108329] IEEE_SET_ROUNDING_MODE ineffective with common subexpression elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108329 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #3 from Thomas Koenig --- Seems to be much more complicated than I thought, see the thrad starting at https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609532.html
[Bug tree-optimization/107608] [13 Regression] Failure on fold-overflow-1.c and pr95115.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107608 --- Comment #12 from Aldy Hernandez --- (In reply to Richard Biener from comment #6) > (In reply to Jakub Jelinek from comment #0) > > ... but then > > comes dom2 and happily replaces > > _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0; > > return _1; > > with > > _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0; > > return Inf; > > (I think this is still correct) > > Note this is also a pessimization code-generation wise since if we > preserve the multiplication the result is readily available in a > register but as optimized we have another constant pool entry and load. > > So we might want to consider not propagating constants generated by > operations > we cannot eliminate. If the only consumer is a compare-and-branch we > can of course still end up with a seemingly dead stmt, so this would be only > for the missed optimization. [Sorry for the delayed response. I've been on PTO.] For the original testcase, the propagation happens in DOM: [local count: 1073741824]: _1 = 3.4028234663852885981170418348451692544e+38 * 2.0e+0; return _1; range_of_expr gets called on the return's _1 and correctly returns Inf, which allows cprop_operand to do the replacement. If I understand correctly you're suggesting not propagating constants that were generated by an operation we can't eliminate. In this case, it'd be easy to chase the DEF back to the offending _1 definition (from cprop_operand and every other places where we do propagations based on range_of_expr's result), but ranger doesn't keep track of how it got to an answer, so we'd have to chase all operands used to generate _1?? That'd get hairy pretty fast, unless I'm misunderstanding something. It really looks like the problem here is DCE (and the gimplifier as you point out in comment #2), which is removing a needed statement. Can't this be fixed there?
[Bug web/88860] Clarify gcc online manual 6.38 Attribute Syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88860 --- Comment #8 from Jonathan Wakely --- Has it been reviewed and approved? I can't do that for patches outside the libstdc++-v3 dir.
[Bug web/88860] Clarify gcc online manual 6.38 Attribute Syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88860 --- Comment #7 from Jonny Grant --- (In reply to Jonathan Wakely from comment #6) > (In reply to Jonny Grant from comment #5) > > Re the patches, I recall I did email them, but pasted here too as another > > developer was doing that. I'll have a good read of that contribution guide. > > If you've emailed them to the list then it's better to link to the mails in > the list archive, not duplicate them here. > > > What did you think of the "infelicities" patch? > > It loses a little of the nuance, i.e. that the limitations are unfortunate. > But I think it's an improvement. Ok thank you. May I ask if you could commit the patch please?
[Bug modula2/108344] Many tests time out: isatty called in a tight loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108344 Rainer Orth changed: What|Removed |Added Target Milestone|--- |13.0
[Bug modula2/108344] New: Many tests time out: isatty called in a tight loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108344 Bug ID: 108344 Summary: Many tests time out: isatty called in a tight loop Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Host: i386-pc-solaris2.11 Target: i386-pc-solaris2.11 Build: i386-pc-solaris2.11 I'm seeing a very weird error running the m2 testsuite on Solaris/x86: quite a number of tests time out in compilation. However, this only happens when gcc is configured to use /bin/as, not with gas. Besides, the timeouts affect only 64-bit compiltions. I'm seeing this with both flex 2.5.35 and 2.6.4. Here's what I observe: for the affected tests, is in a tight loop like this: 12901: /var/gcc/regression/master/11.4-gcc/build/gcc/cc1gm2 -fcpp-begin -E -l fabbd4c7 ioctl(0x6, 0x0, 0x1032, 0x8c15c33) + 7 08c15c87 yy_init_buffer(yy_buffer_state*, __FILE*) (0xadce188, 0xadce189, 0xfeff9778, 0xadce188, 0x0, 0xadce189) + 67 08c15d17 yyrestart(__FILE*) (0xad29110, 0x1, 0x2000, 0xad29110, 0x14, 0xadcbb60) + 27 08c18918 yylex() (0xad6c320, 0xfeff97f0, 0xfeff97f8, 0x8c4e16f, 0x2a, 0x1) + 2668 08c18b9c m2flex_GetToken (0x2a, 0x1, 0xfeff9808, 0x8c4e16f, 0xadd4d58, 0x2a) + 3c 08c4e16f M2LexBuf_GetToken (0x1, 0xfeff983c, 0xfeff9858, 0x8c347cd, 0xadd3750, 0x2a) + 3f 08c4ebe5 M2LexBuf_OpenSource (0xadd3750, 0x2a, 0xfeff9858, 0x8c344d8) + 65 08c347cd M2Comp_compile (0xfeffa662, 0x43, 0x36, 0xad33290) + 3fd 08bea500 gm2_langhook_parse_file() (0x3, 0xf9e09000, 0xfeff9948, 0x92a78d7, 0x43, 0x0) + 60 092a442d compile_file() (0x2, 0x8b3c3de, 0xfeff9948, 0x92a7e34) + 1d 092a78dc toplev::main(int, char**) (0x1000, 0x84ee24f, 0xfae8e310, 0xa4411e1) + 136c 0a4411e1 main (0xfeff9c6c, 0xfeff99b4, 0x8be8add) + 31 08be8a46 _start (0x4f, 0xfeff9cee, 0xfeff9d23, 0xfeff9d2f, 0xfeff9d32, 0xfeff9d3c) + 46 That ioctl is ioctl(6, TCGETA, 0xFEFF96E0)Err#25 ENOTTY no doubt resulting from calls to isatty in the generated gm2-compiler/m2flex.c. What's even weirder, if I run such a compilation manually, it completes in about half a second, and I've not yet managed to reproduce the issue with anything but a full make -jN -k check-m2 run. This is pretty tedious because those 600 second timeouts massively add up, slowing the whole test time tremendously. I've already tried using flex -B to generate the lexer, but that didn't make a difference, which judging from the skeleton file is no wonder. However, when using --never-interactive, things gets way worse: I've already several instances of cc1gm2 running for 12+ minutes (way beyond the 600 second timeout of runtest), making not syscall whatsoever. All this suggests that something is very weird in the m2 lexer somewhere. Here's the list of affected tests (all in gm2/iso/pass, doesn't change between runs): addadr1.mod bits32c.mod callwraptime.mod caseiso.mod caseiso2.mod cast.mod cast3.mod castiso.mod ChanConsts.mod const1.mod constreal.mod constructor1.mod constructor2.mod constructor3.mod constructor4.mod constructor5.mod constructor6.mod constsize4.mod ConvTypes.mod delim.mod delim2.mod enummodule.mod except1.mod expproc.mod expproc2.mod isob.mod isobitset.mod isobitset2.mod longm.mod m.mod proccast.mod realbitscast.mod set12.mod stringchar.mod subassign.mod testaddindr.mod testconv.mod testconv2.mod testconv3.mod testconv4.mod testconv5.mod testconv6.mod testconv7.mod testconv8.mod testconv9.mod testiso.mod testiso2.mod testisosize.mod testlength.mod testlength2.mod testlength3.mod testlength4.mod testlength5.mod unbounded.mod unbounded2.mod
[Bug modula2/108261] modula-2 module registration process seems to fail with shared libraries.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108261 --- Comment #7 from Gaius Mulley --- Created attachment 54218 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54218=edit Potential fix for target multilib_dir handling (version 4) shared lib fix
[Bug modula2/108182] gm2 driver mishandles target and multilib options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108182 --- Comment #10 from Gaius Mulley --- here is version 4 of the bugfix which enables the driver to link against shared libraries.
[Bug tree-optimization/108008] [12 Regression] wrong code with -O3 and posix_memalign since r12-4526-gd8edfadfc7a9795b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108008 Martin Liška changed: What|Removed |Added Keywords|needs-bisection | --- Comment #14 from Martin Liška --- > Note I can not reproduce on the branch after r12-8855-g19a9b5e587e87f52, > so maybe that's truly the duplicate. gcc-12 branch is fixed since the mentioned revision.
[Bug sanitizer/108343] ASAN at -O3 misses a heap-use-after-free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108343 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-01-09 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=108085 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Liška --- It has similar symptoms like PR108085.
[Bug c/108340] compiler segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108340 --- Comment #5 from Jakub Jelinek --- The trunk change caused various regressions and needed multiple follow-ups, I'm afraid it is not a good idea to backport that. r13-2658, r13-2709, r13-2891 at least. Perhaps backporting the 2 match.pd hunks from r13-2658 and nothing else could work for 12.3, provided it fixes the testcases.
[Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
m.cencora at gmail dot com changed:
What|Removed |Added
CC||m.cencora at gmail dot com
--- Comment #17 from m.cencora at gmail dot com ---
It is (In reply to Richard Biener from comment #16)
> (In reply to Witold Baryluk from comment #15)
> > I know this is a pretty old bug, but I was exploring some assembly of gcc
> > and clang on godbolt, and also stumbled into same issue.
> >
> > https://godbolt.org/z/qPzMhWse1
> >
> > class A {
> > public:
> > virtual int f7(int x) const;
> > };
> >
> > int g(const A * const a, int x) {
> > int r = 0;
> > for (int i = 0; i < 1; i++)
> > r += a->f7(x);
> > return r;
> > }
> >
> > (same happens without loop, when just calling a->f7 multiple times)
> >
> >
> >
> > g(A const*, int):
> > pushr13
> > mov r13d, esi
> > pushr12
> > xor r12d, r12d
> > pushrbp
> > mov rbp, rdi
> > pushrbx
> > mov ebx, 1
> > sub rsp, 8
> > .L2:
> > mov rax, QWORD PTR [rbp+0] # a vtable deref
> > mov esi, r13d
> > mov rdi, rbp
> > call[QWORD PTR [rax]]# f7 indirect call
> > add r12d, eax
> > dec ebx
> > jne .L2
> >
> > add rsp, 8
> > pop rbx
> > pop rbp
> > mov eax, r12d
> > pop r12
> > pop r13
> > ret
> >
> >
> > I was expecting mov rax, QWORD PTR [rbp+0] and call[QWORD PTR
> > [rax]], to be hoisted out of the loop (call converted to lea, and call
> > register).
> >
> >
> > A bit sad.
> >
> > Is there some recent work done on this optimization?
> >
> > Are there at least some cases where it is valid to do CSE, or change code so
> > it is moved out of the loop?
>
> GCC sees a->f() as possibly altering the virtual table [pointer] since
> the function gets passed 'a' and thus a pointer to it (and *a is global
> memory anyway, so GCC has to assume f() has access to it).
>
> In C++ probably there's probably no virtual function that could do this.
> A virtual DTOR would leave an uninitialized object. Not sure if
>
> class A
> {
> virtual void f() { }
> }
> class B : A
> {
> virtual void f() { new A (this); }
> }
>
> would be valid (maybe with first calling the DTOR on the existing object).
It is valid, but to be able to use B object after B::f was invoked (and a new
object is placed there instead), a user need to launder the pointer.
https://en.cppreference.com/w/cpp/utility/launder
[Bug target/108274] [13 Regression] ICE in df_refs_verify during arm_reorg pass with -fipa-icf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108274 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug target/108240] [13 Regression] ICE in emit_library_call_value_1 at gcc/calls.cc:4181 since r13-4894-gacc727cf02a144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108240 --- Comment #4 from Segher Boessenkool --- (In reply to Kewen Lin from comment #3) > With the culprit commit r13-4894, we always implicitly enable powerpc64 for > both explicit and implicit 64 bit, it's the same as before for the explicit > 64 bit case, but for the implicit 64 bit case, there is no chance for the > used cpu to unset powerpc64 (like this case). To keep it consistent with the > previous, the fix can be to only enable powerpc64 implicitly for explicit 64 > bit, while let it be for implicit 64 bit. No? If the user says to use a CPU without 64-bit instructions, while the user also says we require 64-bit insns (via -m64), we should just error. Not hide the problem (and cause many more problems!) We used to do that: f951: Error: ‘-m64’ requires a PowerPC64 cpu We can do such a check again, just in a bit different spot probably.
[Bug ipa/108250] [12/13 regression] llvm-tblgen miscompiled on powerpc-unknown-linux-gnu since r12-5383-g22c242342e38eb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108250 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.3
[Bug middle-end/108209] goof in genmatch.cc:commutative_op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108209 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug middle-end/108209] goof in genmatch.cc:commutative_op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108209 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:46034c46f82dec169fe7fc7c2d82d8321d9a9512 commit r13-5068-g46034c46f82dec169fe7fc7c2d82d8321d9a9512 Author: Richard Biener Date: Mon Jan 9 14:28:03 2023 +0100 middle-end/108209 - typo in genmatch.cc:commutative_op The early out for user-id handling indicated commutative rather than not commutative. PR middle-end/108209 * genmatch.cc (commutative_op): Fix return value for user-id with non-commutative first replacement.
[Bug preprocessor/108244] [13 Regression] `pragma GCC diagnostic` and -E -fdirectives-only causes the preprocessor to become confused since r13-1544-ge46f4d7430c52104
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108244 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[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 Target Milestone|--- |10.5
[Bug c++/108242] [10/11/12/13 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/108241] [12/13 Regression] ICE in lra_eliminate_regs_1, at lra-eliminations.cc:658
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108241 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.3 Priority|P3 |P2
