[Bug target/99889] Add powerpc ELFv1 support for -fpatchable-function-entry* with "o" sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99889 Kewen Lin changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org --- Comment #2 from Kewen Lin --- By checking the related materials and discussions, I think the original issue does still exist even if the recent trunk makes the linking error gone because of comdat flag being introduced onto the __patchable_function_entries section. The justification is that the flag SECTION_LINK_ORDER is to ensure "__patchable_function_entries" section would be discarded or retained as its link_to section together, it's expected that the link_to section is the section holding function code, but on ELFv1 64bit the link_to section is section .opd, it's wrong. And without comdat flag supported, we still need to support SECTION_LINK_ORDER to work well.
[Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> Basically:
> void
> aarch64_print_patchable_function_entry (FILE *file,
> unsigned HOST_WIDE_INT
> patch_area_size,
> bool record_p)
> {
> if (cfun->machine->label_is_assembled
> && aarch64_bti_enabled ()
> && !cgraph_node::get (cfun->decl)->only_called_directly_p ())
>
>
> That last check just needs to be removed as there is no way to know if the
> linker will output a veneer.
That only fixes the -fpatchable-function-entry= case.
aarch64-bti-insert.cc needs to be fixed too:
/* Since a Branch Target Exception can only be triggered by an indirect call,
we exempt function that are only called directly. We also exempt
functions that are already protected by Return Address Signing (PACIASP/
PACIBSP). For all other cases insert a BTI C at the beginning of the
function. */
if (!cgraph_node::get (cfun->decl)->only_called_directly_p ())
[Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2022-08-17
Status|UNCONFIRMED |NEW
--- Comment #3 from Andrew Pinski ---
Basically:
void
aarch64_print_patchable_function_entry (FILE *file,
unsigned HOST_WIDE_INT patch_area_size,
bool record_p)
{
if (cfun->machine->label_is_assembled
&& aarch64_bti_enabled ()
&& !cgraph_node::get (cfun->decl)->only_called_directly_p ())
That last check just needs to be removed as there is no way to know if the
linker will output a veneer.
[Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671 --- Comment #2 from D Scott Phillips --- th(In reply to Andrew Pinski from comment #1) > Shouldn't the linker add the BTI inside the ___veneer instead? The bti instruction has to be placed at the target of the indirect branch (at the top of `func` in this case) so I don't think it would be possible to work around this just within the veneer.
[Bug target/106671] aarch64: BTI instruction are not inserted for cross-section direct calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671 --- Comment #1 from Andrew Pinski --- Shouldn't the linker add the BTI inside the ___veneer instead?
[Bug c/106672] support Apple's old __private_extern__ keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106672 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-08-17 Ever confirmed|0 |1
[Bug c/106672] New: support Apple's old __private_extern__ keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106672
Bug ID: 106672
Summary: support Apple's old __private_extern__ keyword
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: egallager at gcc dot gnu.org
Reporter: egallager at gcc dot gnu.org
CC: iains at gcc dot gnu.org
Target Milestone: ---
Back when Apple had its own version of GCC it supported a __private_extern__
keyword, and clang still supports this keyword, albeit with a deprecation
warning:
$ clang -c __private_extern__.c
__private_extern__.c:1:24: warning: use of __private_extern__ on a declaration
may not produce external symbol private to the linkage unit and is deprecated
[-Wprivate-extern]
__private_extern__ int foo;
^
__private_extern__.c:1:24: note: use __attribute__((visibility("hidden")))
attribute instead
1 warning generated.
$
Meanwhile, GCC rejects the same code with:
$ /usr/local/bin/gcc -c __private_extern__.c
__private_extern__.c:1:19: error: expected ';' before 'int'
1 | __private_extern__ int foo;
| ^~~~
| ;
$
While __private_extern__ should no longer be used in new code, there is still
some old code out there with __private_extern__ in it that one may wish to
compile. Some projects hack around this by adding
-D__private_extern__=__attribute__\(\(__visibility__\("hidden"\)\)\) to their
compile flags, but it would be easier if GCC just handled this automatically. I
am self-assigning, although it may take me awhile to get to, so if someone else
thinks they can do this first, feel free to take it from me.
[Bug target/106671] New: aarch64: BTI instruction are not inserted for cross-section direct calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671 Bug ID: 106671 Summary: aarch64: BTI instruction are not inserted for cross-section direct calls Product: gcc Version: 12.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: scott at os dot amperecomputing.com Target Milestone: --- Created attachment 53469 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53469=edit [PATCH] aarch64: Add a BTI test for cross-section calls Direct calls to functions in other sections do not cause `bti c` instructions to be added to the callee. During linking, if the sections are farther apart than a direct branch can reach, a trampoline indirect branch sequence may be added. Because the callee does not have a `bti c` instruction, the call will result in a Branch Target exception. With the attached test case on `cc (GCC) 12.1.1 20220507 (Red Hat 12.1.1-1)`, the code compiles to (trimmed): .text func: mov w0, 37 ret .section.main.text,"ax",@progbits main: hint25 // paciasp stp x29, x30, [sp, -16]! mov x29, sp bl func cmp w0, 37 csetw0, ne ldp x29, x30, [sp], 16 hint29 // autiasp ret And then linking yields: 00040118 : 40118: 528004a0mov w0, #0x25 // #37 4011c: d65f03c0ret 1004 : 1004: d503233fpaciasp 10040004: a9bf7bfdstp x29, x30, [sp, #-16]! 10040008: 910003fdmov x29, sp 1004000c: 9409bl 10040030 <___veneer> 10040010: 7100941fcmp w0, #0x25 10040014: 1a9f07e0csetw0, ne // ne = any 10040018: a8c17bfdldp x29, x30, [sp], #16 1004001c: d50323bfautiasp 10040020: d65f03c0ret 10040030 <___veneer>: 10040030: 90f80010adrpx16, 4 <_start> 10040034: 91046210add x16, x16, #0x118 10040038: d61f0200br x16 Finally, I've made this little test case, but the real case where I'm running into this is in the Linux kernel, where the two sections are .init.text and .text, and the equivalent of a ___veneer thing is in the module plt.
[Bug rtl-optimization/106594] [13 Regression] sign-extensions no longer merged into addressing mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106594 --- Comment #8 from Roger Sayle --- Time for a status update. The PR title is a little misleading; sign-extensions aren't really the problem, but it turns out that the equivalent zero-extensions aren't always optimized as well as the equivalent sign-extensions (due to alternate possible RTL representations), even on symmetric targets like aarch64. The following patch solves the underlying issue reported in the PR: diff --git a/gcc/combine.cc b/gcc/combine.cc index a5fabf3..d739cae 100644 --- a/gcc/combine.cc +++ b/gcc/combine.cc @@ -7288,7 +7288,17 @@ expand_compound_operation (rtx x) && (STORE_FLAG_VALUE & ~GET_MODE_MASK (inner_mode)) == 0) return SUBREG_REG (XEXP (x, 0)); + /* If ZERO_EXTEND is cheap on this target, do nothing, +i.e. don't attempt to convert it to a pair of shifts. */ + if (set_src_cost (x, mode, optimize_this_for_speed_p) + <= COSTS_N_INSNS (1)) + return x; } + /* Likewise, if SIGN_EXTEND is cheap, do nothing. */ + else if (GET_CODE (x) == SIGN_EXTEND + && set_src_cost (x, mode, optimize_this_for_speed_p) + <= COSTS_N_INSNS (1)) +return x; /* If we reach here, we want to return a pair of shifts. The inner shift is a left shift of BITSIZE - POS - LEN bits. The outer The explanation/motivation for this fix is in the code immediately above in expand_compound_operation, that considers converting SIGN_EXTEND into ZERO_EXTEND, but checks set_src_cost to confirm that it'd be cheaper than the pair of shifts mentioned at the bottom. By converting SIGN_EXTEND to ZERO_EXTEND earlier (for example during the tree-ssa passes), the new ZERO_EXTEND now passes through the above logic and always gets converted to a pair of shifts, regardless of the cost, triggering the regresssion. Thanks to Tamar for confirming the above change results in a significant performance benefit (sometimes ~5%) on aarch64. The complication is that the above change, to preserve ZERO_EXTEND/SIGN_EXTEND in GCC's preferred canonical RTL when these operations are cheap, exposes a number of latent bugs and missed optimization opportunities (on at least x86 and aarch64). I'm currently bootstrapping and regression testing a number of fixes to prevent these and minimize disruption should the above change be approved. Hence we're making progress, but a clean "fix" isn't ready just yet. p.s. HP is right that REG_EQUAL notes may help (when x & 0xff is cheaper than x & 0x23, i.e. if we're really doing AND then including nonzero_bits is free, but if this is a zero_extension, the AND is implicit, and will only be recognized as an addressing mode if the precision mask isn't modified by nonzero_bits).
[Bug analyzer/106003] RFE: -fanalyzer could complain about misuse of file-descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106003 Bug 106003 depends on bug 106551, which changed state. Bug 106551 Summary: [13 Regression] dup2 causes -fanalyzer ICE in valid_to_unchecked_state, at analyzer/sm-fd.cc:751 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106551 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug analyzer/106551] [13 Regression] dup2 causes -fanalyzer ICE in valid_to_unchecked_state, at analyzer/sm-fd.cc:751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106551 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||dmalcolm at gcc dot gnu.org --- Comment #8 from David Malcolm --- Presumably fixed by the above commit; marking as resolved.
[Bug analyzer/106539] -fanalyzer doesn't consider that realloc could shrink the buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106539 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from David Malcolm --- Presumably fixed by the above commit; marking as resolved.
[Bug target/106640] [13 Regression] during RTL pass: stv ICE: RTL check: expected elt 1 type 'i' or 'n', have 'e' (rtx ashift) in compute_convert_gain, at config/i386/i386-features.cc:1251/1285
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106640 --- Comment #2 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:524c06610d2f28688655f12184e5bc615474 commit r13-2100-g524c06610d2f28688655f12184e5bc615474 Author: Roger Sayle Date: Wed Aug 17 22:23:33 2022 +0100 [Committed] PR target/106640: Fix use of XINT in TImode compute_convert_gain. Thanks to Zdenek Sojka for reporting PR target/106640 where an RTL checking build reveals a thinko in my recent patch to support TImode shifts/rotates in STV. My "senior moment" was to inappropriately use XINT where I should be using INTVAL of XEXP. 2022-08-17 Roger Sayle gcc/ChangeLog PR target/106640 * config/i386/i386-features.cc (timde_scalar_chain::compute_convert_gain): Replace incorrect use of XINT with INTVAL (XEXP (src, 1)).
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349 --- Comment #20 from CVS Commits --- The releases/gcc-10 branch has been updated by Segher Boessenkool : https://gcc.gnu.org/g:cebbbc1596001e86c3c4d5f2223ddac50e5e0bb8 commit r10-10951-gcebbbc1596001e86c3c4d5f2223ddac50e5e0bb8 Author: Segher Boessenkool Date: Tue Apr 26 11:26:09 2022 + rs6000: Make the has_arch target selectors actually work 2022-04-26 Segher Boessenkoool gcc/testsuite/ PR target/105349 * lib/target-supports.exp (check_effective_target_has_arch_pwr5): Use the specified dg-options. (check_effective_target_has_arch_pwr6): Ditto. (check_effective_target_has_arch_pwr7): Ditto. (check_effective_target_has_arch_pwr8): Ditto. (check_effective_target_has_arch_pwr9): Ditto. (check_effective_target_has_arch_ppc64): Ditto. (cherry picked from commit ad56a60f58c1ed662deaf60d5736c332ec2caabb)
[Bug testsuite/105349] [12 regression] gcc.target/powerpc/bswap-brw.c fails after r12-8221
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105349 --- Comment #19 from CVS Commits --- The releases/gcc-11 branch has been updated by Segher Boessenkool : https://gcc.gnu.org/g:7b03e09c1c6058cd89ceea223ba11caca5ba2844 commit r11-10212-g7b03e09c1c6058cd89ceea223ba11caca5ba2844 Author: Segher Boessenkool Date: Tue Apr 26 11:26:09 2022 + rs6000: Make the has_arch target selectors actually work 2022-04-26 Segher Boessenkoool gcc/testsuite/ PR target/105349 * lib/target-supports.exp (check_effective_target_has_arch_pwr5): Use the specified dg-options. (check_effective_target_has_arch_pwr6): Ditto. (check_effective_target_has_arch_pwr7): Ditto. (check_effective_target_has_arch_pwr8): Ditto. (check_effective_target_has_arch_pwr9): Ditto. (check_effective_target_has_arch_pwr10): Ditto. (check_effective_target_has_arch_ppc64): Ditto. (cherry picked from commit ad56a60f58c1ed662deaf60d5736c332ec2caabb)
[Bug c++/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 67906, which changed state. Bug 67906 Summary: Missing warning about std::move without effect https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67906 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/67906] Missing warning about std::move without effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67906 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #13 from Marek Polacek --- Test added.
[Bug c++/67906] Missing warning about std::move without effect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67906 --- Comment #12 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:177e93e95272e9b373203dee5b28d2b284ffa05e commit r13-2099-g177e93e95272e9b373203dee5b28d2b284ffa05e Author: Marek Polacek Date: Wed Aug 17 15:43:45 2022 -0400 c++: Add new std::move test [PR67906] As discussed in 67906, let's make sure we don't warn about a std::move when initializing when there's a T(const T&&) ctor. PR c++/67906 gcc/testsuite/ChangeLog: * g++.dg/cpp0x/Wredundant-move11.C: New test.
[Bug fortran/106670] New: [OpenMP][5.2] Warn for unknown '!$ompx' (!$omx') sentinels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106670
Bug ID: 106670
Summary: [OpenMP][5.2] Warn for unknown '!$ompx' (!$omx')
sentinels
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic, openmp
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
OpenMP 5.2 reserves 'ompx' ('!$ompx') and for fixed-form Fortran !/*/c + $omx',
used "for implementation-defined extensions to the OpenMP directives."
For C/C++, those are diagnosed – either by default (-Wattributes) or with
some flag (-Wunknown-pragmas), implied by -Wall:
foo.C:1: warning: ignoring ‘#pragma ompx nothing2’ [-Wunknown-pragmas]
1 | #pragma ompx nothing2
|
foo.C:2:1: warning: attribute ignored [-Wattributes]
2 | [[ompx::directive (nothing2)]];
| ^~
However, for Fortran, !$ompx is silently ignored. I think it would be useful to
have some flag to warn about unknown '!$ompx' that can be silenced.
We currently support:
!$omp → -fopenmp
!$ → -fopenmp (Conditional Compilation Sentinel)
!$acc → -fopenacc
!GCC$ →
https://gcc.gnu.org/onlinedocs/gfortran/GNU-Fortran-Compiler-Directives.html
Questions:
* What to warn for – only !$ompx/!$omx or more?
* Which -W... to use for this? Especially when only warning for
Examples:
!$omp nothing2 ! only free form
!$omx nothing2! only fixed form
[Bug libstdc++/106664] std::valarray::resize(0): spurious -Walloc-zero warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106664 --- Comment #2 from Vadim Zeitlin --- FWIW I think it's a rather useful warning as allocating 0 bytes is rarely intentional, i.e. I haven't seen any false positive occurrences of this warning in my own code. And in valarray case, it indicates a small but real problem too: empty valarray shouldn't allocate memory at all, not allocate 0 bytes. And AFAICS it would be pretty trivial to fix the warning in valarray code (but I have never contributed to libstdc++ so I don't know how to do it and don't volunteer to do it neither).
[Bug middle-end/106609] sh3eb-elf cross compiler is being miscompiled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609 Andrew Pinski changed: What|Removed |Added Component|target |middle-end Summary|[SH] miscompilation due to |sh3eb-elf cross compiler is |incorrect elimination of|being miscompiled |comparisons to 0| Target|sh3eb-elf |x86_64-linux-gnu --- Comment #8 from Andrew Pinski --- >I can reproduce with gcc-12 as host compiler, but not with gcc-11 as host >compiler. That is good to know. Now someone needs to figure out where the target compiler is being miscompiled ...
[Bug c++/90428] -Wredundant-move could warn for more cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90428 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Marek Polacek --- Should be fixed.
[Bug libstdc++/106664] std::valarray::resize(0): spurious -Walloc-zero warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106664 Andrew Pinski changed: What|Removed |Added Component|tree-optimization |libstdc++ --- Comment #1 from Andrew Pinski --- I don't know how important it is to fix this really -Walloc-zero is not enabled by either -Wextra or -Wall
[Bug c++/90428] -Wredundant-move could warn for more cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90428
--- Comment #3 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:6c136d53e89e32fe9d22e41e5df89c08d3470049
commit r13-2097-g6c136d53e89e32fe9d22e41e5df89c08d3470049
Author: Marek Polacek
Date: Wed Aug 17 13:36:52 2022 -0400
c++: Extend -Wredundant-move for const-qual objects [PR90428]
In this PR, Jon suggested extending the -Wredundant-move warning
to warn when the user is moving a const object as in:
struct T { };
T f(const T& t)
{
return std::move(t);
}
where the std::move is redundant, because T does not have
a T(const T&&) constructor (which is very unlikely). Even with
the std::move, T(T&&) would not be used because it would mean
losing the const. Instead, T(const T&) will be called.
I had to restructure the function a bit, but it's better now. This patch
depends on my other recent patches to maybe_warn_pessimizing_move.
PR c++/90428
gcc/cp/ChangeLog:
* typeck.cc (can_do_rvo_p): Rename to ...
(can_elide_copy_prvalue_p): ... this.
(maybe_warn_pessimizing_move): Extend the
-Wredundant-move warning to warn about std::move on a
const-qualified object.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/Wredundant-move1.C: Adjust dg-warning.
* g++.dg/cpp0x/Wredundant-move9.C: Likewise.
* g++.dg/cpp0x/Wredundant-move10.C: New test.
[Bug c++/106666] Anonymous struct incorrectly allows types with constructors if placed in a known sized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 77314. *** This bug has been marked as a duplicate of bug 77314 ***
[Bug c++/77314] Allows C++11 POD types in anonymous structures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77314 Andrew Pinski changed: What|Removed |Added CC||twmouton at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 10 has been marked as a duplicate of this bug. ***
[Bug c++/106669] New: incorrect definition of viewable_range ("more madness with move-only views")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106669
Bug ID: 106669
Summary: incorrect definition of viewable_range ("more madness
with move-only views")
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: h2+bugs at fsfe dot org
Target Milestone: ---
In GCC12.1 we now have ranges that are views, but whose references aren't
viewable. See the code below.
Before views were allowed to be move-only, S was not considered a view, but `S
&` was considered viewable (it would just be wrapped in ref_view). Now, S is a
valid view, and S (no-ref!) is also a viewable range. But apparently the
requirements for viewable_range were not correctly updated, because `S &` is
now no longer viewable. The code in the standard is the following:
template
concept viewable_range =
range &&
((view> && constructible_from, T>) ||
(!view> &&
(is_lvalue_reference_v || (movable> &&
!is-initializer-list;
For any `T &` where T is a view but not copy-constructible, this concept will
evaluate to false. I am assuming this is an LWG issue and will report on the
reflector unless you see a good reason for the current behaviour?
#include
#include
struct S : std::string_view, std::ranges::view_base
{
S() = delete;
S(S const &) = delete;
S(S &&) = default;
S & operator=(S const &) = delete;
S & operator=(S &&) = default;
S(std::string_view v) : std::string_view{v} {}
};
static_assert(std::ranges::view); // fails expectedly on
gcc11.3, passes on gcc12.1
static_assert(std::ranges::viewable_range); // fails expectedly on
gcc11.3, passes on gcc12.1
static_assert(std::ranges::viewable_range); // passes on gcc11.3, fails
unexpectedly on gcc12.1
int main()
{
S s{"foo"};
s | std::views::filter([] (char) { return true;}); // this fails in gcc12.1
}
[Bug target/106609] [SH] miscompilation due to incorrect elimination of comparisons to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #7 from Mikael Pettersson --- I can reproduce with gcc-12 as host compiler, but not with gcc-11 as host compiler. I'm using the example in comment #4, and a recent HEAD of master (bac07a1da24) configured with --target=sh3eb-elf. With "GCC: (GNU) 11.3.1 20220812" as host compiler, the cross-compiler compiles (-O1) the example to: _f: cmp/pz r4 bf.s.L3 add r4,r5 tst r5,r5 bf .L4 rts mov r4,r0 .align 1 .L3: rts mov #1,r0 .align 1 .L4: rts mov #3,r0 which looks ok to me (not knowing SH asm...). With "GCC: (GNU) 12.1.1 20220812" (the 12.2.0 RC) as host compiler, the cross-compiler instead compiles the example to: _f: cmp/pz r4 bf .L3 bf .L4 rts mov r4,r0 .align 1 .L3: rts mov #1,r0 .align 1 .L4: rts mov #3,r0 which looks broken.
[Bug c++/89780] -Wpessimizing-move is too agressive with templates and recommends pessimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89780
--- Comment #9 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:6602a2b2dee16af6e2d451c704789356042b5881
commit r13-2096-g6602a2b2dee16af6e2d451c704789356042b5881
Author: Marek Polacek
Date: Wed Aug 3 19:47:30 2022 -0400
c++: Tweak for -Wpessimizing-move in templates [PR89780]
In my previous patches I've been extending our std::move warnings,
but this tweak actually dials it down a little bit. As reported in
bug 89780, it's questionable to warn about expressions in templates
that were type-dependent, but aren't anymore because we're instantiating
the template. As in,
template
Dest withMove() {
T x;
return std::move(x);
}
template Dest withMove(); // #1
template Dest withMove(); // #2
Saying that the std::move is pessimizing for #1 is not incorrect, but
it's not useful, because removing the std::move would then pessimize #2.
So the user can't really win. At the same time, disabling the warning
just because we're in a template would be going too far, I still want to
warn for
template
Dest withMove() {
Dest x;
return std::move(x);
}
because the std::move therein will be pessimizing for any instantiation.
So I'm using the suppress_warning machinery to that effect.
Problem: I had to add a new group to nowarn_spec_t, otherwise
suppressing the -Wpessimizing-move warning would disable a whole bunch
of other warnings, which we really don't want.
PR c++/89780
gcc/cp/ChangeLog:
* pt.cc (tsubst_copy_and_build) : Maybe suppress
-Wpessimizing-move.
* typeck.cc (maybe_warn_pessimizing_move): Don't issue warnings
if they are suppressed.
(check_return_expr): Disable -Wpessimizing-move when returning
a dependent expression.
gcc/ChangeLog:
* diagnostic-spec.cc (nowarn_spec_t::nowarn_spec_t): Handle
OPT_Wpessimizing_move and OPT_Wredundant_move.
* diagnostic-spec.h (nowarn_spec_t): Add NW_REDUNDANT enumerator.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/Wpessimizing-move3.C: Remove dg-warning.
* g++.dg/cpp0x/Wredundant-move2.C: Likewise.
[Bug c++/106423] -Wc++20-compat diagnostics not suppressed by #pragma GCC diagnostic ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106423 --- Comment #4 from Ville Voutilainen --- (In reply to Tom Honermann from comment #3) > I believe this issue can be resolved as fixed via commit > 60468d6cd46a3bd3afe8ff856f82afcd4c65a217 for the gcc 13 release. Yes, it's normal procedure that the bz will be closed as fixed once the patches have been merged, it's just a separate step.
[Bug c++/106276] Missing -Wpessimizing-move warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106276
--- Comment #8 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:8d22c7cb8b1a6f9b67c54a798dd5504244614e51
commit r13-2095-g8d22c7cb8b1a6f9b67c54a798dd5504244614e51
Author: Marek Polacek
Date: Mon Aug 1 17:02:23 2022 -0400
c++: Extend -Wpessimizing-move to other contexts
In my recent patch which enhanced -Wpessimizing-move so that it warns
about class prvalues too I said that I'd like to extend it so that it
warns in more contexts where a std::move can prevent copy elision, such
as:
T t = std::move(T());
T t(std::move(T()));
T t{std::move(T())};
T t = {std::move(T())};
void foo (T);
foo (std::move(T()));
This patch does that by adding two maybe_warn_pessimizing_move calls.
These must happen before we've converted the initializers otherwise the
std::move will be buried in a TARGET_EXPR.
PR c++/106276
gcc/cp/ChangeLog:
* call.cc (build_over_call): Call maybe_warn_pessimizing_move.
* cp-tree.h (maybe_warn_pessimizing_move): Declare.
* decl.cc (build_aggr_init_full_exprs): Call
maybe_warn_pessimizing_move.
* typeck.cc (maybe_warn_pessimizing_move): Handle TREE_LIST and
CONSTRUCTOR. Add a bool parameter and use it. Adjust a diagnostic
message.
(check_return_expr): Adjust the call to
maybe_warn_pessimizing_move.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/Wpessimizing-move7.C: Add dg-warning.
* g++.dg/cpp0x/Wpessimizing-move8.C: New test.
[Bug c++/106423] -Wc++20-compat diagnostics not suppressed by #pragma GCC diagnostic ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106423 --- Comment #3 from Tom Honermann --- I believe this issue can be resolved as fixed via commit 60468d6cd46a3bd3afe8ff856f82afcd4c65a217 for the gcc 13 release.
[Bug c++/106668] ICE: friend function in struct declaration in generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106668
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=105852
--- Comment #3 from Andrew Pinski ---
Here is another testcase using templated lambda instead of auto:
void foo();
bool ok = [] () {
struct y {
friend void foo();
};
return 0;
}();
[Bug c++/106668] ICE: friend function in struct declaration in generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106668 --- Comment #2 from Marek Polacek --- Fixed on trunk by commit e8ed26c2ac38ab1f6ed5a627d9089a9243e06a0c Author: Jason Merrill Date: Tue Jun 7 15:52:30 2022 -0400 c++: non-templated friends [PR105852] The previous patch for 105852 avoids copying DECL_TEMPLATE_INFO from a non-templated friend, but it really shouldn't have it in the first place. PR c++/105852
[Bug c++/106668] ICE: friend function in struct declaration in generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106668 --- Comment #1 from Jean-Michaël Celerier --- When checking on gcc.godbolt.org it seems that it crashes as far back as GCC 4.9.0 (and 4.8 doesn't seem to be able to compile generic lambdas)
[Bug c++/106668] New: ICE: friend function in struct declaration in generic lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106668
Bug ID: 106668
Summary: ICE: friend function in struct declaration in generic
lambda
Product: gcc
Version: 12.1.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: ---
Repro: foo.cpp
void foo();
bool ok = [] (auto x) {
struct y {
friend void foo();
};
return 0;
}(0);
build:
$ g++ foo.cpp
: In instantiation of ' [with auto:1 = int]':
:7:6: required from here
:3:14: internal compiler error: Segmentation fault
3 | struct y {
| ^
0x1ba65f9 internal_error(char const*, ...)
???:0
0x878158 instantiate_decl(tree_node*, bool, bool)
???:0
0x8936ab instantiate_pending_templates(int)
???:0
0x79c46d c_parse_final_cleanups()
???: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 rtl-optimization/81501] mulitple calls to __tls_get_addr() with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81501 --- Comment #7 from Yann Droneaud --- (In reply to Roy Jacobson from comment #6) > We recently upgraded our toolchain from GCC9 to GCC11, and we're seeing > __tls_get_addr take up to 10% of total runtime under some workloads, where > it was 1-2% before. > > It seems that some changes to the optimization passes in 10 or 11 have > significantly increased the impact of this problem. In bug #82803, comment #12, (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82803#c12), I've shown a workaround I used, which might be useful until GCC handle __tls_get_addr() as returning a constant addresses that doesn't need to be looked up multiple times in a function.
[Bug fortran/46539] libquadmath: Add -static-libquadmath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46539 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Implemented now on the trunk.
[Bug fortran/46539] libquadmath: Add -static-libquadmath
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46539 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:745be54bd6634fe63d6be83615e264c83d2ae9f9 commit r13-2094-g745be54bd6634fe63d6be83615e264c83d2ae9f9 Author: Jakub Jelinek Date: Wed Aug 17 17:00:33 2022 +0200 fortran: Add -static-libquadmath support [PR46539] The following patch is a revival of the https://gcc.gnu.org/legacy-ml/gcc-patches/2014-10/msg00771.html patch. While trunk configured against recent glibc and with linker --as-needed support doesn't really need to link against -lquadmath anymore, there are still other targets where libquadmath is still in use. As has been discussed, making -static-libgfortran imply statically linking both libgfortran and libquadmath is undesirable because of the significant licensing differences between the 2 libraries. Compared to the 2014 patch, this one doesn't handle -lquadmath addition in the driver, which to me looks incorrect, libgfortran configure determines where in libgfortran.spec -lquadmath should be present if at all and with what it should be wrapped, but analyzes gfortran -### -static-libgfortran stderr and based on that figures out what gcc/configure.ac determined. 2022-08-17 Francois-Xavier Coudert Jakub Jelinek PR fortran/46539 gcc/ * common.opt (static-libquadmath): New option. * gcc.cc (driver_handle_option): Always accept -static-libquadmath. * config/darwin.h (LINK_SPEC): Handle -static-libquadmath. gcc/fortran/ * lang.opt (static-libquadmath): New option. * invoke.texi (-static-libquadmath): Document it. * options.cc (gfc_handle_option): Error out if -static-libquadmath is passed but we do not support it. libgfortran/ * acinclude.m4 (LIBQUADSPEC): From $FC -static-libgfortran -### output determine -Bstatic/-Bdynamic, -bstatic/-bdynamic, -aarchive_shared/-adefault linker support or Darwin remapping of -lgfortran to libgfortran.a%s and use that around or instead of -lquadmath in LIBQUADSPEC. * configure: Regenerated. Co-Authored-By: Francois-Xavier Coudert
[Bug c++/104548] parser rejects alias template id of lambda in unevaluated-context and accepts when no alias is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104548 John Eivind Helset changed: What|Removed |Added CC||jehelset at gmail dot com --- Comment #2 from John Eivind Helset --- here is another variant of this i think: https://godbolt.org/z/nfsWPn6x8
[Bug c++/106667] New: Diagnosing misuses of capturing lambda coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106667
Bug ID: 106667
Summary: Diagnosing misuses of capturing lambda coroutines
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Consider the following example using std::generator from P2502 (sorry the
example isn't super reduced, https://godbolt.org/z/b4vj7E7d1):
int main() {
int lo = 10;
int hi = 20;
auto gen = [=]() -> std::generator {
for (int i = lo; i != hi; ++i) {
co_yield i;
}
}();
for (int i : gen) {
printf("%d\n", i);
}
}
This usage is bad! The lambda captures lo and hi, the coroutine is going to
capture a reference to the lambda, which then gets destroyed. Then we attempt
to access the coroutine, which attempts to read the dead lambda's captures.
ASAN flags the first iteration of that loop as stack-use-after-scope.
Is this situation in general statically diagnosable? The situation here is we
have:
1. A coroutine that is a non-static member function
2. That initially suspends
3. And has non-static data members that are used in the body (or, for lambdas,
captures)
4. And the coroutine outlives the class instance
This will probably be a more common bug in lambdas, specifically, than other
kinds of non-static member functions. This is specifically Core Guideline CP.51
(https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rcoro-capture).
[Bug c++/106666] New: Anonymous struct incorrectly allows types with constructors if placed in a known sized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
Bug ID: 10
Summary: Anonymous struct incorrectly allows types with
constructors if placed in a known sized array
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: twmouton at gmail dot com
Target Milestone: ---
Consider the following:
#include
#include
struct ConstructMe {
ConstructMe() {
std::cout << "I have been constructed" << std::endl;
}
~ConstructMe() {
std::cout << "I have been destructed" << std::endl;
}
};
struct Foo {
Foo()
: me{ std::make_unique< ConstructMe >() } {
std::cout << "Foo" << std::endl;
}
struct {
std::unique_ptr< ConstructMe > me[1];
};
};
int main() {
Foo f;
return 0;
}
Compiled with g++ 12.1 using only -std=c++17.
If you remove the "[1]" after "me" the compiler will emit the error "error:
member 'std::unique_ptr Foome' with
constructor not allowed in anonymous aggregate" with similar errors for the
existence of a destructor and copy-assignment operator.
To make matters worse, if you do make this an array then the object is only
constructed if it's included in the member initialization list (in above -
remove the unique_ptr and use just a plain ConstructMe to see that it is not
constructed) and it is never destructed. In the example above using unique_ptr,
this means the memory is leaked when Foo falls out of scope.
Since this is an extension, I am not sure what the correct behavior should be
but it should be consistent regardless of an object is in an array or single
member. I see two options for this.
1. Make it so the objects in an array that have
constructor/destructor/copy-assignment defined emit the same errors as not
having an array.
2. Objects with zero argument constructors should be allowed in an anonymous
struct, and should be constructed/destructed as if they were direct members of
the enclosing struct.
For what it's worth, clang seems to have chosen option 2.
[Bug fortran/106566] [OpenMP] declare simd fails with with bogus "already been host associated" for module procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106566 --- Comment #4 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:1513512ec7d0751cba30c9c8804f2be462acfb9b commit r13-2093-g1513512ec7d0751cba30c9c8804f2be462acfb9b Author: Tobias Burnus Date: Wed Aug 17 16:19:58 2022 +0200 Fortran: OpenMP fix declare simd inside modules and absent linear step [PR106566] gcc/fortran/ChangeLog: PR fortran/106566 * openmp.cc (gfc_match_omp_clauses): Fix setting linear-step value to 1 when not specified. (gfc_match_omp_declare_simd): Accept module procedures. gcc/testsuite/ChangeLog: PR fortran/106566 * gfortran.dg/gomp/declare-simd-4.f90: New test. * gfortran.dg/gomp/declare-simd-5.f90: New test. * gfortran.dg/gomp/declare-simd-6.f90: New test.
[Bug middle-end/106548] [OpenMP] ICE in #pragma openmp parallel for simd linear with long long variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106548 --- Comment #4 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:d9c9424d2c4f7b25acfc00db0076a65882c8a99f commit r13-2091-gd9c9424d2c4f7b25acfc00db0076a65882c8a99f Author: Tobias Burnus Date: Wed Aug 17 15:45:56 2022 +0200 OpenMP: Fix var replacement with 'simd' and linear-step vars [PR106548] gcc/ChangeLog: PR middle-end/106548 * omp-low.cc (lower_rec_input_clauses): Use build_outer_var_ref for 'simd' linear-step values that are variable. libgomp/ChangeLog: PR middle-end/106548 * testsuite/libgomp.c/linear-2.c: New test.
[Bug rtl-optimization/81501] mulitple calls to __tls_get_addr() with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81501 Roy Jacobson changed: What|Removed |Added CC||roi.jacobson1 at gmail dot com --- Comment #6 from Roy Jacobson --- We recently upgraded our toolchain from GCC9 to GCC11, and we're seeing __tls_get_addr take up to 10% of total runtime under some workloads, where it was 1-2% before. It seems that some changes to the optimization passes in 10 or 11 have significantly increased the impact of this problem.
[Bug middle-end/106492] [OpenMP] ICE in #pragma omp for simd and bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106492 Tobias Burnus changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Tobias Burnus --- Close as FIXED - on GCC mainline (GCC 13), GCC 12 (just before GCC 12.2), and GCC 11.
[Bug middle-end/106492] [OpenMP] ICE in #pragma omp for simd and bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106492 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:a96e5a928916ed5be9dea181316ebf8c174285e7 commit r11-10210-ga96e5a928916ed5be9dea181316ebf8c174285e7 Author: Tobias Burnus Date: Tue Aug 9 07:57:40 2022 +0200 OpenMP: Fix folding with simd's linear clause [PR106492] gcc/ChangeLog: PR middle-end/106492 * omp-low.c (lower_rec_input_clauses): Add missing folding to data type of linear-clause list item. gcc/testsuite/ChangeLog: PR middle-end/106492 * g++.dg/gomp/pr106492.C: New test. (cherry picked from commit 8a16b9f983824b6b9a25275cd23b6bba8c98b800)
[Bug c++/106665] Cannot pass barrier by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106665 --- Comment #1 from SHIH YEN-TE --- Another workaround is swap the declaration order of variable pool and sync_point. Changed from vector pool; barrier sync_point(8); To barrier sync_point(8); vector pool; Then the Segmentation fault disappeared.
[Bug c++/104493] OpenMP offload map cannot handle const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104493 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Tobias Burnus --- Now committed to GCC mainline (GCC 13). Close as FIXED. Thanks for the report and for the patience. * * * > When I tried master and devel/omp/gcc-12, the fix has not been applied. > Just keep a note here. Probably this has been planned. Regarding OG12 alias devel/omp/gcc-12: the mainline version was now also applied (cherry-picked) to OG12 as https://gcc.gnu.org/g:c76e4ac478afc0069f95694e6fcc3e155bf6fb3b
[Bug c++/106665] New: Cannot pass barrier by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106665
Bug ID: 106665
Summary: Cannot pass barrier by reference
Product: gcc
Version: 12.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: shihyente at hotmail dot com
Target Milestone: ---
Hi,
The failed case was tested under Ubuntu 22.04.1 LTS
g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/yt/Utils/gcc-12.2.0-RC-20220812/libexec/gcc/x86_64-pc-linux-gnu/12.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --prefix=/home/yt/Utils/gcc-12.2.0-RC-20220812
--enable-languages=c,c++ --enable-libstdcxx-backtrace=yes --disable-multilib
--enable-checking=yes
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.1.1 20220812 (GCC)
Code (test.cpp)
#include
#include
#include
using namespace std;
void foo(auto& sync_point) {
sync_point.arrive_and_wait();
}
int main() {
vector pool;
barrier sync_point(8);
for (size_t i = 0; i < 8; ++i)
pool.emplace_back([&] { foo(sync_point); });
}
Commandline to compile (no warning):
/home/yt/Utils/gcc-12.2.0-RC-20220812/bin/g++ -std=c++23 -g -O0 -Wall -Wextra
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations
-fsanitize=undefined -pthread
-Wl,-rpath=/home/yt/Utils/gcc-12.2.0-RC-20220812/lib64 test.cpp
Run (sometimes only showed "Segmentation fault (core dumped)")
/home/yt/Utils/gcc-12.2.0-RC-20220812/include/c++/12.1.1/bits/unique_ptr.h:720:14:
runtime error: reference binding to null pointer of type 'struct __state_t'
/home/yt/Utils/gcc-12.2.0-RC-20220812/include/c++/12.1.1/barrier:120:8: runtime
error: member access within null pointer of type 'struct __state_t'
/home/yt/Utils/gcc-12.2.0-RC-20220812/include/c++/12.1.1/barrier:120:17:
runtime error: member call on null pointer of type 'struct __tickets_t'
/home/yt/Utils/gcc-12.2.0-RC-20220812/include/c++/12.1.1/array:209:26: runtime
error: member access within null pointer of type 'struct array'
/home/yt/Utils/gcc-12.2.0-RC-20220812/include/c++/12.1.1/array:209:26: runtime
error: reference binding to null pointer of type 'const __barrier_phase_t'
/home/yt/Utils/gcc-12.2.0-RC-20220812/include/c++/12.1.1/array:61:41: runtime
error: load of null pointer of type 'const __barrier_phase_t'
/home/yt/Utils/gcc-12.2.0-RC-20220812/include/c++/12.1.1/array:61:41: runtime
error: reference binding to null pointer of type '__barrier_phase_t'
/home/yt/Utils/gcc-12.2.0-RC-20220812/include/c++/12.1.1/array:61:41: runtime
error: load of null pointer of type 'const __barrier_phase_t'
/home/yt/Utils/gcc-12.2.0-RC-20220812/include/c++/12.1.1/array:209:39: runtime
error: reference binding to null pointer of type 'value_type'
/home/yt/Utils/gcc-12.2.0-RC-20220812/include/c++/12.1.1/barrier:119:24:
runtime error: reference binding to null pointer of type '__barrier_phase_t'
Segmentation fault (core dumped)
GDB (sometimes only showed "exited normally")
Thread 9 "a.out" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x73c09640 (LWP 374398)]
0x0040a5bb in
std::__atomic_impl::compare_exchange_strong
(__failure=std::memory_order::acquire, __success=std::memory_order::acq_rel,
__desired=(unknown: 0x1), __expected=@0x73c08baf: 0, __ptr=0xc0) at
/home/yt/Utils/gcc-12.2.0-RC-20220812/include/c++/12.1.1/bits/atomic_base.h:1005
1005return __atomic_compare_exchange(__ptr,
std::__addressof(__expected),
Known workaround: Do not pass barrier by reference.
MSVC and Clang++ are working fine, so I am assuming the test code is legal.
Thank you very much.
Best,
John Shih
[Bug c++/104493] OpenMP offload map cannot handle const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104493 --- Comment #6 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:92a5de3df2dc958d6b3d18a0466189ad31f5ae79 commit r13-2089-g92a5de3df2dc958d6b3d18a0466189ad31f5ae79 Author: Tobias Burnus Date: Wed Aug 17 14:17:08 2022 +0200 OpenMP/C++: Allow classes with static members to be mappable [PR104493] As this is the last lang-specific user of the omp_mappable_type hook, the hook is removed, keeping only a generic omp_mappable_type for incomplete types (or error_node). PR c++/104493 gcc/c/ChangeLog: * c-decl.cc (c_decl_attributes, finish_decl): Call omp_mappable_type instead of removed langhook. * c-typeck.cc (c_finish_omp_clauses): Likewise. gcc/cp/ChangeLog: * cp-objcp-common.h (LANG_HOOKS_OMP_MAPPABLE_TYPE): Remove. * cp-tree.h (cp_omp_mappable_type, cp_omp_emit_unmappable_type_notes): Remove. * decl2.cc (cp_omp_mappable_type_1, cp_omp_mappable_type, cp_omp_emit_unmappable_type_notes): Remove. (cplus_decl_attributes): Call omp_mappable_type instead of removed langhook. * decl.cc (cp_finish_decl): Likewise; call cxx_incomplete_type_inform in lieu of cp_omp_emit_unmappable_type_notes. * semantics.cc (finish_omp_clauses): Likewise. gcc/ChangeLog: * gimplify.cc (omp_notice_variable): Call omp_mappable_type instead of removed langhook. * omp-general.h (omp_mappable_type): New prototype. * omp-general.cc (omp_mappable_type): New; moved from ... * langhooks.cc (lhd_omp_mappable_type): ... here. * langhooks-def.h (lhd_omp_mappable_type, LANG_HOOKS_OMP_MAPPABLE_TYPE): Remove. (LANG_HOOKS_FOR_TYPES_INITIALIZER): Remote the latter. * langhooks.h (struct lang_hooks_for_types): Remove omp_mappable_type. gcc/testsuite/ChangeLog: * g++.dg/gomp/unmappable-1.C: Remove dg-error; remove dg-note no longer shown as TYPE_MAIN_DECL is NULL. * c-c++-common/gomp/map-incomplete-type.c: New test. Co-authored-by: Chung-Lin Tang
[Bug libstdc++/106664] New: std::valarray::resize(0): spurious -Walloc-zero warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106664
Bug ID: 106664
Summary: std::valarray::resize(0): spurious -Walloc-zero
warning
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: gchicares at sbcglobal dot net
Target Milestone: ---
With -Walloc-zero and -O1 or greater, resizing a valarray to zero length
elicits a warning. Unexpected because the zero-byte allocation happens in a
system header, even though -Wsystem-headers is not specified.
Occurs with gcc-12 but not gcc-11, though gcc-11 would also allocate zero
bytes. Maybe _GLIBCXX_NOTHROW, added in gcc-12, explains that difference.
Copy ctor and operator=() are also affected. Looks like checking for zero in
__valarray_get_storage() would take care of those, too.
#include
int main()
{
std::valarray w {1};
w.resize(0); // warns
// Similarly warns on other operations, e.g.:
std::valarray x;
std::valarray y {x}; // warns
}
$g++ -O1 -Walloc-zero va_resize_0.cpp
In file included from /usr/include/c++/12/valarray:100,
from va_resize_0.cpp:1:
In function ‘_Tp* std::__valarray_get_storage(size_t) [with _Tp = double]’,
inlined from ‘void std::valarray<_Tp>::resize(std::size_t, _Tp) [with _Tp =
double]’ at /usr/include/c++/12/valarray:1042:41,
inlined from ‘int main()’ at va_resize_0.cpp:5:13:
/usr/include/c++/12/bits/valarray_array.h:58:44: warning: argument 1 value is
zero [-Walloc-zero]
58 | { return static_cast<_Tp*>(operator new(__n * sizeof(_Tp))); }
|^~~
In file included from /usr/include/c++/12/bits/stl_construct.h:59,
from /usr/include/c++/12/bits/stl_tempbuf.h:60,
from /usr/include/c++/12/bits/stl_algo.h:61,
from /usr/include/c++/12/algorithm:61,
from /usr/include/c++/12/valarray:38:
/usr/include/c++/12/new: In function ‘int main()’:
/usr/include/c++/12/new:126:26: note: in a call to allocation function ‘void*
operator new(std::size_t)’ declared here
126 | _GLIBCXX_NODISCARD void* operator new(std::size_t) _GLIBCXX_THROW
(std::bad_alloc)
| ^~~~
In function ‘_Tp* std::__valarray_get_storage(size_t) [with _Tp = double]’,
inlined from ‘std::valarray<_Tp>::valarray(const std::valarray<_Tp>&) [with
_Tp = double]’ at /usr/include/c++/12/valarray:647:64,
inlined from ‘int main()’ at va_resize_0.cpp:9:31:
/usr/include/c++/12/bits/valarray_array.h:58:44: warning: argument 1 value is
zero [-Walloc-zero]
58 | { return static_cast<_Tp*>(operator new(__n * sizeof(_Tp))); }
|^~~
/usr/include/c++/12/new: In function ‘int main()’:
/usr/include/c++/12/new:126:26: note: in a call to allocation function ‘void*
operator new(std::size_t)’ declared here
126 | _GLIBCXX_NODISCARD void* operator new(std::size_t) _GLIBCXX_THROW
(std::bad_alloc)
| ^~~~
[Bug libstdc++/106611] std::is_nothrow_copy_constructible returns wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
--- Comment #5 from Nikolas Klauser ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Nikolas Klauser from comment #2)
> > static_assert(!noexcept(std::declval(;
> >
> > is fine.
>
> It doesn't look fine to me! Is there a 'CopyConstructible(' missing?
>
> The reproducer for comment 3 would be helpful.
Oops! Yes, there is a CopyConstructible() missing around the declval.
Here is the reproducer for comment #3 (Godbolt:
https://godbolt.org/z/fYEzME3b8):
#include
#include
struct S {
S() noexcept(false) = default;
S(const S&) noexcept(false) = default;
S(S&&) noexcept(false) = default;
S& operator=(const S&) noexcept(false) = default;
S& operator=(S&&) noexcept(false) = default;
};
static_assert(!std::is_nothrow_default_constructible_v);
static_assert(!std::is_nothrow_copy_constructible_v);
static_assert(!std::is_nothrow_move_constructible_v);
static_assert(!std::is_nothrow_copy_assignable_v);
static_assert(!std::is_nothrow_move_assignable_v);
static_assert(!noexcept(S()));
static_assert(!noexcept(S(std::declval(;
static_assert(!noexcept(S(std::declval(;
static_assert(!noexcept(std::declval() = std::declval()));
static_assert(!noexcept(std::declval() = std::declval()));
I think the relevant part in the standard is
https://eel.is/c++draft/except.spec, which states that anything marked
noexcept(false) is potentially throwing.
[Bug libstdc++/106611] std::is_nothrow_copy_constructible returns wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106611
--- Comment #4 from Jonathan Wakely ---
(In reply to Nikolas Klauser from comment #2)
> static_assert(!noexcept(std::declval(;
>
> is fine.
It doesn't look fine to me! Is there a 'CopyConstructible(' missing?
The reproducer for comment 3 would be helpful.
[Bug target/106635] AARCH64 STUR instruction causes bus error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106635 --- Comment #12 from Xiaoguang --- (In reply to Richard Earnshaw from comment #11) > (In reply to Xiaoguang from comment #9) > > Yeah, I also find such description, my memory type is uncachable normal > > memory, but not device memory > > I use mmap to get the virtual address with an O_SYNC in fd > > Yes, I think you're correct: you can have non-cacheable normal memory and > that supports unaligned accesses. > > However, I don't know how you are supposed to set that up with Linux mmap > calls. It's beyond my knowledge of how the kernel works with the system. > You'd be best asking about that in a different forum where some kernel > experts hang out. > > I don't know what other constraints you might have on your system, but have > you considered using cacheable memory and then inserting cache > synchronization calls at the points where you really need to synchronize > data? That may well have significantly better performance than trying to > map the data as non-cacheable. Note that if you have simultaneous readers > of the data, you'll need to mark the pointers to it as volatile anyway, > because otherwise the compiler might re-order the stores to separate > locations. Thanks very much for the help, I'll continue to investigate this failure, but it is not related with gcc anymore.
[Bug c++/106658] [C++23] P2590 - Explicit lifetime management
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106658 --- Comment #2 from Richard Biener --- See for example PR101641 where even existing cases are currently impossible to get right. So the only way to make std::start_lifetime_at is to somehow emit a hard memory barrier for the compiler _and_ make sure the underlying storage is address-taken. Note this barrier has to prevail in RTL as well (I think std::launder is broken in this regard).
[Bug gcov-profile/106659] [13 Regression] error: no member named 'fancy_abort' in namespace 'std'; did you mean simply 'fancy_abort'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106659 --- Comment #2 from Richard Biener --- looks obvious to me
[Bug target/106635] AARCH64 STUR instruction causes bus error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106635 --- Comment #11 from Richard Earnshaw --- (In reply to Xiaoguang from comment #9) > Yeah, I also find such description, my memory type is uncachable normal > memory, but not device memory > I use mmap to get the virtual address with an O_SYNC in fd Yes, I think you're correct: you can have non-cacheable normal memory and that supports unaligned accesses. However, I don't know how you are supposed to set that up with Linux mmap calls. It's beyond my knowledge of how the kernel works with the system. You'd be best asking about that in a different forum where some kernel experts hang out. I don't know what other constraints you might have on your system, but have you considered using cacheable memory and then inserting cache synchronization calls at the points where you really need to synchronize data? That may well have significantly better performance than trying to map the data as non-cacheable. Note that if you have simultaneous readers of the data, you'll need to mark the pointers to it as volatile anyway, because otherwise the compiler might re-order the stores to separate locations.
[Bug c++/106658] [C++23] P2590 - Explicit lifetime management
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106658 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- 1.1 can be done without any code but 1.2 makes std::start_lifetime_at (p) retain the memory bit representation as initial value of the object? The paper mentions std::launder (ick), but I'm not sure how this is implementable at all if not sufficiently restricted.
[Bug tree-optimization/106663] FSM threading doesn't handle computed goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106663 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from Richard Biener --- Thanks ;) If you get to the point that it works but breaks later in the copier feel free to assign back.
[Bug tree-optimization/106663] FSM threading doesn't handle computed goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106663 Aldy Hernandez changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-08-17 Assignee|unassigned at gcc dot gnu.org |aldyh at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #2 from Aldy Hernandez --- (In reply to Richard Biener from comment #1) > Created attachment 53468 [details] > patch restoring backward threader functionality > > The attached restores functionality in the backwards threader but as said it > gives up in find_taken_edge_goto doing > > m_solver->range_of_expr (r, dest, m_last_stmt); > tree addr; > if (!r.singleton_p () > || (TREE_CODE (addr) != ADDR_EXPR > && TREE_CODE (TREE_OPERAND (addr, 0)) != LABEL_DECL)) > return NULL; > > since the range we get is non-null, not In my prange branch I have the following for a prange: + void set_pt (tree base); + void set_pt (tree base, const wide_int ); + bool get_pt (tree , wide_int ) const; Your snippet above could be: m_solver->range_of_expr (r, dest, m_last_stmt); tree addr; wide_int offset; if (is_a (r)) && as_a (r).get_pt (addr, offset) && offset == 0 && TREE_CODE (addr) != ADDR_EXPR && TREE_CODE (TREE_OPERAND (addr, 0)) != LABEL_DECL))) ... Or some such... it was working last time I poked at it last year ;-). Anyways, confirmed. I'll take it.
[Bug tree-optimization/106663] FSM threading doesn't handle computed goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106663 --- Comment #1 from Richard Biener --- Created attachment 53468 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53468=edit patch restoring backward threader functionality The attached restores functionality in the backwards threader but as said it gives up in find_taken_edge_goto doing m_solver->range_of_expr (r, dest, m_last_stmt); tree addr; if (!r.singleton_p () || (TREE_CODE (addr) != ADDR_EXPR && TREE_CODE (TREE_OPERAND (addr, 0)) != LABEL_DECL)) return NULL; since the range we get is non-null, not
[Bug tree-optimization/106663] New: FSM threading doesn't handle computed goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106663
Bug ID: 106663
Summary: FSM threading doesn't handle computed goto
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
For the following B->C isn't threaded but it seems the code is/was halfway
there. With ranger we won't ever get as range for the goto destination
though, so whether the thread copier handles things correctly is unknown.
unsigned g;
void FSM (int start)
{
void *states[] = { &, &, &, & };
void *state = states[start];
do {
goto *state;
A:
g += 1;
state = g & 1 ? & : &
continue;
B:
g += 2;
state = &
continue;
C:
g += 3;
state = states[g & 3];
continue;
E:
break;
} while (1);
}
[Bug middle-end/106662] New: [OpenMP] 'for simd firstprivate(j) lastprivate(j)' with 'parallel shared(j)' gives unexpected result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106662
Bug ID: 106662
Summary: [OpenMP] 'for simd firstprivate(j) lastprivate(j)'
with 'parallel shared(j)' gives unexpected result
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, sandra at gcc dot gnu.org
Target Milestone: ---
[Lightly related to PR106504 - but that one uses 'parallel private' not
shared.]
The following program, converted to C++ from libgomp.fortran/pr27416-1.f90
and with 'simd' added to the workshare-loop construct,
yields:
* 22 with 'for' - i.e. the existing Fortran testcase, but C++-ified.
and independent of 'num_threads(1)'
* 22 with clang++-12
* 22 with icc 19
while
* 16 is obtained with GCC
(as if 0 and not 6 is firstprivatized)
int
main()
{
int j = 6;
#pragma omp parallel num_threads (4) shared(j)
{
int i;
#pragma omp for simd firstprivate (j) lastprivate (j) // private(i)
for (i = 1; i <= 16; ++i)
if (i == 16)
j = j + i;
}
__builtin_printf("j = %i =?= %i\n", j, 6+16);
if (j != 6+16)
__builtin_abort();
return 0;
}
Likewise with a combined construct:
...
#pragma omp parallel for simd num_threads (4) firstprivate (j) lastprivate
(j)
for (int i = 1; i <= 16; ++i)
...
And likewise with the equivalent Fortran code.
[Bug target/106609] [SH] miscompilation due to incorrect elimination of comparisons to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106609 --- Comment #6 from Sébastien Michelland --- First bad commit is r12-1955-ga86b3453fc6e29cf0e19916b01c393652d838d56, though I don't know what path is taken from there to the incorrect rewrite.
[Bug fortran/105318] [OpenMP] is_device_ptr rejects valid arguments to has_device_addr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105318 --- Comment #1 from Tobias Burnus --- Likewise, the following is now permitted: type(c_ptr) :: aptr ... !$omp target is_device_ptr(aPtr) but still rejected with: Error: Non-dummy object ‘aptr’ in IS_DEVICE_PTR clause at (1)
[Bug target/106635] AARCH64 STUR instruction causes bus error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106635 --- Comment #10 from Xiaoguang --- (In reply to Xiaoguang from comment #9) > (In reply to Andrew Pinski from comment #8) > > In ARM Armv8, for A-profile architecture (ARM DDI 0487G.b (ID072021)): > > > > From section B2.5.2 Alignment of data accesses: > > > > An unaligned access to any type of Device memory causes an Alignment fault. > > > > Unaligned accesses to Normal memory > > Yeah, I also find such description, my memory type is uncachable normal > memory, but not device memory > I use mmap to get the virtual address with an O_SYNC in fd Also I didn't see whether normal memory cacheable or not impacts alignment access , besides, STUR instruction has unscaled imm offset, it should support unaligned access on normal memory, no matter cached or not,and my X0 is normal memory so I'm still confusing why it fails, please correct my if my understanding is wrong. thanks very much
