[Bug c/104711] Unnecessary -Wshift-negative-value warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104711 --- Comment #5 from Richard Biener --- I agree that -fwrapv should make left-shift of positive values when the result is not representable well-defined but I'm not sure about the negative value case - the standard does not provide enough reasoning to suggest the undefinedness is because of actual overflow - in fact the standard allows E1 << 0 and there's definitely no overflow for negative E1 in that case. Supposedly the standard simply chickened out for non-twos-complement archs here again and unfortunately didn't leave the door open for implementation-defined behavior. I suppose you are asking for an option to turn all left shifts into logical shifts?
[Bug target/104714] [nvptx] Means to specify any sm_xx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104714
--- Comment #1 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> [ FWIW, it would be great if we could simply specify -march=native, and have
> gcc query the nvidia driver to see what board there is using
> cuDeviceGetAttribute and CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MAJOR and
> CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MINOR. And possibly handle the
> situation of multiple boards by using the minimum. But, much more involved
> to realize. ]
Though, it might be better to handle this externally, so have a tool:
...
$ cat test.c
#include
#include
int compute_capability_major;
int compute_capability_minor;
int
main (void)
{
cuInit(0);
int num_devices;
cuDeviceGetCount (_devices);
for (int i = 0; i < num_devices; ++i)
{
CUdevice device;
cuDeviceGet (, i);
cuDeviceGetAttribute (_capability_major,
CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MAJOR,
device);
cuDeviceGetAttribute (_capability_minor,
CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MINOR,
device);
printf ("sm_%d%d\n", compute_capability_major, compute_capability_minor);
}
return 0;
}
...
that compiles like so:
...
$ gcc test.c -I ~/cuda/11.6.0/include -lcuda -o a.out -g
...
and prints:
...
$ ./a.out
sm_75
...
and then name the tool nvptx-print-native or some such and use:
...
native=$(nvptx-print-native)
$cc ... -march=$native
...
in scripts.
[Bug rtl-optimization/104154] [12 Regression] Another ICE due to recent ifcvt changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154 --- Comment #10 from CVS Commits --- The master branch has been updated by Robin Dapp : https://gcc.gnu.org/g:2240ebd8e46e098f972a662d0aad85348b304889 commit r12-7420-g2240ebd8e46e098f972a662d0aad85348b304889 Author: Robin Dapp Date: Mon Feb 7 08:39:41 2022 +0100 arc: Fix for new ifcvt behavior [PR104154] ifcvt now passes a CC-mode "comparison" to backends. This patch simply returns from gen_compare_reg () in that case since nothing needs to be prepared anymore. gcc/ChangeLog: PR rtl-optimization/104154 * config/arc/arc.cc (gen_compare_reg): Return the CC-mode comparison ifcvt passed us.
[Bug target/104704] [12 Regression] ix86_gen_scratch_sse_rtx doesn't work with explicit XMM7/XMM15/XMM31 usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104704 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0 Keywords||wrong-code
[Bug fortran/104696] [12 Regression][OpenMP] Implicit mapping breaks struct mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104696 Richard Biener changed: What|Removed |Added Target Milestone|--- |12.0
[Bug c++/102990] [9/10/11/12 Regression] ICE in tsubst_copy_and_build with NSDMI and double to int conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102990 --- Comment #8 from Andrew Pinski --- *** Bug 104720 has been marked as a duplicate of this bug. ***
[Bug c++/104720] internal compiler error: in tsubst_copy_and_build, at cp/pt.c:19817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104720 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 102990. *** This bug has been marked as a duplicate of bug 102990 ***
[Bug libstdc++/104719] Use of `std::move` in libstdc++ leads to worsened debug performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719 --- Comment #9 from Vittorio Romeo --- I have done some benchmarking for three use cases, both with `-O0` and `-Og`, hacking my `libstdc++` headers to add `[[gnu::always_inline]]` where deemed appropriate. --- The use cases were: 1. `operator[]` benchmark -- `vector_squareop` and `carray_squareop` as seen above 2. Iterator benchmark -- `vector_iter` and `carray_iter` as seen above 3. Algorithm benchmark -- `std::accumulate` versus a raw `for` loop --- All the benchmark results, benchmarking rig specs, and used code available here: https://gist.github.com/vittorioromeo/efa005d44ccd4ec7279181768a0c1f0b --- In short, these are the results: - For all benchmarks, when using `-O0` without any modification to `libstdc++`, the overhead of the Standard Library can be huge (+25-400%). - For all benchmarks, when using `-Og` without any modification to `libstdc++`, the overhead of the Standard Library is small (+5-15%). - For the `operator[]` benchmark, when using `-O0` after applying `[[gnu::always_inline]]` to all the functions touched by the benchmark, we reduce the overhead from 25% to around 10%. - For the `operator[]` benchmark, when using `-Og` after applying `[[gnu::always_inline]]` to all the functions touched by the benchmark, we reduce the overhead from 34% to around 11%. - For the iterator benchmark, when using `-O0` after applying `[[gnu::always_inline]]` to all the functions touched by the benchmark, we reduce the overhead from 302% to around 186%. - For the iterator benchmark, when using `-Og` after applying `[[gnu::always_inline]]` to all the functions touched by the benchmark, we reduce the overhead from 11% to around 8%. - For the algorithm benchmark, when using `-O0` after applying `[[gnu::always_inline]]` to all the functions touched by the benchmark, we reduce the overhead from 304% to around 47%. - For the algorithm benchmark, when using `-Og`, independently of whether we modify `libstdc++` or not, the overhead is around 36%.
[Bug translation/104552] Mistakes in strings to be translated in GCC 12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104552 Eric Gallager changed: What|Removed |Added Keywords||diagnostic, easyhack Blocks||40883 Severity|normal |trivial CC||egallager at gcc dot gnu.org Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 [Bug 40883] [meta-bug] Translation breakage with trivial fixes
[Bug c++/104699] zero-length-array is not considered as an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104699 --- Comment #6 from qingzhe huang --- Really appreciate the detailed explanation! Very clear and completely convinced.
[Bug rtl-optimization/104664] [12 Regression] ICE: in extract_constrain_insn, at recog.cc:2670 (insn does not satisfy its constraints) with -Og -ffinite-math-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104664 --- Comment #6 from Hongyu Wang --- Fixed for GCC 12.
[Bug rtl-optimization/104664] [12 Regression] ICE: in extract_constrain_insn, at recog.cc:2670 (insn does not satisfy its constraints) with -Og -ffinite-math-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104664 --- Comment #5 from CVS Commits --- The master branch has been updated by Hongyu Wang : https://gcc.gnu.org/g:e2385690a3ead66744e51115966f25f9c05bb3e2 commit r12-7419-ge2385690a3ead66744e51115966f25f9c05bb3e2 Author: Hongyu Wang Date: Mon Feb 28 15:09:59 2022 +0800 i386: Fix V8HF vector init under -mno-avx [PR 104664] For V8HFmode vector init with HFmode, do not directly emits V8HF move with subreg, which may cause reload to assign general register to move src. gcc/ChangeLog: PR target/104664 * config/i386/i386-expand.cc (ix86_expand_vector_init_duplicate): Use vec_setv8hf_0 for HF to V8HFmode move instead of subreg. gcc/testsuite/ChangeLog: PR target/104664 * gcc.target/i386/pr104664.c: New test.
[Bug middle-end/104721] currently_expanding_gimple_stmt isn't cleared properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104721 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-02-28 Ever confirmed|0 |1
[Bug middle-end/104721] currently_expanding_gimple_stmt isn't cleared properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104721 --- Comment #1 from H.J. Lu --- Created attachment 52528 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52528=edit A patch I am testing this.
[Bug middle-end/104721] New: currently_expanding_gimple_stmt isn't cleared properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104721
Bug ID: 104721
Summary: currently_expanding_gimple_stmt isn't cleared properly
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
expand_gimple_basic_block has
currently_expanding_gimple_stmt = stmt;
...
if (new_bb)
return new_bb; <<< currently_expanding_gimple_stmt isn't cleared.
...
if (new_bb)
{
if (can_fallthru)
bb = new_bb;
else
return new_bb; <<< currently_expanding_gimple_stmt isn't
cleared.
}
currently_expanding_gimple_stmt = NULL;
[Bug tree-optimization/91384] [9/10/11/12 Regression] Compare with negation is not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91384 --- Comment #16 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:28068d1115648adcc08ae57372170f3277915a0d commit r12-7417-g28068d1115648adcc08ae57372170f3277915a0d Author: Roger Sayle Date: Mon Feb 28 22:30:27 2022 + PR tree-optimization/91384: peephole2 to eliminate testl after negl. This patch is my proposed solution to PR tree-optimization/91384 which is a missed-optimization/code quality regression on x86_64. The problematic idiom is "if (r = -a)" which is equivalent to both "r = -a; if (r != 0)" and alternatively "r = -a; if (a != 0)". In this particular case, on x86_64, we prefer to use the condition codes from the negation, rather than require an explicit testl instruction. Unfortunately, combine can't help, as it doesn't attempt to merge pairs of instructions that share the same operand(s), only pairs/triples of instructions where the result of each instruction feeds the next. But I doubt there's sufficient benefit to attempt this kind of "combination" (that wouldn't already be caught by the tree-ssa passes). Fortunately, it's relatively easy to fix this up (addressing the regression) during peephole2 to eliminate the unnecessary testl in: movl%edi, %ebx negl%ebx testl %edi, %edi je .L2 2022-02-28 Roger Sayle gcc/ChangeLog PR tree-optimization/91384 * config/i386/i386.md (peephole2): Eliminate final testl insn from the sequence *movsi_internal, *negsi_1, *cmpsi_ccno_1 by transforming using *negsi_2 for the negation. gcc/testsuite/ChangeLog PR tree-optimization/91384 * gcc.target/i386/pr91384.c: New test case.
[Bug middle-end/80270] [9/10/11/12 Regression ICE in extract_bit_field_1 at gcc/expmed.c:1798
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80270 --- Comment #7 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:7e5c6edeb1b2339e10f10bee270e61dbad985800 commit r12-7416-g7e5c6edeb1b2339e10f10bee270e61dbad985800 Author: Roger Sayle Date: Mon Feb 28 22:26:43 2022 + PR middle-end/80270: ICE in extract_bit_field_1 This patch fixes PR middle-end/80270, an ICE-on-valid regression, where performing a bitfield extraction on a variable explicitly stored in a hard register by the user causes a segmentation fault during RTL expansion. Nearly identical source code without the "asm" qualifier compiles fine. The point of divergence is in simplify_gen_subreg which tries to avoid creating non-trivial SUBREGs of hard registers, to avoid problems during register allocation. This suggests the simple solution proposed here, to copy hard registers to a new pseudo in extract_integral_bit_field, just before calling simplify_gen_subreg. 2022-02-28 Roger Sayle Eric Botcazou gcc/ChangeLog PR middle-end/80270 * expmed.cc (extract_integral_bit_field): If OP0 is a hard register, copy it to a pseudo before calling simplify_gen_subreg. gcc/testsuite/ChangeLog * gcc.target/i386/pr80270.c: New test case.
[Bug target/104637] [9/10/11/12 Regression] ICE: maximum number of LRA assignment passes is achieved (30) with -Og -fno-forward-propagate -mavx since r9-5221-gd8fcab689435a29d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104637 --- Comment #4 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:ec1b9ba2d7913fe5e9deacc8e55e7539262f5124 commit r12-7415-gec1b9ba2d7913fe5e9deacc8e55e7539262f5124 Author: Vladimir N. Makarov Date: Mon Feb 28 16:43:50 2022 -0500 [PR104637] LRA: Split hard regs as many as possible on one subpass LRA hard reg split subpass is a small subpass used as the last resort for LRA when it can not assign a hard reg to a reload pseudo by other ways (e.g. by spilling non-reload pseudos). For simplicity the subpass works on one split base (as each split changes pseudo live range info). In this case it results in reaching maximal possible number of subpasses. The patch implements as many non-overlapping hard reg splits splits as possible on each subpass. gcc/ChangeLog: PR rtl-optimization/104637 * lra-assigns.cc (lra_split_hard_reg_for): Split hard regs as many as possible on one subpass. gcc/testsuite/ChangeLog: PR rtl-optimization/104637 * gcc.target/i386/pr104637.c: New.
[Bug target/104698] Inefficient code for DI to TI sign extend on power10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104698 --- Comment #3 from Michael Meissner --- It goes beyond 'just use RTL'. The problem is the code only generates an altivec instruction. So if the __int128_t value is in a GPR, the compiler will need to do a move to the vector registers (1 insn), the instruction, and then move back to the GPRs (2 insns). What it needs to do is have code paths for when the __int128_t is in a GPR and a code path when it is in an altivec register. I have patches that I'm testing that does this (i.e. handles both GPR and Altivec registers) to avoid having to do direct moves.
[Bug target/104208] -mlong-double-64 should override a previous -mabi=ibmlongdouble
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104208
--- Comment #2 from Segher Boessenkool ---
If you want -mlong-double-64 to override -mabi={ibm,ieee}longdouble, you need
make sure that the last of those options on the command line wins. And what
should -mlong-double-128 do in that scheme?
[Bug tree-optimization/91384] [9/10/11/12 Regression] Compare with negation is not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91384 Roger Sayle changed: What|Removed |Added Status|NEW |ASSIGNED CC||roger at nextmovesoftware dot com Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com --- Comment #15 from Roger Sayle --- Patch proposed. https://gcc.gnu.org/pipermail/gcc-patches/2022-February/591013.html
[Bug c++/77384] Assembler error - std::forward(decimal64) already defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77384
--- Comment #3 from danielberger at gmail dot com ---
looks like this is now an ICE on trunk:
> :9:63: error: Two symbols with same comdat_group are not linked by
> the same_comdat_group list.
> 9 | int main(void){return 0;/*stub provided by Compiler Explorer*/}
> | ^
> _ZSt7forwardIDdEOT_RNSt16remove_referenceIS0_E4typeE/765 (constexpr _Tp&&
> std::forward(typename remove_reference<_Tp>::type&) [with _Tp =
> decimal::decimal64]) @0x7fa30f39b000
> Type: function definition analyzed
> Visibility: semantic_interposition no_reorder public weak comdat
> comdat_group:_ZSt7forwardIDdEOT_RNSt16remove_referenceIS0_E4typeE one_only
> visibility_specified
> previous sharing asm name: 761
> References: __gxx_personality_v0/768 (addr)
> Referring:
> Function flags: body
> Called by: _ZNSt4pairIiDdEC2IiDdLb1EEEOT_OT0_/763
> Calls:
> _ZSt7forwardIDdEOT_RNSt16remove_referenceIS0_E4typeE/761 (constexpr _Tp&&
> std::forward(typename remove_reference<_Tp>::type&) [with _Tp =
> ]) @0x7fa30f087cc0
> Type: function definition analyzed
> Visibility: semantic_interposition no_reorder public weak comdat
> comdat_group:_ZSt7forwardIDdEOT_RNSt16remove_referenceIS0_E4typeE one_only
> visibility_specified
> next sharing asm name: 765
> References: __gxx_personality_v0/768 (addr)
> Referring:
> Function flags: body
> Called by: _ZNSt4pairIiDdEC1IiDdLb1EEEOT_OT0_/754
> Calls:
> :9:63: internal compiler error: symtab_node::verify failed
> 0x217c229 internal_error(char const*, ...)
> ???:0
> 0xbdf772 symtab_node::verify_symtab_nodes()
> ???:0
> 0xbfbcaf symbol_table::finalize_compilation_unit()
> ???:0
> Please submit a full bug report, with preprocessed source (by using
> -freport-bug).
> Please include the complete backtrace with any bug report.
> See
[Bug c++/104594] narrowing of -1 to unsigned char not detected with requires concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104594 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org
[Bug c++/104720] New: internal compiler error: in tsubst_copy_and_build, at cp/pt.c:19817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104720
Bug ID: 104720
Summary: internal compiler error: in tsubst_copy_and_build, at
cp/pt.c:19817
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jeanmichael.celerier at gmail dot com
Target Milestone: ---
Created attachment 52527
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52527=edit
Repro for the bug
Repro:
```
$ g++ -std=c++20 processed.cpp -fcoroutines -fext-numeric-literals
In file included from /usr/include/boost/pfr/detail/core17.hpp:11,
from /usr/include/boost/pfr/detail/core.hpp:17,
from /usr/include/boost/pfr/core.hpp:12,
from /usr/include/boost/pfr.hpp:12,
from
/home/jcelerier/ossia/score/3rdparty/avendish/include/avnd/concepts/generic.hpp:7,
from
/home/jcelerier/ossia/score/3rdparty/avendish/include/avnd/concepts/audio_port.hpp:5,
from
/home/jcelerier/ossia/score/3rdparty/avendish/examples/Oscr/ControlGallery.hpp:2,
from /tmp/av/build/examples__ControlGallery_ossia.cpp:3:
/usr/include/boost/pfr/detail/fields_count.hpp: In substitution of
‘template constexpr decltype (sizeof (T{}))
boost::pfr::detail::detect_fields_count_dispatch(boost::pfr::detail::size_t_,
long int, int) [with T = examples::ControlGallery::; long
unsigned int N = ]’:
/usr/include/boost/pfr/detail/fields_count.hpp:305:78: required from
‘constexpr std::size_t boost::pfr::detail::fields_count() [with T = const
examples::ControlGallery::; std::size_t = long unsigned int]’
/usr/include/boost/pfr/detail/core17.hpp:54:54: required from ‘constexpr auto
boost::pfr::detail::tie_as_tuple(T&) [with T = const
examples::ControlGallery::]’
/usr/include/boost/pfr/core.hpp:106:29: required from ‘constexpr auto
boost::pfr::structure_to_tuple(const T&) [with T =
examples::ControlGallery::]’
/home/jcelerier/ossia/score/3rdparty/avendish/include/avnd/concepts/port.hpp:12:549:
required from ‘struct avnd::inputs_type’
/home/jcelerier/ossia/score/3rdparty/avendish/include/avnd/concepts/processor.hpp:36:43:
required from ‘constexpr const int
avnd::mono_sample_array_input_port_count’
/home/jcelerier/ossia/score/3rdparty/avendish/include/avnd/concepts/processor.hpp:60:8:
required by substitution of ‘template requires
(monophonic_audio_processor) && ((inputs_is_value) &&
(outputs_is_value)) struct avnd::effect_container [with T =
examples::ControlGallery]’
/home/jcelerier/ossia/score/3rdparty/avendish/include/avnd/binding/ossia/node.hpp:471:31:
required from ‘class oscr::safe_node_base’
/home/jcelerier/ossia/score/3rdparty/avendish/include/avnd/binding/ossia/port_node.hpp:7:7:
required from ‘class oscr::safe_node’
/tmp/av/build/examples__ControlGallery_ossia.cpp:11:25: required from here
/usr/include/boost/pfr/detail/fields_count.hpp:243:17: internal compiler error:
in tsubst_copy_and_build, at cp/pt.c:19817
243 | -> decltype(sizeof(T{}))
| ^~~
0x16b7aa9 internal_error(char const*, ...)
???:0
0x63d391 fancy_abort(char const*, int, char const*)
???:0
0x69d25e fold_non_dependent_init(tree_node*, int, bool, tree_node*)
???:0
0x807e3d finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
???:0
0x7cd4ae tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x7ccc26 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x7dbe67 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0x66c809 build_new_function_call(tree_node*, vec**, int)
???:0
0x7f9c5c finish_call_expr(tree_node*, vec**, bool,
bool, int)
???:0
0x7dd8b0 instantiate_decl(tree_node*, bool, bool)
???:0
0xfbdbe2 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xfbddfa walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0xfbed9c walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*))
???:0
0x69cde4 maybe_constant_value(tree_node*, tree_node*, bool)
???:0
0x7cd689 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x7dd8b0 instantiate_decl(tree_node*, bool, bool)
???:0
0x6db023 mark_used(tree_node*, int)
???:0
0x66c81e build_new_function_call(tree_node*, vec**, int)
???:0
0x7f9c5c
[Bug libstdc++/104719] Use of `std::move` in libstdc++ leads to worsened debug performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Severity|normal |enhancement Last reconfirmed||2022-02-28 --- Comment #8 from Jonathan Wakely --- (In reply to Vittorio Romeo from comment #6) > > The request is to replace it with some kind of magic that does the same as > > std::move without actually writing std::move. > > More generally speaking, ensure that function such as `std::move`, > `std::forward`, `std::vector::operator[]`, > `std::vector::iterator::operator*`, and so on never appear in debugging > call stacks and do not affect performance in `-Og` (or even `-O0`. They will still appear in debugging stacks, because GCC emits debug info even for inline functions. That means that GDB makes it look like the function was entered and exited, even if the actual code is completely inlined. That was the original topic of PR 96780 (because I don't think it's useful for std::move and std::forward). I think what *should* matters is actual raw performance, not how many stack frames you see in the debugger. However, reading twitter and reddit, I think people would complain about insane levels of complexity in the std::lib *even if it has zero overhead*. > I think the title for my issue is a bit too specific, but I'd like to make > this a wider discussion in how to mitigate debug performance overhead caused > by C++ standard library abstractions. OK, confirming as an enhancement, but somebody will need to do measurements and propose specific patches. I'm not aware of any low-hanging fruit for runtime perf, so the problems need to be identified before they can be fixed.
[Bug libstdc++/104719] Use of `std::move` in libstdc++ leads to worsened debug performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719 --- Comment #7 from Jonathan Wakely --- (In reply to Vittorio Romeo from comment #4) > I like the idea of having the compiler itself fold calls to things like > `std::move` and `std::forward` as suggested in the linked > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96780. That benefits user code too, so that users won't have to use static_cast in their own code because "std::move is slow". > But I think this issue I opened should be more general for any standard > library function that ends up impacting debug performance. Another common > example in the gamedev community is `std::vector`. Does the gamedev community actually use -Og though? Because if they only use -O0 (as is certainly the case for some) then the solution is "don't do that". Do they even use GCC/libstdc++ at all? Would they actually be more likely to if we change anything here? For those who are using -Og, adding always_inline to trivial accessors shouldn't be necessary, because GCC _should_ always inline them anyway. > In this benchmark, which uses `-Og`, you can notice a large performance > difference between a `std::vector` and `int*` dynamic array for > operations that I believe should have equal performance: > - https://quick-bench.com/q/lrS4I-lmDJ3VFP8L8rG2YHGXO-8 > - https://quick-bench.com/q/Uf-t79n7uYWAKdThOL_wxSp12Y0 > > Are the above results also something that should be handled on the compiler > side of things? Or would, for example, marking `std::vector::operator[]` and > `std::vector::iterator::operator*` as `always_inline` remove the performance > discrepancy? Somebody will have to investigate whether lack of inlining is the problem there. My guess would be that it's not due to trivial functions like op[] failing to be inlined, and so always_inline wouldn't help (except at -O0, but "don't do that" if you need performance :-)
[Bug libstdc++/104719] Use of `std::move` in libstdc++ leads to worsened debug performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719 --- Comment #6 from Vittorio Romeo --- > The request is to replace it with some kind of magic that does the same as > std::move without actually writing std::move. More generally speaking, ensure that function such as `std::move`, `std::forward`, `std::vector::operator[]`, `std::vector::iterator::operator*`, and so on never appear in debugging call stacks and do not affect performance in `-Og` (or even `-O0`. I think the title for my issue is a bit too specific, but I'd like to make this a wider discussion in how to mitigate debug performance overhead caused by C++ standard library abstractions.
[Bug libstdc++/104719] Use of `std::move` in libstdc++ leads to worsened debug performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719 Jonathan Wakely changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=67906,| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=81159,| |https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=90428 | --- Comment #5 from Jonathan Wakely --- (In reply to Eric Gallager from comment #3) > Seems related to some of the requests for more warnings about uses of > std::move that might degrade performance, e.g. bug 67906, bug 81159, bug > 90428 > > Also, Marek's blog post about std::move seems relevant here: > https://developers.redhat.com/blog/2019/04/12/understanding-when-not-to- > stdmove-in-c I don't think any of those are relevant, they're about *unnecessary* uses of std::move where that is either entirely redundant or doesn't change semantics but prevents the optimizer doing better on its own. This is about *necessary* uses of std::move, and removing the move here would change semantics and potentially break the code. The request is to replace it with some kind of magic that does the same as std::move without actually writing std::move.
[Bug libstdc++/104719] Use of `std::move` in libstdc++ leads to worsened debug performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719 --- Comment #4 from Vittorio Romeo --- I see that `std::move` is indeed inlined with `-Og`, my apologies on not noticing that. I like the idea of having the compiler itself fold calls to things like `std::move` and `std::forward` as suggested in the linked https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96780. But I think this issue I opened should be more general for any standard library function that ends up impacting debug performance. Another common example in the gamedev community is `std::vector`. In this benchmark, which uses `-Og`, you can notice a large performance difference between a `std::vector` and `int*` dynamic array for operations that I believe should have equal performance: - https://quick-bench.com/q/lrS4I-lmDJ3VFP8L8rG2YHGXO-8 - https://quick-bench.com/q/Uf-t79n7uYWAKdThOL_wxSp12Y0 Are the above results also something that should be handled on the compiler side of things? Or would, for example, marking `std::vector::operator[]` and `std::vector::iterator::operator*` as `always_inline` remove the performance discrepancy?
[Bug libstdc++/104719] Use of `std::move` in libstdc++ leads to worsened debug performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=67906, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=81159, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=90428 CC||egallager at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #3 from Eric Gallager --- Seems related to some of the requests for more warnings about uses of std::move that might degrade performance, e.g. bug 67906, bug 81159, bug 90428 Also, Marek's blog post about std::move seems relevant here: https://developers.redhat.com/blog/2019/04/12/understanding-when-not-to-stdmove-in-c
[Bug libstdc++/104719] Use of `std::move` in libstdc++ leads to worsened debug performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719 --- Comment #2 from Jonathan Wakely --- (In reply to Vittorio Romeo from comment #0) > Would it be possible to replace `std::move` calls internal to `libstdc++` > with a cast, No, absolutely not. > or some sort of compiler intrinsic? No, but the compiler could just fold it away (see PR 96780). > Or maybe mark `std::move` > as "always inline" even without optimizations enabled? Maybe, although since your benchmark shows there is no problem with GCC at -Og I think this is a Clang problem, not libstdc++ or libc++.
[Bug libstdc++/104719] Use of `std::move` in libstdc++ leads to worsened debug performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=96780 --- Comment #1 from Jonathan Wakely --- If it's not inlined at -Og then that's a compiler problem, GCC inlines it at -Og: https://quick-bench.com/q/d1H4VjD_Xns4ef7iOfweIy6rPNM
[Bug c++/104682] Missing deprecated warning on enumerator in class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104682 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Marek Polacek --- Fixed in GCC 12.
[Bug c++/104682] Missing deprecated warning on enumerator in class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104682
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:430c89274d7f82810724126637ffdc5507d442f0
commit r12-7413-g430c89274d7f82810724126637ffdc5507d442f0
Author: Marek Polacek
Date: Fri Feb 25 14:56:13 2022 -0500
c++: Lost deprecated/unavailable attr in class tmpl [PR104682]
When looking into the other PR I noticed that we fail to give a warning
for a deprecated enumerator when the enum is in a class template. This
only happens when the attribute doesn't have an argument. The reason is
that when we tsubst_enum, we create a new enumerator:
build_enumerator (DECL_NAME (decl), value, newtag,
DECL_ATTRIBUTES (decl), DECL_SOURCE_LOCATION (decl));
but DECL_ATTRIBUTES (decl) is null when the attribute was provided
without an argument -- in that case it simply melts into a tree flag.
handle_deprecated_attribute has:
if (!args)
*no_add_attrs = true;
so the attribute isn't retained and we lose it when tsubsting. Same
thing when the attribute is on the enum itself.
Attribute unavailable is a similar case, but it's different in that
it can be a late attribute whereas "deprecated" can't:
is_late_template_attribute has
/* But some attributes specifically apply to templates. */
&& !is_attribute_p ("abi_tag", name)
&& !is_attribute_p ("deprecated", name)
&& !is_attribute_p ("visibility", name))
return true;
else
return false;
which looks strange, but attr-unavailable-9.C tests that we don't error
when
the attribute is applied on a template.
PR c++/104682
gcc/cp/ChangeLog:
* cp-tree.h (build_enumerator): Adjust.
* decl.cc (finish_enum): Make it return the new decl.
* pt.cc (tsubst_enum): Propagate TREE_DEPRECATED and
TREE_UNAVAILABLE.
gcc/testsuite/ChangeLog:
* g++.dg/ext/attr-unavailable-10.C: New test.
* g++.dg/ext/attr-unavailable-11.C: New test.
* g++.dg/warn/deprecated-17.C: New test.
* g++.dg/warn/deprecated-18.C: New test.
[Bug c++/104667] [10 Regression] ICE in is_late_template_attribute, at cp/decl2.cc:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104667 Marek Polacek changed: What|Removed |Added Summary|[10/11 Regression] ICE in |[10 Regression] ICE in |is_late_template_attribute, |is_late_template_attribute, |at cp/decl2.cc:1299 |at cp/decl2.cc:1299 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed.
[Bug c++/104667] [10/11 Regression] ICE in is_late_template_attribute, at cp/decl2.cc:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104667 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:89cea574209521204c8cfe6c4f8c5760581a306c commit r11-9629-g89cea574209521204c8cfe6c4f8c5760581a306c Author: Marek Polacek Date: Thu Feb 24 16:41:53 2022 -0500 c++: ICE with attribute on enumerator [PR104667] When processing a template, the enumerators we build don't have a type yet. But is_late_template_attribute is not prepared to see a _DECL without a type, so we crash on enum tree_code code = TREE_CODE (type); (I found that we don't give the "is deprecated" warning for the enumerator 'f' in the test. Reported as PR104682.) PR c++/104667 gcc/cp/ChangeLog: * decl2.c (is_late_template_attribute): Cope with a decl without a type. gcc/testsuite/ChangeLog: * g++.dg/ext/attrib64.C: New test. (cherry picked from commit c8b0571e334792c0c789438617cfb7faf86ab599)
[Bug c++/104667] [10/11 Regression] ICE in is_late_template_attribute, at cp/decl2.cc:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104667 Marek Polacek changed: What|Removed |Added Summary|[10/11/12 Regression] ICE |[10/11 Regression] ICE in |in |is_late_template_attribute, |is_late_template_attribute, |at cp/decl2.cc:1299 |at cp/decl2.cc:1299 | --- Comment #4 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/104667] [10/11/12 Regression] ICE in is_late_template_attribute, at cp/decl2.cc:1299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104667 --- Comment #3 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:c8b0571e334792c0c789438617cfb7faf86ab599 commit r12-7412-gc8b0571e334792c0c789438617cfb7faf86ab599 Author: Marek Polacek Date: Thu Feb 24 16:41:53 2022 -0500 c++: ICE with attribute on enumerator [PR104667] When processing a template, the enumerators we build don't have a type yet. But is_late_template_attribute is not prepared to see a _DECL without a type, so we crash on enum tree_code code = TREE_CODE (type); (I found that we don't give the "is deprecated" warning for the enumerator 'f' in the test. Reported as PR104682.) PR c++/104667 gcc/cp/ChangeLog: * decl2.cc (is_late_template_attribute): Cope with a decl without a type. gcc/testsuite/ChangeLog: * g++.dg/ext/attrib64.C: New test.
[Bug tree-optimization/104715] [12 Regression] false dangling pointer with strstr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104715 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Jakub Jelinek --- Created attachment 52526 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52526=edit gcc12-pr104715.patch Untested fix. Note, I think pass_waccess::gimple_call_return_arg should also handle BUILT_IN_STRPBRK, but that is probably GCC 13 material.
[Bug libstdc++/104719] New: Use of `std::move` in libstdc++ leads to worsened debug performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104719
Bug ID: 104719
Summary: Use of `std::move` in libstdc++ leads to worsened
debug performance
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: vittorio.romeo at outlook dot com
Target Milestone: ---
`std::accumulate` is defined as follows in `libstdc++`:
```
template
_GLIBCXX20_CONSTEXPR
inline _Tp
accumulate(_InputIterator __first, _InputIterator __last, _Tp __init)
{
// concept requirements
__glibcxx_function_requires(_InputIteratorConcept<_InputIterator>)
__glibcxx_requires_valid_range(__first, __last);
for (; __first != __last; ++__first)
__init = _GLIBCXX_MOVE_IF_20(__init) + *__first;
return __init;
}
```
Where `_GLIBCXX_MOVE_IF_20` is:
```
#if __cplusplus > 201703L
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// DR 2055. std::move in std::accumulate and other algorithms
# define _GLIBCXX_MOVE_IF_20(_E) std::move(_E)
#else
# define _GLIBCXX_MOVE_IF_20(_E) _E
#endif
```
When compiling a program using `std::accumulate` in debug mode, under `-Og`,
there is a noticeable performance impact due to the presence of `std::move`.
- With `std::move`: https://quick-bench.com/q/h_M_AUs3pgBE3bYr82rsA1_VtjU
- Without `std::move`: https://quick-bench.com/q/ysis2b1CgIZkRsO2cqfjZm9Jkio
This performance degradation is one example of why many people (especially in
the gamedev community) are not adopting standard library algorithms and modern
C++ more widely.
Would it be possible to replace `std::move` calls internal to `libstdc++` with
a cast, or some sort of compiler intrinsic? Or maybe mark `std::move` as
"always inline" even without optimizations enabled?
Related issue for libc++:
https://github.com/llvm/llvm-project/issues/53689
[Bug middle-end/104550] bogus warning from -Wuninitialized + -ftrivial-auto-var-init=pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550 qinzhao at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #22 from qinzhao at gcc dot gnu.org --- Fixed in gcc12
[Bug middle-end/104550] bogus warning from -Wuninitialized + -ftrivial-auto-var-init=pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104550 --- Comment #21 from CVS Commits --- The master branch has been updated by Qing Zhao : https://gcc.gnu.org/g:3f3246eb16f554c70c5ce87ad2c785f83adb4625 commit r12-7411-g3f3246eb16f554c70c5ce87ad2c785f83adb4625 Author: Qing Zhao Date: Mon Feb 28 15:58:43 2022 + Suppress uninitialized warnings for new created uses from __builtin_clear_padding folding [PR104550] __builtin_clear_padding() will clear all the padding bits of the object. actually, it doesn't involve any use of an user variable. Therefore, users do not expect any uninitialized warning from it. It's reasonable to suppress uninitialized warnings for all new created uses from __builtin_clear_padding folding. PR middle-end/104550 gcc/ChangeLog: * gimple-fold.cc (clear_padding_flush): Suppress warnings for new created uses. gcc/testsuite/ChangeLog: * gcc.dg/auto-init-pr104550-1.c: New test. * gcc.dg/auto-init-pr104550-2.c: New test. * gcc.dg/auto-init-pr104550-3.c: New test.
[Bug c++/104712] -fkeep-inline-functions causing link errors (debian but not godbolt?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104712
ajrh at ajrh dot net changed:
What|Removed |Added
CC||ajrh at ajrh dot net
--- Comment #6 from ajrh at ajrh dot net ---
Created attachment 52525
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52525=edit
mention -ffunction-sections -Wl,-gc-sections in gcov manual
On deeper investigation the original code had lots of unused inlined explicit
template specializations, and a few of these had constants missing the 'inline'
keyword. So gcc is behaving perfectly.Apologies for the misleading
testcase.
I understand better now:--keep-inline-functions is correctly generating
lots of otherwise dead code, and of course some of it might not link.
Though I only wanted to link it in order to run gcov to find and remove all the
dead code, an amusing catch-22.
Am I correct that a good way to fix this sometimes will be to use
-ffunction-sections -Wl,-gc-sections ?E.g. in the example below:
extern int i;
inline int f(const char *x)
{
return i;
}
int main(int argc, char *argv[])
{
return !!argc;
}
gcc -o x --coverage x.cpp && {x; gcov x}
File 'x.cpp'
Lines executed:100.00% of 2
gcc -o x --coverage -fkeep-inline-functions x.cpp && {x; gcov x}
x.cpp:(.text._Z1fPKc[_Z1fPKc]+0x1c): undefined reference to `i'
g++ -o x --coverage -fkeep-inline-functions -ffunction-sections
-Wl,-gc-sections x.cpp && {x; gcov x}
File 'x.cpp'
Lines executed:50.00% of 4
If that's right it might be useful to mention as a hint in the manual.
Attached a texi patch if so.
Thank you all for the help.
[Bug tree-optimization/104715] [12 Regression] false dangling pointer with strstr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104715 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/104715] [12 Regression] false dangling pointer with strstr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104715
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Other tests:
char *
foo (char *p)
{
{
char q[61] =
"012345678901234567890123456789012345678901234567890123456789";
char *r = q;
p = __builtin_strcat (p, r);
}
return p;
}
char *
bar (char *p)
{
{
char q[] = "0123456789";
char *r = q;
p = __builtin_strstr (p, r);
}
return p;
}
char *
baz (char *p)
{
{
char q[] = "0123456789";
char *r = q;
p = __builtin_strpbrk (p, r);
}
return p;
}
unsigned long
qux (char *p)
{
unsigned long s;
{
char q[] = "0123456789";
char *r = q;
s = __builtin_strspn (p, r);
}
return s;
}
There is false positive warning on foo and bar and not on baz/qux.
Using q directly in the builtin calls doesn't result in a warning though.
I wanted to suggest that pass_waccess::check_call_dangling would add support
for
ERF_RETURNS_ARG functions (ignore all arguments but the one that is returned)
and similarly handle various builtins that guarnatee certain arguments don't
really escape like in addition to those ERF_RETURNS_ARG ones mempcpy, strcat,
strncat, strpbrk, strstr, strspn, strcspn for which only something based on the
first argument can be returned (for strspn/strcspn based on no argument).
But apparently that function doesn't do anything on these testcases because
isn't passed to it.
[Bug target/102429] nvptx: ICE with expand_GOMP_SIMT_XCHG_BFLY : in expand_insn, at optabs.c:7947 for DCmode (complex double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102429 --- Comment #1 from Tom de Vries --- Created attachment 52524 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52524=edit Tentative patch
[Bug c++/98939] [C++23] Implement P1787R6 "Declarations and where to find them"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98939 --- Comment #8 from Marek Polacek --- Additional comments about this proposal: https://gcc.gnu.org/pipermail/gcc-patches/2021-August/578297.html
[Bug c++/104682] Missing deprecated warning on enumerator in class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104682 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #2 from Marek Polacek --- Patch posted: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590946.html
[Bug analyzer/104434] Analyzer doesn't know about "pure" and "const" functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104434 --- Comment #6 from David Malcolm --- OpenBLAS commit adding __attribute__((const)) to the decl: https://github.com/xianyi/OpenBLAS/commit/1c1ffb0591186e50311670369dee2cb450980d9a
[Bug ada/94181] Misidentified dangling reference in container implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94181 --- Comment #1 from simon at pushface dot org --- Fixed in 10.1.0 (also OK in 11.2.0, 12.0.1)
[Bug libstdc++/103407] [12 regression] abi_check FAILs on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103407 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #8 from Jonathan Wakely --- > Oh dear, yes, wrong patch. I'll attach the right one in a few hours. I've now managed to test it on both Solaris 11.3 and 11.4. However, it didn't work on 11.4 and in hindsight it's clear why not: _GLIBCXX_HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT is always 0 on Solaris, as explained in this snippet from acinclude.m4: # The Solaris 2 runtime linker doesn't support the GNU extension of # binding the same symbol to different versions
[Bug tree-optimization/104717] [9/10/11/12 Regression] ICE: verify_ssa failed (Error: type mismatch between an SSA_NAME and its symbol)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104717 --- Comment #2 from Thomas Schwinge --- Reproduced, thanks for the report. The problem disappears when adding '-fno-ipa-pta' to '-O1 -fopenacc -fstack-arrays'. Not yet analyzed the differences. The problem does not reproduce with '-O1 -fopenmp -fipa-pta -fstack-arrays' and code changes as per: -!$acc parallel copyout(array) +!$omp target map(from:array) array = [(-i, i = 1, nn)] -!$acc end parallel +!$omp end target ..., so really points to something specific to OpenACC handling.
[Bug sanitizer/104718] Leak reported for elided static variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104718 --- Comment #2 from Jakub Jelinek --- Well, you can use -fno-tree-dce to make it appear again even with current trunk. Though perhaps we can say that it is user's fault in that case. After all, the testcase does leak memory, because it never deletes those pointers, we just normally don't complain about it because the pointer is still reachable in mut2. But if mut2 isn't actually used, it isn't live anywhere.
[Bug sanitizer/104718] Leak reported for elided static variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104718 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Martin Liška --- Fixed with r10-2106-g6343b6bf3bb83c87.
[Bug sanitizer/104718] New: Leak reported for elided static variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104718 Bug ID: 104718 Summary: Leak reported for elided static variable Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: dlong at cadence dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Created attachment 52523 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52523=edit test case showing incorrect leak report This is a case where g++ is able to detect that a section of code is not used, and as a result it seems to be more-or-less eliding a static variable that references some dynamically allocated storage. It seems that this is confusing the leak sanitizer, which reports the storage for that variable as leaked. Normally, static variables which reference dynamically allocated memory at program exit are not shown as leaks. If you compile the attached test with: g++-9.3.0 -std=c++17 -O2 -fsanitize=address -DUSE2=true lsantest.cc -o lsantest so that the mutex mut2 is not elided and then run ./lsantest, the program exits cleanly and reports no leaks. If you compile it with: g++-9.3.0 -std=c++17 -O2 -fsanitize=address -DUSE2=false lsantest.cc -o lsantest so that mut2 can be elided and then run ./lsantest, the sanitizer will report a leak at exit. mut1 is never elided and never reported as a leak. mut2 will not be reported as a leak if use2 is just static bool instead of static bool const. Nor will it be reported as a leak if mut2 is not declared static.
[Bug tree-optimization/104717] [9/10/11/12 Regression] ICE: verify_ssa failed (Error: type mismatch between an SSA_NAME and its symbol)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104717 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||tschwinge at gcc dot gnu.org, ||vries at gcc dot gnu.org Target Milestone|--- |9.5 Keywords||openacc Ever confirmed|0 |1 Summary|ICE: verify_ssa failed |[9/10/11/12 Regression] |(Error: type mismatch |ICE: verify_ssa failed |between an SSA_NAME and its |(Error: type mismatch |symbol) |between an SSA_NAME and its ||symbol) Last reconfirmed||2022-02-28 Status|UNCONFIRMED |NEW --- Comment #1 from Jakub Jelinek --- Started with r6-5810-g597a8ab9c6f57c416c2b0a734c2098fa0335e628 As -fopenacc has been introduced already in r5-6458-g41dbbb3789850dfea98dd8984f69806284f87b6e , I think this means it is a regression from GCC 5.x.
[Bug ipa/104648] [12 Regression] ICE in cgraphunit_cc_finalize, at cgraphunit.cc:2540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104648 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed on master.
[Bug ipa/104648] [12 Regression] ICE in cgraphunit_cc_finalize, at cgraphunit.cc:2540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104648 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:1060d06b4df8836135ed15d020afbd3637dc625b commit r12-7410-g1060d06b4df8836135ed15d020afbd3637dc625b Author: Martin Liska Date: Mon Feb 28 11:58:01 2022 +0100 Fix error recovery in toplev::finalize. PR ipa/104648 gcc/ChangeLog: * main.cc (main): Use flag_checking instead of CHECKING_P and run toplev::finalize only if there is not error seen. gcc/testsuite/ChangeLog: * g++.dg/pr104648.C: New test.
[Bug tree-optimization/104716] ICE in copy_loop_before, at tree-loop-distribution.cc:952
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104716 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-02-28 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started to ICE with r12-3903-g0288527f47cec6698b31ccb3210816415506009e but unsure if we can call it a regression, because -fno-move-loop-stores wasn't in GCC 11.
[Bug tree-optimization/104717] New: ICE: verify_ssa failed (Error: type mismatch between an SSA_NAME and its symbol)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104717 Bug ID: 104717 Summary: ICE: verify_ssa failed (Error: type mismatch between an SSA_NAME and its symbol) Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gfortran 12.0.1 20220227 snapshot (g:d1574a9b820f17adb9004255e2018967e9be063b) ICEs when compiling the following testcase, extracted from libgomp/testsuite/libgomp.oacc-fortran/privatized-ref-2.f90, w/ -O1 -fopenacc -fstack-arrays: program main implicit none (type, external) integer :: j integer, allocatable :: A(:) A = [(3*j, j=1, 10)] call foo (A, size(A)) deallocate (A) contains subroutine foo (array, nn) integer :: i, nn integer :: array(nn) !$acc parallel copyout(array) array = [(-i, i = 1, nn)] !$acc end parallel end subroutine foo end % gfortran-12.0.1 -O1 -fopenacc -fstack-arrays -c qatodltq.f90 qatodltq.f90:8:16: 8 | deallocate (A) |^ Error: type mismatch between an SSA_NAME and its symbol qatodltq.f90:8:16: Error: type mismatch between an SSA_NAME and its symbol while verifying SSA_NAME A.14_21 in statement # .MEM_20 = VDEF <.MEM_13> A.14_21 = __builtin_alloca_with_align (_19, 32); during IPA pass: pta qatodltq.f90:8:16: internal compiler error: verify_ssa failed 0x1199793 verify_ssa(bool, bool) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220227/work/gcc-12-20220227/gcc/tree-ssa.cc:1211 0xe66da5 execute_function_todo /var/tmp/portage/sys-devel/gcc-12.0.1_p20220227/work/gcc-12-20220227/gcc/passes.cc:2091 0xe67182 do_per_function /var/tmp/portage/sys-devel/gcc-12.0.1_p20220227/work/gcc-12-20220227/gcc/passes.cc:1694 0xe67182 do_per_function /var/tmp/portage/sys-devel/gcc-12.0.1_p20220227/work/gcc-12-20220227/gcc/passes.cc:1684 0xe671dc execute_todo /var/tmp/portage/sys-devel/gcc-12.0.1_p20220227/work/gcc-12-20220227/gcc/passes.cc:2138 BTW, the error is emitted twice in a row.
[Bug c/104627] [12 Regression] New failure in deprecated.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104627
--- Comment #6 from Jakub Jelinek ---
2022-02-28 Jakub Jelinek
PR c/104627
* tree.cc (warn_deprecated_use): For types prefer to use node
and only use TYPE_MAIN_VARIANT (node) if TYPE_STUB_DECL (node) is
NULL.
--- gcc/tree.cc.jj 2022-02-18 12:38:06.172391744 +0100
+++ gcc/tree.cc 2022-02-28 13:17:57.223216010 +0100
@@ -12047,8 +12047,11 @@ warn_deprecated_use (tree node, tree att
attr = DECL_ATTRIBUTES (node);
else if (TYPE_P (node))
{
- tree decl = TYPE_STUB_DECL (TYPE_MAIN_VARIANT (node));
+ tree decl = TYPE_STUB_DECL (node);
if (decl)
+ attr = TYPE_ATTRIBUTES (TREE_TYPE (decl));
+ else if ((decl = TYPE_STUB_DECL (TYPE_MAIN_VARIANT (node)))
+ != NULL_TREE)
{
node = TREE_TYPE (decl);
attr = TYPE_ATTRIBUTES (node);
keeps the previous C behavior for gcc.dg/deprecated.c and the #c5 testcase,
while
maintains the C++ behavior for deprecated-16.C and the #c5 testcase.
[Bug tree-optimization/104716] New: ICE in copy_loop_before, at tree-loop-distribution.cc:952
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104716 Bug ID: 104716 Summary: ICE in copy_loop_before, at tree-loop-distribution.cc:952 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gfortran 12.0.1 20220227 snapshot (g:d1574a9b820f17adb9004255e2018967e9be063b) ICEs when compiling the following testcase w/ -O2 -ftree-loop-distribution -fno-move-loop-stores -fno-tree-dominator-opts: SUBROUTINE FOO() COMMON /WORK/ C2(2, 2) DIMENSION D11(2) EQUIVALENCE (D11(1), C2(1, 1)) DO 40 I = 1, 2 DO 30 J = 1, 2 ASSIGN 10 TO ILBL IF (C2(J, I) .NE. 0.0) THEN ASSIGN 20 TO ILBL ENDIF GO TO ILBL 10 CONTINUE 20 CONTINUE C2(J, I) = C2(J, I) + 1 30 CONTINUE 40 CONTINUE DO 50 I = 1, 2 PRINT 90, I 50 CONTINUE RETURN 90 FORMAT(I5) END % gfortran-12.0.1 -O2 -ftree-loop-distribution -fno-move-loop-stores -fno-tree-dominator-opts -w -c umdmfg43.f during GIMPLE pass: ldist umdmfg43.f:1:20: 1 | SUBROUTINE FOO() |^ internal compiler error: in copy_loop_before, at tree-loop-distribution.cc:952 0x740892 copy_loop_before /var/tmp/portage/sys-devel/gcc-12.0.1_p20220227/work/gcc-12-20220227/gcc/tree-loop-distribution.cc:952 0x740892 generate_loops_for_partition /var/tmp/portage/sys-devel/gcc-12.0.1_p20220227/work/gcc-12-20220227/gcc/tree-loop-distribution.cc:988 0x740892 generate_code_for_partition /var/tmp/portage/sys-devel/gcc-12.0.1_p20220227/work/gcc-12-20220227/gcc/tree-loop-distribution.cc:1348 0x740892 loop_distribution::distribute_loop(loop*, vec const&, control_dependences*, int*, bool*, bool) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220227/work/gcc-12-20220227/gcc/tree-loop-distribution.cc:3167 0xff7caf loop_distribution::execute(function*) /var/tmp/portage/sys-devel/gcc-12.0.1_p20220227/work/gcc-12-20220227/gcc/tree-loop-distribution.cc:3816 0xff899b execute /var/tmp/portage/sys-devel/gcc-12.0.1_p20220227/work/gcc-12-20220227/gcc/tree-loop-distribution.cc:3905
[Bug tree-optimization/104715] [12 Regression] false dangling pointer with strstr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104715
--- Comment #2 from Andrew Pinski ---
Reduced to show it is an issue with strstr:
char *
trim_xml_text(char * intxt)
{
char * etext;
{
char z[]="<", *pz = z;
etext = __builtin_strstr(intxt, pz);
}
return etext;
}
[Bug tree-optimization/104715] [12 Regression] false dangling pointer with strstr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104715 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |12.0 Last reconfirmed||2022-02-28 Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org --- Comment #1 from Martin Liška --- Isolated from autogen: https://sourceforge.net/p/autogen/bugs/211/
[Bug tree-optimization/104715] New: [12 Regression] false dangling pointer with strstr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104715
Bug ID: 104715
Summary: [12 Regression] false dangling pointer with strstr
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
This code warns about a dangling pointer but there is none as strstr does not
return an offset based on the second argument only the first argument
#include
#include
#include
char *
trim_xml_text(char * intxt, char const * pznm)
{
size_t nm_len = strlen(pznm);
char * etext;
{
char z[64], *pz = z;
if (nm_len + 4 >= sizeof(z))
pz = malloc(nm_len + 4);
pz[0] = '<';
pz[1] = '/';
memcpy(pz+2, pznm, nm_len);
nm_len += 2;
pz[nm_len++] = '>';
pz[nm_len] = 0;
*intxt = ' ';
etext = strstr(intxt, pz);
if (pz != z) free(pz);
}
if (etext == NULL)
return etext;
{
char * result = etext + nm_len;
*etext = 0;
return result;
}
}
[Bug target/104713] gcc does not reject -march=i686 -fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713 --- Comment #4 from Adrian Bunk --- (In reply to Jakub Jelinek from comment #3) > Just build for those as -march=i586. There is no "for those" in Debian. There is one build of all packages for one i386 Debian release architecture. Building the Debian i386 architecture with -march=i586 would also remove CMOV support. > i686 is what is used as the supported lowest > common denominator of 32-bit code. This is not true. The lowest common denominator of 32-bit x86 code on Linux is -march=i486, since the 486 is the lowest supported CPU in the kernel. Distributions usually use various baselines higher than 486 for their 32-bit x86 ports. E.g. for distributions dropping support for actual 32-bit hardware (keeping only multiarch/multilib support), using -march=x86-64 (or whatever higher they are using for their 64bit x86) might make more sense since it also brings MMX/SSE/SSE2 which are not in -march=i686 (this also allows using SSE instead of the x87 FPU with its excess precision oddity). > preventing -fcf-protection with > -march=i686 would be a really bad idea, that would basically prevent all of > CET protection for 32-bit code, The toolchain emitting instructions not supported by the selected target is also a really bad idea. gcc rejecting -fcf-protection for < 686 indicates that this option was not intended to enable emitting instructions not already supported by the -march setting. The proper solution might be a -mmultibyte-nops option?
[Bug c++/104699] zero-length-array is not considered as an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104699 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > GCC, Clang, Intel and MSVC all agree here: the int[0] type does not match > the X partial specialization. Although they don't agree for std::is_array, because libc++ uses Clang's __is_array instrinsic.
[Bug c/104627] [12 Regression] New failure in deprecated.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104627
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
On e.g.
struct A {};
struct __attribute__((deprecated)) B {};
typedef struct A C __attribute__((deprecated));
void f1 (struct A *);
void f2 (struct B *);
void f3 (C *);
void f4 (const struct A *);
void f5 (const struct B *);
void f6 (const C *);
the r12-7287 change when compiled by C++ differs just with one extra
+aaa.c:2:36: note: declared here
+2 | struct __attribute__((deprecated)) B {};
+ |^
which wasn't there before, but in C changes:
-aaa.c:6:1: warning: ‘C’ is deprecated [-Wdeprecated-declarations]
+aaa.c:6:1: warning: ‘A’ is deprecated [-Wdeprecated-declarations]
and
-aaa.c:9:1: warning: ‘C’ is deprecated [-Wdeprecated-declarations]
+aaa.c:9:1: warning: ‘A’ is deprecated [-Wdeprecated-declarations]
[Bug target/104714] New: [nvptx] Means to specify any sm_xx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104714 Bug ID: 104714 Summary: [nvptx] Means to specify any sm_xx Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- I'm testing on a couple of boards, with some different settings, and one of those settings is: test native architecture. That is, for an NVIDIA T400 with sm_75, test with -misa=sm_75. But that doesn't work for all boards, because f.i. for a GeForce GT 1030, with sm_61, gcc doesn't support -misa=sm_61. It only support values for which different code may be generated. So, we use instead -misa=sm_53. I have some code in a script, which has this mapped out: ... case $id in GeForce-GT-710) sm=35 opt_sm=35 ;; Quadro-K620) sm=50 opt_sm=35 # Next is 53, too high. ;; GeForce-GT-1030) sm=61 opt_sm=53 # Next is 75, to high. ;; NVIDIA-T400) sm=75 opt_sm=75 ;; *) echo "Unknown id: $id" exit 1 ;; esac ... There are two problems with this: - it's cumbersome to do the mapping, possibly in various locations - the mapping may have to be updated for newer releases, which introduce additional -misa values It would be nice to be able to just specify what board sm you have, and then have gcc figure out the current closest and supported -misa value. We could do this by just allowing any -misa value, say allow -misa=sm_61 and internally map it to sm_53. OTOH, we could use this as an opportunity to sidestep the much regretted name -misa (given that -mptx is used to specify the ptx isa version, and misa the ptx architecture) and introduce say -march for this. This option would then have to be mutually exclusive with -misa. There's an open question though: when specifying sm_61, the code generation internally will switch to sm_53, but what do we emit in the .target field: ... // BEGIN PREAMBLE .version 6.0 .target sm_xx .address_size 64 // END PREAMBLE ... ? sm_53 or sm_61? I'm not entirely sure yet what the benefit would be of having ".target sm_61". F.i. the driver 510.x has given up on the kepler architecture, so we can't use it for a kepler board. But we can generate code for ".target sm_30" and have that same driver map it onto a post-kepler board. So I don't see any benefits here in terms of allowed driver version. So for the moment, I'd go with sm_53. [ FWIW, it would be great if we could simply specify -march=native, and have gcc query the nvidia driver to see what board there is using cuDeviceGetAttribute and CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MAJOR and CU_DEVICE_ATTRIBUTE_COMPUTE_CAPABILITY_MINOR. And possibly handle the situation of multiple boards by using the minimum. But, much more involved to realize. ]
[Bug target/104713] gcc does not reject -march=i686 -fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Just build for those as -march=i586. preventing -fcf-protection with -march=i686 would be a really bad idea, that would basically prevent all of CET protection for 32-bit code, i686 is what is used as the supported lowest common denominator of 32-bit code.
[Bug target/104713] gcc does not reject -march=i686 -fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713 --- Comment #2 from Adrian Bunk --- (In reply to Andrew Pinski from comment #1) > Is OLPC really still around? I thought it died when Google came out with > their chrome books. Sorry for being unclear, this is the historical reason why the binutils/gcc definition of i686 does not include multi-byte NOPs. While all 32bit x86 hardware is pretty dated in the year 2022, there is still a surprisingly large number of users of 32bit x86 including like in the case of this Debian bug on a (likely non-OLPC) Geode. The Debian i386 port has the toolchain configured for i686, and it is therefore a problem that due to this gcc bug an autoconf test for -fcf-protection succeeds.
[Bug target/104713] gcc does not reject -march=i686 -fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713 --- Comment #1 from Andrew Pinski --- Is OLPC really still around? I thought it died when Google came out with their chrome books.
[Bug target/104713] New: gcc does not reject -march=i686 -fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713 Bug ID: 104713 Summary: gcc does not reject -march=i686 -fcf-protection Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bunk at stusta dot de Target Milestone: --- To support the Geode in OLPC, the toolchain definition of i686 does include CMOV but it does not include multi-byte NOPs. https://bugs.debian.org/1004894 is due to autodetection for -fcf-protection that incorrectly succeeds with -march=i686. The bug is likely in https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386-options.cc;h=805539364108eee07f5bda527acd6f39f3f7bf95;hb=HEAD#l2929 A similar problem in a different place was bug 84148. Testcase: $ touch test.c $ gcc -m32 -march=i586 -fcf-protection -c test.c cc1: error: ‘-fcf-protection’ is not compatible with this target $ gcc -m32 -march=i686 -fcf-protection -c test.c $
[Bug fortran/95868] Derived-type deferred-length character component handling broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95868 --- Comment #4 from Tobias Burnus --- I additionally observe the following: string-flag BLK size That makes it difficult to check the length later on during ME processing. In my case, for lang hooks in trans-openmp.c for mapping omp target map(var) where var is allocatable and var%string is a deferred-length allocatable. EXPECTED: * the field's GFC_DECL_STRING_LEN points for 'var%string' to the _string_length component. * TODO: Check whether the debug info is correctly set for those.
[Bug c++/104699] zero-length-array is not considered as an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104699
--- Comment #4 from Jonathan Wakely ---
The std::is_array result is a consequence of the compiler not matching the
is_array partial specialization for int[0]:
using size_t = decltype(sizeof(0));
template struct X { static constexpr bool value = false; };
template struct X { static constexpr bool value =
true; };
static_assert( ! X::value );
GCC, Clang, Intel and MSVC all agree here: the int[0] type does not match the
X partial specialization.
I don't think it would be reasonable for the library to work differently, and I
don't think it's reasonable to add kluges to make_shared to support creating an
object of a type that should only exist as a subobject of some other object.
[Bug c++/104699] zero-length-array is not considered as an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104699 Jonathan Wakely changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=104706 --- Comment #3 from Jonathan Wakely --- (In reply to qingzhe huang from comment #2) > This is the direct result of template specialization "is_array" is > ill-format code or something. No it's not ill-formed, as shown by the fact that is_array::value compiles perfectly fine. You just don't like the result of that trait, but that doesn't make it invalid or ill-formed. > https://www.godbolt.org/z/8nE6qojaE Please read https://gcc.gnu.org/bugs again, which asks for the code to be provided *here* not via a URL. This is the code from the second godbolt.org link: #include #include using namespace std; static_assert( ! std::is_array::value); shared_ptr ptr=make_shared(); This doesn't fail because is_array is ill-formed, it fails because int[0] is neither an unbounded array (like int[]) nor an array with non-zero bound (like int[1]). That means we treat it as a non-array, which then fails to compile because it can't be destroyed using a pseudo-destructor. I don't see any need to support make_shared, it's not a valid type according to the C++ type system, and is only useful as a member of a struct. As I said at PR 104706, this is useless and you wouldn't be able to do anything with shared_ptr even if you could create it. The restrictions on C99 flexible array members are relevant here: - Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero. - Flexible array members may only appear as the last member of a struct that is otherwise non-empty. We *could* treat make_shared(n) as equivalent to make_shared(n) and create a dynamically-sized array, but why bother? Just use int[] instead.
[Bug tree-optimization/104700] [12 Regression] ICE on valid code at -O2 and -O3 with -fno-tree-ccp -fno-tree-dce -fno-tree-vrp on x86_64-linux-gnu: in find_or_generate_expression, at tree-ssa-pre.cc:2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104700 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Richard Biener --- Fixed.
[Bug c++/104712] -fkeep-inline-functions causing link errors (debian but not godbolt?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104712 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Yeah, but I can't reproduce a problem with it in the short testcase. Note, if you want to see on godbolt what you see on Debian, use -fpie -pie options.
[Bug libstdc++/104706] make_unique cannot create struct of size of 0 due to default_delete's static_assert failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104706 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jonathan Wakely --- (In reply to qingzhe huang from comment #0) > See code in compiler explorer: https://www.godbolt.org/z/cb8973Ys1 Again, please provide the info requested by https://gcc.gnu.org/bugs (which clearly says not just a URL to somewhere else). > struct of size of 0 does have its usage and it is supported by GNU C > (https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html). However, make_unique > makes it impossible to create such an unique_ptr because its default_delete > requires "A" must have non-zero size. Good, this code is useless. I dispute that it has uses, except as part of another struct, or with another member present. Specifically, if you create this object using make_unique() then there is no additional memory after it, so no way to ever access the array elements (because there aren't any array elements). I don't think we want to support this.
[Bug rtl-optimization/104154] [12 Regression] Another ICE due to recent ifcvt changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154 Claudiu Zissulescu changed: What|Removed |Added CC||claziss at gmail dot com --- Comment #9 from Claudiu Zissulescu --- I don't know why I haven't been notified for this PR, and I went a bit ahead and pushed a patch on the subject: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590929.html I am bootstrapping and testing Robin's patch as well. Thanks!
[Bug tree-optimization/104700] [12 Regression] ICE on valid code at -O2 and -O3 with -fno-tree-ccp -fno-tree-dce -fno-tree-vrp on x86_64-linux-gnu: in find_or_generate_expression, at tree-ssa-pre.cc:2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104700 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:37b583b9d7719f663656ce65ac822c11471fb540 commit r12-7408-g37b583b9d7719f663656ce65ac822c11471fb540 Author: Richard Biener Date: Mon Feb 28 08:36:25 2022 +0100 tree-optimization/104700 - adjust constant handling in PRE The following refactors find_or_generate_expression to more properly handle constant valued SSA names thereby simplifying the code and avoiding ICEing after the last change to NARY processing. 2022-02-28 Richard Biener PR tree-optimization/104700 * tree-ssa-pre.cc (get_or_alloc_expr_for): Remove and inline into ... (find_or_generate_expression): ... here, simplifying code. * gcc.dg/pr104700-2.c: New testcase. * gcc.dg/torture/pr104700-1.c: Likewise.
[Bug target/104704] [12 Regression] ix86_gen_scratch_sse_rtx doesn't work with explicit XMM7/XMM15/XMM31 usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104704 --- Comment #7 from Hongtao.liu --- (In reply to Hongtao.liu from comment #6) > (In reply to Hongtao.liu from comment #5) > > I notice it regresses > > > > FAIL: gcc.target/i386/incoming-11.c scan-assembler-not andl[\\t > > ]*\\$-16,[\\t ]*%esp > > Why replace ix86_gen_scratch_sse_rtx with gen_reg_rtx will affect this > testcase, hmm. Oh, it's just revert of r12-2665-g7f4c3943f795fd
[Bug target/104704] [12 Regression] ix86_gen_scratch_sse_rtx doesn't work with explicit XMM7/XMM15/XMM31 usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104704 --- Comment #6 from Hongtao.liu --- (In reply to Hongtao.liu from comment #5) > I notice it regresses > > FAIL: gcc.target/i386/incoming-11.c scan-assembler-not andl[\\t > ]*\\$-16,[\\t ]*%esp Why replace ix86_gen_scratch_sse_rtx with gen_reg_rtx will affect this testcase, hmm.
[Bug c++/104709] A translated error message will include untanslated parts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104709 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-02-28
[Bug c++/104712] -fkeep-inline-functions causing link errors (debian but not godbolt?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104712 --- Comment #4 from Jonathan Wakely --- The in-class declaration is the definition if it's inline and has an initializer.
[Bug middle-end/104381] [12 Regression] -gtoggle no longer applied when using optimize attribute since r12-4608-gb4702276615ff8d4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104381 Martin Liška changed: What|Removed |Added CC||slyfox at gcc dot gnu.org --- Comment #3 from Martin Liška --- *** Bug 104705 has been marked as a duplicate of this bug. ***
[Bug middle-end/104705] [12 regression] ICE ‘global_options’ are modified in local context in cl_optimization_compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104705 Martin Liška changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #3 from Martin Liška --- The root cause is the same as PR104381. *** This bug has been marked as a duplicate of bug 104381 ***
[Bug target/104704] [12 Regression] ix86_gen_scratch_sse_rtx doesn't work with explicit XMM7/XMM15/XMM31 usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104704 --- Comment #5 from Hongtao.liu --- I notice it regresses FAIL: gcc.target/i386/incoming-11.c scan-assembler-not andl[\\t ]*\\$-16,[\\t ]*%esp
[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964 Roger Sayle changed: What|Removed |Added CC||cnsun at uwaterloo dot ca --- Comment #15 from Roger Sayle --- *** Bug 100536 has been marked as a duplicate of this bug. ***
[Bug middle-end/100536] ICE: in expand_call with large union (1GB) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100536 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Roger Sayle --- This bug is a duplicate of PR 84964, for which a patch has just been proposed. *** This bug has been marked as a duplicate of bug 84964 ***
[Bug c++/84964] [9/10/11/12 Regression] ICE in expand_call, at calls.c:4540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84964 Roger Sayle changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com CC||roger at nextmovesoftware dot com --- Comment #14 from Roger Sayle --- Patch proposed. https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590961.html
