[Bug rtl-optimization/101076] New: RTL Combine pass won't generate sign_extnd RTX in some senario
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101076
Bug ID: 101076
Summary: RTL Combine pass won't generate sign_extnd RTX in some
senario
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: wf831130 at sina dot com
Target Milestone: ---
I found a little bug in the combine pass.
When I use 64bit gcc to compile the below test.c, I found some issue
cat test.c
int test(int a)
{ return (a << 16) >> 16; }
In the combine pass, the log shows
Trying 6 -> 7:
6: r76:SI=r78:DI#0<<0x10
REG_DEAD r78:DI
7: r75:SI=r76:SI>>0x10
REG_DEAD r76:SI
Failed to match this instruction:
(set (reg:SI 75)
(ashiftrt:SI (subreg:SI (ashift:DI (reg:DI 78)
(const_int 16 [0x10])) 0)
(const_int 16 [0x10])))
Then I debugged and checkd the gcc code and fonud some issue in the function
make_compound_operation_int which is in the combine.c,
case ASHIFTRT:
lhs = XEXP (x, 0);
rhs = XEXP (x, 1);
/* If we have (ashiftrt (ashift foo C1) C2) with C2 >= C1,
this is a SIGN_EXTRACT. */
if (CONST_INT_P (rhs)
&& GET_CODE (lhs) == ASHIFT
&& CONST_INT_P (XEXP (lhs, 1))
&& INTVAL (rhs) >= INTVAL (XEXP (lhs, 1))
&& INTVAL (XEXP (lhs, 1)) >= 0
&& INTVAL (rhs) < mode_width)
{
new_rtx = make_compound_operation (XEXP (lhs, 0), next_code);
new_rtx = make_extraction (mode, new_rtx,
INTVAL (rhs) - INTVAL (XEXP (lhs, 1)),
NULL_RTX, mode_width - INTVAL (rhs),
code == LSHIFTRT, 0, in_code == COMPARE);
break;
}
/* See if we have operations between an ASHIFTRT and an ASHIFT.
If so, try to merge the shifts into a SIGN_EXTEND. We could
also do this for some cases of SIGN_EXTRACT, but it doesn't
seem worth the effort; the case checked for occurs on Alpha. */
if (!OBJECT_P (lhs)
&& ! (GET_CODE (lhs) == SUBREG
&& (OBJECT_P (SUBREG_REG (lhs
&& CONST_INT_P (rhs)
&& INTVAL (rhs) >= 0
&& INTVAL (rhs) < HOST_BITS_PER_WIDE_INT
&& INTVAL (rhs) < mode_width
&& (new_rtx = extract_left_shift (mode, lhs, INTVAL (rhs))) != 0)
new_rtx = make_extraction (mode, make_compound_operation (new_rtx,
next_code),
0, NULL_RTX, mode_width - INTVAL (rhs),
code == LSHIFTRT, 0, in_code == COMPARE);
break;
The issue code is "(new_rtx = extract_left_shift (mode, lhs, INTVAL (rhs))) !=
0)", this part wants to extract_left_shift information, but the second input
parameter lhs is not right, it's still SUBREG, but it should transmit ashift
part into the function. So the second parameter "lhs" should change to "XEXP
(lhs, 0)".
After change this issue, we can get the right combine result(sign_extend):
Trying 6 -> 7:
6: r138:SI=r140:DI#0<<0x10
REG_DEAD r140:DI
7: r137:SI=r138:SI>>0x10
REG_DEAD r138:SI
Successfully matched this instruction:
(set (reg:SI 137)
(sign_extend:SI (subreg:HI (reg:DI 140) 0)))
allowing combination of insns 6 and 7
original costs 4 + 4 = 8
replacement cost 8
deferring deletion of insn with uid = 6.
modifying insn i3 7: r137:SI=sign_extend(r140:DI#0)
REG_DEAD r140:DI
deferring rescan insn with uid = 7.
[Bug target/101007] [12 Regression] ICE: in extract_insn, at recog.c:2770 (unrecognizable insn) with -mno-sse2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101007 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #7 from Hongtao.liu --- (In reply to Jakub Jelinek from comment #6) > Fixed, although perhaps desirable to backport (except for the testcase). Since the regression is introduced by r12-760-g94de7e225c1fda079052c3f0725c926437d56c94, i guess there's no need for backport unless we want to backport r12-760 too.
[Bug libgcc/101075] libatomic's libat_lock_n can deadlock from inconsistent locking order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101075 Ryan Prichard changed: What|Removed |Added Attachment #51019|0 |1 is obsolete|| --- Comment #1 from Ryan Prichard --- Created attachment 51020 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51020=edit deadlock-gcc-libatomic.c Simplify the test program's buffer allocation a bit.
[Bug libgcc/101075] New: libatomic's libat_lock_n can deadlock from inconsistent locking order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101075 Bug ID: 101075 Summary: libatomic's libat_lock_n can deadlock from inconsistent locking order Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: rprichard at google dot com Target Milestone: --- Created attachment 51019 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51019=edit deadlock-gcc-libatomic.c libatomic's libat_lock_n[1] maps each 64-byte memory block to a different mutex. When the function acquires the locks for an atomic access, it starts with the lock for the first 64-byte span of the access, then the 2nd span, and so forth. If it hits the end of the table of locks, it wraps around to the start of the table. The result is that two concurrent atomic accesses can lock mutexes in an inconsistent order, then deadlock. e.g. Suppose we have 4 threads, WATCH_SIZE is 64, NLOCKS is 64, and the threads are doing atomic accesses of size 4KiB. Each access acquires all 64 locks, but they start at different indices, so if one thread can acquire a lock while another thread is still acquiring its locks, the program deadlocks. I attached a test program reproducing the deadlock. Aside: I'm not sure why libatomic uses multiple locks for an access. This question came up before (Bug 66842). I can see the rationale for using only the page-offset of an address, to handle an object aliased from two virtual pages. (It seems that LLVM uses only one lock for an access, and it hashes the low 30 bits into its lock index, so I think it won't handle two aliased pages?[2]) [1] https://github.com/gcc-mirror/gcc/blob/d9f1466f88abef7c814d02ba39a6ea5ef420aaec/libatomic/config/posix/lock.c#L82-L96 [2] https://github.com/llvm/llvm-project/blob/b8919fb0eac15d13c5f56d3d30ce378a588dd78c/compiler-rt/lib/builtins/atomic.c#L108-L123
[Bug tree-optimization/94566] conversion between std::strong_ordering and int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94566 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2020-04-13 00:00:00 |2021-6-14 --- Comment #4 from Andrew Pinski --- I wonder if we should always convert if-cases to switches and then do switchconv and then lower the smaller ones (3 if max) right after switchconv and then lower the rest in late as we do right now. This should get the conv1 case. The conv2 case problem is don't sink until late and never redo switchconv. So here is the proposed pipeline: iftoswitch - change to do it even without an heurstics sink switchconv switchlower - early
[Bug testsuite/101020] [12 regression] Several test case failures after r12-1316
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101020 --- Comment #3 from CVS Commits --- The master branch has been updated by Xiong Hu Luo : https://gcc.gnu.org/g:327a6b55e171669f2e72588570c931cd000822d0 commit r12-1443-g327a6b55e171669f2e72588570c931cd000822d0 Author: Xionghu Luo Date: Mon Jun 14 20:00:11 2021 -0500 rs6000: Fix test case failures by PR100085 [PR101020] Tested pass, committing as obvious. gcc/testsuite/ChangeLog: 2021-06-14 Xionghu Luo PR target/101020 * gcc.target/powerpc/float128-call.c: Adjust counts for be and le.
[Bug libstdc++/100940] views::take and views::drop should not define _S_has_simple_extra_args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100940 --- Comment #7 from TC --- (In reply to Patrick Palka from comment #6) > > For the other adaptors, we still unconditionally disable perfect forwarding > call wrapper semantics. I'm not sure if the performance/diagnostic tradeoff > is worth it to enable perfect forwarding semantics when the function object > is non-trivial. Personally, I'd happily pay some diagnostic complexity when I get things wrong if that means I get better performance when I get things right. Good diagnostics only matter when my code is broken, while performance matters when my code is working. The former should (hopefully) be a transient condition.
[Bug tree-optimization/101042] Bogus -Wstringop-overread with 11.1.0 and -O1 because of a call to printf _after_ assertions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101042 Martin Sebor changed: What|Removed |Added Last reconfirmed||2021-06-15 Keywords||missed-optimization CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #2 from Martin Sebor --- printf being treated as a possible clobber is one problem. Another is GCC not implementing the same optimization for calloc as for malloc/bzero (I opened PR 101074 to track that separately). The warning disappears when the printf call is removed and then reappears when the second assert (assert(field->type == FIELD.type);) is removed. Other than that, the warning is based on the IL below: [local count: 548457796]: : _3 = field_7->D.3115.string; _4 = strcmp (_3, 1B); if (_4 == 0) goto ; [99.96%] else goto ; [0.04%] The integer constant in the call to strcmp() is not a valid pointer (PR 99578 comment 1 explains the rationale).
[Bug tree-optimization/101074] New: calloc result not treated as zeroed out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101074
Bug ID: 101074
Summary: calloc result not treated as zeroed out
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
GCC folds malloc + bzero (or malloc + memset zero) to calloc and "knows" that
the returned memory is zeroed out. But it doesn't seem to understand that the
memory returned from a call specifically made to calloc is also zeroed out. In
the test case below both functions should be optimized equivalently but only
the first produces optimal code, the second is suboptimal.
$ cat z.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout z.c
struct A { int i; };
void* f (void)
{
struct A *p = __builtin_malloc (sizeof *p);
__builtin_memset (p, 0, sizeof *p);
if (p->i) // folded to false
__builtin_abort ();
return p;
}
void* g (void)
{
struct A *p = __builtin_calloc (1, sizeof *p);
if (p->i) // not folded
__builtin_abort ();
return p;
}
;; Function f (f, funcdef_no=0, decl_uid=1945, cgraph_uid=1, symbol_order=0)
void * f ()
{
struct A * p;
[local count: 1073741824]:
p_3 = __builtin_calloc (4, 1); [tail call]
return p_3;
}
;; Function g (g, funcdef_no=1, decl_uid=1949, cgraph_uid=2, symbol_order=1)
void * g ()
{
struct A * p;
int _1;
[local count: 1073741824]:
p_4 = __builtin_calloc (1, 4);
_1 = p_4->i;
if (_1 != 0)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin_abort ();
[local count: 1073741824]:
return p_4;
}
[Bug tree-optimization/91540] missed value-replacement in phiopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91540 --- Comment #5 from Andrew Pinski --- In summary, clang is trying to produce xor always for similar value reductions (or still branches) while GCC produce plus and minus; though producing xor or ior might lead to better code in general.
[Bug tree-optimization/91540] missed value-replacement in phiopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91540
--- Comment #4 from Andrew Pinski ---
On the trunk we get:
_5 = cond1_2(D) & cond2_3(D);
_6 = (int) _5;
_7 = 43 - _6;
If we replace the minus with xor, we would get what clang gives.
I think we do this with or though.
I looked into a slightly different case:
int Test(bool cond1, bool cond2)
{
if (cond1)
{
if (cond2)
{
return 43;
}
}
return 42;
}
int Test1(bool cond1, bool cond2)
{
int t = 0;
if (cond1)
{
if (cond2)
{
t = 1;
}
}
return 42 + t;
}
int Test0(bool cond1, bool cond2)
{
int t = 0;
if (cond1)
{
if (cond2)
{
t = 1;
}
}
return 42 + t;
}
int Test2(bool cond1, bool cond2)
{
int t = cond1 & cond2;
return 42 + t;
}
int Test3(bool cond1, bool cond2)
{
int t = (cond1 & cond2);
return 42 | t;
}
CUT
GCC produces the decent code for all of the Tests here while clang produces
produces decent for Test2 and Test3.
[Bug fortran/97046] Bad interaction between lbound/ubound, allocatable arrays and bind(C) subroutine with dimension(..) parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97046 --- Comment #9 from José Rui Faustino de Sousa --- Created attachment 51018 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51018=edit Updated patch.
[Bug fortran/97046] Bad interaction between lbound/ubound, allocatable arrays and bind(C) subroutine with dimension(..) parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97046 --- Comment #8 from José Rui Faustino de Sousa --- Updated patch: https://gcc.gnu.org/pipermail/fortran/2021-June/056163.html
[Bug fortran/94331] Bind(C) corrupts array descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331 --- Comment #13 from José Rui Faustino de Sousa --- Created attachment 51017 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51017=edit Updated patch.
[Bug fortran/94327] Bind(c) argument attributes are incorrectly set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94327 --- Comment #6 from José Rui Faustino de Sousa --- Created attachment 51016 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51016=edit Updated patch.
[Bug fortran/94327] Bind(c) argument attributes are incorrectly set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94327 --- Comment #5 from José Rui Faustino de Sousa --- Updated patch: https://gcc.gnu.org/pipermail/fortran/2021-June/056163.html
[Bug fortran/93963] Select rank mishandling allocatable and pointer arguments with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93963 --- Comment #7 from José Rui Faustino de Sousa --- Created attachment 51015 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51015=edit Updated patch.
[Bug fortran/93963] Select rank mishandling allocatable and pointer arguments with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93963 --- Comment #6 from José Rui Faustino de Sousa --- Updated patch: https://gcc.gnu.org/pipermail/fortran/2021-June/056163.html
[Bug fortran/93308] bind(c) subroutine changes lower bound of array argument in caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93308 --- Comment #7 from José Rui Faustino de Sousa --- Created attachment 51014 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51014=edit Updated patch.
[Bug fortran/93308] bind(c) subroutine changes lower bound of array argument in caller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93308 --- Comment #6 from José Rui Faustino de Sousa --- Updated patch: https://gcc.gnu.org/pipermail/fortran/2021-June/056163.html
[Bug fortran/94331] Bind(C) corrupts array descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94331 --- Comment #12 from José Rui Faustino de Sousa --- Updated patch posted: https://gcc.gnu.org/pipermail/fortran/2021-June/056163.html
[Bug middle-end/100876] [11 Regression] -Wmismatched-new-delete should understand placement new when it's not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100876 Martin Sebor changed: What|Removed |Added Summary|-Wmismatched-new-delete |[11 Regression] |should understand placement |-Wmismatched-new-delete |new when it's not inlined |should understand placement ||new when it's not inlined --- Comment #4 from Martin Sebor --- Fixed in GCC 12. Since this fixes a false positive I think it can be backported even if it also fixes a false negative. I'll plan to do it for GCC 11.2 unless there are objections.
[Bug middle-end/100876] -Wmismatched-new-delete should understand placement new when it's not inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100876 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:d9f1466f88abef7c814d02ba39a6ea5ef420aaec commit r12-1441-gd9f1466f88abef7c814d02ba39a6ea5ef420aaec Author: Martin Sebor Date: Mon Jun 14 16:34:48 2021 -0600 Teach compute_objsize about placement new [PR100876]. Resolves: PR c++/100876 - -Wmismatched-new-delete should understand placement new when it's not inlined gcc/ChangeLog: PR c++/100876 * builtins.c (gimple_call_return_array): Check for attribute fn spec. Handle calls to placement new. (ndecl_dealloc_argno): Avoid placement delete. gcc/testsuite/ChangeLog: PR c++/100876 * g++.dg/warn/Wmismatched-new-delete-4.C: New test. * g++.dg/warn/Wmismatched-new-delete-5.C: New test. * g++.dg/warn/Wstringop-overflow-7.C: New test. * g++.dg/warn/Wfree-nonheap-object-6.C: New test. * g++.dg/analyzer/placement-new.C: Prune out expected warning.
[Bug fortran/94104] Request for diagnostic improvement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94104 José Rui Faustino de Sousa changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug fortran/94104] Request for diagnostic improvement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94104 --- Comment #3 from José Rui Faustino de Sousa --- Created attachment 51013 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51013=edit Error message improvement
[Bug fortran/94104] Request for diagnostic improvement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94104 --- Comment #2 from José Rui Faustino de Sousa --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2021-June/056162.html
[Bug target/100777] MMA builtin usage ICEs when used in a #pragma omp parallel and using -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100777 --- Comment #3 from Peter Bergner --- Fixed on trunk. I'll backport the fix to gcc11 and gcc10 after baking on trunk for a day or two.
[Bug c++/100796] [11 Regression] GCC does not honor #pragma diagnostic ignored when using the integrated preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100796 --- Comment #5 from Jason Merrill --- Created attachment 51012 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51012=edit fix Testing this fix now. Making a suitable testcase for the testsuite will be a bit tricky...
[Bug tree-optimization/100864] (a&!b) | b is not opimized to a | b for comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100864
--- Comment #5 from Andrew Pinski ---
So what is done for A && !B (and A || !B), is the following:
/* Simple range test simplifications. */
/* A < B || A >= B -> true. */
(for test1 (lt le le le ne ge)
test2 (ge gt ge ne eq ne)
(simplify
(bit_ior:c (test1 @0 @1) (test2 @0 @1))
(if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
|| VECTOR_INTEGER_TYPE_P (TREE_TYPE (@0)))
{ constant_boolean_node (true, type); })))
/* A < B && A >= B -> false. */
(for test1 (lt lt lt le ne eq)
test2 (ge gt eq gt eq gt)
(simplify
(bit_and:c (test1 @0 @1) (test2 @0 @1))
(if (INTEGRAL_TYPE_P (TREE_TYPE (@0))
|| VECTOR_INTEGER_TYPE_P (TREE_TYPE (@0)))
{ constant_boolean_node (false, type); })))
But this could be expanded to other non-integer types.
For float types e.g (with -ffast-math):
int f(float a, float b)
{
int c = a == b;
int d = a != b;
return c & d;
}
Is not optimized until reassoc1. I will change that to be similar what I Have
too.
[Bug target/100777] MMA builtin usage ICEs when used in a #pragma omp parallel and using -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100777 --- Comment #2 from CVS Commits --- The master branch has been updated by Peter Bergner : https://gcc.gnu.org/g:20073534c0ccca0a4e079c053ee0874af10b2ea0 commit r12-1439-g20073534c0ccca0a4e079c053ee0874af10b2ea0 Author: Peter Bergner Date: Mon Jun 14 16:55:18 2021 -0500 rs6000: MMA builtin usage ICEs when used in a #pragma omp parallel and using -fopenmp [PR100777] Using an MMA builtin within an openmp parallel code block, leads to an SSA verification ICE on the temporaries we create while expanding the MMA builtins at gimple time. The solution is to use create_tmp_reg_or_ssa_name(), which knows when to create either an SSA or register temporary. 2021-06-14 Peter Bergner gcc/ PR target/100777 * config/rs6000/rs6000-call.c (rs6000_gimple_fold_mma_builtin): Use create_tmp_reg_or_ssa_name(). gcc/testsuite/ PR target/100777 * gcc.target/powerpc/pr100777.c: New test.
[Bug libstdc++/100894] The std::common_reference implementation seems to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100894 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3ae416e0a77a000b536171dbe06c3c2d136fb8e1 commit r11-8572-g3ae416e0a77a000b536171dbe06c3c2d136fb8e1 Author: Jonathan Wakely Date: Mon Jun 14 20:31:00 2021 +0100 libstdc++: Fix common_reference for non-reference results [PR100894] The result of COMMON-REF(A&, B&&) where they have no common reference type should be ill-formed. Our implementation fails to check that the COMMON-REF result is a reference, so is well-formed when it shouldn't be. This means that common_reference uses that result when it shouldn't do. The fix is to reject the result of COMMON-REF(A, B) if it's not a reference, so that common_reference falls through to the next case, which uses COND-RES, which yields the correct non-reference result. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/100894 * include/std/type_traits (__common_ref_impl): Only use the type if it's a reference. * testsuite/20_util/common_reference/100894.cc: New test. (cherry picked from commit c37b5ddcc88e0cc0f6a4ad609eda51021df0f6bb)
[Bug tree-optimization/101062] [10/11/12 Regression] wrong code with "-O2 -fno-toplevel-reorder -frename-registers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101062 --- Comment #6 from Eric Botcazou --- > Does Ada allow bitfields in unions and if yes, what does it want for those? Yes, it does, and I don't think there is any specific need so the default should be OK like for structures.
[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223
Fangrui Song changed:
What|Removed |Added
CC||i at maskray dot me
--- Comment #7 from Fangrui Song ---
Some notes.
{gcc,clang} -fsanitize-coverage={trace-pc,trace-cmp} is another coverage
feature. It uses no_sanitize_coverage instead of no_instrument_function. The
GCC support for no_sanitize_coverage is very new (by Martin, in 2021-05-25).
(In Clang, the feature has more modes, e.g. you can control func/bb/edge.)
The Linux kernel use case (include/linux/compiler_types.h ) uses 'noinline' so
inlining is not a concern.
/* Section for code which can't be instrumented at all */
#define noinstr \
noinline notrace __attribute((__section__(".noinstr.text")))\
__no_kcsan __no_sanitize_address
Clang supports another filtering mechanism, -fprofile-list=
(https://reviews.llvm.org/D94820). But the kernel use case seems to prefer a
function attribute.
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #4 from Andrew Macleod --- I just checked a patch in for PR 101014 which I suspect will fix this as well.. want to give it a try off trunk? I plan to port it to gcc 11 as well
[Bug gcov-profile/80223] RFE: Exclude functions from profile instrumentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80223 Nick Desaulniers changed: What|Removed |Added CC||elver at google dot com, ||isanbard at gmail dot com, ||kees at outflux dot net, ||maskray at google dot com, ||ndesaulniers at google dot com --- Comment #6 from Nick Desaulniers --- We had a request for something like this today on LKML, see the thread. https://lore.kernel.org/lkml/cakwvodmpti93n2l0_yqkrzldmpxzror7zggszonyaw2pgsh...@mail.gmail.com/ And more specific use case: https://lore.kernel.org/lkml/20210614190700.gf68...@worktop.programming.kicks-ass.net/ I've implemented this in LLVM; no_instrument_function function attribute in C can be used to disable coverage of -fprofile-generate (instrumentation based profiling; "PGO") and -fprofile-arcs (coverage; "GCOV"). PGO: https://reviews.llvm.org/D104253 GCOV: https://reviews.llvm.org/D104257 Inlining is a good point and something I'll need to check; generally when caller's and callee's function attributes don't match, we block inline substitution (though we permit it for always_inline; developer be damned). One question Fangrui had made was whether no_instrument_function is the appropriate function attribute to re-use. https://reviews.llvm.org/D104253#2817695 It looks like both -finstrument-functions and -pg are affected by attribute no_instrument_function; I decided to reuse no_instrument_function in LLVM because: 1. it already exists; implementation is barely more than 1 LoC. 2. it already affects code gen of 2 different flags. 3. its name perfectly describes developer intent. 4. the Linux kernel is already wired up to make use of no_instrument_function attribute (though the kernel's configuration step (KConfig) will need changes to detect support for this issue probably). I haven't landed the changes in LLVM yet, and don't particularly care what the attribute used ultimately is even if that means revisting our approach in LLVM. But without a solution to this problem, it's likely to block PGO and regress GCOV for x86 Linux kernels.
[Bug tree-optimization/101014] [12 Regression] Big compile time hog with -O3 since r12-1268-g9858cd1a6827ee7a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101014 --- Comment #4 from Andrew Macleod --- When a range is being calculated for an ssa-name, the propagation process often goes along back edges. These back edges sometime require other ssa-names which have not be processed yet. These are flagged as "poor values" and when propagation is done, we visit the list of poor values, calculate them, and see if that may result if a better range for the original ssa-name. The problem is that calculating these poor values may also spawn another set of requests since the block at the far end of the back edge has not been processed yet... its highly likely that some additional unprocessed ssa-names are used in the calculation of that name, but typically they do not affect the current range in a significant way. Thus we mostly we care about the first order effect only. It turns out to be very rare that a 2nd order effect on a back edge affects anything that we don't catch later. This patch turns off poor-value tagging when looking up the first order values, thus avoiding the 2nd order and beyond cascading effects. I haven't found a test case we miss yet because of this change, yet it probably resolves a number of the outstanding compilation problems in a significant way. I think this will probably apply to gcc 11 in some form as well, so I'll look at an equivalent patch for there.
[Bug tree-optimization/101062] [10/11/12 Regression] wrong code with "-O2 -fno-toplevel-reorder -frename-registers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101062
--- Comment #5 from Jakub Jelinek ---
--- gcc/expr.c.jj 2021-06-14 12:27:02.0 +0200
+++ gcc/expr.c 2021-06-14 22:18:56.852524237 +0200
@@ -5120,15 +5120,18 @@ get_bit_range (poly_uint64_pod *bitstart
poly_int64_pod *bitpos, tree *offset)
{
poly_int64 bitoffset;
- tree field, repr;
gcc_assert (TREE_CODE (exp) == COMPONENT_REF);
- field = TREE_OPERAND (exp, 1);
- repr = DECL_BIT_FIELD_REPRESENTATIVE (field);
- /* If we do not have a DECL_BIT_FIELD_REPRESENTATIVE there is no
- need to limit the range we can access. */
- if (!repr)
+ tree field = TREE_OPERAND (exp, 1);
+ tree repr = DECL_BIT_FIELD_REPRESENTATIVE (field);
+ tree type = TREE_TYPE (TREE_OPERAND (exp, 0));
+ /* If we do not have a DECL_BIT_FIELD_REPRESENTATIVE (except for bitfields
+ in unions) there is no need to limit the range we can access. */
+ if (!repr
+ && (TREE_CODE (type) != UNION_TYPE
+ || !TYPE_SIZE (type)
+ || !tree_fits_poly_uint64_p (TYPE_SIZE (type
{
*bitstart = *bitend = 0;
return;
@@ -5153,6 +5156,14 @@ get_bit_range (poly_uint64_pod *bitstart
}
}
+ /* For bitfields in unions, return bitsize of the whole union. */
+ if (!repr)
+{
+ *bitstart = *bitpos;
+ *bitend = *bitstart + tree_to_poly_uint64 (TYPE_SIZE (type)) - 1;
+ return;
+}
+
/* Compute the adjustment to bitpos from the offset of the field
relative to the representative. DECL_FIELD_OFFSET of field and
repr are the same by construction if they are not constants,
fixes it for me.
[Bug libstdc++/100894] The std::common_reference implementation seems to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100894 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:c37b5ddcc88e0cc0f6a4ad609eda51021df0f6bb commit r12-1437-gc37b5ddcc88e0cc0f6a4ad609eda51021df0f6bb Author: Jonathan Wakely Date: Mon Jun 14 20:31:00 2021 +0100 libstdc++: Fix common_reference for non-reference results [PR100894] The result of COMMON-REF(A&, B&&) where they have no common reference type should not be a reference. The implementation of COMMON-REF fails to check that the result is a reference, so is well-formed when it shouldn't be. This means that common_reference uses that result when it shouldn't. The fix is to reject the result of COMMON-REF(A, B) if it's not a reference, so that common_reference falls through to the next case, which uses COND-RES, which yields a non-reference result. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/100894 * include/std/type_traits (__common_ref_impl): Only use the type if it's a reference. * testsuite/20_util/common_reference/100894.cc: New test.
[Bug c++/100796] [11 Regression] GCC does not honor #pragma diagnostic ignored when using the integrated preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100796 --- Comment #4 from Giuseppe D'Angelo --- Created attachment 51011 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51011=edit testcase Hi, I've tried to "carve" a subset of files that show the problem. Apologies for not really being minimal. How to reproduce: 1) uncompress 2) cd $dir/home/peppe/projects/src/qt5/qtbase/build 3) (with c++ = GCC 11) run c++ -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_TESTCASE_BUILDDIR=\"/home/peppe/projects/src/qt5/qtbase/build/tests/auto/corelib/io/qurl\" -DQT_TESTCASE_SOURCEDIR=\"/home/peppe/projects/src/qt5/qtbase/tests/auto/corelib/io/qurl\" -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -Itests/auto/corelib/io/qurl/tst_qurl_autogen/include -I../tests/auto/corelib/io/qurl -Itests/auto/corelib/io/qurl -Iinclude -Iinclude/QtCore -I../mkspecs/linux-g++ -Iinclude/QtTest -Iinclude/QtConcurrent -Isrc/testlib -Iinclude/QtTest/6.2.0 -Iinclude/QtTest/6.2.0/QtTest -Isrc/corelib -Iinclude/QtCore/6.2.0 -Iinclude/QtCore/6.2.0/QtCore -g -fPIE -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wextra -fPIC -pthread -Wsuggest-override -std=gnu++2a -o /dev/null -c ../tests/auto/corelib/io/qurl/tst_qurl.cpp That for me generates a bunch of false warnings such as > include/QtCore/../../../src/corelib/kernel/qtmetamacros.h:159:32: warning: > ‘virtual const QMetaObject* QSocketNotifier::metaObject() const’ can be > marked override [-Wsuggest-override] > 159 | virtual const QMetaObject *metaObject() const; \ > |^~ > include/QtCore/../../../src/corelib/kernel/qsocketnotifier.h:51:5: note: in > expansion of macro ‘Q_OBJECT’ >51 | Q_OBJECT > | ^~~~ and many more. As mentioned before: adding -no-integrated-cpp to the command line, and/or splitting the compilation in explicit preprocessing+compilation, makes the warnings disappear. Please let me know if the testcase works or if I forgot to add something (hoping that system headers don't make a difference, anyways, I'm testing under Ubuntu 20.04).
[Bug c++/101071] [10/11/12 Regression] ICE in gimplify_init_constructor, at gimplify.c:5228
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101071 Andrew Pinski changed: What|Removed |Added Target Milestone|9.5 |10.4 Summary|[9/10/11/12 Regression] ICE |[10/11/12 Regression] ICE |in |in |gimplify_init_constructor, |gimplify_init_constructor, |at gimplify.c:5228 |at gimplify.c:5228
[Bug c++/101071] [9/10/11/12 Regression] ICE in gimplify_init_constructor, at gimplify.c:5228
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101071 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |9.5
[Bug libstdc++/100894] The std::common_reference implementation seems to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100894 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |10.4 --- Comment #1 from Jonathan Wakely --- For the next time I can't figure out how this works ... COMMON-REF(A&, B&&) is COMMON-REF(B&&, A&) which is COMMON-REF(const B&, A&) which is COND-RES(const B&, const A&) if that is a reference type, ill-formed otherwise. Since the COND-RES type is just B, it's ill-formed. That means that common_reference_t uses the third bullet, so it's COND-RES(A&, B&&) which is B.
[Bug fortran/101069] ICE in gfc_resolve_expr, at fortran/resolve.c:7087
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101069 --- Comment #2 from G. Steinmetz --- Oops, indeed.
[Bug c/29186] optimzation breaks floating point exception flag reading
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29186 Andrew Pinski changed: What|Removed |Added CC||pavel.morozkin at gmail dot com --- Comment #27 from Andrew Pinski --- *** Bug 101063 has been marked as a duplicate of this bug. ***
[Bug middle-end/101063] #pragma STDC FENV_ACCESS ON: wrong code generation: instructions leading to side effects may not be generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101063 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 29186 (and others). *** This bug has been marked as a duplicate of bug 29186 ***
[Bug preprocessor/89808] An option to disable warning "#pragma once in main file"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89808 Alejandro Colomar changed: What|Removed |Added CC||colomar.6.4.3 at gmail dot com --- Comment #12 from Alejandro Colomar --- Still buggy in gcc-11 (Debian 11.1.0-3) 11.1.0 I'll have a look at the code and see if I can fix it.
[Bug pch/64117] warning control #pragmas in precompiled headers are not obeyed for template code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64117 --- Comment #7 from Alejandro Colomar --- Oops, sorry, I meant the previous comment for another bug. I don't know if it's solved or not in gcc-11
[Bug fortran/79524] [9/10/11/12 Regression] valgrind error for gcc/testsuite/gfortran.dg/fimplicit_none_2.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79524 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||gs...@t-online.de --- Comment #12 from anlauf at gcc dot gnu.org --- *** Bug 101069 has been marked as a duplicate of this bug. ***
[Bug fortran/101069] ICE in gfc_resolve_expr, at fortran/resolve.c:7087
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101069 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from anlauf at gcc dot gnu.org --- This is testcase gfortran.dg/fimplicit_none_2.f90 without -fimplicit-none, tracked as pr79524. *** This bug has been marked as a duplicate of bug 79524 ***
[Bug pch/64117] warning control #pragmas in precompiled headers are not obeyed for template code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64117 Alejandro Colomar changed: What|Removed |Added CC||colomar.6.4.3 at gmail dot com --- Comment #6 from Alejandro Colomar --- Still buggy in gcc-11 (gcc-11 (Debian 11.1.0-3) 11.1.0) I'll have a look at the code and see if I can fix it.
[Bug target/101058] [12 Regression] ICE in extract_insn, at recog.c:2770 since r12-1215-g8d7dae0eb366a88a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101058 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Uroš Bizjak --- Fixed.
[Bug tree-optimization/101062] [10/11/12 Regression] wrong code with "-O2 -fno-toplevel-reorder -frename-registers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101062
Jakub Jelinek changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
Ah, and there is also a problem that for bitfields in unions we don't create
DECL_BIT_FIELD_REPRESENTATIVE in finish_bitfield_layout and so then
get_bit_range returns { 0, 0 } as bitstart, bitend and so the access isn't
really restricted.
So, wonder, shall we for bitfields in UNION_TYPE in get_bit_range return the
range of the union? Or is it ok for d[4].b RMW to update also d[5].b next to
it, just not anything beyond end of the variable (so essentially set
bitregion_start/bitregion_end to the start and end of d variable), something
else?
At least for multithreaded apps, even the modification of another element of
the same array seems bad to me.
Does Ada allow bitfields in unions and if yes, what does it want for those?
Changing the testcase with sed -i -e s/union/struct/g fixes the bug...
[Bug target/101058] [12 Regression] ICE in extract_insn, at recog.c:2770 since r12-1215-g8d7dae0eb366a88a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101058 --- Comment #11 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:4986946f3b761dd4c3e0d79ca735c90e33f4bb83 commit r12-1436-g4986946f3b761dd4c3e0d79ca735c90e33f4bb83 Author: Uros Bizjak Date: Mon Jun 14 20:56:18 2021 +0200 i386: Split V2HImode *punpckwd to SSE instruction [PR101058] V2HImode *punpckwd should not be split to the insn that depends on TARGET_MMX_WITH_SSE, since the later is disabled on 32bit targets. Also return true early from ix86_vectorize_vec_perm_const when testing with V2HI mode. *punpckwd can be used to implement all permutations. 2021-06-14 Uroš Bizjak gcc/ PR target/101058 * config/i386/i386-expand.c (ix86_vectorize_vec_perm_const): Return true early when testing with V2HImode. * config/i386/mmx.md (*punpckwd): Split to sse2_pshuflw_1. gcc/testsuite/ PR target/101058 * gcc.target/i386/pr101058.c: New test.
[Bug libstdc++/101034] wrong constraint in std::any's constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101034 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |9.5
[Bug libstdc++/100982] wrong constraint in std::optional::operator=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100982 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:37864c5e6aa6befc17051f162c02d4f593a57e57 commit r10-9915-g37864c5e6aa6befc17051f162c02d4f593a57e57 Author: Jonathan Wakely Date: Wed Jun 9 11:03:15 2021 +0100 libstdc++: Fix constraint on std::optional assignment [PR 100982] libstdc++-v3/ChangeLog: PR libstdc++/100982 * include/std/optional (optional::operator=(const optional&)): Fix value category used in is_assignable check. * testsuite/20_util/optional/assignment/100982.cc: New test. (cherry picked from commit b3fce1bd45f72cc9e55fb7431762e92e30fefcf1)
[Bug libstdc++/101034] wrong constraint in std::any's constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101034 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b0d29239bd2e90b4d0af6608c01c1a1a40d617f3 commit r10-9914-gb0d29239bd2e90b4d0af6608c01c1a1a40d617f3 Author: Jonathan Wakely Date: Mon Jun 14 14:18:33 2021 +0100 libstdc++: Fix std::any constraints [PR101034] PR libstdc++/101034 libstdc++-v3/ChangeLog: * include/std/any (any(in_place_t, initializer_list, A&&...)) (any::emplace(initializer_list, A&&...)): Fix constraint to use lvalue. * testsuite/20_util/any/cons/101034.cc: New test. (cherry picked from commit 14f26c75d255ef05b706a12d25b003da8a2f5b45)
[Bug tree-optimization/101062] [10/11/12 Regression] wrong code with "-O2 -fno-toplevel-reorder -frename-registers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101062
--- Comment #3 from Jakub Jelinek ---
And
union U { signed b : 5; };
int c;
volatile union U d[7] = {{8}};
short e = 1;
__attribute__((noipa, noinline, noclone)) void
foo ()
{
d[6].b = 0;
d[6].b = 0;
d[6].b = 0;
d[6].b = 0;
d[6].b = 0;
e = 0;
c = 0;
}
int
main ()
{
foo ();
if (e != 0)
__builtin_abort ();
return 0;
}
it started even in between r0-74314-gc245c134da2fdced8608d3e992c969ae22932752
and r0-74353-g5cd88d6857dffe4f10c834c773c300881ec20e32
Seems the problem is the d[6].b store, which incorrectly uses a 64-bit load
from d+24 and then later on stores adjusted value to that. But d is only 28
bytes long and with -fno-toplevel-reorder the e variable is right after it and
scheduling moves the load from *(long long *)(((char *)) + 24) before store
to e and its update after store to e.
[Bug tree-optimization/101062] [10/11/12 Regression] wrong code with "-O2 -fno-toplevel-reorder -frename-registers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101062 --- Comment #2 from Jakub Jelinek --- Actually, with noinline,noclone,noipa it started already with r0-102336-g8f0fe813790d58066714c8f38f4916925c83517d
[Bug c++/101052] Suggest stdlib.h when exit(1) is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101052 --- Comment #5 from Jonny Grant --- Amazing 1-day turnaround, thank you Jonathan!
[Bug tree-optimization/101062] [10/11/12 Regression] wrong code with "-O2 -fno-toplevel-reorder -frename-registers"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101062
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P2
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Target Milestone|--- |10.4
CC||jakub at gcc dot gnu.org
Last reconfirmed||2021-06-14
Summary|wrong code with "-O2|[10/11/12 Regression] wrong
|-fno-toplevel-reorder |code with "-O2
|-frename-registers" |-fno-toplevel-reorder
||-frename-registers"
--- Comment #1 from Jakub Jelinek ---
Started with r10-3542-g0b92cf305dcf34387a8e2564e55ca8948df3b47a
so likely latent before.
Slightly adjusted testcase:
/* { dg-do run } */
/* { dg-options "-O2 -fno-toplevel-reorder -frename-registers" } */
union U { signed b : 5; };
int c;
volatile union U d[7] = {{8}};
short e = 1;
__attribute__((noipa)) void
foo ()
{
for (c = 5; c; c--)
e = d[6].b = 0;
}
int
main ()
{
foo ();
if (e != 0)
__builtin_abort ();
return 0;
}
[Bug c++/101052] Suggest stdlib.h when exit(1) is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101052 Jonathan Wakely changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/101052] Suggest stdlib.h when exit(1) is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101052 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jonathan Wakely --- Implemented for GCC 12
[Bug libstdc++/100894] The std::common_reference implementation seems to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100894 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-06-14
[Bug c++/101073] New: [9/10/11/12 Regression] ICE in cxx_eval_constant_expression, at cp/constexpr.c:6941
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101073
Bug ID: 101073
Summary: [9/10/11/12 Regression] ICE in
cxx_eval_constant_expression, at cp/constexpr.c:6941
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: ---
With file gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi9.C and option
-fno-elide-constructors, affects versions down to r6 :
$ g++-12-20210613 -c constexpr-nsdmi9.C -fno-elide-constructors
constexpr-nsdmi9.C:15:19: internal compiler error: in
cxx_eval_constant_expression, at cp/constexpr.c:6941
15 | constexpr X o = { };
| ^
0x6fae2c cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6941
0x6fa62e cxx_eval_indirect_ref
../../gcc/cp/constexpr.c:5019
0x6fa62e cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6461
0x6fa4b2 cxx_eval_component_reference
../../gcc/cp/constexpr.c:3879
0x6fa4b2 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6637
0x6fa62e cxx_eval_indirect_ref
../../gcc/cp/constexpr.c:5019
0x6fa62e cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6461
0x7009eb cxx_eval_store_expression
../../gcc/cp/constexpr.c:5327
0x6fa70d cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6350
0x6f7344 cxx_eval_call_expression
../../gcc/cp/constexpr.c:2539
0x6f9ff0 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6241
0x6f8fe9 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6733
0x6f8fe9 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6733
0x6f8fe9 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6733
0x6faff0 cxx_eval_indirect_ref
../../gcc/cp/constexpr.c:4976
0x6faff0 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6461
0x70075f cxx_eval_store_expression
../../gcc/cp/constexpr.c:5263
0x6fa70d cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6350
0x6f7344 cxx_eval_call_expression
../../gcc/cp/constexpr.c:2539
0x6f9ff0 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:6241
[Bug c++/101052] Suggest stdlib.h when exit(1) is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101052 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:93bfadf3a1db7d73e9ca4a4a3d40f7f81ea16d39 commit r12-1435-g93bfadf3a1db7d73e9ca4a4a3d40f7f81ea16d39 Author: Jonathan Wakely Date: Mon Jun 14 11:38:11 2021 +0100 c-family: Add fix-it suggestions for more names [PR101052] PR c++/101052 gcc/c-family/ChangeLog: * known-headers.cc (get_stdlib_header_for_name): Add known headers for EXIT_FAILURE, EXIT_SUCCESS, abort, atexit, calloc, exit, and getenv. gcc/testsuite/ChangeLog: * g++.dg/spellcheck-stdlib.C: Add checks for names. * gcc.dg/spellcheck-stdlib.c: Likewise.
[Bug c++/101072] New: [11/12 Regression] ICE in build_target_expr_with_type, at cp/tree.c:845
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101072 Bug ID: 101072 Summary: [11/12 Regression] ICE in build_target_expr_with_type, at cp/tree.c:845 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: --- With file gcc/testsuite/g++.dg/cpp0x/constexpr-empty14.C and option -fno-elide-constructors, changed between 20201129 and 20201206 : $ g++-12-20210613 -c constexpr-empty14.C -fno-elide-constructors constexpr-empty14.C: In function 'void foo(S)': constexpr-empty14.C:9:19: internal compiler error: in build_target_expr_with_type, at cp/tree.c:845 9 | constexpr S x = s; | ^ 0x86c2c0 build_target_expr_with_type(tree_node*, tree_node*, int) ../../gcc/cp/tree.c:845 0x81d535 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../gcc/cp/pt.c:20831 0x6ffa0c fold_non_dependent_expr_template ../../gcc/cp/constexpr.c:7597 0x886e74 store_init_value(tree_node*, tree_node*, vec**, int) ../../gcc/cp/typeck2.c:764 0x744fcd check_initializer ../../gcc/cp/decl.c:7163 0x747317 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int) ../../gcc/cp/decl.c:7963 0x802791 cp_parser_init_declarator ../../gcc/cp/parser.c:22044 0x7e348a cp_parser_simple_declaration ../../gcc/cp/parser.c:14587 0x7e5049 cp_parser_declaration_statement ../../gcc/cp/parser.c:13722 0x7e5941 cp_parser_statement ../../gcc/cp/parser.c:11852 0x7e6254 cp_parser_statement_seq_opt ../../gcc/cp/parser.c:12219 0x7e630f cp_parser_compound_statement ../../gcc/cp/parser.c:12168 0x8017f8 cp_parser_function_body ../../gcc/cp/parser.c:24236 0x8017f8 cp_parser_ctor_initializer_opt_and_function_body ../../gcc/cp/parser.c:24287 0x801ca6 cp_parser_function_definition_after_declarator ../../gcc/cp/parser.c:30246 0x802b6c cp_parser_function_definition_from_specifiers_and_declarator ../../gcc/cp/parser.c:30162 0x802b6c cp_parser_init_declarator ../../gcc/cp/parser.c:21806 0x8052b4 cp_parser_single_declaration ../../gcc/cp/parser.c:30742 0x805495 cp_parser_template_declaration_after_parameters ../../gcc/cp/parser.c:30314 0x805c5b cp_parser_explicit_template_declaration ../../gcc/cp/parser.c:30580
[Bug c++/101071] New: [9/10/11/12 Regression] ICE in gimplify_init_constructor, at gimplify.c:5228
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101071
Bug ID: 101071
Summary: [9/10/11/12 Regression] ICE in
gimplify_init_constructor, at gimplify.c:5228
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: ---
With file gcc/testsuite/g++.dg/cpp0x/variadic-alias2.C and option
-fno-elide-constructors, started between 20200308 and 20200412 :
$ g++-8 -c variadic-alias2.C -O2 -fno-elide-constructors
$
$ g++-12-20210613 -c variadic-alias2.C -O2 -fno-elide-constructors
z1.cc: In function 'void test_min_filter()':
z1.cc:97:3: internal compiler error: in gimplify_init_constructor, at
gimplify.c:5228
97 | (void)(computed{} = expected{});// compiles for identical types
| ^~~
0xaec735 gimplify_init_constructor
../../gcc/gimplify.c:5228
0xaed305 gimplify_modify_expr_rhs
../../gcc/gimplify.c:5397
0xaf0bdc gimplify_modify_expr
../../gcc/gimplify.c:5759
0xae6b13 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14079
0xaefdbc gimplify_target_expr
../../gcc/gimplify.c:6782
0xae6ae6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14476
0xae9448 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6863
0xae7646 gimplify_cleanup_point_expr
../../gcc/gimplify.c:6605
0xae7646 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14472
0xae9448 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6863
0xae99a1 gimplify_bind_expr
../../gcc/gimplify.c:1424
0xae74ca gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14280
0xae9448 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6863
0xaea46b gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:15324
0xaea8bf gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:15478
0x981ec7 cgraph_node::analyze()
../../gcc/cgraphunit.c:670
0x9847e7 analyze_functions
../../gcc/cgraphunit.c:1234
0x9851ad symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2508
[Bug c++/101070] New: ICE: Error reporting routines re-entered.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101070
Bug ID: 101070
Summary: ICE: Error reporting routines re-entered.
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: ---
Affects versions down to at least r5 :
$ cat z1.cc
typedef int A __attribute__((aligned(16)));
void f ()
{
A b[2];
b = 0;
}
$ cat z2.cc
typedef int A __attribute__((aligned(16)));
A b[2];
int p =
$ g++-12-20210613 -c z1.cc
z1.cc: In function 'void f()':
z1.cc:4:8: error: alignment of array elements is greater than element size
4 | A b[2];
|^
'
Internal compiler error: Error reporting routines re-entered.
0xd444d6 layout_type(tree_node*)
../../gcc/stor-layout.c:2599
0x86a29c build_cplus_array_type(tree_node*, tree_node*, int)
../../gcc/cp/tree.c:1113
0x86d900 build_cplus_array_type(tree_node*, tree_node*, int)
../../gcc/cp/tree.c:1602
0x86d900 strip_typedefs(tree_node*, bool*, unsigned int)
../../gcc/cp/tree.c:1602
0x75ae4b type_to_string
../../gcc/cp/error.c:3336
0x75ba85 cp_printer
../../gcc/cp/error.c:4416
0x172c4be pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:1475
0x172056d diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:1275
0x1720ace diagnostic_impl
../../gcc/diagnostic.c:1437
0x17213da error_at(unsigned int, char const*, ...)
../../gcc/diagnostic.c:1760
0x8814d2 cp_build_modify_expr(unsigned int, tree_node*, tree_code, tree_node*,
int)
../../gcc/cp/typeck.c:8903
0x881f69 build_x_modify_expr(unsigned int, tree_node*, tree_code, tree_node*,
int)
../../gcc/cp/typeck.c:9033
0x7d4f2a cp_parser_assignment_expression
../../gcc/cp/parser.c:10198
0x7d5b6c cp_parser_expression
../../gcc/cp/parser.c:10327
0x7d8787 cp_parser_expression_statement
../../gcc/cp/parser.c:12071
0x7e5983 cp_parser_statement
../../gcc/cp/parser.c:11867
0x7e6254 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:12219
0x7e630f cp_parser_compound_statement
../../gcc/cp/parser.c:12168
0x8017f8 cp_parser_function_body
../../gcc/cp/parser.c:24236
0x8017f8 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:24287
[Bug fortran/101069] New: ICE in gfc_resolve_expr, at fortran/resolve.c:7087
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101069 Bug ID: 101069 Summary: ICE in gfc_resolve_expr, at fortran/resolve.c:7087 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- The ICE is always reproducible with gcc-11-20201004 and newer on my environment, and never with gcc-11-20200823, but ICEs sometimes sporadically for older versions too. Other brands may also stumble. $ cat z1.f90 program p character(*), parameter :: x(2) = [character(n) :: 'a', 'b'] end $ gfortran-12-20210613 -c z1.f90 # configured with --enable-checking=yes z1.f90:2:34: 2 |character(*), parameter :: x(2) = [character(n) :: 'a', 'b'] | 1 Error: Cannot initialize parameter array at (1) with variable length elements f951: internal compiler error: Segmentation fault 0xe1963f crash_signal ../../gcc/toplev.c:327 0x798173 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7087 0x79a9d4 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:12525 0x79a9d4 resolve_charlen ../../gcc/fortran/resolve.c:12475 0x7a6c29 resolve_charlen ../../gcc/fortran/resolve.c:12466 0x7a6c29 resolve_types ../../gcc/fortran/resolve.c:17344 0x7a227c gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17461 0x78a7b4 resolve_all_program_units ../../gcc/fortran/parse.c:6400 0x78a7b4 gfc_parse_file() ../../gcc/fortran/parse.c:6652 0x7d7dcf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:212
[Bug libstdc++/100940] views::take and views::drop should not define _S_has_simple_extra_args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100940 Patrick Palka changed: What|Removed |Added Target Milestone|--- |11.2 --- Comment #6 from Patrick Palka --- Patch at: https://gcc.gnu.org/pipermail/libstdc++/2021-June/052736.html The patch disables perfect forwarding for take/drop only when the argument is integer-like (fixing the reported correctness issue), and also disables perfect forwarding for split when the argument is a scalar or a copy-constructible view (safely restoring good diagnostics for these cases). For the other adaptors, we still unconditionally disable perfect forwarding call wrapper semantics. I'm not sure if the performance/diagnostic tradeoff is worth it to enable perfect forwarding semantics when the function object is non-trivial.
[Bug fortran/100683] Array initialization refuses valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100683 --- Comment #9 from José Rui Faustino de Sousa --- Created attachment 51010 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51010=edit Patch and changelog
[Bug fortran/100683] Array initialization refuses valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100683 --- Comment #8 from José Rui Faustino de Sousa --- Corrected patch posted: https://gcc.gnu.org/pipermail/fortran/2021-June/056160.html
[Bug fortran/100683] Array initialization refuses valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100683
--- Comment #7 from José Rui Faustino de Sousa ---
I was using pr87993.f90 from the testsuite... ;-)
The fix is simple enough:
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index a37ad66..a9518e7 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -7138,8 +7138,10 @@ gfc_resolve_expr (gfc_expr *e)
/* Also try to expand a constructor. */
if (t)
{
+ gfc_simplify_expr(e, 1);
gfc_expression_rank (e);
- if (gfc_is_constant_expr (e) || gfc_is_expandable_expr (e))
+ if (e->expr_type == EXPR_ARRAY
+ && (gfc_is_constant_expr (e) || gfc_is_expandable_expr (e)))
gfc_expand_constructor (e, false);
}
I really should have though of this possibility...
Thank you very much.
Best regards,
José Rui
[Bug analyzer/101068] New: Analyzer does not purge constraints in loops (e.g. in explode-2.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101068
Bug ID: 101068
Summary: Analyzer does not purge constraints in loops (e.g. in
explode-2.c)
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Looking at gcc.dg/analyzer/explode-2.c, it appears that it treats the SSA names
for the results of the two "get" calls as constant within the loop i.e. they
acquire constraints on the first iteration due to the while/switch edges that
are taken, and these constraints aren't purged when processing subsequent
iterations.
Hence, rather than:
while (get ())
{
switch (get ())
{
[...snip...]
}
}
the analyzer effectively treats this as:
int a, b;
a = get ();
b = get ();
while (a)
{
switch (b)
{
[...snip...]
}
}
and this artifically helps stop this testcase from exploding.
[Bug c++/101052] Suggest stdlib.h when exit(1) is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101052 Jonathan Wakely changed: What|Removed |Added Keywords||patch --- Comment #2 from Jonathan Wakely --- Patch posted for review: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572665.html
[Bug libstdc++/101034] wrong constraint in std::any's constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101034 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:028fd30231ea8a5ddea5525851ed93e0bc658a23 commit r11-8569-g028fd30231ea8a5ddea5525851ed93e0bc658a23 Author: Jonathan Wakely Date: Mon Jun 14 14:18:33 2021 +0100 libstdc++: Fix std::any constraints [PR101034] PR libstdc++/101034 libstdc++-v3/ChangeLog: * include/std/any (any(in_place_t, initializer_list, A&&...)) (any::emplace(initializer_list, A&&...)): Fix constraint to use lvalue. * testsuite/20_util/any/cons/101034.cc: New test. (cherry picked from commit 14f26c75d255ef05b706a12d25b003da8a2f5b45)
[Bug c++/101067] New: SFINAE Out-of-line Function Definition not Matching Declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101067 Bug ID: 101067 Summary: SFINAE Out-of-line Function Definition not Matching Declaration Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bboys_nick at icloud dot com Target Milestone: --- Created attachment 51009 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51009=edit The preprocessed file as required. When declaring a class A constructor constrained to check for type equivalence of the underlying value_type of a passed-in iterator with a in-class defined nested class B, the out of line definition of this constructor does not match the function declaration in class using SFINAE technique(enable_if>), with both A and B being templated. A more detailed description of the problem can be found on this thread on stackoverflow. https://stackoverflow.com/questions/67965118/c-concepts-sfinae-clang-and-msvc-g-different-results-for-out-of-line-functi A brief test case is provided at https://godbolt.org/z/7nr7a8jY8.
[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 100913, which changed state. Bug 100913 Summary: cppcheck: 2 * pointless new assignments in the parser ? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100913 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c/100913] cppcheck: 2 * pointless new assignments in the parser ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100913 Tobias Burnus changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Tobias Burnus --- FIXED. @David: Thanks for the report. @Martin: Thanks for bisecting/assigning the bug.
[Bug middle-end/100944] missing -Warray-bounds accessing a flexible array member of a nested struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100944 --- Comment #2 from Martin Sebor --- The front end does complain but only with -Wpedantic.
[Bug c/100913] cppcheck: 2 * pointless new assignments in the parser ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100913 --- Comment #2 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:12d13cf50fe68c898ee65d71d1ba9cdb3ea07996 commit r12-1433-g12d13cf50fe68c898ee65d71d1ba9cdb3ea07996 Author: Tobias Burnus Date: Mon Jun 14 16:49:24 2021 +0200 C/C++: Fix unused set var warning with omp_clause_affinity [PR100913] PR c/100913 gcc/c/ChangeLog: * c-parser.c (c_parser_omp_clause_affinity): No need to set iterator var in the error case. gcc/cp/ChangeLog: * parser.c (cp_parser_omp_clause_affinity): No need to set iterator var in the error case.
[Bug tree-optimization/100934] [9/10/11 Regression] wrong code at -O3 during unrolling since r9-6299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100934 Richard Biener changed: What|Removed |Added Known to fail|12.0|11.1.0 Summary|[9/10/11/12 Regression] |[9/10/11 Regression] wrong |wrong code at -O3 during|code at -O3 during |unrolling since r9-6299 |unrolling since r9-6299 Known to work||12.0 --- Comment #12 from Richard Biener --- Fixed on trunk sofar.
[Bug tree-optimization/100934] [9/10/11/12 Regression] wrong code at -O3 during unrolling since r9-6299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100934 --- Comment #11 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:788bb7edb3975b80c4cb16323e7a5e55a2471e46 commit r12-1432-g788bb7edb3975b80c4cb16323e7a5e55a2471e46 Author: Richard Biener Date: Mon Jun 14 14:57:26 2021 +0200 tree-optimization/100934 - properly mark irreducible regions for DOM The jump threading code requires marked irreducible regions for the purpose of validating jump threading paths but DOM fails to provide that resulting in mised number of iteration upper bounds clearing. 2021-06-14 Richard Biener PR tree-optimization/100934 * tree-ssa-dom.c (pass_dominator::execute): Properly mark irreducible regions. * gcc.dg/torture/pr100934.c: New testcase.
[Bug libstdc++/101034] wrong constraint in std::any's constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101034 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:14f26c75d255ef05b706a12d25b003da8a2f5b45 commit r12-1430-g14f26c75d255ef05b706a12d25b003da8a2f5b45 Author: Jonathan Wakely Date: Mon Jun 14 14:18:33 2021 +0100 libstdc++: Fix std::any constraints [PR101034] PR libstdc++/101034 libstdc++-v3/ChangeLog: * include/std/any (any(in_place_t, initializer_list, A&&...)) (any::emplace(initializer_list, A&&...)): Fix constraint to use lvalue. * testsuite/20_util/any/cons/101034.cc: New test.
[Bug c/101066] New: Wrong code after fixup_cfg3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101066
Bug ID: 101066
Summary: Wrong code after fixup_cfg3
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Target: s390*-*-*, x86_64-*-*
int a = 1, c, d, e;
int *b =
static int g(int *h) {
c = *h;
return d;
}
static void f(int *h) {
e = *h;
*b = 0;
g(h);
}
int main() {
f(b);
printf("%d\n", c);
}
Running `gcc t.c -Os && ./a.out` results in printed 1 whereas 0 is expected.
This does not happen for -O[0,1,2,3] i.e. there 0 is printed.
Prior fixup_cfg3 the code looks good to me and afterwards the assignment to c
uses a cached/initial value of variable a which is wrong:
int main ()
{
int * b.0_1;
int c.1_2;
int _6;
int _7;
int * b.2_8;
int _10;
int _11;
[local count: 1073741824]:
b.0_1 = b;
_6 = *b.0_1;
_7 = _6;
e = _7;
b.2_8 = b;
*b.2_8 = 0;
_10 = _6;
c = _10;
_11 = d;
c.1_2 = c;
printf ("%d\n", c.1_2);
return 0;
}
Reproducible on IBM Z as well as x86_64 using commit 831589c227c.
[Bug target/101058] [12 Regression] ICE in extract_insn, at recog.c:2770 since r12-1215-g8d7dae0eb366a88a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101058 --- Comment #10 from Jakub Jelinek --- And maybe for V2SImode too, though haven't verified that.
[Bug libstdc++/101055] [11/12 Regression] should use __has_cpp_attribute() with __ prefixed/suffixed names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101055 Jonathan Wakely changed: What|Removed |Added See Also||http://bugzilla.opensuse.or ||g/show_bug.cgi?id=1187254 --- Comment #6 from Jonathan Wakely --- N.B. this fixes a problem when using libstdc++ 11.1 headers with Clang 9, where the __has_cpp_attribute(no_unique_address) test was true, but the [[__no_unique_address__]] attribute was not recognized and so was ignored, resulting in layout changes for std::tuple.
[Bug libstdc++/101055] [11/12 Regression] should use __has_cpp_attribute() with __ prefixed/suffixed names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101055 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jonathan Wakely --- Fixed for 11.2
[Bug c++/101065] New: "internal compiler error: Segmentation fault signal terminated program cc1plus" when compiling some malformed code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101065
Bug ID: 101065
Summary: "internal compiler error: Segmentation fault signal
terminated program cc1plus" when compiling some
malformed code
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: 786246442 at qq dot com
Target Milestone: ---
A minified example is:
```
class A {public: class B;};
class C {public: typedef ::A A;
class A::B {};
```
Expected: g++ will return where the error in the code is
Actual:
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See <\usr\share\doc\gcc-10\README.Bugs> for instructions.
[Bug libstdc++/101056] std::compare_partial_order_fallback missing the constraint of "F < E is well-formed"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101056 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b76a529c095f076c4780df0c913cf6d2391bcbc9 commit r12-1425-gb76a529c095f076c4780df0c913cf6d2391bcbc9 Author: Jonathan Wakely Date: Mon Jun 14 12:30:52 2021 +0100 libstdc++: Implement LWG 3465 for std::compare_partial_order_fallback [PR101056] libstdc++-v3/ChangeLog: PR libstdc++/101056 * libsupc++/compare (compare_partial_order_fallback): Add constraint using reversed parameter order, as per LWG 3465. * testsuite/18_support/comparisons/algorithms/fallback.cc: Adjust expected result.
[Bug tree-optimization/100934] [9/10/11/12 Regression] wrong code at -O3 during unrolling since r9-6299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100934
--- Comment #10 from rguenther at suse dot de ---
On Mon, 14 Jun 2021, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100934
>
> --- Comment #9 from Jakub Jelinek ---
> (In reply to Richard Biener from comment #8)
> > --- a/gcc/tree-ssa-threadupdate.c
> > +++ b/gcc/tree-ssa-threadupdate.c
> > @@ -2379,12 +2379,15 @@ jump_thread_path_registry::duplicate_thread_path
> > (edge entry,
> > missuses of the functions. I.e. if you ask to copy something weird,
> > it will work, but the state of structures probably will not be
> > correct. */
> > + bool loop_header_duplicated = false;
> >for (i = 0; i < n_region; i++)
> > {
> >/* We do not handle subloops, i.e. all the blocks must belong to the
> > same loop. */
> >if (region[i]->loop_father != loop)
> > return false;
> > + if (region[i]->loop_father == loop)
> > + loop_header_duplicated = true;
>
> The if right above this returns false if loop_father is not loop, so
> wouldn't be loop_header_duplicated == true whenever n_region != 0 (or always)?
whoops yes, this should be region[i] == loop->header but as said the
issue is elsewhere (patch in testing) and the issue in
duplicate_thread_path does not have a testcase yet.
[Bug target/101058] [12 Regression] ICE in extract_insn, at recog.c:2770 since r12-1215-g8d7dae0eb366a88a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101058 --- Comment #9 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #8) > Though, when this *punpckwd define_insn_and_split handles all possible > constant permutations for V2HImode, shouldn't ix86_vectorize_vec_perm_const > say so: > case E_V2HImode: >if (!TARGET_SSE2) > return false; > + /* All implementable with *punpckwd. */ > + if (d.testing_p) > +return true; >break; > ? Yes, we can add this optimization. V2HImode is actually mentioned a couple of lines below, where it is claimed that it is fully implementable for one operand.
[Bug debug/101064] New: long compile time in var_tracking for Go package
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101064 Bug ID: 101064 Summary: long compile time in var_tracking for Go package Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: thanm at google dot com Target Milestone: --- Created attachment 51008 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51008=edit testcase to reproduce (Go files, some profile reports) Building the attached Go package with gccgo results in a very long compile time, apparently due to var_tracking. To reproduce, unpack the tar file and build with either: A) go clean -cache; go build . or B) gccgo -c -O2 -g -m64 -fgo-pkgpath=xyz ./aenum.go ./avx_optabs.go [Note: this issue is first posted on the main Go issue tracker at https://github.com/golang/go/issues/46600; more details there]. This is a fairly modest sized Go package; building it with the main (non-gcc) Go compiler takes about a third of a second (user + sys, reported by /bin/time). For gccgo, building with -O0 takes about a second, but the time taken at -O1 and -O2 are much longer: -O1: 450 seconds -O2: 257 seconds Along with the test case, I am attaching some profiles collected using 'pprof'. The pass consuming the extra compile time appears to be variable_tracking; from the profiles the problem looks to be related to alias analysis / memory disambiguation.
[Bug tree-optimization/100934] [9/10/11/12 Regression] wrong code at -O3 during unrolling since r9-6299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100934
--- Comment #9 from Jakub Jelinek ---
(In reply to Richard Biener from comment #8)
> --- a/gcc/tree-ssa-threadupdate.c
> +++ b/gcc/tree-ssa-threadupdate.c
> @@ -2379,12 +2379,15 @@ jump_thread_path_registry::duplicate_thread_path
> (edge entry,
> missuses of the functions. I.e. if you ask to copy something weird,
> it will work, but the state of structures probably will not be
> correct. */
> + bool loop_header_duplicated = false;
>for (i = 0; i < n_region; i++)
> {
>/* We do not handle subloops, i.e. all the blocks must belong to the
> same loop. */
>if (region[i]->loop_father != loop)
> return false;
> + if (region[i]->loop_father == loop)
> + loop_header_duplicated = true;
The if right above this returns false if loop_father is not loop, so
wouldn't be loop_header_duplicated == true whenever n_region != 0 (or always)?
[Bug tree-optimization/100934] [9/10/11/12 Regression] wrong code at -O3 during unrolling since r9-6299
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100934
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #8 from Richard Biener ---
(In reply to Jeffrey A. Law from comment #7)
> So when we're finding jump threads we know if we thread through the loop
> latch and we note when that's going to create an irreducible region. We
> generally suppress threading through the latch before the loop optimizers
> have run, but allow it afterwards.
>
> But I'm not aware of a really good place to adjust the loop bound estimates,
> particularly for the backwards threader. THe backwards threader uses
> copy_bbs API, so much of the guts of what's happening is opaque.
>
> Peek at jump_thread_path_registry:::duplicate_thread_path. All the
> backwards threader bits go through there at some point.
OK, so it looks like mark_threaded_blocks already has code to deal with this:
if (crossed_headers > 1)
{
vect_free_loop_info_assumptions
((*path)[path->length () - 1]->e->dest->loop_father);
break;
but mark_threaded_blocks is only called after we process all FSM paths though
it's handling of the case wouldn't necessarily fix this instance where we
just duplicate the loop header incoming its backedge and to one of its
destination still in the same loop.
It looks like applying the FSM threads goes through different code paths
than the regular threading...
But the issue at hand must be more subtle since invalidating the number of
iterations on the loop that is then removed of course doesn't change
anything. Still it is likely going to be an issue. Possible fix for that
but not this testcase:
diff --git a/gcc/tree-ssa-threadupdate.c b/gcc/tree-ssa-threadupdate.c
index a86302be18e..4e31fa8f5c2 100644
--- a/gcc/tree-ssa-threadupdate.c
+++ b/gcc/tree-ssa-threadupdate.c
@@ -2379,12 +2379,15 @@ jump_thread_path_registry::duplicate_thread_path (edge
entry,
missuses of the functions. I.e. if you ask to copy something weird,
it will work, but the state of structures probably will not be
correct. */
+ bool loop_header_duplicated = false;
for (i = 0; i < n_region; i++)
{
/* We do not handle subloops, i.e. all the blocks must belong to the
same loop. */
if (region[i]->loop_father != loop)
return false;
+ if (region[i]->loop_father == loop)
+ loop_header_duplicated = true;
}
initialize_original_copy_tables ();
@@ -2501,6 +2504,11 @@ jump_thread_path_registry::duplicate_thread_path (edge
entry,
/* Add the other PHI node arguments. */
add_phi_args_after_copy (region_copy, n_region, NULL);
+ /* Invalidate loop niter information if the loop header was part of the
+ thread path. */
+ if (loop_header_duplicated)
+vect_free_loop_info_assumptions (loop);
+
free (region_copy);
adjust_paths_after_duplication (current_path_no);
The actual issue seems to be that the DOM pass following the problematic
threading threads additional paths through loop headers which ends up
rotating the loop and also affecting niter estimates since it crosses
a irreducible region boundary. Ah - but we have _not_ marked irreducible
regions but we are querying them from DOM threading!
diff --git a/gcc/tree-ssa-dom.c b/gcc/tree-ssa-dom.c
index 075b1ccb9de..c231e6c8467 100644
--- a/gcc/tree-ssa-dom.c
+++ b/gcc/tree-ssa-dom.c
@@ -727,7 +727,8 @@ pass_dominator::execute (function *fun)
gcc.dg/tree-ssa/pr21417.c can't be threaded if loop preheader is
missing. We should improve jump threading in future then
LOOPS_HAVE_PREHEADERS won't be needed here. */
- loop_optimizer_init (LOOPS_HAVE_PREHEADERS | LOOPS_HAVE_SIMPLE_LATCHES);
+ loop_optimizer_init (LOOPS_HAVE_PREHEADERS | LOOPS_HAVE_SIMPLE_LATCHES
+ | LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS);
/* We need accurate information regarding back edges in the CFG
for jump threading; this may include back edges that are not part of
fixes the testcase.
[Bug c++/99910] [11/12 Regression] g++.dg/modules/xtreme-header-2_b.C ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99910 Christophe Lyon changed: What|Removed |Added Target|cris-elf|cris-elf armeb CC||clyon at gcc dot gnu.org --- Comment #4 from Christophe Lyon --- I've noticed FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2a (internal compiler error) on armeb (looks OK on arm) on gcc-11 branch. It appeared between r11-8552 and r11-8563.
[Bug middle-end/101063] #pragma STDC FENV_ACCESS ON: wrong code generation: instructions leading to side effects may not be generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101063 --- Comment #1 from Marc Glisse --- > Note 1: Under -Wall gcc generates warning: > :5: warning: ignoring '#pragma STDC FENV_ACCESS' [-Wunknown-pragmas] That seems like a huge hint, this is not implemented in gcc. You can find several existing PR in this bugzilla. There is a branch refs/users/glisse/heads/fenv that was kind of functional last time I tried, but I'll never have time to polish it.
[Bug target/101058] [12 Regression] ICE in extract_insn, at recog.c:2770 since r12-1215-g8d7dae0eb366a88a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101058 --- Comment #8 from Jakub Jelinek --- Though, when this *punpckwd define_insn_and_split handles all possible constant permutations for V2HImode, shouldn't ix86_vectorize_vec_perm_const say so: case E_V2HImode: if (!TARGET_SSE2) return false; + /* All implementable with *punpckwd. */ + if (d.testing_p) +return true; break; ?
[Bug target/101058] [12 Regression] ICE in extract_insn, at recog.c:2770 since r12-1215-g8d7dae0eb366a88a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101058 --- Comment #7 from Jakub Jelinek --- Sure, your patch looks much better.
[Bug target/101058] [12 Regression] ICE in extract_insn, at recog.c:2770 since r12-1215-g8d7dae0eb366a88a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101058 --- Comment #6 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #5) We can split directly to sse2_pshuflw_1, avoiding mmx_pshufw_1. These two actually generate the same instruction (PSHUFLW) when XMM registers are involved.
