Re: [PATCH] PR c/104506: Tolerate error_mark_node in useless_type_conversion_p.
On Mon, Feb 14, 2022 at 11:33 PM Richard Biener wrote: > > On Tue, Feb 15, 2022 at 12:58 AM Andrew Pinski via Gcc-patches > wrote: > > > > On Mon, Feb 14, 2022 at 4:54 AM Roger Sayle > > wrote: > > > > > > > > > > > > This simple fix to the middle-end, resolves PR c/104506, by adding an > > > > > > explicit check for error_mark_node to useless_type_conversion_p. I first > > > > > > trying fixing this in the C front-end, but the type is valid at the point > > > > > > that the NOP_EXPR is created, so the poisoned type leaks to the > > > middle-end. > > > > > > Returning either true or false from useless_type_conversion_p avoids the > > > > > > ICE-after-error. Apologies to Andrew Pinski, I hadn't noticed that he'd > > > > > > assigned this PR to himself until after my regression testing had > > > finished. > > > > > > > > > > > > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap and > > > > > > make -k check with no new failures. Ok for mainline? > > > > > > > > > > > > > > > > > > 2022-02-14 Roger Sayle > > > > > > > > > > > > gcc/ChangeLog > > > > > > PR c/104506 > > > > > > * gimple-expr.cc (useless_type_conversion_p): Add a check for > > > > > > error_mark_node. > > > > I came up with a different patch (attached) which just changes > > tree_ssa_useless_type_conversion rather than useless_type_conversion_p > > which I was going to submit but had an issue with my build machine. > > I did it this way as it was similar to how > > STRIP_NOPS/tree_nop_conversion was done already. > > > > Also from my description of the patch > > STRIP_USELESS_TYPE_CONVERSION is mostly used inside the gimplifier > > and the places where it is used outside of the gimplifier would not > > be adding too much overhead. > > > > Though I think Richard Biener's patch is better really. It would be > > interesting to see how the C++ front-end handles this case, I remember > > it using integer_type_node in some locations after an error for a > > type. > > If the fix to the C frontend doesn't work out I'd indeed prefer your variant. > Nit: > > + outer_type = TREE_TYPE (expr); > + inner_type = TREE_TYPE (TREE_OPERAND (expr, 0)); > + > + if (!inner_type || inner_type == error_mark_node) > +return false; > > unless we get to a case where inner_type == NULL I would not bother > checking that. Understood, I will remove it, I was just copying exactly what was done in tree_nop_conversion really. The history on the null check seems to date to 2000 without any explanation really. Thanks, Andrew Pinski > > As said, that TREE_TYPE (error_mark_node) is not a type is IMHO bad > for error recovery. Maybe we really need ERROR_TYPE here. > > > Thanks, > > Andrew Pinski > > > > > > > > > > > > > > gcc/testsuite/ChangeLog > > > > > > PR c/104506 > > > > > > * gcc.dg/pr104506.c: New test case. > > > > > > > > > > > > > > > > > > Roger > > > > > > -- > > > > > >
Re: [committed][nvptx] Handle pre-sm_7x shared atomic store using atomic exchange
Hi Tom!
For my understanding:
On 2022-02-10T10:13:10+0100, Tom de Vries via Gcc-patches
wrote:
> The ptx isa specifies (for pre-sm_7x) that atomic operations on shared memory
> locations do not guarantee atomicity with respect to normal store instructions
> to the same address.
>
> This can be fixed by:
> - inserting barriers between normal stores and atomic operations to a common
> address
> - using atom.exch to store to locations accessed by other atomic operations.
>
> It's not clearly spelled out which barriers are needed, and a barrier seem
> more
> expensive than atomic exchange.
>
> Implement the pre-sm_7x shared atomic store using atomic exchange.
>
> That includes stores using generic addressing, since those may also point to
> shared memory.
It is expected that this changes, for example (similar elsewhere)
'nvptx-none/libatomic/store_4_.o', to use (a) 'atom.exch' (with a new
dummy register allocated) and yet (b) 'membar.sys' remains before as well
as after (a):
.visible .func __atomic_store_4 (.param .u64 %in_ar0, .param .u32 %in_ar1,
.param .u32 %in_ar2)
{
.reg .u64 %ar0;
ld.param.u64 %ar0,[%in_ar0];
.reg .u32 %ar1;
ld.param.u32 %ar1,[%in_ar1];
.reg .u32 %ar2;
ld.param.u32 %ar2,[%in_ar2];
.reg .u64 %r22;
.reg .u32 %r23;
+.reg .u32 %r25;
mov.u64 %r22,%ar0;
mov.u32 %r23,%ar1;
.loc 2 39 5
membar.sys;
-st.u32 [%r22],%r23;
+atom.exch.b32 %r25,[%r22],%r23;
membar.sys;
.loc 2 40 1
ret;
}
And, for example (similar elsewhere) 'nvptx-none/libgomp/single.o', a
'ld' that previously was issued after 'membar.sys' now moves before that
one:
.visible .func (.param .u64 %value_out) GOMP_single_copy_start
{
[...]
.reg .u64 %r33;
.reg .u64 %r34;
[...]
.reg .pred %r51;
.reg .u64 %r50;
.reg .u64 %r52;
[...]
ld.shared.u64 %r50,[nvptx_thrs];
add.u64 %r33,%r50,%r49;
.loc 2 1317 32
ld.u64 %r34,[%r33+32];
.loc 2 1317 6
setp.eq.u64 %r51,%r34,0;
@ %r51 bra $L6;
.loc 4 66 3
-membar.sys;
ld.u64 %r52,[%r33+24];
-st.u64 [%r34+80],%r52;
+membar.sys;
+atom.exch.b64 %r53,[%r34+80],%r52;
$L6:
[...]
(But I see there is another 'ld.u64 %r34,[%r33+32]' that previously also
already was issued before the 'membar.sys'.)
Grüße
Thomas
> [nvptx] Handle pre-sm_7x shared atomic store using atomic exchange
>
> gcc/ChangeLog:
>
> 2022-02-02 Tom de Vries
>
> * config/nvptx/nvptx-protos.h (nvptx_mem_maybe_shared_p): Declare.
> * config/nvptx/nvptx.cc (nvptx_mem_data_area): New static function.
> (nvptx_mem_maybe_shared_p): New function.
> * config/nvptx/nvptx.md (define_expand "atomic_store"): New
> define_expand.
>
> gcc/testsuite/ChangeLog:
>
> 2022-02-02 Tom de Vries
>
> * gcc.target/nvptx/atomic-store-1.c: New test.
> * gcc.target/nvptx/atomic-store-3.c: New test.
> * gcc.target/nvptx/stack-atomics-run.c: Update.
>
> ---
> gcc/config/nvptx/nvptx-protos.h| 1 +
> gcc/config/nvptx/nvptx.cc | 22
> gcc/config/nvptx/nvptx.md | 30
> ++
> gcc/testsuite/gcc.target/nvptx/atomic-store-1.c| 26 +++
> gcc/testsuite/gcc.target/nvptx/atomic-store-3.c| 25 ++
> gcc/testsuite/gcc.target/nvptx/stack-atomics-run.c | 6 -
> 6 files changed, 109 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/config/nvptx/nvptx-protos.h b/gcc/config/nvptx/nvptx-protos.h
> index a846e341917..0bf9af406a2 100644
> --- a/gcc/config/nvptx/nvptx-protos.h
> +++ b/gcc/config/nvptx/nvptx-protos.h
> @@ -60,5 +60,6 @@ extern const char *nvptx_output_simt_exit (rtx);
> extern const char *nvptx_output_red_partition (rtx, rtx);
> extern const char *nvptx_output_atomic_insn (const char *, rtx *, int, int);
> extern bool nvptx_mem_local_p (rtx);
> +extern bool nvptx_mem_maybe_shared_p (const_rtx);
> #endif
> #endif
> diff --git a/gcc/config/nvptx/nvptx.cc b/gcc/config/nvptx/nvptx.cc
> index 1b0227a2c31..5b26c0f4c7d 100644
> --- a/gcc/config/nvptx/nvptx.cc
> +++ b/gcc/config/nvptx/nvptx.cc
> @@ -76,6 +76,7 @@
> #include "intl.h"
> #include "opts.h"
> #include "tree-pretty-print.h"
> +#include "rtl-iter.h"
>
> /* This file should be included last. */
> #include "target-def.h"
> @@ -2787,6 +2788,27 @@ nvptx_print_operand_address (FILE *file, machine_mode
> mode, rtx addr)
>nvptx_print_address_operand (file, addr, mode);
> }
>
> +static nvptx_data_area
> +nvptx_mem_data_area (const_rtx x)
> +{
> + gcc_assert (GET_CODE (x) == MEM);
> +
> + const_rtx addr = XEXP (x, 0);
> + subrtx_iterator::array_type array;
> + FOR_EACH_SUBRTX (iter, array, addr, ALL)
> +if (SYMBOL_REF_P (*iter))
> + return SYMBOL_DATA_AREA (*iter);
> +
> + return DATA_AREA_GENERIC;
> +}
> +
> +bool
> +nvptx_mem_maybe_shared_p (const_rtx x)
> +{
> +
Re: [PATCH] PR c/104506: Tolerate error_mark_node in useless_type_conversion_p.
On Tue, Feb 15, 2022 at 12:58 AM Andrew Pinski via Gcc-patches wrote: > > On Mon, Feb 14, 2022 at 4:54 AM Roger Sayle > wrote: > > > > > > > > This simple fix to the middle-end, resolves PR c/104506, by adding an > > > > explicit check for error_mark_node to useless_type_conversion_p. I first > > > > trying fixing this in the C front-end, but the type is valid at the point > > > > that the NOP_EXPR is created, so the poisoned type leaks to the middle-end. > > > > Returning either true or false from useless_type_conversion_p avoids the > > > > ICE-after-error. Apologies to Andrew Pinski, I hadn't noticed that he'd > > > > assigned this PR to himself until after my regression testing had finished. > > > > > > > > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap and > > > > make -k check with no new failures. Ok for mainline? > > > > > > > > > > > > 2022-02-14 Roger Sayle > > > > > > > > gcc/ChangeLog > > > > PR c/104506 > > > > * gimple-expr.cc (useless_type_conversion_p): Add a check for > > > > error_mark_node. > > I came up with a different patch (attached) which just changes > tree_ssa_useless_type_conversion rather than useless_type_conversion_p > which I was going to submit but had an issue with my build machine. > I did it this way as it was similar to how > STRIP_NOPS/tree_nop_conversion was done already. > > Also from my description of the patch > STRIP_USELESS_TYPE_CONVERSION is mostly used inside the gimplifier > and the places where it is used outside of the gimplifier would not > be adding too much overhead. > > Though I think Richard Biener's patch is better really. It would be > interesting to see how the C++ front-end handles this case, I remember > it using integer_type_node in some locations after an error for a > type. If the fix to the C frontend doesn't work out I'd indeed prefer your variant. Nit: + outer_type = TREE_TYPE (expr); + inner_type = TREE_TYPE (TREE_OPERAND (expr, 0)); + + if (!inner_type || inner_type == error_mark_node) +return false; unless we get to a case where inner_type == NULL I would not bother checking that. As said, that TREE_TYPE (error_mark_node) is not a type is IMHO bad for error recovery. Maybe we really need ERROR_TYPE here. > Thanks, > Andrew Pinski > > > > > > > > > gcc/testsuite/ChangeLog > > > > PR c/104506 > > > > * gcc.dg/pr104506.c: New test case. > > > > > > > > > > > > Roger > > > > -- > > > >
[Bug target/103627] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103627 --- Comment #7 from Arseny Solokha --- Should this PR be closed, or are there backports pending?
Re: Uninit warnings due to optimizing short-circuit conditionals
On Mon, Feb 14, 2022 at 6:38 PM Mark Wielaard wrote: > > On Mon, 2022-02-14 at 12:20 -0500, David Malcolm wrote: > > On Mon, 2022-02-14 at 17:57 +0100, Mark Wielaard wrote: > > > On Mon, 2022-02-14 at 10:57 -0500, David Malcolm wrote: > > > > [CCing Mark in the hopes of insight from the valgrind side of > > > > things] > > > > > > Adding Julian to CC so he can correct me if I say something silly. > > > > > > > There is a false positive from -Wanalyzer-use-of-uninitialized- > > > > value on > > > > gcc.dg/analyzer/pr102692.c here: > > > > > > > > ‘fix_overlays_before’: events 1-3 > > > > | > > > > | 75 | while (tail > > > > | | > > > > | 76 | && (tem = make_lisp_ptr (tail, 5), > > > > | | ^~ > > > > | | | > > > > | | (1) following ‘false’ branch (when ‘tail’ is > > > > NULL)... > > > > | 77 | (end = marker_position (XOVERLAY (tem)- > > > > > end)) >= pos)) > > > > > > > > | | > > > > ~ > > > > |.. > > > > | 82 | if (!tail || end < prev || !tail->next) > > > > | | ~~~ > > > > | | || > > > > | | |(3) use of uninitialized value > > > > ‘end’ here > > > > | | (2) ...to here > > > > | > > > > > > > > The issue is that inner || of the conditionals have been folded > > > > within the > > > > frontend from a chain of control flow: > > > > > > > >5 │ if (tail == 0B) goto ; else goto ; > > > >6 │ : > > > >7 │ if (end < prev) goto ; else goto ; > > > >8 │ : > > > >9 │ _1 = tail->next; > > > > 10 │ if (_1 == 0B) goto ; else goto ; > > > > 11 │ : > > > > > > > > to an OR expr (and then to a bitwise-or by the gimplifier): > > > > > > > >5 │ _1 = tail == 0B; > > > >6 │ _2 = end < prev; > > > >7 │ _3 = _1 | _2; > > > >8 │ if (_3 != 0) goto ; else goto ; > > > >9 │ : > > > > 10 │ _4 = tail->next; > > > > 11 │ if (_4 == 0B) goto ; else goto ; > > > > > > > > This happens for sufficiently simple conditionals in > > > > fold_truth_andor. > > > > In particular, the (end < prev) is short-circuited without > > > > optimization, > > > > but is evaluated with optimization, leading to the false positive. > > > > > > > > Given how early this folding occurs, it seems the simplest fix is > > > > to > > > > try to detect places where this optimization appears to have > > > > happened, > > > > and suppress uninit warnings within the statement that would have > > > > been short-circuited (and thus e.g. ignoring them when evaluating > > > > _2 > > > > above for the case where _1 is known to be true at the (_1 | _2) , > > > > and > > > > thus _2 being redundant). > > > > > > > > Attached is a patch that implements this. > > > > > > > > There are some more details in the patch, but I'm wondering if this > > > > is a > > > > known problem, and how e.g. valgrind copes with such code. My > > > > patch > > > > feels like something of a hack, but I'm not sure of any other way > > > > around > > > > it given that the conditional is folded directly within the > > > > frontend. > > > > > > As far as I know this is what valgrind memcheck also does with an > > > bitwise or. It knows that _3 is defined and true if either _1 or _2 > > > is > > > defined and true. Or more generically that the result bits of a > > > bitwise > > > or are defined for those bits that are both defined or where one is > > > defined and has the value 1. > > > > Aha - thanks. I think the distinction here is that: > > > > * GCC's -fanalyzer complains about uninitialized values immediately > > when it sees one being fetched for use in any expression (replacing the > > value with a safe one to avoid further complaints), without considering > > how they are going to be used in the expression, whereas > > > > * it sounds like valgrind keeps track of uninitialized bits, propagates > > the "uninit-ness" of the bits, and complains at certain times when > > uninitialized bits are used in certain ways. > > Yes. valgrind keeps track of uninitialized bits and propagates them > around till "use". Where use is anything that might alter the > observable behavior of the program. Which is control flow transfers, > conditional moves, addresses used in memory accesses, and data passed > to system calls. > > This paper describes some of the memcheck tricks: > https://valgrind.org/docs/memcheck2005.pdf That probably means bugs like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63311 could be resolved as fixed (in valgrind). But indeed GCCs own uninit diagnostics fall foul of this as well. I suppose one could track uses and if they are used in bitwise operations could demote them to "maybe" even though they appear unconditionally. Now, we cannot distinguish
[Bug debug/104544] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104544 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-02-15 CC||pinskia at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |10.4 --- Comment #1 from Andrew Pinski --- The difference starts in combine.
[Bug tree-optimization/104543] [12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104543 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-02-15 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- Confirmed. >From what I could tell it is the unroll and jam pass which is messing up. -fno-loop-unroll-and-jam [local count: 542102826]: # c.4_21 = PHI <0(7), _9(23)> _7 = a[c.4_21]; _8 = _7 ^ 1; a[c.4_21] = _8; _9 = c.4_21 + 1; _11 = b_lsm.13_13 + 1; if (_11 <= 2) goto ; [83.33%] else goto ; [16.67%] [local count: 451752355]: a[c.4_21] = _7;
[Bug debug/104544] New: [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104544
Bug ID: 104544
Summary: [10/11/12 Regression] '-fcompare-debug' failure
(length) w/ -O2
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: compare-debug-failure
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: aarch64-linux-gnu
Created attachment 52444
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52444=edit
gkd diff
gcc 12.0.1 20220213 snapshot (g:58aeb75d4097010ad9bb72b964265b18ab284f93) fails
-fcompare-debug check when compiling the following testcase w/ -O2:
int m, n;
__int128 q;
void
bar (unsigned __int128 x, int y)
{
if (x)
q += y;
}
void
foo (void)
{
bar (!!q - 1, (m += m ? m : 1) < n);
}
% aarch64-linux-gnu-gcc-12.0.1 -O2 -fcompare-debug -c tod26vmj.c
aarch64-linux-gnu-gcc-12.0.1: error: tod26vmj.c: '-fcompare-debug' failure
(length)
gkd diff attached.
[Bug tree-optimization/104543] [12 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104543 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Keywords||wrong-code Summary|wrong code at -O3 on|[12 Regression] wrong code |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu
[Bug tree-optimization/104543] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104543 --- Comment #1 from Zhendong Su --- >From Compiler Explorer: https://godbolt.org/z/s1WW4snzM
[Bug tree-optimization/104543] New: wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104543
Bug ID: 104543
Summary: wrong code at -O3 on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
This appears to be a recent regression.
[588] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220215 (experimental) [master r12-7236-g2c3309e3d0f] (GCC)
[589] %
[589] % gcctk -O2 small.c; ./a.out
[590] %
[590] % gcctk -O3 small.c
[591] % ./a.out
Aborted
[592] %
[592] % cat small.c
int a[3], b, c;
int e() {
if (!c) {
for (b = 0; b < 3; b++)
for (c = 0; c < 3; c++)
a[c] ^= 1;
return -1;
}
return 0;
}
int main() {
e();
if (a[1] != 1)
__builtin_abort();
return 0;
}
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 96864, which changed state. Bug 96864 Summary: loop not vectorized due AVX512 condition handling https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96864 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/96864] loop not vectorized due AVX512 condition handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96864 Hongtao.liu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #3 from Hongtao.liu --- .
[Bug target/96864] loop not vectorized due AVX512 condition handling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96864 --- Comment #2 from Hongtao.liu --- Fixed in GCC12 by r12-6756-g8bc700f4c3fbe405413db02281ef2918bfa831fc.
[Bug middle-end/102464] Miss optimization for (_Float16) sqrtf ((float) f16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102464 Hongtao.liu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Hongtao.liu --- Fixed in GCC12.
[Bug rtl-optimization/104059] [12 Regression] cprop_hardreg propgates hard registers for mov instructions between different REG_CLASS without considering cost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104059 Hongtao.liu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Hongtao.liu --- Fixed in GCC12.
[Bug libstdc++/104542] New: make_obj_using_allocator and uninitialized_construct_using_allocator lack constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104542 Bug ID: 104542 Summary: make_obj_using_allocator and uninitialized_construct_using_allocator lack constexpr Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: de34 at live dot cn Target Milestone: --- std::make_obj_using_allocator and std::uninitialized_construct_using_allocator are constexpr in C++20 (LWG3185, LWG3321), but currently they are not constexpr in libstdc++. I think the related compiler support for std::construct_at is available since gcc11 (partially available in gcc10), so these functions are reasonably constexpr in libstdc++ now, and this fix should be backported to gcc 10/11. wandbox links: gcc10 with manual constexpr (lacks support for CZ044): https://wandbox.org/permlink/CvSEindXZa3MMRT5 gcc11&12 with manual constexpr: https://wandbox.org/permlink/8i7oM16jGxlmz3FC https://wandbox.org/permlink/VHQJhGINcdpNC0Eh gcc11&12 with std versions, currently doesn't compile: https://wandbox.org/permlink/ZUx1xZIOphwxcJhS https://wandbox.org/permlink/f8uujdEoMUPbsUIq
[Bug rtl-optimization/104541] New: [10/11/12 Regression] ICE: maximum number of LRA assignment passes is achieved (30) with -O -fno-tree-ter -fsanitize-coverage=trace-cmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104541 Bug ID: 104541 Summary: [10/11/12 Regression] ICE: maximum number of LRA assignment passes is achieved (30) with -O -fno-tree-ter -fsanitize-coverage=trace-cmp Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 52443 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52443=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O -fno-tree-ter -fsanitize-coverage=trace-cmp testcase.c during RTL pass: reload testcase.c: In function 'foo': testcase.c:9:1: internal compiler error: maximum number of LRA assignment passes is achieved (30) 9 | } | ^ 0x11b641c lra_assign(bool&) /repo/gcc-trunk/gcc/lra-assigns.cc:1694 0x11b07ef lra(_IO_FILE*) /repo/gcc-trunk/gcc/lra.cc:2395 0x1161129 do_reload /repo/gcc-trunk/gcc/ira.cc:5940 0x1161129 execute /repo/gcc-trunk/gcc/ira.cc:6126 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7228-20220214143106-g0a1a3afb5fb-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-7228-20220214143106-g0a1a3afb5fb-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.1 20220214 (experimental) (GCC)
[Bug target/104540] New: ICE: SIGSEGV in cfi_oprnd_equal_p with -O2 -fharden-conditional-branches -mforce-drap -mstackrealign --param=max-grow-copy-bb-insns=125
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104540 Bug ID: 104540 Summary: ICE: SIGSEGV in cfi_oprnd_equal_p with -O2 -fharden-conditional-branches -mforce-drap -mstackrealign --param=max-grow-copy-bb-insns=125 Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-pc-linux-gnu Created attachment 52442 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52442=edit reduced testcase Compiler output: $ x86_64-pc-linux-gnu-gcc -O2 -fharden-conditional-branches -mforce-drap -mstackrealign --param=max-grow-copy-bb-insns=125 testcase.C during RTL pass: dwarf2 testcase.C: In function 'void foo()': testcase.C:19:1: internal compiler error: Segmentation fault 19 | } | ^ 0x166367f crash_signal /repo/gcc-trunk/gcc/toplev.cc:322 0x11e1770 cfa_reg::operator==(cfa_reg const&) const /repo/gcc-trunk/gcc/dwarf2out.h:144 0x11e1770 cfa_equal_p(dw_cfa_location const*, dw_cfa_location const*) /repo/gcc-trunk/gcc/dwarf2cfi.cc:765 0x11e1a99 cfi_row_equal_p /repo/gcc-trunk/gcc/dwarf2cfi.cc:831 0x11e534a maybe_record_trace_start /repo/gcc-trunk/gcc/dwarf2cfi.cc:2565 0x11e590b create_trace_edges /repo/gcc-trunk/gcc/dwarf2cfi.cc:2679 0x11e5f16 scan_trace /repo/gcc-trunk/gcc/dwarf2cfi.cc:2903 0x11e7303 create_cfi_notes /repo/gcc-trunk/gcc/dwarf2cfi.cc:2930 0x11e7303 execute_dwarf2_frame /repo/gcc-trunk/gcc/dwarf2cfi.cc:3301 0x11e7303 execute /repo/gcc-trunk/gcc/dwarf2cfi.cc:3789 Please submit a full bug report, with preprocessed source (by using -freport-bug). Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. $ x86_64-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-7228-20220214143106-g0a1a3afb5fb-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld --with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-7228-20220214143106-g0a1a3afb5fb-checking-yes-rtl-df-extra-amd64 Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.1 20220214 (experimental) (GCC)
Re: [PATCH] c: Add diagnostic when operator= is used as truth cond [PR25689]
On 2/14/22 21:30, Zhao Wei Liew wrote:
On 14/02/2022, Jason Merrill wrote:
+/* Returns true if EXPR is a reference to an implicit
+ call to operator=(). */
+static bool
+is_assignment_overload_ref_p (tree expr)
+{
+ if (expr == NULL_TREE || !REFERENCE_REF_P (expr))
+return false;
This will only warn about op= that returns a reference, which is not
required.
Ah I understand now. I added some new test cases for non-reference return types
and copied some code from extract_call_expr that seems to do what we want.
Good plan, but let's call extract_call_expr rather than copy from it.
+ return fndecl != NULL_TREE
+&& DECL_OVERLOADED_OPERATOR_P (fndecl)
+&& DECL_OVERLOADED_OPERATOR_IS (fndecl, NOP_EXPR)
+&& DECL_ASSIGNMENT_OPERATOR_P (fndecl);
This could be
&& DECL_ASSIGNMENT_OPERATOR_P (fndecl)
&& DECL_OVERLOADED_OPERATOR_IS (fndecl, NOP_EXPR);
without the separate DECL_OVERLOADED_OPERATOR_P test.
I see. I've adjusted the code as you suggested and it works. Thanks!
-- Everything below is the patch v4 --
When compiling the following code with g++ -Wparentheses, GCC does not
warn on the if statement. For example, there is no warning for this code:
struct A {
A& operator=(int);
operator bool();
};
void f(A a) {
if (a = 0); // no warning
}
This is because a = 0 is a call to operator=, which GCC does not handle.
This patch fixes this issue by handling calls to operator= when deciding
to warn.
Bootstrapped and tested on x86_64-pc-linux-gnu.
v3: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590310.html
Changes since v3:
1. Also handle COMPOUND_EXPRs and TARGET_EXPRs.
v2: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590236.html
Changes since v2:
1. Add more test cases in Wparentheses-31.C.
2. Refactor added logic to a function (is_assignment_overload_ref_p).
3. Use REFERENCE_REF_P instead of INDIRECT_REF_P.
v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590158.html
Changes since v1:
1. Use CALL_EXPR_OPERATOR_SYNTAX to avoid warnings for explicit
operator=() calls.
2. Use INDIRECT_REF_P to filter implicit operator=() calls.
3. Use cp_get_callee_fndecl_nofold.
4. Add spaces before (.
PR c/25689
gcc/cp/ChangeLog:
* semantics.cc (maybe_convert_cond): Handle the implicit
operator=() case for -Wparentheses.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wparentheses-31.C: New test.
---
gcc/cp/semantics.cc | 29 +-
gcc/testsuite/g++.dg/warn/Wparentheses-31.C | 62 +
2 files changed, 90 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/warn/Wparentheses-31.C
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 0cb17a6a8ab1c..9c3f613a1aa62 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -815,6 +815,33 @@ finish_goto_stmt (tree destination)
return add_stmt (build_stmt (input_location, GOTO_EXPR, destination));
}
+/* Returns true if CALL is a (possibly wrapped) CALL_EXPR
+ to operator=() that is written as an operator expression. */
+static bool
+is_assignment_op_expr_p(tree call)
Missing space before (
+{
+ if (call == NULL_TREE)
+return false;
+
+ /* Unwrap the CALL_EXPR. */
+ while (TREE_CODE (call) == COMPOUND_EXPR)
+call = TREE_OPERAND (call, 1);
+ if (REFERENCE_REF_P (call))
+call = TREE_OPERAND (call, 0);
+ if (TREE_CODE (call) == TARGET_EXPR)
+call = TARGET_EXPR_INITIAL (call);
+
+ if (call == NULL_TREE
+ || TREE_CODE (call) != CALL_EXPR
+ || !CALL_EXPR_OPERATOR_SYNTAX (call))
+return false;
+
+ tree fndecl = cp_get_callee_fndecl_nofold (call);
+ return fndecl != NULL_TREE
+&& DECL_ASSIGNMENT_OPERATOR_P (fndecl)
+&& DECL_OVERLOADED_OPERATOR_IS (fndecl, NOP_EXPR);
+}
+
/* COND is the condition-expression for an if, while, etc.,
statement. Convert it to a boolean value, if appropriate.
In addition, verify sequence points if -Wsequence-point is enabled. */
@@ -836,7 +863,7 @@ maybe_convert_cond (tree cond)
/* Do the conversion. */
cond = convert_from_reference (cond);
- if (TREE_CODE (cond) == MODIFY_EXPR
+ if ((TREE_CODE (cond) == MODIFY_EXPR || is_assignment_op_expr_p (cond))
&& warn_parentheses
&& !warning_suppressed_p (cond, OPT_Wparentheses)
&& warning_at (cp_expr_loc_or_input_loc (cond),
diff --git a/gcc/testsuite/g++.dg/warn/Wparentheses-31.C
b/gcc/testsuite/g++.dg/warn/Wparentheses-31.C
new file mode 100644
index 0..8d48ca5205782
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wparentheses-31.C
@@ -0,0 +1,62 @@
+/* Test that -Wparentheses warns for struct/class assignments,
+ except for explicit calls to operator= (). */
+/* PR c/25689 */
+/* { dg-options "-Wparentheses" } */
+
+struct A
+{
+ A& operator= (int);
+ A operator= (double);
+ operator bool ();
+};
+
+struct B
+{
+ bool x;
+ B& operator= (int);
[Bug c++/104107] [9/10/11/12 Regression] parsing crashes on class template instantiation since r9-6853-g17838af989014f5e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104107 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2c3309e3d0f5cb8f298f7604848d115f0992e04f commit r12-7236-g2c3309e3d0f5cb8f298f7604848d115f0992e04f Author: Jason Merrill Date: Thu Feb 10 17:57:38 2022 -0500 c++: TTP in member alias template [PR104107] In the first testcase, coerce_template_template_parms was adding too much of outer_args when coercing to match P's template parameters, so that when substituting into the 'const T&' parameter we got an unrelated template argument for T. We should only add outer_args when the argument template is a nested template. PR c++/104107 PR c++/95036 gcc/cp/ChangeLog: * pt.cc (coerce_template_template_parms): Take full parms. Avoid adding too much of outer_args. (coerce_template_template_parm): Adjust. (template_template_parm_bindings_ok_p): Adjust. (convert_template_argument): Adjust. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/alias-decl-ttp2.C: New test. * g++.dg/cpp1z/ttp2.C: New test.
[Bug c++/95036] [9/10/11/12 Regression] ICE with variadic template template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95036 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2c3309e3d0f5cb8f298f7604848d115f0992e04f commit r12-7236-g2c3309e3d0f5cb8f298f7604848d115f0992e04f Author: Jason Merrill Date: Thu Feb 10 17:57:38 2022 -0500 c++: TTP in member alias template [PR104107] In the first testcase, coerce_template_template_parms was adding too much of outer_args when coercing to match P's template parameters, so that when substituting into the 'const T&' parameter we got an unrelated template argument for T. We should only add outer_args when the argument template is a nested template. PR c++/104107 PR c++/95036 gcc/cp/ChangeLog: * pt.cc (coerce_template_template_parms): Take full parms. Avoid adding too much of outer_args. (coerce_template_template_parm): Adjust. (template_template_parm_bindings_ok_p): Adjust. (convert_template_argument): Adjust. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/alias-decl-ttp2.C: New test. * g++.dg/cpp1z/ttp2.C: New test.
[pushed] c++: TTP in member alias template [PR104107]
In the first testcase, coerce_template_template_parms was adding too much of
outer_args when coercing to match P's template parameters, so that when
substituting into the 'const T&' parameter we got an unrelated template
argument for T. We should only add outer_args when the argument template is
a nested template.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/104107
PR c++/95036
gcc/cp/ChangeLog:
* pt.cc (coerce_template_template_parms): Take full parms.
Avoid adding too much of outer_args.
(coerce_template_template_parm): Adjust.
(template_template_parm_bindings_ok_p): Adjust.
(convert_template_argument): Adjust.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/alias-decl-ttp2.C: New test.
* g++.dg/cpp1z/ttp2.C: New test.
---
gcc/cp/pt.cc | 41 +++-
gcc/testsuite/g++.dg/cpp0x/alias-decl-ttp2.C | 25
gcc/testsuite/g++.dg/cpp1z/ttp2.C| 21 ++
3 files changed, 77 insertions(+), 10 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/alias-decl-ttp2.C
create mode 100644 gcc/testsuite/g++.dg/cpp1z/ttp2.C
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 1b18e2a7787..6dda66081bd 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -7731,8 +7731,8 @@ coerce_template_template_parm (tree parm,
template class> class TT>
class C; */
{
- tree parmparm = DECL_INNERMOST_TEMPLATE_PARMS (parm);
- tree argparm = DECL_INNERMOST_TEMPLATE_PARMS (arg);
+ tree parmparm = DECL_TEMPLATE_PARMS (parm);
+ tree argparm = DECL_TEMPLATE_PARMS (arg);
if (!coerce_template_template_parms
(parmparm, argparm, complain, in_decl, outer_args))
@@ -8001,8 +8001,8 @@ unify_bound_ttp_args (tree tparms, tree targs, tree parm,
tree& arg,
the parameters to A, and OUTER_ARGS contains A. */
static int
-coerce_template_template_parms (tree parm_parms,
- tree arg_parms,
+coerce_template_template_parms (tree parm_parms_full,
+ tree arg_parms_full,
tsubst_flags_t complain,
tree in_decl,
tree outer_args)
@@ -8011,6 +8011,9 @@ coerce_template_template_parms (tree parm_parms,
tree parm, arg;
int variadic_p = 0;
+ tree parm_parms = INNERMOST_TEMPLATE_PARMS (parm_parms_full);
+ tree arg_parms = INNERMOST_TEMPLATE_PARMS (arg_parms_full);
+
gcc_assert (TREE_CODE (parm_parms) == TREE_VEC);
gcc_assert (TREE_CODE (arg_parms) == TREE_VEC);
@@ -8046,8 +8049,26 @@ coerce_template_template_parms (tree parm_parms,
specialized as P, so they match.*/
processing_template_decl_sentinel ptds (/*reset*/false);
++processing_template_decl;
+
tree pargs = template_parms_level_to_args (parm_parms);
- pargs = add_outermost_template_args (outer_args, pargs);
+
+ /* PARM, and thus the context in which we are passing ARG to it, may be
+at a deeper level than ARG; when trying to coerce to ARG_PARMS, we
+want to provide the right number of levels, so we reduce the number of
+levels in OUTER_ARGS before prepending them. This is most important
+when ARG is a namespace-scope template, as in alias-decl-ttp2.C.
+
+ARG might also be deeper than PARM (ttp23). In that case, we include
+all of OUTER_ARGS. The missing levels seem potentially problematic,
+but I can't come up with a testcase that breaks. */
+ if (int arg_outer_levs = TMPL_PARMS_DEPTH (arg_parms_full) - 1)
+ {
+ auto x = make_temp_override (TREE_VEC_LENGTH (outer_args));
+ if (TMPL_ARGS_DEPTH (outer_args) > arg_outer_levs)
+ TREE_VEC_LENGTH (outer_args) = arg_outer_levs;
+ pargs = add_to_template_args (outer_args, pargs);
+ }
+
pargs = coerce_template_parms (arg_parms, pargs, NULL_TREE, tf_none,
/*require_all*/true, /*use_default*/true);
if (pargs != error_mark_node)
@@ -8186,16 +8207,16 @@ template_template_parm_bindings_ok_p (tree tparms, tree
targs)
/* Extract the template parameters from the template
argument. */
if (TREE_CODE (targ) == TEMPLATE_DECL)
- targ_parms = DECL_INNERMOST_TEMPLATE_PARMS (targ);
+ targ_parms = DECL_TEMPLATE_PARMS (targ);
else if (TREE_CODE (targ) == TEMPLATE_TEMPLATE_PARM)
- targ_parms = DECL_INNERMOST_TEMPLATE_PARMS (TYPE_NAME (targ));
+ targ_parms = DECL_TEMPLATE_PARMS (TYPE_NAME (targ));
/* Verify that we can coerce the template template
parameters from the template argument to the template
parameter. This requires an exact match. */
if (targ_parms
&& !coerce_template_template_parms
-
[Bug ipa/102513] [10/11/12 Regression] Many false positive warnings with recursive function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513
--- Comment #10 from Feng Xue ---
(In reply to Martin Jambor from comment #8)
> I am about to thest the following patch. In longer-run, it would be better
> to never generate lattice values outside of the value_range but there is an
> ordering problem, we need the complete VR info before we can use it. I plan
> to rearrange IPA-CP into making multiple passes over the lattice dependency
> graph and this should quite naturally be solved by doing this kind of
> resursive-value-generation only in second and later passes.
>
>
> diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
> index 453e9c93cc3..cbbb8bbc80a 100644
> --- a/gcc/ipa-cp.cc
> +++ b/gcc/ipa-cp.cc
> @@ -6154,8 +6154,16 @@ decide_whether_version_node (struct cgraph_node *node)
> {
> ipcp_value *val;
> for (val = lat->values; val; val = val->next)
> - ret |= decide_about_value (node, i, -1, val, ,
> - _gen_clones);
> + {
> + if (!plats->m_value_range.bottom_p ()
> + && !plats->m_value_range.m_vr.contains_p (val->value))
> + {
> + gcc_checking_assert (val->self_recursion_generated_p ());
> + continue;
> + }
> + ret |= decide_about_value (node, i, -1, val, ,
> +_gen_clones);
> + }
> }
>
>if (!plats->aggs_bottom)
Here is a complication that value range for recursion index might not be not
easily computed, and could not prevent IPA-CP generating useless copy.
Constraint of recursion index comes from "block2[level][x]", not its value
range deduced from condition predicate (level > 0). Change the case to cover up
value range of "level", and we will get same warning. So in the circumstances,
one way for us is to disable warning for these copies?
extern int block2[7][256];
extern unsigned G_START;
extern unsigned G_SCALE;
static int encode_block(int block2[7][256], unsigned level)
{
int best_score = 0;
for (unsigned x = G_START; x < G_SCALE * level; x++) {
int v = block2[1][x];
block2[level][x] = 0;
best_score += v * v;
}
if (G_SCALE * level > G_START && best_score > 64) {
int score = 0;
score += encode_block(block2, level - 1);
score += encode_block(block2, level - 1);
if (score < best_score) {
best_score = score;
}
}
return best_score;
}
[Bug tree-optimization/104539] Failed to inline a very simple template function when it's explicit instantiated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104539
--- Comment #1 from Cassio Neri ---
Sorry, the last snippet above should be
template
inline
int f() {
return 0;
}
[Bug tree-optimization/104539] New: Failed to inline a very simple template function when it's explicit instantiated.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104539
Bug ID: 104539
Summary: Failed to inline a very simple template function when
it's explicit instantiated.
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: cassio.neri at gmail dot com
Target Milestone: ---
Consider:
template
//inline
int f() {
return 0;
}
int g() {
return f<0>() + 1;
}
Using -O3, I'd expect f to be inlined in g and this is indeed the case:
g():
mov eax, 1
ret
However, if f is explicit instantiated:
template unsigned f<0>();
then we get a function call (or a jmp if tail call optimisation is possible)
g():
sub rsp, 8
call int f<0>()
add rsp, 8
add eax, 1
ret
A (quite unusual, IMHO) workaround is declaring f as inline:
template
inline
unsigned f() {
return n;
}
https://godbolt.org/z/TarsTY3zb
[Bug middle-end/98465] Bogus -Wstringop-overread with -std=gnu++20 -O2 and std::string::insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98465 Randy changed: What|Removed |Added CC||Randy at miningrigrentals dot com --- Comment #34 from Randy --- Is the patch for GCC 12 for this issue also applied to std_vstring?
[Bug d/104538] gdc/d21: segfault on mips64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104538 --- Comment #1 from YunQiang Su --- This problem happens only for the new gdc code introduced in gcc-12.
[Bug d/104538] New: gdc/d21: segfault on mips64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104538
Bug ID: 104538
Summary: gdc/d21: segfault on mips64
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: syq at debian dot org
Target Milestone: ---
https://buildd.debian.org/status/fetch.php?pkg=gcc-12=mips64el=12-20220214-1=1644848228=0
The segment is from:
gcc/d/dmd/ctfeexpr.d:
UnionExp changeArrayLiteralLength(const ref Loc loc, TypeArray arrayType,
Expression oldval, size_t oldlen, size_t newlen)
if (oldlen != 0)
{
assert(oldval.op == EXP.arrayLiteral);
ArrayLiteralExp ae = cast(ArrayLiteralExp)oldval;
foreach (size_t i; 0 .. copylen)
(*elements)[i] = (*ae.elements)[indxlo + i];
}
if (elemType.ty == Tstruct || elemType.ty == Tsarray)
{
/* If it is an aggregate literal representing a value type,
* we need to create a unique copy for each element
*/
foreach (size_t i; copylen .. newlen)
(*elements)[i] = copyLiteral(defaultElem).copy();
}
else
{
foreach (size_t i; copylen .. newlen)
(*elements)[i] = defaultElem;
}
>>>>emplaceExp!(ArrayLiteralExp)(, loc, arrayType, elements);
ArrayLiteralExp aae = cast(ArrayLiteralExp)ue.exp();
aae.ownedByCtfe = OwnedBy.ctfe;
[Bug ipa/104377] Unreachable code in create_specialized_node of ipa-prop.c?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104377 --- Comment #4 from Feng Xue --- (In reply to Martin Jambor from comment #2) > (In reply to Feng Xue from comment #1) > > > > OK. I does missed something. Here we could not hold assumption that > > ipcp_decision_stage() only sees raw cgraph node, since sometime in the > > future some new ipa pass may be added prior to ipa-cp, and this pass > > introduces clone node. > > Right, initially IPA-SRA was developed as a pass before IPA-CP and it > may well be that we decide to swap the order again. > > > > > However, there is a questionable point about the code snippet > > > > if (!node->can_change_signature > > || old_adj->op != IPA_PARAM_OP_COPY > > || (!known_csts[old_adj->base_index] > > && ipa_is_param_used (info, old_adj->base_index))) > > > > In ipa-cp, known_csts is for the node, has no relation to the node's origin > > node, but here it is accessed via index of the latter (old_adj->base_index), > > will this cause out-of-bound error? > > I think the code is correct. Assume IPA-SRA running before IPA-CP, and > we're compiling a function with two argument, with indices 0 and 1. > > Analysis phases of both passes run before the IPA (WPA) phases of > either. This is important to keep in mind. > > IPA SRA removes the first one with index zero as useless, IPA-CP wants > to remove the second one with index 1, possibly because it is constant > everywhere. In oder to that it has to combine the pre-existing > adjustments with its own changes. > > Before create_specialized_node, the pass checks whether previous > passes did not kill some parameters and stops caring about them, but > it does not re-index anything, all lattices, jump functions, > everything, still keep their positions (and thus indices) they got in > the analysis phase. > > Then create_specialized_node hits this loop. For i=0 encounters an > old_adj element that actually describes the parameter which originally > had index 1. The pass looks up in base_index what the original > (pre-IPA) index of the parameter was (1) and uses those to look up in > its own structures whether it wants to remove it or not. > > Bounds should be always OK, base_index should never be greater than > the original pre-IPA number of parameters (-1) and known_csts should > always have just as many parameters. > > Does that make sense? Yes. Thanks for your explanation.
Re: [PATCH, rs6000] Remove TImode from mode iterator BOOL_128 [PR100694]
Segher, Thanks for your comments. Here are my comments and questions.Thanks. On 15/2/2022 上午 5:36, Segher Boessenkool wrote: > Hi! > > On Wed, Feb 09, 2022 at 10:43:17AM +0800, HAO CHEN GUI wrote: >> This patch removes TImode from mode iterator BOOL_128. Thus, bool >> operations (AND, IOR, XOR, NOT) >> on TImode will be split to the relevant operations on word mode during >> expand (in optabs.c). > > But we also want to allow TImode in VSRs. This of course is a never- > ending story, no choice works very well here. > >> Potential >> optimizations can be implemented after the split. The former practice splits >> it after the reload >> pass which is too later for some optimizations. The new test case >> illustrates it. > > All that are arguments for expanding to split form, not for removing > TImode from the iterator. And you leave PTImode, which *always* is in > GPRs! >From my understanding, PTImode has limitation that it needs to be assigned with an even/odd register pair. So it can't be split before the reload pass. Currently it is split after reload.> > It may be that only leaving the "V" modes there works well; that needs > testing though, more than just asaserting this. > > Just doing it and handling the ICEs later is fine, but in stage 1. > > (You'll also have to show it is *correct*, you need to prove (or show it > really likely :-) ) that after this change there are no TImode things > generated anywhere (anywhere!) that are no longer handled now). > Yes, the TI may be generated after expand pass and causes ICEs. So how about creating two mode iterators? One is for expand which doesn't include TImode, another is for the split which include TImode and make TImode to be split as early as possible? > > Segher
Re: [PATCH] c: Add diagnostic when operator= is used as truth cond [PR25689]
On 14/02/2022, Jason Merrill wrote:
>>
>> +/* Returns true if EXPR is a reference to an implicit
>> + call to operator=(). */
>> +static bool
>> +is_assignment_overload_ref_p (tree expr)
>> +{
>> + if (expr == NULL_TREE || !REFERENCE_REF_P (expr))
>> +return false;
>
> This will only warn about op= that returns a reference, which is not
> required.
>
Ah I understand now. I added some new test cases for non-reference return types
and copied some code from extract_call_expr that seems to do what we want.
>> + return fndecl != NULL_TREE
>> +&& DECL_OVERLOADED_OPERATOR_P (fndecl)
>> +&& DECL_OVERLOADED_OPERATOR_IS (fndecl, NOP_EXPR)
>> +&& DECL_ASSIGNMENT_OPERATOR_P (fndecl);
>
> This could be
>
>&& DECL_ASSIGNMENT_OPERATOR_P (fndecl)
>&& DECL_OVERLOADED_OPERATOR_IS (fndecl, NOP_EXPR);
>
> without the separate DECL_OVERLOADED_OPERATOR_P test.
>
I see. I've adjusted the code as you suggested and it works. Thanks!
-- Everything below is the patch v4 --
When compiling the following code with g++ -Wparentheses, GCC does not
warn on the if statement. For example, there is no warning for this code:
struct A {
A& operator=(int);
operator bool();
};
void f(A a) {
if (a = 0); // no warning
}
This is because a = 0 is a call to operator=, which GCC does not handle.
This patch fixes this issue by handling calls to operator= when deciding
to warn.
Bootstrapped and tested on x86_64-pc-linux-gnu.
v3: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590310.html
Changes since v3:
1. Also handle COMPOUND_EXPRs and TARGET_EXPRs.
v2: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590236.html
Changes since v2:
1. Add more test cases in Wparentheses-31.C.
2. Refactor added logic to a function (is_assignment_overload_ref_p).
3. Use REFERENCE_REF_P instead of INDIRECT_REF_P.
v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590158.html
Changes since v1:
1. Use CALL_EXPR_OPERATOR_SYNTAX to avoid warnings for explicit
operator=() calls.
2. Use INDIRECT_REF_P to filter implicit operator=() calls.
3. Use cp_get_callee_fndecl_nofold.
4. Add spaces before (.
PR c/25689
gcc/cp/ChangeLog:
* semantics.cc (maybe_convert_cond): Handle the implicit
operator=() case for -Wparentheses.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wparentheses-31.C: New test.
---
gcc/cp/semantics.cc | 29 +-
gcc/testsuite/g++.dg/warn/Wparentheses-31.C | 62 +
2 files changed, 90 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/warn/Wparentheses-31.C
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 0cb17a6a8ab1c..9c3f613a1aa62 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -815,6 +815,33 @@ finish_goto_stmt (tree destination)
return add_stmt (build_stmt (input_location, GOTO_EXPR, destination));
}
+/* Returns true if CALL is a (possibly wrapped) CALL_EXPR
+ to operator=() that is written as an operator expression. */
+static bool
+is_assignment_op_expr_p(tree call)
+{
+ if (call == NULL_TREE)
+return false;
+
+ /* Unwrap the CALL_EXPR. */
+ while (TREE_CODE (call) == COMPOUND_EXPR)
+call = TREE_OPERAND (call, 1);
+ if (REFERENCE_REF_P (call))
+call = TREE_OPERAND (call, 0);
+ if (TREE_CODE (call) == TARGET_EXPR)
+call = TARGET_EXPR_INITIAL (call);
+
+ if (call == NULL_TREE
+ || TREE_CODE (call) != CALL_EXPR
+ || !CALL_EXPR_OPERATOR_SYNTAX (call))
+return false;
+
+ tree fndecl = cp_get_callee_fndecl_nofold (call);
+ return fndecl != NULL_TREE
+&& DECL_ASSIGNMENT_OPERATOR_P (fndecl)
+&& DECL_OVERLOADED_OPERATOR_IS (fndecl, NOP_EXPR);
+}
+
/* COND is the condition-expression for an if, while, etc.,
statement. Convert it to a boolean value, if appropriate.
In addition, verify sequence points if -Wsequence-point is enabled. */
@@ -836,7 +863,7 @@ maybe_convert_cond (tree cond)
/* Do the conversion. */
cond = convert_from_reference (cond);
- if (TREE_CODE (cond) == MODIFY_EXPR
+ if ((TREE_CODE (cond) == MODIFY_EXPR || is_assignment_op_expr_p (cond))
&& warn_parentheses
&& !warning_suppressed_p (cond, OPT_Wparentheses)
&& warning_at (cp_expr_loc_or_input_loc (cond),
diff --git a/gcc/testsuite/g++.dg/warn/Wparentheses-31.C
b/gcc/testsuite/g++.dg/warn/Wparentheses-31.C
new file mode 100644
index 0..8d48ca5205782
--- /dev/null
+++ b/gcc/testsuite/g++.dg/warn/Wparentheses-31.C
@@ -0,0 +1,62 @@
+/* Test that -Wparentheses warns for struct/class assignments,
+ except for explicit calls to operator= (). */
+/* PR c/25689 */
+/* { dg-options "-Wparentheses" } */
+
+struct A
+{
+ A& operator= (int);
+ A operator= (double);
+ operator bool ();
+};
+
+struct B
+{
+ bool x;
+ B& operator= (int);
+ B operator= (double);
+ operator bool ();
+};
+
+struct C
+{
+ C& operator= (int);
+
[Bug c++/99215] coroutines: debugging with gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215 --- Comment #14 from Jarrod Smith --- I've been following this and experiencing the issue in gcc 10.2. I still see "" for all variables when debugging C++20 coroutines with gcc 11.2. Is there a workaround (e.g. using a certain branch of gcc) in order to inspect coroutine variables with gdb the meantime?
[Bug c++/104537] New: ICE when generic-lambda as function parameter fails to be converted to pointer to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104537
Bug ID: 104537
Summary: ICE when generic-lambda as function parameter fails to
be converted to pointer to function
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
Consider this invalid conversion for this generic-lambda to pointer to function
which is defined by "decltype(+[](T&& t )->T{return t+1;}".
This ICE happens when original accepted parameter type changed from "T" to
"T&&".
See compiler explorer (https://www.godbolt.org/z/fde1bc3zE)
I suspect this is some related issue with another unconfirmed case PR104358.
template
auto foo(T&& t, decltype(+[](T&& t )->T{return t+1;}) lam){
return lam(t);
}
void test(){
foo(5, [](int t){return t+1;});
}
:8:21: error: invalid user-defined conversion from
'test()::' to 'int (*)(int&&)' [-fpermissive]
8 | foo(5, [](int t){return t+1;});
| ^~
...
internal compiler error: error reporting routines re-entered.
0x2174365 warning_at(unsigned int, int, char const*, ...)
...
[Bug middle-end/104492] [12 Regression] Bogus dangling pointer warning at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104492
--- Comment #5 from Martin Sebor ---
Setting aside the question of warning about inequality expressions involving
invalid pointers, it seems that if the annotation 'candidates ={v}
{CLOBBER(eol)};' is to be interpreted as one would intuitively expect -- as
ending the variable's lifetime -- then GCC moving its use past that point
should be considered a bug in that transformation.
[Bug target/99197] Built-ins for packing/unpacking __ibm128 not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99197
Michael Meissner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Michael Meissner ---
These functions have been documented since June 2018. The file extend.texi
contains:
The @code{__builtin_unpack_ibm128} function takes a @code{__ibm128}
argument and a compile time constant of 0 or 1. If the constant is 0,
the first @code{double} within the @code{__ibm128} is returned,
otherwise the second @code{double} is returned.
The @code{__builtin_pack_ibm128} function takes two @code{double}
arguments and returns a @code{__ibm128} value that combines the two
arguments.
Re: [PATCH] PR c/104506: Tolerate error_mark_node in useless_type_conversion_p.
On Mon, Feb 14, 2022 at 4:54 AM Roger Sayle wrote:
>
>
>
> This simple fix to the middle-end, resolves PR c/104506, by adding an
>
> explicit check for error_mark_node to useless_type_conversion_p. I first
>
> trying fixing this in the C front-end, but the type is valid at the point
>
> that the NOP_EXPR is created, so the poisoned type leaks to the middle-end.
>
> Returning either true or false from useless_type_conversion_p avoids the
>
> ICE-after-error. Apologies to Andrew Pinski, I hadn't noticed that he'd
>
> assigned this PR to himself until after my regression testing had finished.
>
>
>
> This patch has been tested on x86_64-pc-linux-gnu with make bootstrap and
>
> make -k check with no new failures. Ok for mainline?
>
>
>
>
>
> 2022-02-14 Roger Sayle
>
>
>
> gcc/ChangeLog
>
> PR c/104506
>
> * gimple-expr.cc (useless_type_conversion_p): Add a check for
>
> error_mark_node.
I came up with a different patch (attached) which just changes
tree_ssa_useless_type_conversion rather than useless_type_conversion_p
which I was going to submit but had an issue with my build machine.
I did it this way as it was similar to how
STRIP_NOPS/tree_nop_conversion was done already.
Also from my description of the patch
STRIP_USELESS_TYPE_CONVERSION is mostly used inside the gimplifier
and the places where it is used outside of the gimplifier would not
be adding too much overhead.
Though I think Richard Biener's patch is better really. It would be
interesting to see how the C++ front-end handles this case, I remember
it using integer_type_node in some locations after an error for a
type.
Thanks,
Andrew Pinski
>
>
>
> gcc/testsuite/ChangeLog
>
> PR c/104506
>
> * gcc.dg/pr104506.c: New test case.
>
>
>
>
>
> Roger
>
> --
>
>
From 43d418042efacbb7efe8664fbb1176608470474a Mon Sep 17 00:00:00 2001
From: Andrew Pinski
Date: Sun, 13 Feb 2022 00:09:39 +
Subject: [PATCH] c: [PR104506] Fix ICE after error due to change of type to
error_mark_node
The problem here is we end up with an error_mark_node when calling
useless_type_conversion_p and that ICEs. STRIP_NOPS/tree_nop_conversion
has had a check for the inner type being an error_mark_node since g9a6bb3f78c96
(2000). This just adds the check also to tree_ssa_useless_type_conversion.
STRIP_USELESS_TYPE_CONVERSION is mostly used inside the gimplifier
and the places where it is used outside of the gimplifier would not
be adding too much overhead.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
Thanks,
Andrew Pinski
PR c/104506
gcc/ChangeLog:
* tree-ssa.cc (tree_ssa_useless_type_conversion):
Check the inner type before calling useless_type_conversion_p.
gcc/testsuite/ChangeLog:
* gcc.dg/pr104506-1.c: New test.
* gcc.dg/pr104506-2.c: New test.
* gcc.dg/pr104506-3.c: New test.
---
gcc/testsuite/gcc.dg/pr104506-1.c | 12
gcc/testsuite/gcc.dg/pr104506-2.c | 11 +++
gcc/testsuite/gcc.dg/pr104506-3.c | 11 +++
gcc/tree-ssa.cc | 20 +---
4 files changed, 47 insertions(+), 7 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/pr104506-1.c
create mode 100644 gcc/testsuite/gcc.dg/pr104506-2.c
create mode 100644 gcc/testsuite/gcc.dg/pr104506-3.c
diff --git a/gcc/testsuite/gcc.dg/pr104506-1.c
b/gcc/testsuite/gcc.dg/pr104506-1.c
new file mode 100644
index 000..5eb71911b71
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr104506-1.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-options "-std=gnu11" } */
+/* PR c/104506: we used to ICE after the error of
+ changing the type. */
+
+void
+foo (double x)
+/* { dg-message "note: previous definition" "previous definition" { target
*-*-* } .-1 } */
+{
+ (void)x;
+ int x; /* { dg-error "redeclared as different kind of symbol" } */
+}
diff --git a/gcc/testsuite/gcc.dg/pr104506-2.c
b/gcc/testsuite/gcc.dg/pr104506-2.c
new file mode 100644
index 000..3c3c4f8
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr104506-2.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-std=gnu11" } */
+/* PR c/104506: we used to ICE after the error of
+ changing the type. */
+void
+foo (double x)
+/* { dg-message "note: previous definition" "previous definition" { target
*-*-* } .-1 } */
+{
+ x;
+ int x; /* { dg-error "redeclared as different kind of symbol" } */
+}
diff --git a/gcc/testsuite/gcc.dg/pr104506-3.c
b/gcc/testsuite/gcc.dg/pr104506-3.c
new file mode 100644
index 000..b14deb5cf25
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr104506-3.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* PR c/104506: we used to ICE after the error of
+ changing the type. */
+double x;
+/* { dg-message "note: previous declaration" "previous declaration" { target
*-*-* } .-1 } */
+void
+foo (void)
+{
+ x;
+}
+int x; /* { dg-error "conflicting types" } */
diff --git a/gcc/tree-ssa.cc b/gcc/tree-ssa.cc
index 8fe0682981d..98dada09647 100644
--- a/gcc/tree-ssa.cc
+++
[Bug other/104536] [12 Regression] gcc-12-20220213 Fails to build on Cygwin: contraction ‘can%'t’ in format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104536 Andrew Pinski changed: What|Removed |Added Component|bootstrap |other Host||*-*-cygwin Summary|gcc-12-20220213 Fails to|[12 Regression] |build on Cygwin:|gcc-12-20220213 Fails to |contraction ‘can%'t’ in |build on Cygwin: |format |contraction ‘can%'t’ in ||format Target Milestone|--- |12.0 Keywords||build, diagnostic
[Bug bootstrap/104536] gcc-12-20220213 Fails to build on Cygwin: contraction ‘can%'t’ in format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104536 --- Comment #1 from James McKelvey --- Created attachment 52441 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52441=edit Config log
[Bug bootstrap/104536] New: gcc-12-20220213 Fails to build on Cygwin: contraction ‘can%'t’ in format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104536 Bug ID: 104536 Summary: gcc-12-20220213 Fails to build on Cygwin: contraction ‘can%'t’ in format Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: mckelvey at maskull dot com Target Milestone: --- Created attachment 52440 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52440=edit Log of entire build Building on Cygwin with gcc-11-20220212 and Windows 10. ./configure --enable-languages=c,c++ --enable-threads=posix --disable-multilib $ uname CYGWIN_NT-10.0 make[3]: Entering directory '/home/McKelvey/gcc-12-20220213/host-x86_64-pc-cygwin/gcc' /home/McKelvey/gcc-12-20220213/host-x86_64-pc-cygwin/prev-gcc/xg++ -B/home/McKelvey/gcc-12-20220213/host-x86_64-pc-cygwin/prev-gcc/ -B/usr/local/x86_64-pc-cygwin/bin/ -nostdinc++ -B/home/McKelvey/gcc-12-20220213/prev-x86_64-pc-cygwin/libstdc++-v3/src/.libs -B/home/McKelvey/gcc-12-20220213/prev-x86_64-pc-cygwin/libstdc++-v3/libsupc++/.libs -I/home/McKelvey/gcc-12-20220213/prev-x86_64-pc-cygwin/libstdc++-v3/include/x86_64-pc-cygwin -I/home/McKelvey/gcc-12-20220213/prev-x86_64-pc-cygwin/libstdc++-v3/include -I/home/McKelvey/gcc-12-20220213/libstdc++-v3/libsupc++ -L/home/McKelvey/gcc-12-20220213/prev-x86_64-pc-cygwin/libstdc++-v3/src/.libs -L/home/McKelvey/gcc-12-20220213/prev-x86_64-pc-cygwin/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libcody -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid -I../libdecnumber -I../.././gcc/../libbacktrace -I. -I. -I../.././gcc -I../.././gcc/. -I../.././gcc/../include -I../.././gcc/../libcpp/include -I../.././gcc/../libcody -I../.././gcc/../libdecnumber -I../.././gcc/../libdecnumber/bid -I../libdecnumber -I../.././gcc/../libbacktrace \ ../.././gcc/config/i386/host-cygwin.cc ../.././gcc/config/i386/host-cygwin.cc: In function ‘void* cygwin_gt_pch_get_address(size_t, int)’: ../.././gcc/config/i386/host-cygwin.cc:57:35: error: contraction ‘can%'t’ in format; use ‘cannot’ instead [-Werror=format-diag] 57 | fatal_error (input_location, "can%'t get position in PCH file: %m"); | ^~ ../.././gcc/config/i386/host-cygwin.cc:64:37: error: contraction ‘can%'t’ in format; use ‘cannot’ instead [-Werror=format-diag] 64 | fatal_error (input_location, "can%'t extend PCH file: %m"); | ^~ ../.././gcc/config/i386/host-cygwin.cc:75:35: error: contraction ‘can%'t’ in format; use ‘cannot’ instead [-Werror=format-diag] 75 | fatal_error (input_location, "can%'t set position in PCH file: %m"); | ^~ cc1plus: all warnings being treated as errors make[3]: *** [../.././gcc/config/i386/x-cygwin:3: host-cygwin.o] Error 1 make[3]: Leaving directory '/home/McKelvey/gcc-12-20220213/host-x86_64-pc-cygwin/gcc' make[2]: *** [Makefile:5003: all-stage2-gcc] Error 2 make[2]: Leaving directory '/home/McKelvey/gcc-12-20220213' make[1]: *** [Makefile:24127: stage2-bubble] Error 2 make[1]: Leaving directory '/home/McKelvey/gcc-12-20220213' make: *** [Makefile:1072: all] Error 2
[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 --- Comment #9 from qinzhao at gcc dot gnu.org --- having a patch in my local tree, under testing.
Re: [PATCH] Update -Warray-bounds documentation [PR104355]
On 2/10/22 23:48, Richard Sandiford wrote:
Martin Sebor via Gcc-patches writes:
The -Warray-bounds description in the manual is out of date in
a couple of ways. First it claims that the option is only active
with optimization, which isn't entirely correct since at least one
instance is issued even without it. Second, the description of
its level 2 suggests it controls the warning for all trailing
array members, when it only controls it for trailing one-element
arrays (this was made tighter in GCC 10 but we neglected to update
the manual).
In addition, the word "always" in the description of the option
is also interpreted by some as implying that every instance of
the warning is necessarily a true positive. I've reworded
the description to hopefully avoid this misreading(*).
Finally, the generic text that talks about the interaction with
optimizations says that -Wmaybe-uninitialized is not issued unless
optimization is enabled. That's also not accurate anymore since
at least one instance of the warning is independent of optimization
(passing uninitialized objects by reference to const arguments).
The attached changes correct these oversights.
Martin
[*] It should probably be made clearer in the generic text that
no instance of any warning, not just -Warray-bounds, should be
taken to be a definitive indication of a bug in the code. I've
left that for later.
Yeah, maybe, but I guess it's unlikely to be useful in practice.
The chances of users happening to read a given bit of generic text
seem pretty low.
Doesn't mean we shouldn't do it of course (provided that we don't then
castigate users for having failed to notice it).
I'm sure you're right that few users go to the trouble of studying
the manual when interpreting a warning (and some not even before
submitting a problem report).
Update -Warray-bounds documentation [PR104355].
Resolves:
PR middle-end/104355 - Misleading and outdated -Warray-bounds documentation
gcc/ChangeLog:
* doc/invoke.texi (-Warray-bounds): Update documentation.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index b49ba22df89..b7b1f47a5ce 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -5641,8 +5641,10 @@ warns that an unrecognized option is present.
The effectiveness of some warnings depends on optimizations also being
enabled. For example @option{-Wsuggest-final-types} is more effective
-with link-time optimization and @option{-Wmaybe-uninitialized} does not
-warn at all unless optimization is enabled.
+with link-time optimization and some instances of other warnings may
+not be issued at all unless optimization is enabled. While optimization
+in general improves the efficacy of control and data flow sensitive
+warnings, in some cases it may also cause false positives.
@table @gcctabopt
@item -Wpedantic
@@ -7691,20 +7693,22 @@ void f (char c, int i)
@itemx -Warray-bounds=@var{n}
@opindex Wno-array-bounds
@opindex Warray-bounds
-This option is only active when @option{-ftree-vrp} is active
-(default for @option{-O2} and above). It warns about subscripts to arrays
-that are always out of bounds. This warning is enabled by @option{-Wall}.
+Warn about out of bounds subscripts or offsets into arrays. This warning
+level is enabled by @option{-Wall}. It is the most effective when
It's not clear to me which level is “this level” here. How about
something like “This warning is enabled at level 1…”?
Yes, good catch, that was a mistake on my part.
“It is more effective when” seems more natural to me than “It is the most
effective when”, but maybe that's just me.
-Warray-bounds doesn't do much without -ftree-vrp (it detects out-of-
bounds offsets in calls to built-ins), and does almost nothing below
-O2 (all it diagnoses at -O0 is strlen() calls with past-the-end
offsets to string constants). But since the rest of the sentence
mention that it's not completely silent even at -O0 your words sound
good to me too.
Looks good to me otherwise FWIW. OK with those changes if you agree and
if no-one has further comments by Monday.
Pushed now in r12-7234.
Martin
Thanks,
Richard
+@option{-ftree-vrp} is active (the default for @option{-O2} and above)
+but a subset of instances are issued even without optimization.
@table @gcctabopt
@item -Warray-bounds=1
-This is the warning level of @option{-Warray-bounds} and is enabled
+This is the default warning level of @option{-Warray-bounds} and is enabled
by @option{-Wall}; higher levels are not, and must be explicitly requested.
@item -Warray-bounds=2
-This warning level also warns about out of bounds access for
-arrays at the end of a struct and for arrays accessed through
-pointers. This warning level may give a larger number of
-false positives and is deactivated by default.
+This warning level also warns out of bounds accesses to trailing struct
+members of one-element array types (@pxref{Zero Length}) and about
+the intermediate results of
[Bug middle-end/104355] Misleading -Warray-bounds documentation says "always out of bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104355 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:7a1b179b08bc802280ca90ed4c6c8d8b25503e66 commit r12-7234-g7a1b179b08bc802280ca90ed4c6c8d8b25503e66 Author: Martin Sebor Date: Mon Feb 14 15:40:25 2022 -0700 Update -Warray-bounds documentation [PR104355]. Resolves: PR middle-end/104355 - Misleading and outdated -Warray-bounds documentation gcc/ChangeLog: PR middle-end/104355 * doc/invoke.texi (-Warray-bounds): Update documentation.
[Bug target/104253] libgcc missing __floatdiif
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104253 --- Comment #12 from CVS Commits --- The master branch has been updated by Michael Meissner : https://gcc.gnu.org/g:16b65b08484237cc2845c4f5c4f15efe3a43a32c commit r12-7233-g16b65b08484237cc2845c4f5c4f15efe3a43a32c Author: Michael Meissner Date: Mon Feb 14 17:42:14 2022 -0500 Use correct names for __ibm128 if long double is IEEE 128-bit. If you are on a PowerPC system where the default long double is IEEE 128-bit (either through the compiler option -mabi=ieeelongdouble or via the configure option --with-long-double-format=ieee), GCC used the wrong names for some of the conversion functions for the __ibm128 type. Internally, GCC uses IFmode for __ibm128 if long double is IEEE 128-bit, instead of TFmode when long double is IBM 128-bit. This patch adds the missing conversions to prevent the 'if' name from being used. In particular, before the patch, the conversions used were: IFmode to DImode signed:__fixifdi instead of __fixtfdi IFmode to DImode unsigned __fixunsiftiinstead of __fixunstfti DImode to IFmode signed:__floatdiif instead of __floatditf DImode to IFmode unsigned: __floatundiif instead of __floatunditf 2022-02-14 Michael Meissner gcc/ PR target/104253 * config/rs6000/rs6000.cc (init_float128_ibm): Update the conversion functions used to convert IFmode types. gcc/testsuite/ PR target/104253 * gcc.target/powerpc/pr104253.c: New test.
[Bug tree-optimization/104526] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104526 --- Comment #3 from Andrew Macleod --- (In reply to Jakub Jelinek from comment #2) > and evrp properly figured out those ranges, that 1 / int is [-1, 1] and > that 2 >> [-1, 1] is [1, 2]. > But since r12-6924 the IL is: > c.0_1 = c; > _2 = *c.0_1; > _11 = (unsigned int) _2; > _12 = _11 + 1; > _13 = _12 <= 2; > _3 = _12 <= 2 ? _2 : 0; > So, Andrew/Aldy, how hard would it be to improve ranger COND_EXPR handling, > so that it essentially does what we do for the PHI cases? I.e. from the > COND_EXPR condition, compute "assertion" if condition is true or if > condition is false, and use that on the COND_EXPR's second and third > argument. > So for the > _3 = _12 <= 2 ? _2 : 0; > comparison, for second argument the condition must be true which implies that > _2 must be there [-1, 1], while for the third argument the condition must be > false, but the argument is constant 0, so range is [0, 0], then just union > those 2 ranges. > > As this is a P1 regression, if we can fix it, would be nice to get it into > GCC 12. I'm having a look. The bits are all there. Most of gori is stmt oriented, but I may be able to invoke the components such that we evaluate the 2nd and 3rd arguemnts as if they were on true/false edges to improve the results..
Re: [PATCH, rs6000] Remove TImode from mode iterator BOOL_128 [PR100694]
Hi! On Wed, Feb 09, 2022 at 10:43:17AM +0800, HAO CHEN GUI wrote: > This patch removes TImode from mode iterator BOOL_128. Thus, bool > operations (AND, IOR, XOR, NOT) > on TImode will be split to the relevant operations on word mode during expand > (in optabs.c). But we also want to allow TImode in VSRs. This of course is a never- ending story, no choice works very well here. > Potential > optimizations can be implemented after the split. The former practice splits > it after the reload > pass which is too later for some optimizations. The new test case illustrates > it. All that are arguments for expanding to split form, not for removing TImode from the iterator. And you leave PTImode, which *always* is in GPRs! It may be that only leaving the "V" modes there works well; that needs testing though, more than just asaserting this. Just doing it and handling the ICEs later is fine, but in stage 1. (You'll also have to show it is *correct*, you need to prove (or show it really likely :-) ) that after this change there are no TImode things generated anywhere (anywhere!) that are no longer handled now). Segher
[Bug c++/104523] G++ crash when compiling a simple module that includes pybind11/stl.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104523
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Ever confirmed|0 |1
Last reconfirmed|2022-02-13 00:00:00 |2022-02-14
Status|UNCONFIRMED |NEW
--- Comment #4 from Andrew Pinski ---
Confirmed, reduced testcase:
# 1 "mysource.cc"
module ;
# 1 "myheader.h" 1
template
class t {
template friend class tt;
};
t to_wstring() { }
# 4 "mysource.cc" 2
export module mymodule;
Or maybe that is a regression from before
[Bug fortran/104535] New: don't use fmod?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104535 Bug ID: 104535 Summary: don't use fmod? Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fx at gnu dot org Target Milestone: --- I was reminded by comments on the report I made about poor fmod performance on x86 that I should have commented on the original observation. I'd looked at one of the Polyhedron benchmarks which suffers badly from a simple random number routine that calls DMOD. That gets compiled to fmod, which is only inlined, albeit poorly on x86, with the relevant component(s) of -ffast-math. It seems to me that MOD should compile to the arithmetical expression in the standard, which doesn't have the complication of having to treat errors. (When I defined DMOD as a statement function for it in that routine, I got performance much closer to ifort. I should have kept the profiles I compared, but could regenerate them. Is there a good reason not to do that (and maybe similarly with other intrinsics I haven't checked)? I could probably have a go at implementing it if appropriate, though I don't know my way around now.
[Bug c++/95596] string literal wrong overload resolution (char* vs std::string)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95596 Andrew Pinski changed: What|Removed |Added CC||johnsen.david at siemens dot com --- Comment #7 from Andrew Pinski --- *** Bug 104534 has been marked as a duplicate of this bug. ***
[Bug c++/104534] write-strings does not follow C++ standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104534 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 95596. *** This bug has been marked as a duplicate of bug 95596 ***
[Bug fortran/104211] ICE in find_array_section, at fortran/expr.cc:1720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104211 --- Comment #3 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:19b517dff37b8e25f6babf8883483be73cad8fb3 commit r12-7232-g19b517dff37b8e25f6babf8883483be73cad8fb3 Author: Harald Anlauf Date: Thu Feb 10 21:22:48 2022 +0100 Fortran: improve error recovery on bad array section gcc/fortran/ChangeLog: PR fortran/104211 * expr.cc (find_array_section): Replace assertion by error recovery when encountering bad array constructor. gcc/testsuite/ChangeLog: PR fortran/104211 * gfortran.dg/pr104211.f90: New test.
[Bug c++/104534] New: write-strings does not follow C++ standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104534
Bug ID: 104534
Summary: write-strings does not follow C++ standard
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: johnsen.david at siemens dot com
Target Milestone: ---
The bug is present in all versions of GCC from 6 to 11 and on GCC trunk.
example file ws.cpp:
#include
void f(char*) { std::cout << "This compiler is broken" << std::endl; }
void f(bool) { std::cout << "This compiler is correct" << std::endl; }
int main() {
f("This is supposed to work");
return 0;
}
This program is a valid C++ and the standard is very clear on what the result
should be.
As far as I know, there is no way to make GCC generate this result.
compiled with: c++ ws.cpp
Depending on the command line options, the program can:
* compile (and run incorrectly, -Wnowrite-strings),
* compile with a warning (still run incorrectly, -Wwrite-strings),
* or not compile at all (-Werror -Wwrite-strings).
The only outcome that I can't get is the correct one:
* The program compiles without errors and runs correctly.
Other compilers, such as clang++ and Visual Studio C++, follow the standard.
[Bug c/104531] [12 Regression] ICE in prepare_cmp_insn, at optabs.cc:4547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104531 Andrew Pinski changed: What|Removed |Added Component|middle-end |c Keywords|ice-on-valid-code |ice-on-invalid-code --- Comment #1 from Andrew Pinski --- I think this might be invalid code. The C++ front-end does: : In function 'void f(__complex__ int, int)': :3:11: error: invalid operands of types 'int' and '__complex__ int' to binary '' 3 | #pragma omp atomic compare update seq_cst | ^~~ :3:11: note: in evaluation of '(int, __complex__ int)' Without -fopenmp we get: : In function 'f': :4:9: error: invalid operands to binary > (have 'int' and 'complex int') 4 | x = x > y ? y : x; | ^
[Bug c++/104533] New: [12 Regression] ICE in update_vtable_references, at ipa-visibility.cc:383
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104533
Bug ID: 104533
Summary: [12 Regression] ICE in update_vtable_references, at
ipa-visibility.cc:383
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 2024 and 20211121 :
$ cat z1.cc
struct B {
virtual ~B();
};
__attribute__((target_clones("avx")))
B::~B() = default;
$ cat z2.cc
struct B {
virtual ~B();
};
__attribute__((target_clones("sse","avx")))
B::~B() = default;
$ g++-12-20220213 -c z1.cc -fPIC -Ofast
during IPA pass: visibility
z1.cc:5:18: internal compiler error: Segmentation fault
5 | B::~B() = default;
| ^
0xda1fdf crash_signal
../../gcc/toplev.cc:322
0x19be64f update_vtable_references
../../gcc/ipa-visibility.cc:383
0x1029952 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 >*))
../../gcc/tree.cc:11070
0x1029b9c 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 >*))
../../gcc/tree.cc:11157
0x19bf549 function_and_variable_visibility
../../gcc/ipa-visibility.cc:868
[Bug middle-end/104531] [12 Regression] ICE in prepare_cmp_insn, at optabs.cc:4547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104531 Andrew Pinski changed: What|Removed |Added Summary|ICE in prepare_cmp_insn, at |[12 Regression] ICE in |optabs.cc:4547 |prepare_cmp_insn, at ||optabs.cc:4547 Keywords||ice-on-valid-code Target Milestone|--- |12.0 Component|c |middle-end
[Bug c/104532] New: ICE in lvalue_p, at c/c-typeck.cc:4987
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104532
Bug ID: 104532
Summary: ICE in lvalue_p, at c/c-typeck.cc:4987
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20211205 and 20211212 :
$ cat z1.c
void f (int x)
{
#pragma omp target enter data map (to: x->vectors)
}
$ cat z2.c
void f (int x)
{
#pragma omp target enter data map (to: x->vectors[])
}
$ gcc-12-20220213 -c z1.c -fopenmp
z1.c: In function 'f':
z1.c:3:11: internal compiler error: Segmentation fault
3 | #pragma omp target enter data map (to: x->vectors)
| ^~~
0xc1c3cf crash_signal
../../gcc/toplev.cc:322
0x6c1a46 lvalue_p(tree_node const*)
../../gcc/c/c-typeck.cc:4987
0x6ca5a8 build_component_ref(unsigned int, tree_node*, tree_node*, unsigned
int)
../../gcc/c/c-typeck.cc:2470
0x6f742e c_parser_omp_variable_list
../../gcc/c/c-parser.cc:13161
0x6f81dc c_parser_omp_clause_map
../../gcc/c/c-parser.cc:16260
0x700262 c_parser_omp_all_clauses
../../gcc/c/c-parser.cc:17057
0x70d6ae c_parser_omp_target_enter_data
../../gcc/c/c-parser.cc:20904
0x70d6ae c_parser_omp_target
../../gcc/c/c-parser.cc:21195
0x6e7a44 c_parser_pragma
../../gcc/c/c-parser.cc:12499
0x7054a6 c_parser_compound_statement_nostart
../../gcc/c/c-parser.cc:5767
0x705873 c_parser_compound_statement
../../gcc/c/c-parser.cc:5609
0x707128 c_parser_declaration_or_fndef
../../gcc/c/c-parser.cc:2544
0x70e85f c_parser_external_declaration
../../gcc/c/c-parser.cc:1779
0x70f18b c_parser_translation_unit
../../gcc/c/c-parser.cc:1652
0x70f18b c_parse_file()
../../gcc/c/c-parser.cc:23348
0x760792 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1238
[Bug c/104531] New: ICE in prepare_cmp_insn, at optabs.cc:4547
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104531
Bug ID: 104531
Summary: ICE in prepare_cmp_insn, at optabs.cc:4547
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20210905 and 20210919 :
$ cat z1.c
void f (_Complex int y, int x)
{
#pragma omp atomic compare update seq_cst
x = x > y ? y : x;
}
$ gcc-12-20220213 -c z1.c -fopenmp
during RTL pass: expand
z1.c: In function 'f':
z1.c:3:11: internal compiler error: in prepare_cmp_insn, at optabs.cc:4547
3 | #pragma omp atomic compare update seq_cst
| ^~~
0xafd677 prepare_cmp_insn
../../gcc/optabs.cc:4547
0xafd711 emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*,
machine_mode, int, rtx_def*, profile_probability)
../../gcc/optabs.cc:4692
0x839688 do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, profile_probability)
../../gcc/dojump.cc:1220
0x8df4a5 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/expr.cc:9745
0x7c4ea2 expand_gimple_stmt_1
../../gcc/cfgexpand.cc:3967
0x7c4ea2 expand_gimple_stmt
../../gcc/cfgexpand.cc:4028
0x7c9bd7 expand_gimple_basic_block
../../gcc/cfgexpand.cc:6069
0x7cc67e execute
../../gcc/cfgexpand.cc:6795
[Bug target/104529] [12 Regression] inefficient codegen around new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization --- Comment #4 from Andrew Pinski --- (In reply to Tamar Christina from comment #3) > I'm re-opening because I don't think it has anything to do with #94294 > > This is a GCC 12 regression. > > In GCC 11 we generated in the mid-end > ... > and in GCC 12 we now generate > ... > > See https://godbolt.org/z/KKfhxTxnd > > Forcing it to keep the stores before the call to new. Hmm, I should have looked into the code before marking it as a dup.
Re: [PATCH] reload: Adjust comment in find_reloads about subset, not intersection
Rather than assuming it's seen and thought not worth the
bother, I'll go with not-seen, so:
Jeff: ping. A little love for reload, comment-wise, before it's put down!
> From: Richard Sandiford
> CC: "gcc-patches@gcc.gnu.org" , "j...@tachyum.com"
>
> Date: Wed, 2 Feb 2022 16:16:14 +0100
> Old-Content-Type: multipart/alternative; boundary="_000_mpta6f9fge9fsfarmcom_"
> Content-Type: text/plain; charset=iso-8859-1
>
> Richard Sandiford writes:
> > Hans-Peter Nilsson writes:
> >>> From: Richard Sandiford
> >>> Hans-Peter Nilsson via Gcc-patches writes:
> >>> > The mystery isn't so much that there's code mismatching comments or
> >>> > intent, but that this code has been there "forever". There has been a
> >>> > function reg_classes_intersect_p, in gcc since r0-54, even *before*
> >>> > there was reload.c; r0-361, so why the "we don't have a way of forming
> >>> > the intersection" in the actual patch and why wasn't this fixed
> >>> > (perhaps not even noticed) when reload was state-of-the-art?
> >>>
> >>> But doesn't the comment
> >>
> >> (the second, patched comment; removed in the patch)
> >>
> >>> mean that we have/had no way of getting
> >>> a *class* that is the intersection of preferred_class[i] and
> >>> this_alternative[i], to store as the new
> >>> this_alternative[i]?
> >>
> >> Yes, that's likely what's going on in the (second) comment
> >> and code; needing a s/intersection/a class for the
> >> intersection/, but the *first* comment is pretty clear that
> >> the intent is exactly to "override" this_alternative[i]: "If
> >> not (a subclass), but it intersects that class, use the
> >> preferred class instead". But of course, that doesn't
> >> actually have to make sense as code! And indeed it doesn't,
> >> as you say.
> >>
> >>> If the alternatives were register sets rather than classes,
> >>> I think the intended effect would be:
> >>>
> >>> this_alternative[i] &= preferred_class[i];
> >>>
> >>> (i.e. AND_HARD_REG_SET in old money).
> >>>
> >>> It looks like the patch would instead make this_alternative[i] include
> >>> registers that the alternative doesn't actually accept, which feels odd.
> >>
> >> Perhaps I put too much trust in the sanity of old comments.
> >>
> >> How about I actually commit this one instead? Better get it
> >> right before reload is removed.
> >
> > :-) LGTM, but I'd like to hear Jeff's opinion.
>
> So it would be a good idea if I used the right email address.
Perhaps even better to use the address seen in mailing list
conversations, so I'm switching to that one.
>
> >
> > Thanks,
> > Richard
> >
> >> 8< --- >8
> >> "reload: Adjust comment in find_reloads about subset, not intersection"
> >> gcc:
> >>
> >>* reload.cc (find_reloads): Align comment with code where
> >>considering the intersection of register classes then tweaking the
> >>regclass for the current alternative or rejecting it.
> >> ---
> >> gcc/reload.cc | 15 +--
> >> 1 file changed, 9 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/gcc/reload.cc b/gcc/reload.cc
> >> index 664082a533d9..3ed901e39447 100644
> >> --- a/gcc/reload.cc
> >> +++ b/gcc/reload.cc
> >> @@ -3635,9 +3635,11 @@ find_reloads (rtx_insn *insn, int replace, int
> >> ind_levels, int live_known,
> >> a hard reg and this alternative accepts some
> >> register, see if the class that we want is a subset
> >> of the preferred class for this register. If not,
> >> - but it intersects that class, use the preferred class
> >> - instead. If it does not intersect the preferred
> >> - class, show that usage of this alternative should be
> >> + but it intersects that class, we'd like to use the
> >> + intersection, but the best we can do is to use the
> >> + preferred class, if it is instead a subset of the
> >> + class we want in this alternative. If we can't use
> >> + it, show that usage of this alternative should be
> >> discouraged; it will be discouraged more still if the
> >> register is `preferred or nothing'. We do this
> >> because it increases the chance of reusing our spill
> >> @@ -3664,9 +3666,10 @@ find_reloads (rtx_insn *insn, int replace, int
> >> ind_levels, int live_known,
> >> if (! reg_class_subset_p (this_alternative[i],
> >>preferred_class[i]))
> >>{
> >> -/* Since we don't have a way of forming the intersection,
> >> - we just do something special if the preferred class
> >> - is a subset of the class we have; that's the most
> >> +/* Since we don't have a way of forming a register
> >> + class for the intersection, we just do
> >> + something special if the preferred class is a
> >> + subset of the class we have; that's the most
[Bug target/104529] [12 Regression] inefficient codegen around new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529
Tamar Christina changed:
What|Removed |Added
Summary|[missed optimization] |[12 Regression] inefficient
|inefficient codegen around |codegen around new/delete
|new/delete |
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICATE |---
--- Comment #3 from Tamar Christina ---
I'm re-opening because I don't think it has anything to do with #94294
This is a GCC 12 regression.
In GCC 11 we generated in the mid-end
[local count: 536870913]:
_32 = operator new (6);
MEM [(char * {ref-all})_32] = 255;
MEM [(char * {ref-all})_32 + 4B] = 0;
operator delete (_32, 6);
return 56;
and in GCC 12 we now generate
[local count: 536870913]:
MEM [(unsigned char *)] = { 255, 0, 0, 0 };
MEM [(unsigned char *) + 4B] = { 0, 0 };
_34 = operator new (6);
MEM [(char * {ref-all})_34] = MEM
[(char * {ref-all})];
D.24688 ={v} {CLOBBER(eol)};
operator delete (_34, 6);
return 56;
See https://godbolt.org/z/KKfhxTxnd
Forcing it to keep the stores before the call to new.
Re: [PATCH] RISC-V: Add target machine headers as a dependency for riscv-sr.o
On Thu, 10 Feb 2022, Kito Cheng wrote: > OK for release branches, thanks! Backported to GCC 11 & 10 then; not needed for GCC 9. Maciej
Re: [PATCH] ipa: Create LOAD references when necessary during inlining (PR 103171)
Hello and ping, please. Thanks!
Martin
On Fri, Jan 28 2022, Martin Jambor wrote:
> Hi,
>
> in r12-2523-g13586172d0b70c ipa-prop tracking of jump functions during
> inlining got the ability to remove ADDR references when inlining
> discovered that they were not necessary or turn them into LOAD
> references when we know that what was a function call argument passed
> by reference will end up as a load (one or more).
>
> Unfortunately, the code only creates the LOAD references when
> replacing removed ADDR references and PR 103171 showed that with some
> ordering of inlining, we need to add the LOAD reference before we know
> we can remove the ADDR one - or the reference will be lost, leading to
> link errors or even ICEs.
>
> Specifically in testcase gcc.dg/lto/pr103171_1.c added in this patch,
> if foo() is inlined to entry(), we need to create the LOAD reference
> so that when later bar() is inlined into foo() and we discover that
> the paameter is unused, we can remove the ADDR reference and still
> keep the varaible around for the load.
>
> Bootstrapped, LTO bootstrapped and tested on x86_64-linux. OK for
> trunk?
>
> Thanks,
>
> Martin
>
>
>
> gcc/ChangeLog:
>
> 2022-01-28 Martin Jambor
>
> PR ipa/103171
> * ipa-prop.cc (propagate_controlled_uses): Add a LOAD reference
> always when an ADDR_EXPR constant is known to reach a load because
> of inlining, not just when removing an ADDR reference.
>
> gcc/testsuite/ChangeLog:
>
> 2022-01-28 Martin Jambor
>
> PR ipa/103171
> * gcc.dg/ipa/remref-6.c: Adjust dump scan string.
> * gcc.dg/ipa/remref-7.c: New test.
> * gcc.dg/lto/pr103171_0.c: New test.
> * gcc.dg/lto/pr103171_1.c: Likewise.
> ---
> gcc/ipa-prop.cc | 30 ---
> gcc/testsuite/gcc.dg/ipa/remref-6.c | 2 +-
> gcc/testsuite/gcc.dg/ipa/remref-7.c | 33 +
> gcc/testsuite/gcc.dg/lto/pr103171_0.c | 11 +
> gcc/testsuite/gcc.dg/lto/pr103171_1.c | 35 +++
> 5 files changed, 96 insertions(+), 15 deletions(-)
> create mode 100644 gcc/testsuite/gcc.dg/ipa/remref-7.c
> create mode 100644 gcc/testsuite/gcc.dg/lto/pr103171_0.c
> create mode 100644 gcc/testsuite/gcc.dg/lto/pr103171_1.c
>
> diff --git a/gcc/ipa-prop.cc b/gcc/ipa-prop.cc
> index e55fe2776f2..72aa3e2f60d 100644
> --- a/gcc/ipa-prop.cc
> +++ b/gcc/ipa-prop.cc
> @@ -4181,6 +4181,20 @@ propagate_controlled_uses (struct cgraph_edge *cs)
> int d = ipa_get_controlled_uses (old_root_info, i);
> int c = rdesc->refcount;
> rdesc->refcount = combine_controlled_uses_counters (c, d);
> + if (rdesc->refcount != IPA_UNDESCRIBED_USE
> + && ipa_get_param_load_dereferenced (old_root_info, i))
> + {
> + tree cst = ipa_get_jf_constant (jf);
> + gcc_checking_assert (TREE_CODE (cst) == ADDR_EXPR
> +&& (TREE_CODE (TREE_OPERAND (cst, 0))
> +== VAR_DECL));
> + symtab_node *n = symtab_node::get (TREE_OPERAND (cst, 0));
> + new_root->create_reference (n, IPA_REF_LOAD, NULL);
> + if (dump_file)
> + fprintf (dump_file, "ipa-prop: Address IPA constant will reach "
> + "a load so adding LOAD reference from %s to %s.\n",
> + new_root->dump_name (), n->dump_name ());
> + }
> if (rdesc->refcount == 0)
> {
> tree cst = ipa_get_jf_constant (jf);
> @@ -4193,20 +4207,8 @@ propagate_controlled_uses (struct cgraph_edge *cs)
> symtab_node *n = symtab_node::get (TREE_OPERAND (cst, 0));
> if (n)
> {
> - struct cgraph_node *clone;
> - bool removed = remove_described_reference (n, rdesc);
> - /* The reference might have been removed by IPA-CP. */
> - if (removed
> - && ipa_get_param_load_dereferenced (old_root_info, i))
> - {
> - new_root->create_reference (n, IPA_REF_LOAD, NULL);
> - if (dump_file)
> - fprintf (dump_file, "ipa-prop: ...replaced it with "
> - "LOAD one from %s to %s.\n",
> - new_root->dump_name (), n->dump_name ());
> - }
> -
> - clone = cs->caller;
> + remove_described_reference (n, rdesc);
> + cgraph_node *clone = cs->caller;
> while (clone->inlined_to
>&& clone->ipcp_clone
>&& clone != rdesc->cs->caller)
> diff --git a/gcc/testsuite/gcc.dg/ipa/remref-6.c
> b/gcc/testsuite/gcc.dg/ipa/remref-6.c
> index 7deae3114a4..f31f4c14319 100644
> --- a/gcc/testsuite/gcc.dg/ipa/remref-6.c
> +++ b/gcc/testsuite/gcc.dg/ipa/remref-6.c
> @@ -20,5 +20,5 @@ void entry()
> }
>
> /* { dg-final { scan-ipa-dump
[Bug target/104529] [missed optimization] inefficient codegen around new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529
--- Comment #2 from Tamar Christina ---
I don't quite see how this is a CSE problem,
There's only one of each constant and none of them are needed before the call.
unlike in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86892
You don't need the values of your array until you allocate memory for said
array.
x86 has the following sequence in GIMPLE
_32 = operator new (6);
MEM [(char * {ref-all})_32] = 255;
MEM [(char * {ref-all})_32 + 4B] = 0;
operator delete (_32, 6);
which is optimal, you create the object, store the values, and remove it.
AArch64 however has this
MEM [(unsigned char *)] = 255;
MEM [(unsigned char *) + 4B] = 0;
_34 = operator new (6);
MEM [(char * {ref-all})_34] = MEM
[(char * {ref-all})];
D.24688 ={v} {CLOBBER(eol)};
operator delete (_34, 6);
which is where the issue comes from. So this has nothing to do with CSE as far
as I can tell. The GIMPLE is just suboptimal.
[Bug ipa/103083] [10/11/12 Regression] Wrong code due to ipa-cp's bits value propagation since r10-5538-gc7ac9a0c7e3916f1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103083 --- Comment #5 from Martin Jambor --- I have changed the patch a bit and re-submitted for review: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590341.html
[Bug ipa/102513] [10/11/12 Regression] Many false positive warnings with recursive function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513 Martin Jambor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Component|tree-optimization |ipa --- Comment #9 from Martin Jambor --- The patch had to be tweaked a bit but I have proposed the following one on the mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590371.html
[PATCH] ipa-cp: Do not create clones for values outside known value range (PR 102513)
Hi,
PR 102513 shows we emit bogus array access warnings when IPA-CP
creates clones specialized for values which it deduces from arithmetic
jump functions describing self-recursive calls. Those can however be
avoided if we consult the IPA-VR information that the same pass also
has.
The patch below does that at the stage when normally values are only
examined for profitability. It would be better not to create lattices
describing such bogus values in the first place, however that presents
an ordering problem, the pass currently propagates all information,
and so both constants and VR, in no particular order when processing
SCCs, and so this approach seemed much simpler.
I plan to rearrange the pass so that it clones in multiple passes over
the call graph (or rather the lattice dependence graph) and it feels
natural to only do propagation for these kinds of recursion in the
second or later passes, which would fix the issue more elegantly.
Bootstrapped and tested on x86_64, OK for trunk (and perhaps also for
GCC 11)?
Thanks,
Martin
gcc/ChangeLog:
2022-02-14 Martin Jambor
PR ipa/102513
* ipa-cp.cc (decide_whether_version_node): Skip scalar values
which do not fit the known value_range.
gcc/testsuite/ChangeLog:
2022-02-14 Martin Jambor
PR ipa/102513
* gcc.dg/ipa/pr102513.c: New test.
---
gcc/ipa-cp.cc | 28 ++--
gcc/testsuite/gcc.dg/ipa/pr102513.c | 33 +
2 files changed, 59 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/ipa/pr102513.c
diff --git a/gcc/ipa-cp.cc b/gcc/ipa-cp.cc
index 453e9c93cc3..ec37632d487 100644
--- a/gcc/ipa-cp.cc
+++ b/gcc/ipa-cp.cc
@@ -6154,8 +6154,32 @@ decide_whether_version_node (struct cgraph_node *node)
{
ipcp_value *val;
for (val = lat->values; val; val = val->next)
- ret |= decide_about_value (node, i, -1, val, ,
- _gen_clones);
+ {
+ /* If some values generated for self-recursive calls with
+arithmetic jump functions fall outside of the known
+value_range for the parameter, we can skip them. VR interface
+supports this only for integers now. */
+ if (TREE_CODE (val->value) == INTEGER_CST
+ && !plats->m_value_range.bottom_p ()
+ && !plats->m_value_range.m_vr.contains_p (val->value))
+ {
+ /* This can happen also if a constant present in the source
+code falls outside of the range of parameter's type, so we
+cannot assert. */
+ if (dump_file && (dump_flags & TDF_DETAILS))
+ {
+ fprintf (dump_file, " - skipping%s value ",
+ val->self_recursion_generated_p ()
+ ? " self_recursion_generated" : "");
+ print_ipcp_constant_value (dump_file, val->value);
+ fprintf (dump_file, " because it is outside known "
+ "value range.\n");
+ }
+ continue;
+ }
+ ret |= decide_about_value (node, i, -1, val, ,
+_gen_clones);
+ }
}
if (!plats->aggs_bottom)
diff --git a/gcc/testsuite/gcc.dg/ipa/pr102513.c
b/gcc/testsuite/gcc.dg/ipa/pr102513.c
new file mode 100644
index 000..9ee5431b730
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/ipa/pr102513.c
@@ -0,0 +1,33 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -Warray-bounds" } */
+
+extern int block2[7][256];
+
+static int encode_block(int block2[7][256], unsigned level)
+{
+int best_score = 0;
+
+for (unsigned x = 0; x < level; x++) {
+int v = block2[1][x];
+block2[level][x] = 0;
+best_score += v * v;
+}
+
+if (level > 0 && best_score > 64) {
+int score = 0;
+
+score += encode_block(block2, level - 1);
+score += encode_block(block2, level - 1);
+
+if (score < best_score) {
+best_score = score;
+}
+}
+
+return best_score;
+}
+
+int foo(void)
+{
+return encode_block(block2, 5);
+}
--
2.34.1
[Bug rtl-optimization/104154] [12 Regression] Another ICE due to recent ifcvt changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154 --- Comment #8 from Jeffrey A. Law --- So the updated patch fixes the arc build regressions. I haven't looked at the thread with Segher, but I will as soon as I can. Mostly just wanted to let you know that the updated patch does indeed get the port building again.
[Bug c/104510] [9/10/11/12 Regression] ICE: 'verify_gimple' failed: mismatching comparison operand types in verify_gimple_in_seq()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104510 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 52439 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52439=edit gcc12-pr104510.patch Untested fix. Callers don't expect shorten_compare to ever fail, even when it returns NULL it still should convert arguments at least to the original *restype_ptr.
[Bug rtl-optimization/86892] RTL CSE commoning trivial constants across call and/or too early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86892 Andrew Pinski changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- *** Bug 104529 has been marked as a duplicate of this bug. ***
[Bug target/104529] [missed optimization] inefficient codegen around new/delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104529 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 86892. *** This bug has been marked as a duplicate of bug 86892 ***
[Bug c++/104008] [11/12 Regression] New g++ folly compile error with gcc 11.x. Bisected to PR99445 c++: Alias template in pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104008 Aleksei Latyshev changed: What|Removed |Added CC||alex_700_95 at mail dot ru --- Comment #6 from Aleksei Latyshev --- Let me add a simplified reproducer for this bug: https://godbolt.org/z/3ec1dW8YE
Re: Uninit warnings due to optimizing short-circuit conditionals
On Mon, 2022-02-14 at 12:20 -0500, David Malcolm wrote: > On Mon, 2022-02-14 at 17:57 +0100, Mark Wielaard wrote: > > On Mon, 2022-02-14 at 10:57 -0500, David Malcolm wrote: > > > [CCing Mark in the hopes of insight from the valgrind side of > > > things] > > > > Adding Julian to CC so he can correct me if I say something silly. > > > > > There is a false positive from -Wanalyzer-use-of-uninitialized- > > > value on > > > gcc.dg/analyzer/pr102692.c here: > > > > > > ‘fix_overlays_before’: events 1-3 > > > | > > > | 75 | while (tail > > > | | > > > | 76 | && (tem = make_lisp_ptr (tail, 5), > > > | | ^~ > > > | | | > > > | | (1) following ‘false’ branch (when ‘tail’ is > > > NULL)... > > > | 77 | (end = marker_position (XOVERLAY (tem)- > > > > end)) >= pos)) > > > > > > | | > > > ~ > > > |.. > > > | 82 | if (!tail || end < prev || !tail->next) > > > | | ~~~ > > > | | || > > > | | |(3) use of uninitialized value > > > ‘end’ here > > > | | (2) ...to here > > > | > > > > > > The issue is that inner || of the conditionals have been folded > > > within the > > > frontend from a chain of control flow: > > > > > >5 │ if (tail == 0B) goto ; else goto ; > > >6 │ : > > >7 │ if (end < prev) goto ; else goto ; > > >8 │ : > > >9 │ _1 = tail->next; > > > 10 │ if (_1 == 0B) goto ; else goto ; > > > 11 │ : > > > > > > to an OR expr (and then to a bitwise-or by the gimplifier): > > > > > >5 │ _1 = tail == 0B; > > >6 │ _2 = end < prev; > > >7 │ _3 = _1 | _2; > > >8 │ if (_3 != 0) goto ; else goto ; > > >9 │ : > > > 10 │ _4 = tail->next; > > > 11 │ if (_4 == 0B) goto ; else goto ; > > > > > > This happens for sufficiently simple conditionals in > > > fold_truth_andor. > > > In particular, the (end < prev) is short-circuited without > > > optimization, > > > but is evaluated with optimization, leading to the false positive. > > > > > > Given how early this folding occurs, it seems the simplest fix is > > > to > > > try to detect places where this optimization appears to have > > > happened, > > > and suppress uninit warnings within the statement that would have > > > been short-circuited (and thus e.g. ignoring them when evaluating > > > _2 > > > above for the case where _1 is known to be true at the (_1 | _2) , > > > and > > > thus _2 being redundant). > > > > > > Attached is a patch that implements this. > > > > > > There are some more details in the patch, but I'm wondering if this > > > is a > > > known problem, and how e.g. valgrind copes with such code. My > > > patch > > > feels like something of a hack, but I'm not sure of any other way > > > around > > > it given that the conditional is folded directly within the > > > frontend. > > > > As far as I know this is what valgrind memcheck also does with an > > bitwise or. It knows that _3 is defined and true if either _1 or _2 > > is > > defined and true. Or more generically that the result bits of a > > bitwise > > or are defined for those bits that are both defined or where one is > > defined and has the value 1. > > Aha - thanks. I think the distinction here is that: > > * GCC's -fanalyzer complains about uninitialized values immediately > when it sees one being fetched for use in any expression (replacing the > value with a safe one to avoid further complaints), without considering > how they are going to be used in the expression, whereas > > * it sounds like valgrind keeps track of uninitialized bits, propagates > the "uninit-ness" of the bits, and complains at certain times when > uninitialized bits are used in certain ways. Yes. valgrind keeps track of uninitialized bits and propagates them around till "use". Where use is anything that might alter the observable behavior of the program. Which is control flow transfers, conditional moves, addresses used in memory accesses, and data passed to system calls. This paper describes some of the memcheck tricks: https://valgrind.org/docs/memcheck2005.pdf Cheers, Mark
[Bug libstdc++/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #13 from Jonathan Wakely --- Fixed on trunk now. As this adds new symbol versions I don't plan to backport it to gcc-11. Trunk should be used for anybody who needs IEEE128 support.
[committed] libstdc++: Fix stream extraction of IEEE128 long double [PR100912]
Tested powerpc64le-linux with both IEEE/IBM ABIs. Pushed to trunk.
-- >8 --
The std::__convert_from_v helper that formats double and long double
values into a char buffer was not being duplicated for the two long
double ABIs. This resulted in an ODR violation inside the library, where
some callers needed it to use snprintf to format __ibm128 values and
other callers needed it to use __snprintfieee128 to format __ieee128
values. The linker discarded one of the definitions, leaving one set of
callers using the wrong code.
This puts __convert_from_v in the __gnu_cxx_ieee128 inline namespace
when long double is __ieee128, so that there are two different
definitions of the function.
The std::money_put::__do_put overload for __ibm128 values needs a
different fix, because that is defined when long double is __ieee128 and
so would call the one in the inline namespace. That can be fixed by just
inlining the code directly into the function and using an asm alias to
call the right version of snprintf for the __ibm128 format. The code to
do that can be simpler than __convert_from_v because if we're defining
the ALT128_COMPAT symbols we know that we have a recent glibc and so we
can assume that uselocale and snprintf are supported.
libstdc++-v3/ChangeLog:
PR libstdc++/100912
* config/locale/gnu/c_locale.h (__convert_from_v): Use inline
namespace for IEEE128 long double mode.
* config/os/gnu-linux/ldbl-ieee128-extra.ver: Add new symbol
version and export __gnu_cxx_ieee128::__convert_from_v.
* include/bits/locale_facets_nonio.tcc (money_put::__do_put):
Make __ibm128 overload use snprintf directly
* testsuite/util/testsuite_abi.cc: Add new symbol version.
Remove stable IEEE128/LDBL versions.
---
libstdc++-v3/config/locale/gnu/c_locale.h | 10
.../os/gnu-linux/ldbl-ieee128-extra.ver | 7 +-
.../include/bits/locale_facets_nonio.tcc | 23 ---
libstdc++-v3/testsuite/util/testsuite_abi.cc | 8 +++
4 files changed, 29 insertions(+), 19 deletions(-)
diff --git a/libstdc++-v3/config/locale/gnu/c_locale.h
b/libstdc++-v3/config/locale/gnu/c_locale.h
index 176e022b85c..526b62215e1 100644
--- a/libstdc++-v3/config/locale/gnu/c_locale.h
+++ b/libstdc++-v3/config/locale/gnu/c_locale.h
@@ -61,6 +61,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
typedef __locale_t __c_locale;
+#if defined _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT \
+ && defined __LONG_DOUBLE_IEEE128__
+namespace __gnu_cxx_ieee128 {
+#endif
+
// Convert numeric value of type double and long double to string and
// return length of string. If vsnprintf is available use it, otherwise
// fall back to the unsafe vsprintf which, in general, can be dangerous
@@ -108,6 +113,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
return __ret;
}
+#if defined _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT \
+ && defined __LONG_DOUBLE_IEEE128__
+} // namespace __gnu_cxx_ieee128
+#endif
+
_GLIBCXX_END_NAMESPACE_VERSION
} // namespace
diff --git a/libstdc++-v3/config/os/gnu-linux/ldbl-ieee128-extra.ver
b/libstdc++-v3/config/os/gnu-linux/ldbl-ieee128-extra.ver
index 9b421b6f1f9..830cb8c40f4 100644
--- a/libstdc++-v3/config/os/gnu-linux/ldbl-ieee128-extra.ver
+++ b/libstdc++-v3/config/os/gnu-linux/ldbl-ieee128-extra.ver
@@ -2,7 +2,8 @@
GLIBCXX_IEEE128_3.4.29 {
- *__gnu_cxx_ieee128*;
+ _Z*St17__gnu_cxx_ieee1287num_get*;
+ _Z*St17__gnu_cxx_ieee1287num_put*;
_ZNSt14numeric_limitsIu9__ieee128E*;
_ZNSirsERu9__ieee128;
@@ -45,6 +46,10 @@ GLIBCXX_IEEE128_3.4.29 {
} GLIBCXX_3.4.29;
+GLIBCXX_IEEE128_3.4.30 {
+ _ZNSt17__gnu_cxx_ieee12816__convert_from_vERKP15__locale_structPciPKcz;
+} GLIBCXX_3.4.30;
+
CXXABI_IEEE128_1.3.13 {
_ZT[IS]u9__ieee128;
diff --git a/libstdc++-v3/include/bits/locale_facets_nonio.tcc
b/libstdc++-v3/include/bits/locale_facets_nonio.tcc
index 64737823374..98442418f51 100644
--- a/libstdc++-v3/include/bits/locale_facets_nonio.tcc
+++ b/libstdc++-v3/include/bits/locale_facets_nonio.tcc
@@ -635,6 +635,9 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL_OR_CXX11
#if defined _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT \
&& defined __LONG_DOUBLE_IEEE128__
+extern "C"
+__typeof__(__builtin_snprintf) __glibcxx_snprintfibm128 __asm__("snprintf");
+
template
_OutIter
money_put<_CharT, _OutIter>::
@@ -643,30 +646,24 @@ _GLIBCXX_BEGIN_NAMESPACE_LDBL_OR_CXX11
{
const locale __loc = __io.getloc();
const ctype<_CharT>& __ctype = use_facet >(__loc);
-#if _GLIBCXX_USE_C99_STDIO
// First try a buffer perhaps big enough.
int __cs_size = 64;
char* __cs = static_cast(__builtin_alloca(__cs_size));
+ const __c_locale __old = __gnu_cxx::__uselocale(_S_get_c_locale());
+
// _GLIBCXX_RESOLVE_LIB_DEFECTS
// 328. Bad sprintf format modifier in money_put<>::do_put()
- int __len = std::__convert_from_v(_S_get_c_locale(), __cs, __cs_size,
-
Re: [PATCH] PR fortran/104211 - ICE in find_array_section, at fortran/expr.cc:1720
Hi Harald, when referencing a bad array section after an erroneous previous declaration we might hit an assert. The assert can be replaced by a more gracious error recovery. Reported by Gerhard. Regtested on x86_64-pc-linux-gnu. OK for mainline? OK. Thanks for the patch! Best regards Thomas
[Bug libstdc++/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912 --- Comment #12 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3d50dede07de0923f0f320d385162e546445e640 commit r12-7231-g3d50dede07de0923f0f320d385162e546445e640 Author: Jonathan Wakely Date: Mon Feb 14 16:46:55 2022 + libstdc++: Fix stream extraction of IEEE128 long double [PR100912] The std::__convert_from_v helper that formats double and long double values into a char buffer was not being duplicated for the two long double ABIs. This resulted in an ODR violation inside the library, where some callers needed it to use snprintf to format __ibm128 values and other callers needed it to use __snprintfieee128 to format __ieee128 values. The linker discarded one of the definitions, leaving one set of callers using the wrong code. This puts __convert_from_v in the __gnu_cxx_ieee128 inline namespace when long double is __ieee128, so that there are two different definitions of the function. The std::money_put::__do_put overload for __ibm128 values needs a different fix, because that is defined when long double is __ieee128 and so would call the one in the inline namespace. That can be fixed by just inlining the code directly into the function and using an asm alias to call the right version of snprintf for the __ibm128 format. The code to do that can be simpler than __convert_from_v because if we're defining the ALT128_COMPAT symbols we know that we have a recent glibc and so we can assume that uselocale and snprintf are supported. libstdc++-v3/ChangeLog: PR libstdc++/100912 * config/locale/gnu/c_locale.h (__convert_from_v): Use inline namespace for IEEE128 long double mode. * config/os/gnu-linux/ldbl-ieee128-extra.ver: Add new symbol version and export __gnu_cxx_ieee128::__convert_from_v. * include/bits/locale_facets_nonio.tcc (money_put::__do_put): Make __ibm128 overload use snprintf directly * testsuite/util/testsuite_abi.cc: Add new symbol version. Remove stable IEEE128/LDBL versions.
Re: Uninit warnings due to optimizing short-circuit conditionals
On Mon, 2022-02-14 at 17:57 +0100, Mark Wielaard wrote: > Hi David, > > On Mon, 2022-02-14 at 10:57 -0500, David Malcolm wrote: > > [CCing Mark in the hopes of insight from the valgrind side of > > things] > > Adding Julian to CC so he can correct me if I say something silly. > > > There is a false positive from -Wanalyzer-use-of-uninitialized- > > value on > > gcc.dg/analyzer/pr102692.c here: > > > > ‘fix_overlays_before’: events 1-3 > > | > > | 75 | while (tail > > | | > > | 76 | && (tem = make_lisp_ptr (tail, 5), > > | | ^~ > > | | | > > | | (1) following ‘false’ branch (when ‘tail’ is > > NULL)... > > | 77 | (end = marker_position (XOVERLAY (tem)- > > >end)) >= pos)) > > | | > > ~ > > |.. > > | 82 | if (!tail || end < prev || !tail->next) > > | | ~ ~~ > > | | | | > > | | | (3) use of uninitialized value > > ‘end’ here > > | | (2) ...to here > > | > > > > The issue is that inner || of the conditionals have been folded > > within the > > frontend from a chain of control flow: > > > > 5 │ if (tail == 0B) goto ; else goto ; > > 6 │ : > > 7 │ if (end < prev) goto ; else goto ; > > 8 │ : > > 9 │ _1 = tail->next; > > 10 │ if (_1 == 0B) goto ; else goto ; > > 11 │ : > > > > to an OR expr (and then to a bitwise-or by the gimplifier): > > > > 5 │ _1 = tail == 0B; > > 6 │ _2 = end < prev; > > 7 │ _3 = _1 | _2; > > 8 │ if (_3 != 0) goto ; else goto ; > > 9 │ : > > 10 │ _4 = tail->next; > > 11 │ if (_4 == 0B) goto ; else goto ; > > > > This happens for sufficiently simple conditionals in > > fold_truth_andor. > > In particular, the (end < prev) is short-circuited without > > optimization, > > but is evaluated with optimization, leading to the false positive. > > > > Given how early this folding occurs, it seems the simplest fix is > > to > > try to detect places where this optimization appears to have > > happened, > > and suppress uninit warnings within the statement that would have > > been short-circuited (and thus e.g. ignoring them when evaluating > > _2 > > above for the case where _1 is known to be true at the (_1 | _2) , > > and > > thus _2 being redundant). > > > > Attached is a patch that implements this. > > > > There are some more details in the patch, but I'm wondering if this > > is a > > known problem, and how e.g. valgrind copes with such code. My > > patch > > feels like something of a hack, but I'm not sure of any other way > > around > > it given that the conditional is folded directly within the > > frontend. > > As far as I know this is what valgrind memcheck also does with an > bitwise or. It knows that _3 is defined and true if either _1 or _2 > is > defined and true. Or more generically that the result bits of a > bitwise > or are defined for those bits that are both defined or where one is > defined and has the value 1. Aha - thanks. I think the distinction here is that: * GCC's -fanalyzer complains about uninitialized values immediately when it sees one being fetched for use in any expression (replacing the value with a safe one to avoid further complaints), without considering how they are going to be used in the expression, whereas * it sounds like valgrind keeps track of uninitialized bits, propagates the "uninit-ness" of the bits, and complains at certain times when uninitialized bits are used in certain ways. Dave
[OG11][committed] Fortran metadirective fixes
Hello I have backported and committed the recent two fixes for Fortran metadirective handling onto the devel/omp/gcc-11 development branch: 38ed9d83b893df0bbd098c7b44dbbeb56ed7dd1c openmp: Eliminate non-matching metadirective variants early in Fortran front-end (https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590349.html) 8cb0121af50eacb63098a79ff8c6deae05883c6f openmp: More Fortran front-end fixes for metadirectives (https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590350.html) Kwok
Re: Uninit warnings due to optimizing short-circuit conditionals
On Mon, 2022-02-14 at 09:26 -0700, Jeff Law wrote:
>
>
> On 2/14/2022 8:57 AM, David Malcolm via Gcc wrote:
> > [CCing Mark in the hopes of insight from the valgrind side of things]
> >
> > There is a false positive from -Wanalyzer-use-of-uninitialized-value
> > on
> > gcc.dg/analyzer/pr102692.c here:
> >
> > ‘fix_overlays_before’: events 1-3
> > |
> > | 75 | while (tail
> > | |
> > | 76 | && (tem = make_lisp_ptr (tail, 5),
> > | | ^~
> > | | |
> > | | (1) following ‘false’ branch (when ‘tail’ is
> > NULL)...
> > | 77 | (end = marker_position (XOVERLAY (tem)-
> > >end)) >= pos))
> > | |
> > ~
> > |..
> > | 82 | if (!tail || end < prev || !tail->next)
> > | | ~ ~~
> > | | | |
> > | | | (3) use of uninitialized value ‘end’
> > here
> > | | (2) ...to here
> > |
> >
> > The issue is that inner || of the conditionals have been folded
> > within the
> > frontend from a chain of control flow:
> >
> > 5 │ if (tail == 0B) goto ; else goto ;
> > 6 │ :
> > 7 │ if (end < prev) goto ; else goto ;
> > 8 │ :
> > 9 │ _1 = tail->next;
> > 10 │ if (_1 == 0B) goto ; else goto ;
> > 11 │ :
> >
> > to an OR expr (and then to a bitwise-or by the gimplifier):
> >
> > 5 │ _1 = tail == 0B;
> > 6 │ _2 = end < prev;
> > 7 │ _3 = _1 | _2;
> > 8 │ if (_3 != 0) goto ; else goto ;
> > 9 │ :
> > 10 │ _4 = tail->next;
> > 11 │ if (_4 == 0B) goto ; else goto ;
> >
> > This happens for sufficiently simple conditionals in
> > fold_truth_andor.
> > In particular, the (end < prev) is short-circuited without
> > optimization,
> > but is evaluated with optimization, leading to the false positive.
> >
> > Given how early this folding occurs, it seems the simplest fix is to
> > try to detect places where this optimization appears to have
> > happened,
> > and suppress uninit warnings within the statement that would have
> > been short-circuited (and thus e.g. ignoring them when evaluating _2
> > above for the case where _1 is known to be true at the (_1 | _2) ,
> > and
> > thus _2 being redundant).
> >
> > Attached is a patch that implements this.
> >
> > There are some more details in the patch, but I'm wondering if this
> > is a
> > known problem, and how e.g. valgrind copes with such code. My patch
> > feels like something of a hack, but I'm not sure of any other way
> > around
> > it given that the conditional is folded directly within the frontend.
> Presumably when "tail ==0", "end" is initialized somewhere?
I don't think it does, but it shouldn't be a problem in the code as
written, due to short-circuiting (as I understand things) - but the
short-circuiting is being removed by the optimizer.
"end" only gets initialized at line 71 of the source below, for the
case where the initial value of "tail" is non-NULL:
63 │ void
64 │ fix_overlays_before (struct buffer *bp, long prev, long pos)
65 │ {
66 │ struct Lisp_Overlay *tail = bp->overlays_before, *parent = 0,
*right_pair;
67 │ struct lisp *tem;
68 │ long end;
69 │ while (tail
70 │ && (tem = make_lisp_ptr (tail, 5),
71 │ (end = marker_position (XOVERLAY (tem)->end)) >= pos))
72 │ {
73 │ parent = tail;
74 │ tail = tail->next;
75 │ }
76 │ if (!tail || end < prev || !tail->next) /* { dg-bogus "use of
uninitialized value 'end'" "uninit" } */
77 │ /* { dg-bogus "dereference of NULL 'tail'" "null deref" { target
*-*-* } .-1 } */
78 │ return;
At -O2 we have this at pr102692.c.022t.ssa:
59 │:
60 │ tail_23 = bp_22(D)->overlays_before;
61 │ parent_24 = 0B;
62 │ goto ; [INV]
63 │
64 │:
65 │ parent_32 = tail_11;
66 │ tail_33 = tail_11->next;
67 │
68 │:
69 │ # tail_11 = PHI
70 │ # parent_13 = PHI
71 │ # end_15 = PHI
72 │ if (tail_11 != 0B)
73 │ goto ; [INV]
74 │ else
75 │ goto ; [INV]
76 │
77 │:
78 │ tem_27 = make_lisp_ptr (tail_11, 5);
79 │ _1 = XOVERLAY (tem_27);
80 │ _2 = _1->end;
81 │ end_30 = marker_position (_2);
82 │ if (end_30 >= pos_31(D))
83 │ goto ; [INV]
84 │ else
85 │ goto ; [INV]
86 │
87 │:
88 │ # end_16 = PHI
89 │ _3 = tail_11 == 0B;
90 │ _4 = end_16 < prev_34(D);
91 │ _5 = _3 | _4;
92 │ if (_5 != 0)
93 │ goto ; [INV]
94 │ else
95 │ goto ; [INV]
96 │
97 │:
98 │ _6 = tail_11->next;
99 │ if (_6 == 0B)
100 │ goto ; [INV]
[Bug libstdc++/100806] deadlock in std::counting_semaphore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100806 Thomas Rodgers changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Thomas Rodgers --- I believe this has been fully resolved.
[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 --- Comment #8 from qinzhao at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #7) > If we just want to avoid the warning in cases like that (there is nothing > wrong in the testcases themselves, the warning just warns about an > implementation detail that a normally uninitialized variable will be really > uninitialized even despite the -ftrivial-auto-var-init= option), then > maybe_warn_switch_unreachable > already has: > if (gimple_code (stmt) == GIMPLE_GOTO > && TREE_CODE (gimple_goto_dest (stmt)) == LABEL_DECL > && DECL_ARTIFICIAL (gimple_goto_dest (stmt))) > /* Don't warn for compiler-generated gotos. These occur >in Duff's devices, for example. */; > and so for flag_auto_var_init > AUTO_INIT_UNINITIALIZED perhaps we could also > avoid warnings on: > 1) call to .DEFERRED_INIT > 2) call to __builtin_clear_padding if the second argument is present and > non-zero > 3) I guess we would need not to warn on a gimple assign store right after > the .DEFERRED_INIT call that has the lhs of .DEFERRED_INIT as rhs > anything else? Yes, I think the above 3 should include all the cases.
Re: [pushed] LRA, rs6000, Darwin: Amend lo_sum use for forced constants [PR104117].
On 2022-02-14 11:00, Richard Sandiford wrote:
Hi Vlad,
Vladimir Makarov via Gcc-patches writes:
Hi, Richard. Change LRA is mine and I approved it for Iain's patch.
I think there is no need for this code and it is misleading. If
'mem[low_sum]' does not work, I don't think that 'reg=low_sum;mem[reg]'
will help for any existing target. As machine-dependent code for any
target most probably (for ppc64 darwin it is exactly the case) checks
address only in memory, it can wrongly accept wrong address by reloading
it into reg and use it in memory. So these are my arguments for the
remove this code from process_address_1.
I'm probably making too much of this, but:
I think the code is potentially useful in that existing targets do forbid
forbid lo_sum addresses in certain contexts (due to limited offset range)
while still wanting lo_sum to be used to be load the address. If we
handle the high/lo_sum split in generic code then we have more chance
of being able to optimise things. So it feels like this is setting an
unfortunate precedent.
I still don't understand what went wrong before though (the PR trail
was a bit too long to process :-)). Is there a case where
(lo_sum (high X) X) != X? If so, that seems like a target bug to me.
Or does the target accept (set R1 (lo_sum R2 X)) for an X that cannot
be split into a HIGH/LO_SUM pair? I'd argue that's a target bug too.
Sometimes it is hard to make a line where an RA bug is a bug in
machine-dependent code or in RA itself.
For this case I would say it is a bug in the both parts.
Low-sum is generated by LRA and it does not know that it should be
wrapped by unspec for darwin. Generally speaking we could avoid the
change in LRA but it would require to do non-trivial analysis in machine
dependent code to find cases when 'reg=low_sum ... mem[reg]' is
incorrect code for darwin (PIC) target (and may be some other PIC
targets too). Therefore I believe the change in LRA is a good solution
even if the change can potentially result in less optimized code for
some cases. Taking your concern into account we could probably improve
the patch by introducing a hook (I never liked such solutions as we
already have too many hooks directing RA) or better to make the LRA
change working only for PIC target. Something like this (it probably
needs better recognition of pic target):
--- a/gcc/lra-constraints.cc
+++ b/gcc/lra-constraints.cc
@@ -3616,21 +3616,21 @@ process_address_1 (int nop, bool check_only_p,
if (HAVE_lo_sum)
{
/* addr => lo_sum (new_base, addr), case (2) above. */
insn = emit_insn (gen_rtx_SET
(new_reg,
gen_rtx_HIGH (Pmode, copy_rtx (addr;
code = recog_memoized (insn);
if (code >= 0)
{
*ad.inner = gen_rtx_LO_SUM (Pmode, new_reg, addr);
- if (!valid_address_p (op, , cn))
+ if (!valid_address_p (op, , cn) && !flag_pic)
{
/* Try to put lo_sum into register. */
insn = emit_insn (gen_rtx_SET
(new_reg,
gen_rtx_LO_SUM (Pmode,
new_reg, addr)));
code = recog_memoized (insn);
if (code >= 0)
{
*ad.inner = new_reg;
if (!valid_address_p (op, , cn))
[Bug c++/104507] [10/11/12 Regression] internal compiler error: unexpected expression ‘(int)(__ret)’ of kind cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104507
Patrick Palka changed:
What|Removed |Added
Ever confirmed|0 |1
Summary|[10/11 Regression] internal |[10/11/12 Regression]
|compiler error: unexpected |internal compiler error:
|expression ‘(int)(__ret)’ |unexpected expression
|of kind cast_expr |‘(int)(__ret)’ of kind
||cast_expr
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-02-14
Known to fail||12.0
--- Comment #6 from Patrick Palka ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Daniel Nelson from comment #2)
> > Had a few moments to do some testing/bisecting, and found the commit that
> > fixed this in mainline.
>
> I kinda of see how that might help here but not really. I wonder if there is
> another testcase which might shows the issue on the trunk still.
trunk crashes on this version:
#define ERR_MAX -20
#define s_errmsg(r) \
_k_errmsg[(((int)r) <= 0 && r) ? -(r) : -ERR_MAX]
extern const char *_k_errmsg[];
template
inline int DoFoo() {
int __ret = 0;
const char *n = s_errmsg(__ret);
return __ret;
}
Re: Uninit warnings due to optimizing short-circuit conditionals
Hi David, On Mon, 2022-02-14 at 10:57 -0500, David Malcolm wrote: > [CCing Mark in the hopes of insight from the valgrind side of things] Adding Julian to CC so he can correct me if I say something silly. > There is a false positive from -Wanalyzer-use-of-uninitialized-value on > gcc.dg/analyzer/pr102692.c here: > > ‘fix_overlays_before’: events 1-3 > | > | 75 | while (tail > | | > | 76 | && (tem = make_lisp_ptr (tail, 5), > | | ^~ > | | | > | | (1) following ‘false’ branch (when ‘tail’ is NULL)... > | 77 | (end = marker_position (XOVERLAY (tem)->end)) >= > pos)) > | | > ~ > |.. > | 82 | if (!tail || end < prev || !tail->next) > | | ~~~ > | | || > | | |(3) use of uninitialized value ‘end’ here > | | (2) ...to here > | > > The issue is that inner || of the conditionals have been folded within the > frontend from a chain of control flow: > >5 │ if (tail == 0B) goto ; else goto ; >6 │ : >7 │ if (end < prev) goto ; else goto ; >8 │ : >9 │ _1 = tail->next; > 10 │ if (_1 == 0B) goto ; else goto ; > 11 │ : > > to an OR expr (and then to a bitwise-or by the gimplifier): > >5 │ _1 = tail == 0B; >6 │ _2 = end < prev; >7 │ _3 = _1 | _2; >8 │ if (_3 != 0) goto ; else goto ; >9 │ : > 10 │ _4 = tail->next; > 11 │ if (_4 == 0B) goto ; else goto ; > > This happens for sufficiently simple conditionals in fold_truth_andor. > In particular, the (end < prev) is short-circuited without optimization, > but is evaluated with optimization, leading to the false positive. > > Given how early this folding occurs, it seems the simplest fix is to > try to detect places where this optimization appears to have happened, > and suppress uninit warnings within the statement that would have > been short-circuited (and thus e.g. ignoring them when evaluating _2 > above for the case where _1 is known to be true at the (_1 | _2) , and > thus _2 being redundant). > > Attached is a patch that implements this. > > There are some more details in the patch, but I'm wondering if this is a > known problem, and how e.g. valgrind copes with such code. My patch > feels like something of a hack, but I'm not sure of any other way around > it given that the conditional is folded directly within the frontend. As far as I know this is what valgrind memcheck also does with an bitwise or. It knows that _3 is defined and true if either _1 or _2 is defined and true. Or more generically that the result bits of a bitwise or are defined for those bits that are both defined or where one is defined and has the value 1. Cheers, Mark
[Bug tree-optimization/104530] [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104530 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |12.0 CC||jakub at gcc dot gnu.org Priority|P3 |P1 --- Comment #1 from Jakub Jelinek --- Started with r12-7128-gc6bb1db76b3ac127aff7dacf391fc1798a94bb7d The comparison is done before dereferencing pointer, but unlike the PR104288 case there is no call that could fail to return in between. I think PR104288 has been fixed on the 11 branch too, so the question is if this still works there.
[Bug tree-optimization/104530] New: [12 Regression] Dead Code Elimination Regression at -O3 (trunk vs. 11.2.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104530
Bug ID: 104530
Summary: [12 Regression] Dead Code Elimination Regression at
-O3 (trunk vs. 11.2.0)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
Dead Code Elimination Regression at -O3 (trunk vs.
a7fede6704dd207fb32b97bc30f945acc7b953c5) 138751
---
cat case.c #138751
void foo(void);
static int a, *b = , c, d = 1;
int main() {
c = 0 == b;
a = *b;
if (c % d)
for (; d; --d)
foo();
b = 0;
}
gcc-58aeb75d4097010ad9bb72b964265b18ab284f93 (trunk) -O3 can not eliminate foo
but gcc-11.2.0 -O3 can.
gcc-58aeb75d4097010ad9bb72b964265b18ab284f93 (trunk) -O3 -S -o /dev/stdout
case.c
- OUTPUT -
main:
.LFB0:
.cfi_startproc
movqb(%rip), %rax
testq %rax, %rax
movl(%rax), %edx
sete%al
movzbl %al, %eax
movl%edx, a(%rip)
cltd
idivl d(%rip)
testl %edx, %edx
je .L9
pushq %rax
.cfi_def_cfa_offset 16
.p2align 4,,10
.p2align 3
.L3:
callfoo
subl$1, d(%rip)
jne .L3
xorl%ecx, %ecx
xorl%eax, %eax
movq%rcx, b(%rip)
popq%rsi
.cfi_def_cfa_offset 8
ret
.L9:
xorl%edx, %edx
xorl%eax, %eax
movq%rdx, b(%rip)
ret
-- END OUTPUT -
gcc-11.2.0 -O3 -S -o /dev/stdout case.c
- OUTPUT -
main:
.LFB0:
.cfi_startproc
movqb(%rip), %rax
movq$0, b(%rip)
movl(%rax), %eax
movl%eax, a(%rip)
xorl%eax, %eax
ret
-- END OUTPUT -
Bisects to:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c6bb1db76b3ac127aff7dacf391fc1798a94bb7d
- Build information -
- 58aeb75d4097010ad9bb72b964265b18ab284f93 (trunk)
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/compiler_cache/gcc-58aeb75d4097010ad9bb72b964265b18ab284f93
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.1 20220213 (experimental) (GCC)
- releases/gcc-11.2.0
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 (GCC)
Re: [PATCH] c++: return-type-req in constraint using only outer tparms [PR104527]
On Mon, 14 Feb 2022, Patrick Palka wrote:
> Here the template context for the atomic constraint has two levels of
> template arguments, but since it depends only on the innermost argument
> T we use a single-level argument vector during substitution into the
> constraint (built by get_mapped_args). We eventually pass this vector
> to do_auto_deduction as part of checking the return-type-requirement
> inside the atom, but do_auto_deduction expects outer_targs to be a full
> set of arguments for sake of satisfaction.
>
> do_auto_deduction has a workaround in place to compensate for callers
> that pass only the innermost arguments as outer_targs, but here we're
> passing the _outermost_ arguments. Since the former situation should
> now (after r12-7101) only occur with adc_unify callers and the latter
Whoops, this should be r12-6919 (after which we pass outer_targs
appropriately during adc_variable_type deduction of non-function-scope
variables), not r12-7101, sorry about that.
> only with adc_requirement callers, this patch conditions the existing
> workaround according to the auto_deduction_context: if the context is
> adc_requirement, we add dummy innermost levels, otherwise we add dummy
> outermost levels as before and also assert that the context is adc_unify.
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu and tested on cmcstl2
> and range-v3, does this look OK for trunk?
>
> PR c++/104527
>
> gcc/cp/ChangeLog:
>
> * pt.cc (do_auto_deduction): When template argument levels are
> missing from outer_targs, fill in the innermost rather than the
> outermost levels with dummy args if the context is
> adc_requirement, otherwise also assert that the context is
> adc_unify.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/cpp2a/concepts-return-req4.C: New test.
> ---
> gcc/cp/pt.cc | 28 +--
> .../g++.dg/cpp2a/concepts-return-req4.C | 24
> 2 files changed, 44 insertions(+), 8 deletions(-)
> create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-return-req4.C
>
> diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
> index 1b18e2a7787..4ff2710b8ba 100644
> --- a/gcc/cp/pt.cc
> +++ b/gcc/cp/pt.cc
> @@ -30215,20 +30215,32 @@ do_auto_deduction (tree type, tree init, tree
> auto_node,
>
>tree full_targs = add_to_template_args (outer_targs, targs);
>
> - /* HACK: Compensate for callers not always communicating all levels of
> - outer template arguments by filling in the outermost missing levels
> - with dummy levels before checking satisfaction. We'll still crash
> - if the constraint depends on a template argument belonging to one of
> - these missing levels, but this hack otherwise allows us to handle a
> - large subset of possible constraints (including all non-dependent
> - constraints). */
>if (int missing_levels = (TEMPLATE_TYPE_ORIG_LEVEL (auto_node)
> - TMPL_ARGS_DEPTH (full_targs)))
> {
> tree dummy_levels = make_tree_vec (missing_levels);
> for (int i = 0; i < missing_levels; ++i)
> TREE_VEC_ELT (dummy_levels, i) = make_tree_vec (0);
> - full_targs = add_to_template_args (dummy_levels, full_targs);
> + if (context == adc_requirement)
> + /* We're checking a requires-expr's return-type-requirement that's
> +part of an atomic constraint that doesn't depend on any innermost
> +template arguments, so OUTER_TARGS (built by get_mapped_args) is
> +missing at least one innermost level. Fill in the innermost
> +levels of OUTER_TARGS with dummy levels. */
> + full_targs = add_to_template_args
> + (add_to_template_args (outer_targs, dummy_levels), targs);
> + else
> + {
> + /* Otherwise, fill in the _outermost_ levels with dummy levels.
> + This compensates for adc_unify callers that only pass the
> + innermost level of template arguments as OUTER_TARGS. We'll
> + still crash if the constraint depends on a template argument
> + belonging to one of these missing levels, but this hack
> + otherwise allows us to handle a large subset of possible
> + constraints (including all non-dependent constraints). */
> + gcc_checking_assert (context == adc_unify);
> + full_targs = add_to_template_args (dummy_levels, full_targs);
> + }
> }
>
>if (!constraints_satisfied_p (auto_node, full_targs))
> diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-return-req4.C
> b/gcc/testsuite/g++.dg/cpp2a/concepts-return-req4.C
> new file mode 100644
> index 000..471946bc8eb
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/cpp2a/concepts-return-req4.C
> @@ -0,0 +1,24 @@
> +// PR c++/104527
> +// { dg-do compile { target c++20 } }
> +
> +template
> +concept is_same = __is_same(T,
Re: [pushed] LRA, rs6000, Darwin: Amend lo_sum use for forced constants [PR104117].
Iain Sandoe writes:
> Hi Richard,
>
> (hopefully, my take won’t cloud the issue ….)
>
>> On 14 Feb 2022, at 16:00, Richard Sandiford via Gcc-patches
>> wrote:
>>
>> Hi Vlad,
>>
>> Vladimir Makarov via Gcc-patches writes:
>>> On 2022-02-14 04:44, Richard Sandiford via Gcc-patches wrote:
Iain Sandoe via Gcc-patches writes:
> Two issues resulted in this PR, which manifests when we force a constant
> into
> memory in LRA (in PIC code on Darwin). The presence of such forced
> constants
> is quite dependent on other RTL optimisations, and it is easy for the
> issue to
> become latent for a specific case.
>
> First, in the Darwin-specific rs6000 backend code, we were not being
> careful
> enough in rejecting invalid symbolic addresses. Specifically, when
> generating
> PIC code, we require a SYMBOL_REF to be wrapped in an
> UNSPEC_MACHOPIC_OFFSET.
>
> Second, LRA was attempting to load a register using an invalid lo_sum
> address.
>
> The LRA changes are approved in the PR by Vladimir, and the RS6000
> changes are
> Darwin-specific (although, of course, any observations are welcome).
>
> Tested on several lo_sum targets and x86_64 all languages except as noted:
> powerpc64-linux (m32/m64) -D
> powerpc64le-linux -D
> powerpc64-aix -Ada -Go -D
> aarch64-linux -Ada -D
> x86_64-linux all langs -D
> powerpc-darwin9 (master and 11.2) -D -Go.
>
> pushed to master, thanks,
> Iain
>
> Signed-off-by: Iain Sandoe
> Co-authored-by: Vladimir Makarov
>
> PR target/104117
>
> gcc/ChangeLog:
>
> * config/rs6000/rs6000.cc (darwin_rs6000_legitimate_lo_sum_const_p):
> Check for UNSPEC_MACHOPIC_OFFSET wrappers on symbolic addresses when
> emitting PIC code.
> (legitimate_lo_sum_address_p): Likewise.
> * lra-constraints.cc (process_address_1): Do not attempt to emit a reg
> load from an invalid lo_sum address.
> ---
> gcc/config/rs6000/rs6000.cc | 38 +++--
> gcc/lra-constraints.cc | 17 ++---
> 2 files changed, 38 insertions(+), 17 deletions(-)
>
> […]
> diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc
> index fdff9e0720a..c700c3f4578 100644
> --- a/gcc/lra-constraints.cc
> +++ b/gcc/lra-constraints.cc
> @@ -3625,21 +3625,8 @@ process_address_1 (int nop, bool check_only_p,
> *ad.inner = gen_rtx_LO_SUM (Pmode, new_reg, addr);
> if (!valid_address_p (op, , cn))
> {
> - /* Try to put lo_sum into register. */
> - insn = emit_insn (gen_rtx_SET
> - (new_reg,
> - gen_rtx_LO_SUM (Pmode, new_reg,
> addr)));
> - code = recog_memoized (insn);
> - if (code >= 0)
> - {
> - *ad.inner = new_reg;
> - if (!valid_address_p (op, , cn))
> - {
> - *ad.inner = addr;
> - code = -1;
> - }
> - }
> -
> + *ad.inner = addr; /* Punt. */
> + code = -1;
> }
> }
> if (code < 0)
Could you go into more details about this? Why is it OK to continue
to try:
(lo_sum new_reg addr)
directly as an address (the context at the top of the hunk), but not try
moving the lo_sum into a register? They should be semantically equivalent,
so it seems that if one is wrong, the other would be too.
>>> Hi, Richard. Change LRA is mine and I approved it for Iain's patch.
>>>
>>> I think there is no need for this code and it is misleading. If
>>> 'mem[low_sum]' does not work, I don't think that 'reg=low_sum;mem[reg]'
>>> will help for any existing target. As machine-dependent code for any
>>> target most probably (for ppc64 darwin it is exactly the case) checks
>>> address only in memory, it can wrongly accept wrong address by reloading
>>> it into reg and use it in memory. So these are my arguments for the
>>> remove this code from process_address_1.
>>
>> I'm probably making too much of this, but:
>>
>> I think the code is potentially useful in that existing targets do forbid
>> forbid lo_sum addresses in certain contexts (due to limited offset range)
>> while still wanting lo_sum to be used to be load the address. If we
>> handle the high/lo_sum split in generic code then we have more chance
>> of being able to optimise things. So it feels like this is setting an
>> unfortunate precedent.
>>
>> I still don't understand what went wrong before though (the PR trail
>> was a bit too long to process :-)). Is there a case where
>>
[Bug c/104510] [9/10/11/12 Regression] ICE: 'verify_gimple' failed: mismatching comparison operand types in verify_gimple_in_seq()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104510 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Started with r5-4736-g1e51d0a29dbfebe6c0df58739562644c1a50f3c3
[PATCH] c++: return-type-req in constraint using only outer tparms [PR104527]
Here the template context for the atomic constraint has two levels of
template arguments, but since it depends only on the innermost argument
T we use a single-level argument vector during substitution into the
constraint (built by get_mapped_args). We eventually pass this vector
to do_auto_deduction as part of checking the return-type-requirement
inside the atom, but do_auto_deduction expects outer_targs to be a full
set of arguments for sake of satisfaction.
do_auto_deduction has a workaround in place to compensate for callers
that pass only the innermost arguments as outer_targs, but here we're
passing the _outermost_ arguments. Since the former situation should
now (after r12-7101) only occur with adc_unify callers and the latter
only with adc_requirement callers, this patch conditions the existing
workaround according to the auto_deduction_context: if the context is
adc_requirement, we add dummy innermost levels, otherwise we add dummy
outermost levels as before and also assert that the context is adc_unify.
Bootstrapped and regtested on x86_64-pc-linux-gnu and tested on cmcstl2
and range-v3, does this look OK for trunk?
PR c++/104527
gcc/cp/ChangeLog:
* pt.cc (do_auto_deduction): When template argument levels are
missing from outer_targs, fill in the innermost rather than the
outermost levels with dummy args if the context is
adc_requirement, otherwise also assert that the context is
adc_unify.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-return-req4.C: New test.
---
gcc/cp/pt.cc | 28 +--
.../g++.dg/cpp2a/concepts-return-req4.C | 24
2 files changed, 44 insertions(+), 8 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-return-req4.C
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index 1b18e2a7787..4ff2710b8ba 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -30215,20 +30215,32 @@ do_auto_deduction (tree type, tree init, tree
auto_node,
tree full_targs = add_to_template_args (outer_targs, targs);
- /* HACK: Compensate for callers not always communicating all levels of
-outer template arguments by filling in the outermost missing levels
-with dummy levels before checking satisfaction. We'll still crash
-if the constraint depends on a template argument belonging to one of
-these missing levels, but this hack otherwise allows us to handle a
-large subset of possible constraints (including all non-dependent
-constraints). */
if (int missing_levels = (TEMPLATE_TYPE_ORIG_LEVEL (auto_node)
- TMPL_ARGS_DEPTH (full_targs)))
{
tree dummy_levels = make_tree_vec (missing_levels);
for (int i = 0; i < missing_levels; ++i)
TREE_VEC_ELT (dummy_levels, i) = make_tree_vec (0);
- full_targs = add_to_template_args (dummy_levels, full_targs);
+ if (context == adc_requirement)
+ /* We're checking a requires-expr's return-type-requirement that's
+ part of an atomic constraint that doesn't depend on any innermost
+ template arguments, so OUTER_TARGS (built by get_mapped_args) is
+ missing at least one innermost level. Fill in the innermost
+ levels of OUTER_TARGS with dummy levels. */
+ full_targs = add_to_template_args
+ (add_to_template_args (outer_targs, dummy_levels), targs);
+ else
+ {
+ /* Otherwise, fill in the _outermost_ levels with dummy levels.
+This compensates for adc_unify callers that only pass the
+innermost level of template arguments as OUTER_TARGS. We'll
+still crash if the constraint depends on a template argument
+belonging to one of these missing levels, but this hack
+otherwise allows us to handle a large subset of possible
+constraints (including all non-dependent constraints). */
+ gcc_checking_assert (context == adc_unify);
+ full_targs = add_to_template_args (dummy_levels, full_targs);
+ }
}
if (!constraints_satisfied_p (auto_node, full_targs))
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-return-req4.C
b/gcc/testsuite/g++.dg/cpp2a/concepts-return-req4.C
new file mode 100644
index 000..471946bc8eb
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-return-req4.C
@@ -0,0 +1,24 @@
+// PR c++/104527
+// { dg-do compile { target c++20 } }
+
+template
+concept is_same = __is_same(T, U);
+
+template
+struct A {
+ template
+requires requires { { 0 } -> is_same; }
+ struct B {};
+
+ template
+requires requires { { 1 } -> is_same; }
+ static void f();
+};
+
+A::B<> a1;
+A::B<> a2; // { dg-error "constraint" }
+
+int main() {
+ A::f();
+ A::f(); // { dg-error "no match" }
+}
--
2.35.1.102.g2b9c120970
Re: Uninit warnings due to optimizing short-circuit conditionals
On 2/14/2022 8:57 AM, David Malcolm via Gcc wrote: [CCing Mark in the hopes of insight from the valgrind side of things] There is a false positive from -Wanalyzer-use-of-uninitialized-value on gcc.dg/analyzer/pr102692.c here: ‘fix_overlays_before’: events 1-3 | | 75 | while (tail | | | 76 | && (tem = make_lisp_ptr (tail, 5), | | ^~ | | | | | (1) following ‘false’ branch (when ‘tail’ is NULL)... | 77 | (end = marker_position (XOVERLAY (tem)->end)) >= pos)) | | ~ |.. | 82 | if (!tail || end < prev || !tail->next) | | ~~~ | | || | | |(3) use of uninitialized value ‘end’ here | | (2) ...to here | The issue is that inner || of the conditionals have been folded within the frontend from a chain of control flow: 5 │ if (tail == 0B) goto ; else goto ; 6 │ : 7 │ if (end < prev) goto ; else goto ; 8 │ : 9 │ _1 = tail->next; 10 │ if (_1 == 0B) goto ; else goto ; 11 │ : to an OR expr (and then to a bitwise-or by the gimplifier): 5 │ _1 = tail == 0B; 6 │ _2 = end < prev; 7 │ _3 = _1 | _2; 8 │ if (_3 != 0) goto ; else goto ; 9 │ : 10 │ _4 = tail->next; 11 │ if (_4 == 0B) goto ; else goto ; This happens for sufficiently simple conditionals in fold_truth_andor. In particular, the (end < prev) is short-circuited without optimization, but is evaluated with optimization, leading to the false positive. Given how early this folding occurs, it seems the simplest fix is to try to detect places where this optimization appears to have happened, and suppress uninit warnings within the statement that would have been short-circuited (and thus e.g. ignoring them when evaluating _2 above for the case where _1 is known to be true at the (_1 | _2) , and thus _2 being redundant). Attached is a patch that implements this. There are some more details in the patch, but I'm wondering if this is a known problem, and how e.g. valgrind copes with such code. My patch feels like something of a hack, but I'm not sure of any other way around it given that the conditional is folded directly within the frontend. Presumably when "tail ==0", "end" is initialized somewhere? If so, yes, this is a known issue. There's a BZ about it somewhere (I don' t have the # handy, but it's probably on the Wuninitialized tracker). Jeff
[Bug c++/104527] [11/12 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104527 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED
Re: [pushed] LRA, rs6000, Darwin: Amend lo_sum use for forced constants [PR104117].
Hi Richard,
(hopefully, my take won’t cloud the issue ….)
> On 14 Feb 2022, at 16:00, Richard Sandiford via Gcc-patches
> wrote:
>
> Hi Vlad,
>
> Vladimir Makarov via Gcc-patches writes:
>> On 2022-02-14 04:44, Richard Sandiford via Gcc-patches wrote:
>>> Iain Sandoe via Gcc-patches writes:
Two issues resulted in this PR, which manifests when we force a constant
into
memory in LRA (in PIC code on Darwin). The presence of such forced
constants
is quite dependent on other RTL optimisations, and it is easy for the
issue to
become latent for a specific case.
First, in the Darwin-specific rs6000 backend code, we were not being
careful
enough in rejecting invalid symbolic addresses. Specifically, when
generating
PIC code, we require a SYMBOL_REF to be wrapped in an
UNSPEC_MACHOPIC_OFFSET.
Second, LRA was attempting to load a register using an invalid lo_sum
address.
The LRA changes are approved in the PR by Vladimir, and the RS6000 changes
are
Darwin-specific (although, of course, any observations are welcome).
Tested on several lo_sum targets and x86_64 all languages except as noted:
powerpc64-linux (m32/m64) -D
powerpc64le-linux -D
powerpc64-aix -Ada -Go -D
aarch64-linux -Ada -D
x86_64-linux all langs -D
powerpc-darwin9 (master and 11.2) -D -Go.
pushed to master, thanks,
Iain
Signed-off-by: Iain Sandoe
Co-authored-by: Vladimir Makarov
PR target/104117
gcc/ChangeLog:
* config/rs6000/rs6000.cc (darwin_rs6000_legitimate_lo_sum_const_p):
Check for UNSPEC_MACHOPIC_OFFSET wrappers on symbolic addresses when
emitting PIC code.
(legitimate_lo_sum_address_p): Likewise.
* lra-constraints.cc (process_address_1): Do not attempt to emit a reg
load from an invalid lo_sum address.
---
gcc/config/rs6000/rs6000.cc | 38 +++--
gcc/lra-constraints.cc | 17 ++---
2 files changed, 38 insertions(+), 17 deletions(-)
[…]
diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc
index fdff9e0720a..c700c3f4578 100644
--- a/gcc/lra-constraints.cc
+++ b/gcc/lra-constraints.cc
@@ -3625,21 +3625,8 @@ process_address_1 (int nop, bool check_only_p,
*ad.inner = gen_rtx_LO_SUM (Pmode, new_reg, addr);
if (!valid_address_p (op, , cn))
{
-/* Try to put lo_sum into register. */
-insn = emit_insn (gen_rtx_SET
- (new_reg,
- gen_rtx_LO_SUM (Pmode, new_reg,
addr)));
-code = recog_memoized (insn);
-if (code >= 0)
- {
-*ad.inner = new_reg;
-if (!valid_address_p (op, , cn))
- {
-*ad.inner = addr;
-code = -1;
- }
- }
-
+*ad.inner = addr; /* Punt. */
+code = -1;
}
}
if (code < 0)
>>> Could you go into more details about this? Why is it OK to continue
>>> to try:
>>>
>>> (lo_sum new_reg addr)
>>>
>>> directly as an address (the context at the top of the hunk), but not try
>>> moving the lo_sum into a register? They should be semantically equivalent,
>>> so it seems that if one is wrong, the other would be too.
>>>
>> Hi, Richard. Change LRA is mine and I approved it for Iain's patch.
>>
>> I think there is no need for this code and it is misleading. If
>> 'mem[low_sum]' does not work, I don't think that 'reg=low_sum;mem[reg]'
>> will help for any existing target. As machine-dependent code for any
>> target most probably (for ppc64 darwin it is exactly the case) checks
>> address only in memory, it can wrongly accept wrong address by reloading
>> it into reg and use it in memory. So these are my arguments for the
>> remove this code from process_address_1.
>
> I'm probably making too much of this, but:
>
> I think the code is potentially useful in that existing targets do forbid
> forbid lo_sum addresses in certain contexts (due to limited offset range)
> while still wanting lo_sum to be used to be load the address. If we
> handle the high/lo_sum split in generic code then we have more chance
> of being able to optimise things. So it feels like this is setting an
> unfortunate precedent.
>
> I still don't understand what went wrong before though (the PR trail
> was a bit too long to process :-)). Is there a case where
> (lo_sum (high X) X) != X? If so, that seems like a target bug to me.
If X is an invalid address (in this case for
[Bug c++/104527] [11/12 Regression] ICE: tree check: accessed elt 1 of 'tree_vec' with 0 elts in hash, at cp/constraint.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104527 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Priority|P3 |P2 CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2022-02-14 --- Comment #1 from Jakub Jelinek --- ICEs since r11-7454-ge52f8ec25c0e58ebd083e8370e2fbc8af4120d87
[Bug testsuite/104423] [libgomp, testsuite] Add means to do accelerator-only testing in libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104423 --- Comment #5 from Tom de Vries --- Created attachment 52438 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52438=edit Tentative patch (GOMP_TARGET_ENV_ITER) A more generic solution using env var GOMP_TARGET_ENV_ITER, which allows us to specify: GOMP_TARGET_ENV_ITER="GOMP_NVPTX_JIT _ -O0".
[Bug middle-end/102276] -ftrivial-auto-var-init fails to initialize a variable, causes a spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102276 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- If we just want to avoid the warning in cases like that (there is nothing wrong in the testcases themselves, the warning just warns about an implementation detail that a normally uninitialized variable will be really uninitialized even despite the -ftrivial-auto-var-init= option), then maybe_warn_switch_unreachable already has: if (gimple_code (stmt) == GIMPLE_GOTO && TREE_CODE (gimple_goto_dest (stmt)) == LABEL_DECL && DECL_ARTIFICIAL (gimple_goto_dest (stmt))) /* Don't warn for compiler-generated gotos. These occur in Duff's devices, for example. */; and so for flag_auto_var_init > AUTO_INIT_UNINITIALIZED perhaps we could also avoid warnings on: 1) call to .DEFERRED_INIT 2) call to __builtin_clear_padding if the second argument is present and non-zero 3) I guess we would need not to warn on a gimple assign store right after the .DEFERRED_INIT call that has the lhs of .DEFERRED_INIT as rhs anything else?
Re: [pushed] LRA, rs6000, Darwin: Amend lo_sum use for forced constants [PR104117].
Hi Vlad,
Vladimir Makarov via Gcc-patches writes:
> On 2022-02-14 04:44, Richard Sandiford via Gcc-patches wrote:
>> Iain Sandoe via Gcc-patches writes:
>>> Two issues resulted in this PR, which manifests when we force a constant
>>> into
>>> memory in LRA (in PIC code on Darwin). The presence of such forced
>>> constants
>>> is quite dependent on other RTL optimisations, and it is easy for the issue
>>> to
>>> become latent for a specific case.
>>>
>>> First, in the Darwin-specific rs6000 backend code, we were not being careful
>>> enough in rejecting invalid symbolic addresses. Specifically, when
>>> generating
>>> PIC code, we require a SYMBOL_REF to be wrapped in an
>>> UNSPEC_MACHOPIC_OFFSET.
>>>
>>> Second, LRA was attempting to load a register using an invalid lo_sum
>>> address.
>>>
>>> The LRA changes are approved in the PR by Vladimir, and the RS6000 changes
>>> are
>>> Darwin-specific (although, of course, any observations are welcome).
>>>
>>> Tested on several lo_sum targets and x86_64 all languages except as noted:
>>> powerpc64-linux (m32/m64) -D
>>> powerpc64le-linux -D
>>> powerpc64-aix -Ada -Go -D
>>> aarch64-linux -Ada -D
>>> x86_64-linux all langs -D
>>> powerpc-darwin9 (master and 11.2) -D -Go.
>>>
>>> pushed to master, thanks,
>>> Iain
>>>
>>> Signed-off-by: Iain Sandoe
>>> Co-authored-by: Vladimir Makarov
>>>
>>> PR target/104117
>>>
>>> gcc/ChangeLog:
>>>
>>> * config/rs6000/rs6000.cc (darwin_rs6000_legitimate_lo_sum_const_p):
>>> Check for UNSPEC_MACHOPIC_OFFSET wrappers on symbolic addresses when
>>> emitting PIC code.
>>> (legitimate_lo_sum_address_p): Likewise.
>>> * lra-constraints.cc (process_address_1): Do not attempt to emit a reg
>>> load from an invalid lo_sum address.
>>> ---
>>> gcc/config/rs6000/rs6000.cc | 38 +++--
>>> gcc/lra-constraints.cc | 17 ++---
>>> 2 files changed, 38 insertions(+), 17 deletions(-)
>>>
>>> […]
>>> diff --git a/gcc/lra-constraints.cc b/gcc/lra-constraints.cc
>>> index fdff9e0720a..c700c3f4578 100644
>>> --- a/gcc/lra-constraints.cc
>>> +++ b/gcc/lra-constraints.cc
>>> @@ -3625,21 +3625,8 @@ process_address_1 (int nop, bool check_only_p,
>>> *ad.inner = gen_rtx_LO_SUM (Pmode, new_reg, addr);
>>> if (!valid_address_p (op, , cn))
>>> {
>>> - /* Try to put lo_sum into register. */
>>> - insn = emit_insn (gen_rtx_SET
>>> - (new_reg,
>>> -gen_rtx_LO_SUM (Pmode, new_reg,
>>> addr)));
>>> - code = recog_memoized (insn);
>>> - if (code >= 0)
>>> - {
>>> - *ad.inner = new_reg;
>>> - if (!valid_address_p (op, , cn))
>>> - {
>>> - *ad.inner = addr;
>>> - code = -1;
>>> - }
>>> - }
>>> -
>>> + *ad.inner = addr; /* Punt. */
>>> + code = -1;
>>> }
>>> }
>>> if (code < 0)
>> Could you go into more details about this? Why is it OK to continue
>> to try:
>>
>>(lo_sum new_reg addr)
>>
>> directly as an address (the context at the top of the hunk), but not try
>> moving the lo_sum into a register? They should be semantically equivalent,
>> so it seems that if one is wrong, the other would be too.
>>
> Hi, Richard. Change LRA is mine and I approved it for Iain's patch.
>
> I think there is no need for this code and it is misleading. If
> 'mem[low_sum]' does not work, I don't think that 'reg=low_sum;mem[reg]'
> will help for any existing target. As machine-dependent code for any
> target most probably (for ppc64 darwin it is exactly the case) checks
> address only in memory, it can wrongly accept wrong address by reloading
> it into reg and use it in memory. So these are my arguments for the
> remove this code from process_address_1.
I'm probably making too much of this, but:
I think the code is potentially useful in that existing targets do forbid
forbid lo_sum addresses in certain contexts (due to limited offset range)
while still wanting lo_sum to be used to be load the address. If we
handle the high/lo_sum split in generic code then we have more chance
of being able to optimise things. So it feels like this is setting an
unfortunate precedent.
I still don't understand what went wrong before though (the PR trail
was a bit too long to process :-)). Is there a case where
(lo_sum (high X) X) != X? If so, that seems like a target bug to me.
Or does the target accept (set R1 (lo_sum R2 X)) for an X that cannot
be split into a HIGH/LO_SUM pair? I'd argue that's a target bug too.
Thanks,
Richard
Re: [PATCH] c: Add diagnostic when operator= is used as truth cond [PR25689]
On 2/12/22 01:59, Zhao Wei Liew wrote:
On Fri, 11 Feb 2022 at 20:47, Jason Merrill wrote:
On the other hand, for empty classes, it seems that a COMPOUND_EXPR
is built in build_over_call under the is_really_empty_class guard (line 9791).
I don't understand the tree structure that I should identify though.
Could you give me any further explanations on that?
True, that's not very recognizable. I suppose we could use a
TREE_LANG_FLAG to mark that COMPOUND_EXPR, or we could leave empty
classes alone; neither assignment nor comparison of empty classes should
happen much in practice.
I agree. I'll leave them alone.
Got it. May I know why it's better to use *_nofold here?
To avoid trying to do constexpr evaluation of the function operand when
it's non-constant; in the interesting cases it won't be needed.
However, have you tested virtual operator=?
Yup, everything seems to work as expected for structs using virtual operator=.
I've updated the test suite to reflect the tests.
One thing to note: I've commented out 2 test statements that shouldn't
work. One of them
is caused by trivial assignments in empty classes being COMPOUND_EXPRs as we
discussed above. The other is an existing issue caused by trivial
assignments in non-empty
classes being MODIFY_EXPRs.
On an unrelated note, I adjusted the if condition to use INDIRECT_REF_P (cond)
instead of TREE_OPERAND_LENGTH (cond) >= 1.
I hope that's better for semantics.
Yes; REFERENCE_REF_P might be even better.
Alright, I've changed it to REFERENCE_REF_P and it seems to work fine as well.
-Everything below is the actual patch v3-
When compiling the following code with g++ -Wparentheses, GCC does not
warn on the if statement. For example, there is no warning for this code:
struct A {
A& operator=(int);
operator bool();
};
void f(A a) {
if (a = 0); // no warning
}
This is because a = 0 is a call to operator=, which GCC does not handle.
This patch fixes this issue by handling calls to operator= when deciding
to warn.
Bootstrapped and tested on x86_64-pc-linux-gnu.
v2: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590236.html
Changes since v2:
1. Add more test cases in Wparentheses-31.C.
2. Refactor added logic to a function (is_assignment_overload_ref_p).
3. Use REFERENCE_REF_P instead of INDIRECT_REF_P.
v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590158.html
Changes since v1:
1. Use CALL_EXPR_OPERATOR_SYNTAX to avoid warnings for explicit
operator=() calls.
2. Use INDIRECT_REF_P to filter implicit operator=() calls.
3. Use cp_get_callee_fndecl_nofold.
4. Add spaces before (.
PR c/25689
gcc/cp/ChangeLog:
* semantics.cc (maybe_convert_cond): Handle the implicit
operator=() case for -Wparentheses.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wparentheses-31.C: New test.
---
gcc/cp/semantics.cc | 21 +++-
gcc/testsuite/g++.dg/warn/Wparentheses-31.C | 55 +
2 files changed, 75 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/warn/Wparentheses-31.C
diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc
index 0cb17a6a8ab..30ffb23a032 100644
--- a/gcc/cp/semantics.cc
+++ b/gcc/cp/semantics.cc
@@ -815,6 +815,25 @@ finish_goto_stmt (tree destination)
return add_stmt (build_stmt (input_location, GOTO_EXPR, destination));
}
+/* Returns true if EXPR is a reference to an implicit
+ call to operator=(). */
+static bool
+is_assignment_overload_ref_p (tree expr)
+{
+ if (expr == NULL_TREE || !REFERENCE_REF_P (expr))
+return false;
This will only warn about op= that returns a reference, which is not
required.
+ tree fn = TREE_OPERAND (expr, 0);
+ if (TREE_CODE (fn) != CALL_EXPR || !CALL_EXPR_OPERATOR_SYNTAX (fn))
+return false;
+
+ tree fndecl = cp_get_callee_fndecl_nofold (fn);
+ return fndecl != NULL_TREE
+&& DECL_OVERLOADED_OPERATOR_P (fndecl)
+&& DECL_OVERLOADED_OPERATOR_IS (fndecl, NOP_EXPR)
+&& DECL_ASSIGNMENT_OPERATOR_P (fndecl);
This could be
&& DECL_ASSIGNMENT_OPERATOR_P (fndecl)
&& DECL_OVERLOADED_OPERATOR_IS (fndecl, NOP_EXPR);
without the separate DECL_OVERLOADED_OPERATOR_P test.
+}
+
/* COND is the condition-expression for an if, while, etc.,
statement. Convert it to a boolean value, if appropriate.
In addition, verify sequence points if -Wsequence-point is enabled. */
@@ -836,7 +855,7 @@ maybe_convert_cond (tree cond)
/* Do the conversion. */
cond = convert_from_reference (cond);
- if (TREE_CODE (cond) == MODIFY_EXPR
+ if ((TREE_CODE (cond) == MODIFY_EXPR || is_assignment_overload_ref_p (cond))
&& warn_parentheses
&& !warning_suppressed_p (cond, OPT_Wparentheses)
&& warning_at (cp_expr_loc_or_input_loc (cond),
diff --git a/gcc/testsuite/g++.dg/warn/Wparentheses-31.C
b/gcc/testsuite/g++.dg/warn/Wparentheses-31.C
new file mode 100644
index 000..7a5789fb7a1
---
Uninit warnings due to optimizing short-circuit conditionals
[CCing Mark in the hopes of insight from the valgrind side of things]
There is a false positive from -Wanalyzer-use-of-uninitialized-value on
gcc.dg/analyzer/pr102692.c here:
‘fix_overlays_before’: events 1-3
|
| 75 | while (tail
| |
| 76 | && (tem = make_lisp_ptr (tail, 5),
| | ^~
| | |
| | (1) following ‘false’ branch (when ‘tail’ is NULL)...
| 77 | (end = marker_position (XOVERLAY (tem)->end)) >= pos))
| | ~
|..
| 82 | if (!tail || end < prev || !tail->next)
| | ~~~
| | ||
| | |(3) use of uninitialized value ‘end’ here
| | (2) ...to here
|
The issue is that inner || of the conditionals have been folded within the
frontend from a chain of control flow:
5 │ if (tail == 0B) goto ; else goto ;
6 │ :
7 │ if (end < prev) goto ; else goto ;
8 │ :
9 │ _1 = tail->next;
10 │ if (_1 == 0B) goto ; else goto ;
11 │ :
to an OR expr (and then to a bitwise-or by the gimplifier):
5 │ _1 = tail == 0B;
6 │ _2 = end < prev;
7 │ _3 = _1 | _2;
8 │ if (_3 != 0) goto ; else goto ;
9 │ :
10 │ _4 = tail->next;
11 │ if (_4 == 0B) goto ; else goto ;
This happens for sufficiently simple conditionals in fold_truth_andor.
In particular, the (end < prev) is short-circuited without optimization,
but is evaluated with optimization, leading to the false positive.
Given how early this folding occurs, it seems the simplest fix is to
try to detect places where this optimization appears to have happened,
and suppress uninit warnings within the statement that would have
been short-circuited (and thus e.g. ignoring them when evaluating _2
above for the case where _1 is known to be true at the (_1 | _2) , and
thus _2 being redundant).
Attached is a patch that implements this.
There are some more details in the patch, but I'm wondering if this is a
known problem, and how e.g. valgrind copes with such code. My patch
feels like something of a hack, but I'm not sure of any other way around
it given that the conditional is folded directly within the frontend.
I've successfully bootstrapped & regrtested the patch on
x86_64-pc-linux-gnu; it fixes the false positive.
Thoughts? Thanks for reading
Dave
analyzer: fix uninit false +ve due to optimized conditionals [PR102692]
gcc/analyzer/ChangeLog:
PR analyzer/102692
* exploded-graph.h (impl_region_model_context::get_stmt): New.
* region-model.cc: Include "gimple-ssa.h", "tree-phinodes.h",
"tree-ssa-operands.h", and "ssa-iterators.h".
(within_short_circuited_stmt_p): New.
(region_model::check_for_poison): Don't warn about uninit values
if within_short_circuited_stmt_p.
* region-model.h (region_model_context::get_stmt): New vfunc.
(noop_region_model_context::get_stmt): New.
gcc/testsuite/ChangeLog:
PR analyzer/102692
* gcc.dg/analyzer/pr102692-2.c: New test.
* gcc.dg/analyzer/pr102692.c: Remove xfail. Remove -O2 from
options and move to...
* gcc.dg/analyzer/torture/pr102692.c: ...here.
Signed-off-by: David Malcolm
---
gcc/analyzer/exploded-graph.h | 2 +
gcc/analyzer/region-model.cc | 112 ++
gcc/analyzer/region-model.h | 5 +
gcc/testsuite/gcc.dg/analyzer/pr102692-2.c| 22
.../gcc.dg/analyzer/{ => torture}/pr102692.c | 4 +-
5 files changed, 143 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/analyzer/pr102692-2.c
rename gcc/testsuite/gcc.dg/analyzer/{ => torture}/pr102692.c (94%)
diff --git a/gcc/analyzer/exploded-graph.h b/gcc/analyzer/exploded-graph.h
index 1854193c65b..1f52725dc98 100644
--- a/gcc/analyzer/exploded-graph.h
+++ b/gcc/analyzer/exploded-graph.h
@@ -90,6 +90,8 @@ class impl_region_model_context : public region_model_context
const state_machine **out_sm,
unsigned *out_sm_idx) FINAL OVERRIDE;
+ const gimple *get_stmt () const OVERRIDE { return m_stmt; }
+
exploded_graph *m_eg;
log_user m_logger;
exploded_node *m_enode_for_diag;
diff --git a/gcc/analyzer/region-model.cc b/gcc/analyzer/region-model.cc
index e659cf03a86..8a509c44178 100644
--- a/gcc/analyzer/region-model.cc
+++ b/gcc/analyzer/region-model.cc
@@ -68,6 +68,11 @@ along with GCC; see the file COPYING3. If not see
#include "stor-layout.h"
#include "attribs.h"
#include "tree-object-size.h"
+#include "gimple-ssa.h"
+#include "tree-phinodes.h"
+#include "tree-ssa-operands.h"
+#include "ssa-iterators.h"
+#include "gimple-pretty-print.h"
#if ENABLE_ANALYZER
@@ -829,6 +834,108 @@
[Bug c++/104513] [12 Regression] goto cdtor_label failures on arm since r12-5256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104513 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
