[Bug other/11146] Bad characters can happen in cpp.1, gcc.1 man pages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11146 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #9 from Andrew Pinski --- podlators 2.1.0 (2008-06-01) Add a new utf8 option to Pod::Man. If set, do not convert non-ASCII characters to *roff escapes or X, and instead output literal UTF-8 characters. Add a new --utf8 option to pod2man. [Pod::Man] Match text between \f(CW and \fP or \fR in headings non-greedily to get the fonts right with multiple C<> formatting codes. [Pod::Man] Protect .Sh text against leading *roff control characters since some *roff implementations apparently "look through" font escapes at the beginning of lines. [Pod::Man] Escape backslashes separately from processing non-ASCII characters and do that, dash escaping, and underscore adjustment before processing non-ASCII characters. Otherwise, we escape the hyphen in eth characters. This was a bug in pod2man which was fixed in 2008 I think. Anyways I can't reproduce the original bug with the even the original .texi code back in which is why I am suspecting it was a pod2man issue.
[Bug tree-optimization/103802] [12 regression] recip-3.c fails after r12-6087 on Power m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103802
--- Comment #6 from luoxhu at gcc dot gnu.org ---
(In reply to Richard Biener from comment #5)
> So the point is that P is invariant but we do not hoist it because it's
> computed in a (estimated) cold block? I notice that the condition is
> invariant, too, so
> in principle we could hoist as
>
> if (d > 0.01)
> P = ( W < E ) ? (W - E)/d : (E - W)/d;
> for (i=0; i < 2; i++ )
> if( d > 0.01 )
> F[i] += P;
Yes. But this loop only iterates twice, so bbs in loop is colder than
preheader.
-funswitch-loops should move the condition out of loop, but also need increase
the loop iteration count:
"/home/luoxhu/workspace/gcc-master/gcc/testsuite/gcc.dg/tree-ssa/recip-3.c:16:14:
note: Not unswitching, loop is not expected to iterate"
>
> alternatively one might argue that invariant expressions (unconditionally
> computed or in a special way under invariant conditions) should be costed
> differently.
>
> I think best would be to restore the original intent of the testcase which
> was added with the fix for PRs 23109, 23948 and 24123. I suppose there
> we saw the invariant hoisted(?) and the loop unrolled so I would suggest
> to either apply the hoisting or the unrolling manually to the testcase.
> (just look at the PRs whether you get a better idea of the origin of the
> testcase).
To restore the original intent of the testcase, increase the loop count is
better than "either apply the hoisting or unrolling". Change it from "2" to at
least "5" will turn the cold bb to hot bb, then the two divides could be
hoisted out in LIM pass again(Verified below change could both pass on
power-m32 and x86-i686):
(It is much reasonable than the other two directions as loop iteration count is
not key for the test code.)
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/recip-3.c
b/gcc/testsuite/gcc.dg/tree-ssa/recip-3.c
index 641c91e..a1d2d87 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/recip-3.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/recip-3.c
@@ -1,7 +1,7 @@
/* { dg-do compile } */
/* { dg-options "-O1 -fno-trapping-math -funsafe-math-optimizations
-fdump-tree-recip" } */
-double F[2] = { 0.0, 0.0 }, e;
+double F[5] = { 0.0, 0.0 }, e;
/* In this case the optimization is interesting. */
float h ()
@@ -13,7 +13,7 @@ float h ()
d = 2.*e;
E = 1. - d;
- for( i=0; i < 2; i++ )
+ for( i=0; i < 5; i++ )
if( d > 0.01 )
{
P = ( W < E ) ? (W - E)/d : (E - W)/d;
@@ -23,4 +23,4 @@ float h ()
F[0] += E / d;
}
-/* { dg-final { scan-tree-dump-times " / " 5 "recip" } } */
+/* { dg-final { scan-tree-dump-times " / " 1 "recip" } } */
[Bug other/11146] Bad characters can happen in cpp.1, gcc.1 man pages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11146
--- Comment #8 from Andrew Pinski ---
So we were doing:
Define the macros @sc{__gnuc__}, @sc{__gnuc_minor__}
Where texi2pod.pl does:
s/\@sc\{([^\}]*)\}/\U$1/g;
Which should be fine. It should have replaced @sc{__gnuc__} with __GNUC__.
We do now:
cpp.texi:defines @code{__GNUC__} to @var{x}, @code{__GNUC_MINOR__} to @var{y},
texi2pod.pl does this for @code:
s/\@(?:code|kbd)\{([^\}]*)\}/C<$1>/g;
Note @sc is defined at:
https://www.gnu.org/software/texinfo/manual/texinfo/html_node/Smallcaps.html
I suspect this was a pod2man bug, looking into the perl source base to find
when the fix was included. There was some __ replacement rules in pod2man in
the recent versions of perl.
[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103931 Martin Liška changed: What|Removed |Added CC||aldot at gcc dot gnu.org, ||pault at gcc dot gnu.org --- Comment #8 from Martin Liška --- > the reduced testcase works in GCC 10.1.0, 10.2.0, 10.3.0, 11.1.0, and 11.2.0. > maybe there is some kind of memory issue even. I guess so as it's rejected with r12-5073-g8875a92d31329ae5 which is a memory leak fix. Note that before that it was accepted since r10-2912-g70570ec192745095.
[Bug tree-optimization/103797] Clang vectorized LightPixel while GCC does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103797 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug d/103840] d: Errors message: Please submit a full bug report in testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103840 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug tree-optimization/66502] SCCVN can't handle PHIs optimistically optimally
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66502 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.0
[Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug fortran/89639] FAIL: gfortran.dg/ieee/ieee_9.f90 -O0 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89639 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug analyzer/103526] -fanalyzer considers memcpy()ed and returned pointer to malloc()ed memory a memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103526 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug c++/78104] optimizer doesn't grok C++ new/delete yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78104 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.0
[Bug c++/53534] gcov erroneously reporting opening brace of constructor is never executed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53534 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=3187 Status|UNCONFIRMED |RESOLVED Target Milestone|--- |4.5.0 --- Comment #3 from Andrew Pinski --- This was actually fixed in GCC 4.5.0 which was released 2 years before this bug report was filed. It was fixed by r0-96945 (aka PR 3187).
[Bug c++/85775] False positive with -Wparentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85775 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-01-07 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/25751] Poor error when templating on undefined types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25751
--- Comment #5 from Andrew Pinski ---
Reduced testcase:
template struct gg{};
int main(void)
{
gg v;
v.begin();
}
[Bug c++/57632] Operator new overloads with stdc++11 enabled looses exception specifier (MacOsX)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57632 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- So the defect report against C++ was closed as not a defect: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#967 . The related one http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#1948 dealing with noexcept was also closed as not a defect. So GCC is correct, There is no bug here.
[Bug c++/103936] [12 Regression] ICE with cs[5]{}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103936 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #3 from Jason Merrill --- Fixed.
[Bug c++/65591] G++ should use default constructor for {}-init when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65591 --- Comment #6 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:765693be1c8dc91fe612e7a499c5e41ba398ab96 commit r12-6339-g765693be1c8dc91fe612e7a499c5e41ba398ab96 Author: Jason Merrill Date: Thu Jan 6 21:58:01 2022 -0500 c++: temporarily restore VEC_INIT_EXPR gimplify [PR103936] PR103936 demonstrates that some VEC_INIT_EXPR can still survive into GENERIC; until that's fixed let's put back the handling in cp_gimplify_expr. PR c++/103936 PR c++/65591 gcc/cp/ChangeLog: * cp-gimplify.c (cp_gimplify_expr): Restore VEC_INIT_EXPR handling. gcc/testsuite/ChangeLog: * g++.dg/init/aggr15.C: New test.
[Bug c++/103936] [12 Regression] ICE with cs[5]{}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103936 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:765693be1c8dc91fe612e7a499c5e41ba398ab96 commit r12-6339-g765693be1c8dc91fe612e7a499c5e41ba398ab96 Author: Jason Merrill Date: Thu Jan 6 21:58:01 2022 -0500 c++: temporarily restore VEC_INIT_EXPR gimplify [PR103936] PR103936 demonstrates that some VEC_INIT_EXPR can still survive into GENERIC; until that's fixed let's put back the handling in cp_gimplify_expr. PR c++/103936 PR c++/65591 gcc/cp/ChangeLog: * cp-gimplify.c (cp_gimplify_expr): Restore VEC_INIT_EXPR handling. gcc/testsuite/ChangeLog: * g++.dg/init/aggr15.C: New test.
[Bug libitm/61594] ICE (assertion failure) in trans-mem.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61594 Andrew Pinski changed: What|Removed |Added Known to fail||4.9.4 Last reconfirmed||2022-01-07 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Known to work||5.1.0 Keywords||ice-on-valid-code, ||needs-bisection --- Comment #8 from Andrew Pinski --- Seems to have been fixed in GCC 5+. Be interesting to see what revision fixed this.
[Bug other/51165] gcc.dg/tm/memopt-3.c failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51165 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug target/58124] ICE: in gen_split_2192, at config/i386/i386.md:3237 with -mtune-ctrl=zero_extend_with_and,partial_reg_stall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58124 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- .
[Bug c++/83426] template argument involves template parameters with implicit integral conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83426 Andrew Pinski changed: What|Removed |Added Keywords||needs-bisection Known to work||12.0 --- Comment #5 from Andrew Pinski --- This seems fixed on the trunk.
[Bug c++/83426] template argument involves template parameters with implicit integral conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83426 Andrew Pinski changed: What|Removed |Added Status|RESOLVED|NEW Resolution|DUPLICATE |--- --- Comment #4 from Andrew Pinski --- No this is a dup of bug 60679. I messed up.
[Bug c++/85515] Bogus suggestions from "GCC's leaky abstractions"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85515 Andrew Pinski changed: What|Removed |Added Keywords||accepts-invalid Known to fail||8.1.0, 8.2.0 Last reconfirmed||2022-01-07 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #9 from Andrew Pinski --- __for_begin was fixed for GCC 9. The lambda suggestion was fixed in GCC 8.3 but you can still access __val so confirmed.
[Bug c++/60679] [DR1647] class specialization not instantiated even though it is a better match than the primary template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60679 Andrew Pinski changed: What|Removed |Added CC||r...@klipp-lischner.net --- Comment #5 from Andrew Pinski --- *** Bug 83426 has been marked as a duplicate of this bug. ***
[Bug c++/83426] template argument involves template parameters with implicit integral conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83426 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 60679. *** This bug has been marked as a duplicate of bug 60679 ***
[Bug c++/60679] [DR1647] class specialization not instantiated even though it is a better match than the primary template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60679 Andrew Pinski changed: What|Removed |Added CC||ghabriel.nunes at hotmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 87108 has been marked as a duplicate of this bug. ***
[Bug c++/87108] Template partial specialization is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87108 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|SUSPENDED |RESOLVED --- Comment #7 from Andrew Pinski --- Just going to mark this as a dup of bug 60679 since the conversion with template specialization is recorded as that bug. *** This bug has been marked as a duplicate of bug 60679 ***
[Bug c++/60679] [DR1647] class specialization not instantiated even though it is a better match than the primary template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60679 --- Comment #3 from Andrew Pinski --- http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1647
[Bug c++/87108] Template partial specialization is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87108 Andrew Pinski changed: What|Removed |Added Depends on||60679 Status|NEW |SUSPENDED --- Comment #6 from Andrew Pinski --- Suspending as CWG 1647 is still active. And yes changing int to unsigned long in the reduced testcase makes the error go away. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60679 [Bug 60679] [DR1647] class specialization not instantiated even though it is a better match than the primary template
[Bug c++/60679] class specialization not instantiated even though it is a better match than the primary template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60679 Andrew Pinski changed: What|Removed |Added Status|NEW |SUSPENDED --- Comment #2 from Andrew Pinski --- yes it does look like that CWG which is still active so suspending.
[Bug c++/88176] Overload resolution chooses template non-member operator over non-template member operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88176 --- Comment #1 from Andrew Pinski --- This one is still rejected. clang also has the same problem.
[Bug c++/89563] decltype resolution doesn't terminate recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89563 --- Comment #2 from Andrew Pinski --- Note I notice clang has the same problem.
[Bug c++/89563] decltype resolution doesn't terminate recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89563 Andrew Pinski changed: What|Removed |Added Known to fail||10.3.0 Keywords||needs-bisection, ||rejects-valid Known to work||11.1.0 --- Comment #1 from Andrew Pinski --- GCC starts to accept the code in GCC 11.
[Bug middle-end/77608] missing protection on trivially detectable runtime buffer overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77608 Siddhesh Poyarekar changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #7 from Siddhesh Poyarekar --- I've posted a patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587698.html which returns the whole size of an object (that's a thing now, since __bos started handling negative offsets) if the offset is not a constant. It goes on top of the dynamic object sizes patchset. Volatile offsets will need more rework (basically delay the side effects check into tree-object-size), so I'll do that after all of these patches are through.
[Bug c++/86966] ICE (Segmentation fault) for an explicit specialization of a member class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86966
Andrew Pinski changed:
What|Removed |Added
Known to fail||4.4.7
Last reconfirmed|2018-08-15 00:00:00 |2022-1-6
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=86960
--- Comment #5 from Andrew Pinski ---
If we change the code slightly to:
template
struct S {
template
struct X { };
};
template<>
template<>
struct S<>::X<> { };
S<>::X<> x;
GCC does not ICE.
[Bug c++/84695] Missed opportunity to issue warning about override
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84695
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from Andrew Pinski ---
Clang has -Winconsistent-missing-override which is turned on by default and
provides the warning:
:8:7: warning: 'two' overrides a member function but is not marked
'override' [-Winconsistent-missing-override]
int two(int) { return 102; }
^
:4:15: note: overridden virtual function is here
virtual int two(int) { return 2; }
^
[Bug c++/80886] __builtin_constant_p magic has broken at some point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80886
--- Comment #2 from Andrew Pinski ---
This has nothing to do with __builtin_constant_p really.
Just GCC started to rejecting:
constexpr void *phardware {((void *) 0x1000)};
Starting in GCC 7; it was accepted before.
What is interesting is the __builtin_constant_p makes clang accept it but that
is a clang bug.
>This use appears to be documented
I don't think it was ever documented to be accepted this way but I could be
wrong.
[Bug c++/56936] gcc doesn't show non-required diagnostics in uninstantiated templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56936 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2022-01-07 Status|UNCONFIRMED |NEW --- Comment #5 from Andrew Pinski --- Confirmed.
[Bug c++/80662] libstdc++ basic_string casting oddity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80662 --- Comment #6 from Andrew Pinski --- (In reply to Jonathan Wakely from comment #5) > Reduced thanks to K-ballo: Hmm, clang compiles and gives: member While both GCC and ICC compiles and gives: non-member And MSVC rejects it with: (15): error C2593: 'operator <<' is ambiguous (10): note: could be 'void my_stream::operator <<(T)' with [ T=const char (&)[12] ] (6): note: or 'void operator <<(C &&,const T (&))' with [ C=my_stream, T=char [12] ] (15): note: while trying to match the argument list '(my_stream, const char [12])' This might be the first time I have seen all four compiler full on disagree for a testcase like this (with GCC and ICC agreeing).
[Bug c++/80841] Fails to match template specialization with polymorphic non-type template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80841 --- Comment #5 from Andrew Pinski --- For the original testcase, GCC accepts the code even for -std=c++17 starting with GCC 7.2.0 (and 8+) and rejected it in GCC 7.1.0 with: : In function 'int main()': :22:95: error: invalid use of incomplete type 'struct MaybeDestruct >' using result = typename MaybeDestruct>::result; ^~ :8:8: note: declaration of 'struct MaybeDestruct >' struct MaybeDestruct; ^ Which is how clang rejects it also for C++17 but accepts it for C++14. I have no idea what is correct really.
[Bug target/103753] Unoptimal avx2 V16HF vector insert to element 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103753 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |12.0 --- Comment #3 from Andrew Pinski --- Fixed.
[Bug target/103774] [i386] GCC should swap the arguments to certain functions to generate a single instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103774 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- Fixed so closing.
[Bug target/103774] [i386] GCC should swap the arguments to certain functions to generate a single instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103774 --- Comment #4 from Hongtao.liu --- Fixed in GCC12 by r12-6338
[Bug target/103753] Unoptimal avx2 V16HF vector insert to element 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103753 --- Comment #2 from Hongtao.liu --- Fixed in GCC12.
[Bug target/103753] Unoptimal avx2 V16HF vector insert to element 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103753 --- Comment #1 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:1f759dbdcddd5eae795da48f46edae274a431cbc commit r12-6337-g1f759dbdcddd5eae795da48f46edae274a431cbc Author: liuhongt Date: Wed Jan 5 15:26:18 2022 +0800 Optimize V16HF vector insert to element 0 for AVX2. gcc/ChangeLog: PR target/103753 * config/i386/i386-expand.c (ix86_expand_vector_set): Not use gen_avx2_pblendph_1 when elt == 0. * config/i386/sse.md (avx2_pblendph): Rename to .. (avx2_pblend_1).. this, and extend to V16HI. (*avx2_pblendw): Rename to .. (*avx2_pblend): .. this, and extend to V16HF. (avx2_pblendw): Rename to .. (*avx2_pblend): .. this, and extend to V16HF. (blendsuf): Removed. (sse4_1_pblend): Renamed to .. (sse4_1_pblend): .. this. gcc/testsuite/ChangeLog: * gcc.target/i386/pr103753.c: New test.
[Bug c++/67006] type-specifier const in declaration of anonymous union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67006
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=64644
--- Comment #1 from Andrew Pinski ---
Note the warning changed to an error in GCC 8:
:2:14: error: anonymous union with no members
const union {};
^
This was because of PR 64644.
[Bug c++/93816] invalid typedef name with class key accepted with template inbetween
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93816 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-07 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. B needs to be a template, otherwise GCC rejects it. It is as if GCC forgets that it was a not defined from a class/struct keyword. There are other issues in this area dealing with union which I need to finish up the patch for that.
[Bug c++/92385] extremely long and memory intensive compilation for brace construction of array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92385 --- Comment #12 from Jason Merrill --- *** Bug 65591 has been marked as a duplicate of this bug. ***
[Bug c++/65591] G++ should use default constructor for {}-init when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65591 Jason Merrill changed: What|Removed |Added Resolution|--- |DUPLICATE Status|SUSPENDED |RESOLVED --- Comment #5 from Jason Merrill --- Yes, this is fixed by r12-6326. And then broken again by r12-6329, which I'll address in the new PR. *** This bug has been marked as a duplicate of bug 92385 ***
[Bug c++/95724] error message could be improved in the cascading error case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95724
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Summary|bogue error : "expected '{' |error message could be
|before ')' token" |improved in the cascading
||error case
Ever confirmed|0 |1
Last reconfirmed||2022-01-07
Severity|normal |enhancement
--- Comment #8 from Andrew Pinski ---
I don't like the error messages from any of the other compilers I tried either:
clang:
:2:29: error: use of undeclared identifier 'a'
template <(union : decltype(a = 0)>)
^
:2:36: error: expected '{' after base class list
template <(union : decltype(a = 0)>)
^
:2:12: error: '(unnamed union at :2:12)' cannot be defined in a
parameter type
template <(union : decltype(a = 0)>)
^
:2:37: error: expected template parameter
template <(union : decltype(a = 0)>)
^
:2:37: error: expected ',' or '>' in template-parameter-list
:2:37: error: expected unqualified-id
MSVC:
(2): error C2059: syntax error: '('
(2): error C2947: expecting '>' to terminate template-parameter-list,
found '>'
(2): error C2059: syntax error: ')'
(3): fatal error C1004: unexpected end-of-file found
ICC:
(2): error: expected a type specifier
template <(union : decltype(a = 0)>)
^
(2): error: expected a "," or ">"
(2): error: expected a declaration
(2): error: expected a ";"
compilation aborted for (code 2)
[Bug libstdc++/80331] unused const std::string not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331 --- Comment #7 from Andrew Pinski --- With -std=c++20 -O2 I get better code than just -std=c++17 -O2: _34 = operator new (24); __builtin_memcpy (_34, "a ", 23); MEM[(char_type &)_34 + 23] = 0; operator delete (_34, 24); That is all I think due to what is referenced in PR 86590.
[Bug c++/78104] optimizer doesn't grok C++ new/delete yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78104 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Known to work||10.1.0 Known to fail||9.4.0 Resolution|--- |FIXED --- Comment #7 from Andrew Pinski --- Fixed in GCC 10. Dup 87732 is also fixed there.
[Bug libstdc++/80331] unused const std::string not optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80331 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-01-07 Resolution|DUPLICATE |--- Status|RESOLVED|NEW Ever confirmed|0 |1 --- Comment #6 from Andrew Pinski --- Reopening as it is not a dup of that one (though I think there is another bug about this one).
[Bug c++/93503] [9/10/11/12 Regression] Duplicated warning on pure virtual template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93503 --- Comment #3 from Andrew Pinski --- For the reduced testcase this is what clang produces: :3:5: error: 'virtual' cannot be specified on member function templates virtual int foo(int) = 0; ^~~~ :3:17: error: illegal initializer (only variables can be initialized) virtual int foo(int) = 0; ^ MSVC: (3): error C2898: 'int S::foo(int)': member function templates cannot be virtual (3): error C2187: syntax error: 'constant' was unexpected here (3): note: This diagnostic occurred in the compiler generated function 'int S::foo(int)' ICC: (3): error: "virtual" is not allowed in a function template declaration virtual int foo(int) = 0; ^ (3): error: expected a ";" virtual int foo(int) = 0; ^ Clang's error message is incorrect even because it says only variables can be initialized which is not true as virtual functions can be initilized to 0 so it can be considered a pure virtual. Maybe GCC's second error message could be changed to talk about pure virtual and such.
[Bug fortran/103898] [12 Regression] ICE: gimplification failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103898 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from sandra at gcc dot gnu.org --- Fixed.
[Bug c++/93503] [9/10/11/12 Regression] Duplicated warning on pure virtual template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93503
Andrew Pinski changed:
What|Removed |Added
Known to fail||12.0, 4.4.6
Target Milestone|--- |9.5
Known to work||4.1.2
Summary|Duplicated warning on pure |[9/10/11/12 Regression]
|virtual implicit template |Duplicated warning on pure
|in C++2a|virtual template
--- Comment #2 from Andrew Pinski ---
Even without concepts we have a duplicated error message:
struct S {
template
virtual int foo(int) = 0;
};
We once warn for the virtual and then again for the = 0 part.
GCC 4.1.2 just to produce just:
:3: error: invalid use of 'virtual' in template declaration of 'virtual
int S::foo(int)'
While GCC 4.4 and above produce:
:3: error: templates may not be 'virtual'
:3: error: templates may not be 'virtual'
So this is a regression even for the C++98 case.
[Bug fortran/103898] [12 Regression] ICE: gimplification failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103898 --- Comment #9 from CVS Commits --- The master branch has been updated by Sandra Loosemore : https://gcc.gnu.org/g:55385f12f604fe242030f0a8fb057598c0f187a6 commit r12-6336-g55385f12f604fe242030f0a8fb057598c0f187a6 Author: Sandra Loosemore Date: Thu Jan 6 11:23:18 2022 -0800 Fortran: Fix handling of optional argument to SIZE intrinsic [PR103898] This patch fixes a think-o in the code that triggered an ICE in the test case. 2021-01-06 Sandra Loosemore PR fortran/103898 gcc/fortran/ * trans-intrinsic.c (gfc_conv_intrinsic_size): Make size_var actually be a variable and fix surrounding code. gcc/testsuite/ * gfortran.dg/pr103898.f90: New test.
[Bug c++/65591] G++ should use default constructor for {}-init when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65591 --- Comment #4 from Andrew Pinski --- Note I thought the patch which fixes PR 92385 would fix this one but instead we are getting an ICE which I filed as PR 103936. I suspect after that is fixed this will also be fixed.
[Bug c++/103936] [12 Regression] ICE with cs[5]{}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103936 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=65591 --- Comment #1 from Andrew Pinski --- This was PR 65591 but I thought I file a seperate bug for the ICE which is new.
[Bug c++/103936] [12 Regression] ICE with cs[5]{}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103936 Andrew Pinski changed: What|Removed |Added CC||jason at gcc dot gnu.org Target Milestone|--- |12.0
[Bug c++/103936] New: [12 Regression] ICE with cs[5]{}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103936
Bug ID: 103936
Summary: [12 Regression] ICE with cs[5]{}
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: blocker
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
After r12-6326, we get an ICE for
struct ss {
ss() {};
};
struct C {
ss s[1000];
};
int main() {
C cs[5]{};
}
CUT
t.cc: In function ‘int main()’:
t.cc:9:15: internal compiler error: in gimplify_expr, at gimplify.c:15747
9 | C cs[5]{};
| ^
0x83bc3c gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/apinski/src/upstream-gcc/gcc/gcc/gimplify.c:15747
0xf1be86 gimplify_stmt(tree_node**, gimple**)
/home/apinski/src/upstream-gcc/gcc/gcc/gimplify.c:7026
0xf1eb30 gimplify_and_add(tree_node*, gimple**)
/home/apinski/src/upstream-gcc/gcc/gcc/gimplify.c:495
0xf1eb30 gimplify_init_ctor_eval
/home/apinski/src/upstream-gcc/gcc/gcc/gimplify.c:4857
0xf1f4c3 gimplify_init_constructor
/home/apinski/src/upstream-gcc/gcc/gcc/gimplify.c:5255
0xf2bd17 gimplify_modify_expr
/home/apinski/src/upstream-gcc/gcc/gcc/gimplify.c:5914
0xf19368 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/apinski/src/upstream-gcc/gcc/gcc/gimplify.c:14951
0xf2a137 gimplify_stmt(tree_node**, gimple**)
/home/apinski/src/upstream-gcc/gcc/gcc/gimplify.c:7026
0xf2a137 gimplify_compound_expr
/home/apinski/src/upstream-gcc/gcc/gcc/gimplify.c:6218
0xf199aa gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/apinski/src/upstream-gcc/gcc/gcc/gimplify.c:14941
0xf3d828 gimplify_stmt(tree_node**, gimple**)
/home/apinski/src/upstream-gcc/gcc/gcc/gimplify.c:7026
0xf3d828 gimplify_cleanup_point_expr
/home/apinski/src/upstream-gcc/gcc/gcc/gimplify.c:6766
0xf1993b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/apinski/src/upstream-gcc/gcc/gcc/gimplify.c:15344
0xf1be86 gimplify_stmt(tree_node**, gimple**)
/home/apinski/src/upstream-gcc/gcc/gcc/gimplify.c:7026
0xf1a5db gimplify_statement_list
/home/apinski/src/upstream-gcc/gcc/gcc/gimplify.c:2014
0xf1a5db gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/apinski/src/upstream-gcc/gcc/gcc/gimplify.c:15396
0xf1be86 gimplify_stmt(tree_node**, gimple**)
/home/apinski/src/upstream-gcc/gcc/gcc/gimplify.c:7026
0xf1a5db gimplify_statement_list
/home/apinski/src/upstream-gcc/gcc/gcc/gimplify.c:2014
0xf1a5db gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/home/apinski/src/upstream-gcc/gcc/gcc/gimplify.c:15396
0xf3d828 gimplify_stmt(tree_node**, gimple**)
/home/apinski/src/upstream-gcc/gcc/gcc/gimplify.c:7026
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/65591] G++ should use default constructor for {}-init when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65591 Bug 65591 depends on bug 65503, which changed state. Bug 65503 Summary: g++ string array in struct crash https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65503 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/92385] extremely long and memory intensive compilation for brace construction of array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92385 Andrew Pinski changed: What|Removed |Added CC||gpkiwi at msn dot com --- Comment #11 from Andrew Pinski --- *** Bug 65503 has been marked as a duplicate of this bug. ***
[Bug c++/65503] g++ string array in struct crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65503 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- Yes this is fixed after the patch for PR 92385 so closing as a dup. *** This bug has been marked as a duplicate of bug 92385 ***
[Bug c++/92385] extremely long and memory intensive compilation for brace construction of array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92385 Andrew Pinski changed: What|Removed |Added CC||gnu at kosak dot com --- Comment #10 from Andrew Pinski --- *** Bug 87680 has been marked as a duplicate of this bug. ***
[Bug c++/87680] Small program produces 160 meg .o file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87680
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW |RESOLVED
--- Comment #7 from Andrew Pinski ---
Yes this is fixed after the patch which fixes PR 92385.
We get now:
.LC0:
.long 10
.long 11
.long 12
.long 13
_3 = operator new (16000);
MEM[(struct Bar *)_3] = {};
MEM [(int *)_3] = { 10, 11, 12, 13 };
vectp.6_7 = _3 + 16;
ivtmp.12_16 = (unsigned long) vectp.6_7;
_9 = (unsigned long) _3;
_13 = _9 + 16000;
[local count: 106300463076]:
# ivtmp.12_18 = PHI
_8 = (void *) ivtmp.12_18;
MEM [(int *)_8] = { 10, 11, 12, 13 };
ivtmp.12_17 = ivtmp.12_18 + 16;
if (_13 == ivtmp.12_17)
goto ; [1.00%]
else
goto ; [99.00%]
*** This bug has been marked as a duplicate of bug 92385 ***
[Bug c++/103711] Virtual base destroyed twice when an exception is thrown in a derived class' constructor called from a delegated constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103711 Jason Merrill changed: What|Removed |Added Known to work||12.0 --- Comment #7 from Jason Merrill --- Fixed for GCC 12 so far. I plan to backport the fix to GCC 11 soon.
[Bug c++/61611] Incorrect exception rethrown from a function-try-catch block when a nested try-catch executes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61611 Jason Merrill changed: What|Removed |Added Target Milestone|--- |12.0 Known to work||12.0 --- Comment #3 from Jason Merrill --- Fixed for GCC 12 so far. Is there interest in having the fix in other release branches?
[Bug c++/66451] Array not fully destructed if element destructor throws exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66451 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.0 Status|ASSIGNED|RESOLVED --- Comment #3 from Jason Merrill --- Fixed for GCC 12.
[Bug c++/52320] missing destructor call after thrown exception in initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52320 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|10.0| Resolution|--- |FIXED Target Milestone|10.4|12.0 --- Comment #13 from Jason Merrill --- Fixed for GCC 12.
[Bug c++/94041] [10 Regression] temporary object destructor called before the end of the full-expression since r10-5577
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94041 Bug 94041 depends on bug 66139, which changed state. Bug 66139 Summary: destructor not called for members of partially constructed anonymous struct/array https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66139 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/93922] [10 Regression] Fails to emit inline class template destructor instantiation, but which is called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93922 Bug 93922 depends on bug 66139, which changed state. Bug 66139 Summary: destructor not called for members of partially constructed anonymous struct/array https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66139 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/93033] [10 Regression] error: incorrect sharing of tree nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033 Bug 93033 depends on bug 66139, which changed state. Bug 66139 Summary: destructor not called for members of partially constructed anonymous struct/array https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66139 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/66139] destructor not called for members of partially constructed anonymous struct/array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66139 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Known to work||12.0 Target Milestone|--- |12.0 Status|ASSIGNED|RESOLVED --- Comment #23 from Jason Merrill --- Fixed for GCC 12.
[Bug c++/103711] Virtual base destroyed twice when an exception is thrown in a derived class' constructor called from a delegated constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103711 --- Comment #6 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:32d8ff73718fd07a9a7dfd2566d3b7b69f37b6bd commit r12-6335-g32d8ff73718fd07a9a7dfd2566d3b7b69f37b6bd Author: Jason Merrill Date: Wed Jan 5 19:39:48 2022 -0500 c++: when delegating constructor throws [PR103711] We were always calling the complete destructor if the target constructor throws, even if we were calling the base constructor. PR c++/103711 gcc/cp/ChangeLog: * init.c (perform_target_ctor): Select destructor by in_chrg. gcc/testsuite/ChangeLog: * g++.dg/eh/delegating1.C: New test.
[Bug c++/61611] Incorrect exception rethrown from a function-try-catch block when a nested try-catch executes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61611 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:6ad76e73375a9c00a0a5f5729ae70bce7a6db5bc commit r12-6334-g6ad76e73375a9c00a0a5f5729ae70bce7a6db5bc Author: Jason Merrill Date: Thu Jan 6 09:45:26 2022 -0500 c++: nested catch in ctor fn-try-block [PR61611] Being in_function_try_handler isn't enough to satisfy the condition of reaching the end of such a handler; in this case, we're reaching the end of a handler within that handler, so we don't want the special semantics. PR c++/61611 gcc/cp/ChangeLog: * except.c (in_nested_catch): New. (expand_end_catch_block): Check it. gcc/testsuite/ChangeLog: * g++.dg/eh/ctor-fntry1.C: New test.
[Bug c++/33799] Return value's destructor not executed when a local variable's destructor throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33799 --- Comment #20 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b10e031458d541f794dfaa08ba606487603a4bb6 commit r12-6333-gb10e031458d541f794dfaa08ba606487603a4bb6 Author: Jason Merrill Date: Wed Jan 5 17:01:12 2022 -0500 c++: destroy retval on throwing cleanup in try [PR33799] My earlier attempt to fix this bug didn't handle the case where both the return and the throwing cleanup are within a try-block that catches and discards the exception. Fixed by adding the retval cleanup to any try-blocks as well as the function body. PR102191 pointed out that we also weren't handling templates properly, so I moved the call out of the parser. PR c++/33799 PR c++/102191 gcc/cp/ChangeLog: * except.c (maybe_splice_retval_cleanup): Check current_binding_level. * semantics.c (do_poplevel): Call it here. * parser.c (cp_parser_compound_statement): Not here. gcc/testsuite/ChangeLog: * g++.dg/eh/return1.C: Add temporary in try block case. * g++.dg/cpp2a/constexpr-dtor11.C: New test.
[Bug c++/102191] [C++20] Can't return prvalue with potentially-throwing destructor during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102191 --- Comment #1 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b10e031458d541f794dfaa08ba606487603a4bb6 commit r12-6333-gb10e031458d541f794dfaa08ba606487603a4bb6 Author: Jason Merrill Date: Wed Jan 5 17:01:12 2022 -0500 c++: destroy retval on throwing cleanup in try [PR33799] My earlier attempt to fix this bug didn't handle the case where both the return and the throwing cleanup are within a try-block that catches and discards the exception. Fixed by adding the retval cleanup to any try-blocks as well as the function body. PR102191 pointed out that we also weren't handling templates properly, so I moved the call out of the parser. PR c++/33799 PR c++/102191 gcc/cp/ChangeLog: * except.c (maybe_splice_retval_cleanup): Check current_binding_level. * semantics.c (do_poplevel): Call it here. * parser.c (cp_parser_compound_statement): Not here. gcc/testsuite/ChangeLog: * g++.dg/eh/return1.C: Add temporary in try block case. * g++.dg/cpp2a/constexpr-dtor11.C: New test.
[Bug c++/53868] Temporary for indirect binding is not destroyed when destructor from initializer temp throws
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53868 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:4c6afbbd48f0c40ddf949bc403d9bd5f5e14204f commit r12-6332-g4c6afbbd48f0c40ddf949bc403d9bd5f5e14204f Author: Jason Merrill Date: Wed Jan 5 11:18:25 2022 -0500 c++: clean up ref-extended temp on throwing dtor [PR53868] We have wrap_temporary_cleanups to handle the EH region nesting problems between cleanups for complete variables and cleanups for temporaries used in their construction, but we weren't calling it for temporaries extended from binding to a reference. We still don't want this for array cleanups (since my PR94041 fix), so I move that exception from initialize_local_var to wrap_temporary_cleanups. PR c++/53868 gcc/cp/ChangeLog: * decl.c (cp_finish_decl): Use wrap_temporary_cleanups for cleanups from set_up_extended_ref_temp. (wrap_temporary_cleanups): Ignore array cleanups. (initialize_local_var): Don't check for array here. * cp-tree.h (BIND_EXPR_VEC_DTOR): New. * init.c (build_vec_delete_1): Set it. gcc/testsuite/ChangeLog: * g++.dg/eh/ref-temp1.C: New test. * g++.dg/eh/ref-temp2.C: New test.
[Bug c++/66451] Array not fully destructed if element destructor throws exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66451 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2fbc45486e13facfeb05bd6ddf70ff9973a30a3c commit r12-6331-g2fbc45486e13facfeb05bd6ddf70ff9973a30a3c Author: Jason Merrill Date: Wed Jan 5 09:49:37 2022 -0500 c++: keep destroying array after one dtor throws [PR66451] When we're cleaning up an array, if one destructor throws, we should still try to clean up the rest of the array. We can use TRY_CATCH_EXPR for this, instead of a TARGET_EXPR like my other recent patches, because a destructor call can't involve any temporaries that need to live longer. I thought about only doing this when we call build_vec_delete_1 from build_vec_init, but it seems appropriate for delete-expressions as well; we've said that the array's lifetime is over, it makes sense to keep trying to destroy it. The standard isn't clear, but clang seems to agree with me. PR c++/66451 gcc/cp/ChangeLog: * init.c (build_vec_delete_1): Handle throwing dtor. (build_vec_init): Tell it we're in a cleanup already. gcc/testsuite/ChangeLog: * g++.dg/eh/array3.C: New test. * g++.dg/eh/array1.C: Mark destructor as throw(). * g++.dg/ipa/devirt-40.C: Likewise. * g++.dg/warn/pr83054.C: Likewise. * g++.dg/eh/delete1.C: Shorten array to one element.
[Bug c++/66139] destructor not called for members of partially constructed anonymous struct/array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66139 --- Comment #22 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:4f6bc28fc7dd86bd9e7408cbf28de1e973dd1eda commit r12-6329-g4f6bc28fc7dd86bd9e7408cbf28de1e973dd1eda Author: Jason Merrill Date: Thu Mar 5 15:50:45 2020 -0500 c++: EH and partially constructed aggr temp [PR66139] Now that PR94041 is fixed, I can return to addressing PR66139, missing cleanups for partially constructed aggregate temporaries. My previous approach of calling split_nonconstant_init in cp_gimplify_init_expr broke because gimplification is too late to be introducing destructor calls. So instead I now call it under cp_fold_function, just before cp_genericize; doing it from cp_genericize itself ran into trouble with the rewriting of invisible references. So now the prediction in cp_gimplify_expr that cp_gimplify_init_expr might need to replace references to TARGET_EXPR_SLOT within TARGET_EXPR_INITIAL has come to pass. constexpr.c already had the simple search-and-replace tree walk I needed, but it needed to be fixed to actually replace all occurrences instead of just the first one. Handling of VEC_INIT_EXPR at gimplify time had similar issues that we worked around with build_vec_init_elt, so I'm moving that to cp_fold_function as well. But it seems that build_vec_init_elt is still useful for setting the VEC_INIT_EXPR_IS_CONSTEXPR flag, so I'm leaving it alone. This also fixes 52320, because build_aggr_init of each X from build_vec_init builds an INIT_EXPR rather than call split_nonconstant_init at that point, and now that INIT_EXPR gets split later. PR c++/66139 PR c++/52320 gcc/cp/ChangeLog: * constexpr.c (replace_decl): Rename from replace_result_decl. * cp-tree.h (replace_decl): Declare it. * cp-gimplify.c (cp_gimplify_init_expr): Call it. (cp_gimplify_expr): Don't handle VEC_INIT_EXPR. (cp_genericize_init, cp_genericize_init_expr) (cp_genericize_target_expr): New. (cp_fold_r): Call them. * tree.c (build_array_copy): Add a TARGET_EXPR. * typeck2.c (digest_init_r): Look through a TARGET_EXPR. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist116.C: New test. * g++.dg/cpp0x/initlist117.C: New test. * g++.dg/cpp0x/lambda/lambda-eh.C: New test. * g++.dg/eh/aggregate1.C: New test.
[Bug c++/52320] missing destructor call after thrown exception in initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52320 --- Comment #12 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:4f6bc28fc7dd86bd9e7408cbf28de1e973dd1eda commit r12-6329-g4f6bc28fc7dd86bd9e7408cbf28de1e973dd1eda Author: Jason Merrill Date: Thu Mar 5 15:50:45 2020 -0500 c++: EH and partially constructed aggr temp [PR66139] Now that PR94041 is fixed, I can return to addressing PR66139, missing cleanups for partially constructed aggregate temporaries. My previous approach of calling split_nonconstant_init in cp_gimplify_init_expr broke because gimplification is too late to be introducing destructor calls. So instead I now call it under cp_fold_function, just before cp_genericize; doing it from cp_genericize itself ran into trouble with the rewriting of invisible references. So now the prediction in cp_gimplify_expr that cp_gimplify_init_expr might need to replace references to TARGET_EXPR_SLOT within TARGET_EXPR_INITIAL has come to pass. constexpr.c already had the simple search-and-replace tree walk I needed, but it needed to be fixed to actually replace all occurrences instead of just the first one. Handling of VEC_INIT_EXPR at gimplify time had similar issues that we worked around with build_vec_init_elt, so I'm moving that to cp_fold_function as well. But it seems that build_vec_init_elt is still useful for setting the VEC_INIT_EXPR_IS_CONSTEXPR flag, so I'm leaving it alone. This also fixes 52320, because build_aggr_init of each X from build_vec_init builds an INIT_EXPR rather than call split_nonconstant_init at that point, and now that INIT_EXPR gets split later. PR c++/66139 PR c++/52320 gcc/cp/ChangeLog: * constexpr.c (replace_decl): Rename from replace_result_decl. * cp-tree.h (replace_decl): Declare it. * cp-gimplify.c (cp_gimplify_init_expr): Call it. (cp_gimplify_expr): Don't handle VEC_INIT_EXPR. (cp_genericize_init, cp_genericize_init_expr) (cp_genericize_target_expr): New. (cp_fold_r): Call them. * tree.c (build_array_copy): Add a TARGET_EXPR. * typeck2.c (digest_init_r): Look through a TARGET_EXPR. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist116.C: New test. * g++.dg/cpp0x/initlist117.C: New test. * g++.dg/cpp0x/lambda/lambda-eh.C: New test. * g++.dg/eh/aggregate1.C: New test.
[Bug c++/94041] [10 Regression] temporary object destructor called before the end of the full-expression since r10-5577
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94041 --- Comment #8 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:beaee0a871b6485d20573fe050b1fd425581e56a commit r12-6328-gbeaee0a871b6485d20573fe050b1fd425581e56a Author: Jason Merrill Date: Sat Jan 1 16:00:22 2022 -0500 c++: temporary lifetime with array aggr init [PR94041] The previous patch fixed temporary lifetime for aggregate initialization of classes; this one extends that fix to arrays. This specifically reverses my r74790, the patch for PR12253, which was made wrong when these semantics were specified in DR201. Since the array cleanup region encloses the regions for any temporaries, we don't need to add an additional region for the array object itself in either initialize_local_var or split_nonconstant_init; we do, however, need to tell split_nonconstant_init how to disable the cleanup once an enclosing object is fully constructed, at which point we want to run that destructor instead. PR c++/94041 gcc/cp/ChangeLog: * decl.c (initialize_local_var): Fix comment. * init.c (build_new_1): Do stabilize array init. (build_vec_init): Use TARGET_EXPR for cleanup. Initialization of an element from an explicit initializer is not a full-expression. * tree.c (expand_vec_init_expr): Pass flags through. * typeck2.c (split_nonconstant_init_1): Handle VEC_INIT_EXPR. (split_nonconstant_init): Handle array cleanups. * cp-tree.h: Adjust. gcc/testsuite/ChangeLog: * g++.dg/init/array12.C: * g++.dg/init/aggr7-eh2.C: New test. * g++.dg/init/aggr7-eh3.C: New test.
[Bug c++/94041] [10 Regression] temporary object destructor called before the end of the full-expression since r10-5577
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94041 --- Comment #7 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ce0ab8fb46f07b0bde56aa31e46d57b81379fde3 commit r12-6327-gce0ab8fb46f07b0bde56aa31e46d57b81379fde3 Author: Jason Merrill Date: Thu Mar 5 15:50:45 2020 -0500 c++: temporary lifetime with aggregate init [PR94041] In C++98 the lifetime of temporaries in aggregate initialization was unclear, but C++11 DR201 clarified that only temporaries created for default-initialization of an array element with no corresponding initializer-clause are destroyed immediately; all others persist until the end of the full-expression. But we never implemented that, and continued treating individual element initializations as full-expressions, such as in my patch for PR50866 in r180442. This blocked my attempted fix for PR66139, which extended the use of split_nonconstant_init, and thus the bug, to aggregate initialization of temporaries within an expression. The longer temporary lifetime creates further EH region overlap problems like the ones that wrap_temporary_cleanups addresses: in aggr7.C, we start out with a normal nesting of A1 c.b1 A2 c.b2 ... ~A2 ~A1 where on the way in, throwing from one of the inits will clean up from the previous inits. But once c.b2 is initialized, throwing from ~A2 must not clean up c.b1; instead it needs to clean up c. So as in build_new_1, we deal with this by guarding the B cleanups with flags that are cleared once c is fully constructed; throwing from one of the ~A still hits that region, but does not call ~B. And then wrap_temporary_cleanups deals with calling ~C, but we need to tell it not to wrap the subobject cleanups. The change from expressing the subobject cleanups with CLEANUP_STMT to TARGET_EXPR was also necessary because we need them to collate with the ~A in gimplify_cleanup_point_expr; the CLEANUP_STMT representation only worked with treating subobject initializations as full-expressions. PR c++/94041 gcc/cp/ChangeLog: * decl.c (check_initializer): Remove obsolete comment. (wrap_cleanups_r): Don't wrap CLEANUP_EH_ONLY. (initialize_local_var): Change assert to test. * typeck2.c (maybe_push_temp_cleanup): New. (split_nonconstant_init_1): Use it. (split_nonconstant_init): Clear cleanup flags. gcc/testsuite/ChangeLog: * g++.dg/init/aggr7-eh.C: New test. * g++.dg/cpp0x/initlist122.C: Also test aggregate variable.
[Bug c++/92385] extremely long and memory intensive compilation for brace construction of array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92385
--- Comment #9 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:e948436eab818c527dd60b0ef939c4f42fbe8ba4
commit r12-6326-ge948436eab818c527dd60b0ef939c4f42fbe8ba4
Author: Jason Merrill
Date: Sat Jan 1 16:00:09 2022 -0500
c++: loop over array elts w/o explicit init [PR92385]
The PR complains that initializing a large array with {} takes a long time
to compile; this was because digest_init would turn {} into a long
CONSTRUCTOR with an initializer for each element, instead of more sensibly
generating a loop. The standard doesn't specify this implementation, but
it
does allow for it by specifying that a temporary created "when a default
constructor is called to initialize an element of an array with no
corresponding initializer" is destroyed "before the construction of the
next
array element, if any." rather than living until the end of the complete
object initialization as usual.
This change is also needed before the PR94041 fix extends the lifetime of
temporaries from elements with explicit initializers.
To implement this, I change digest_init so that in cases where
initialization of trailing array elements isn't constant, we return a
VEC_INIT_EXPR instead of a bare CONSTRUCTOR; when it is encountered later,
we call build_vec_init to generate the actual initialization code.
PR c++/92385
gcc/cp/ChangeLog:
* typeck2.c (PICFLAG_VEC_INIT): New.
(process_init_constructor_array): Set it.
(process_init_constructor): Handle it.
(split_nonconstant_init_1): Handle VEC_INIT_EXPR.
* init.c (build_vec_init): Likewise.
* cp-gimplify.c (cp_gimplify_expr): Factor out...
* tree.c (expand_vec_init_expr): ...this function.
(build_vec_init_elt): Handle BRACE_ENCLOSED_INITIALIZER_P.
(build_vec_init_expr): Likewise.
* constexpr.c (cxx_eval_vec_init): Likewise.
(reduced_constant_expression_p): Check arrays before C++20.
* cp-tree.h (expand_vec_init_expr): Declare.
gcc/testsuite/ChangeLog:
* g++.dg/init/array61.C: New test.
[Bug c++/90184] confusing diagnostic "attribute using prefix"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90184 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-01-07 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Confirmed, I didn't even know what using was pointing to. simple testcase: int e [[using gnu : aligned(alignof(int))]]; Anyways here is what clang reports: :1:9: warning: default scope specifier for attributes is a C++17 extension [-Wc++17-extensions] int e [[using gnu : aligned(alignof(int))]]; ^ Which I think is clang's is easier to understand.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #76 from Jonathan Wakely --- (In reply to cqwrteur from comment #74) > Also another patch on fixing freestanding C++ build There's a patch on PR 103866 to fix freestanding, but that's irrelevant to this bug. Please try to stay on topic and stop going off on tangents. There are already 76 comments here, and half of them are from you, and most of those are unnecessary or unhelpful. When you can't stop yourself from vomiting your stupid opinions all over bugzilla it makes it difficult and unpleasant to try and follow the bugs. And so less likely to get fixed.
[Bug sanitizer/89868] -fsanitize=address inhibits core dumps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89868 --- Comment #12 from Jonny Grant --- (In reply to Jakub Jelinek from comment #11) > The shadow maps are 1/8 of the address space, so I think that is 16TB. Ah ok, that explains it. Thank you.
[Bug libstdc++/100017] [11/12 regression] error: 'fenv_t' has not been declared in '::' -- canadian compilation fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #75 from cqwrteur --- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100427 https://gcc.gnu.org/pipermail/gcc-patches/2022-January/587838.html
[Bug c++/85782] acc loops with continue statements ICE in c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85782 Andrew Pinski changed: What|Removed |Added Known to work||8.2.0, 9.1.0 Status|UNCONFIRMED |RESOLVED Keywords||ice-on-valid-code Known to fail||8.1.0 Target Milestone|--- |8.2 Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- Fixed so closing as such.
[Bug c++/89048] function argument as a template argument in trailing return type error message could be better
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89048 Andrew Pinski changed: What|Removed |Added Keywords|rejects-valid | Summary|constant evaluation in |function argument as a |trailing return type|template argument in |rejected|trailing return type error ||message could be better Status|WAITING |NEW --- Comment #4 from Andrew Pinski --- Confirmed for the error message being not so helpful.
[Bug tree-optimization/103835] bogus sprintf warnings due to missing strlen propagation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103835
--- Comment #5 from Martin Sebor ---
It's the same cause. When the -Wformat-overflow and -truncation warnings are
unable to compute the exact length of a string argument to a directive like %s
they use the size of the array the string is stored in as a worst case estimate
(if they can determine the size of the array). In other words, they assume the
string is as long as fits in the array (minus 1 for the terminating nul). See
the example below. In simple cases specifying a precision (e.g., "%.4s") to
constrain the amount of output can be used to avoid the potential overflow and
suppress the warning. This is difficult to do with multiple string directives;
with those, using snprintf is the preferred alternative. To avoid the
-Wformat-truncation warning for the equivalent snprintf calls it's necessary to
check the function's return value.
The sprintf pass keeps a running total of the ranges of the bytes formatted by
each directive, and the warning tries to strike a balance between providing too
little and too much detail to understand why it triggers. This is tricky as
the range of total bytes on output includes the sum of more and more
directives. We discussed various approaches to improve this some time ago (see
pr77696) but didn't converge on one that made everyone happy.
$ cat a.c && gcc -O2 -S -Wall a.c
char a[8], b[8];
void f (void)
{
__builtin_sprintf (a, "%s%i", b, 123);
}
a.c: In function ‘f’:
a.c:5:28: warning: ‘%i’ directive writing 3 bytes into a region of size between
1 and 8 [-Wformat-overflow=]
5 | __builtin_sprintf (a, "%s%i", b, 123);
|^~
a.c:5:3: note: ‘__builtin_sprintf’ output between 4 and 11 bytes into a
destination of size 8
5 | __builtin_sprintf (a, "%s%i", b, 123);
| ^
The decision when to warn and when not is difficult. All these warnings depend
on various optimizations, and those are never perfect. The warnings make a few
basic assumptions (e.g., unreachable code is eliminated) and sometimes apply
heuristics like the string length above. Both of these can lead to false
positives in addition to false negatives.
[Bug c++/89048] constant evaluation in trailing return type rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89048
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #3 from Andrew Pinski ---
ICC gives:
(3): error: a parameter is not allowed
template constexpr auto f(F f) -> X { return {}; }
^
Which I think is a better error message than what GCC gives.
For the other case it is rejected at instaintation time.
That is take:
template struct X { };
template constexpr auto g(F f) { return X{}; }
constexpr int h(void) {return 0;}
int t = g(&h);
GCC error message is:
: In instantiation of 'constexpr auto g(F) [with F = int (*)()]':
:5:10: required from here
:3:61: error: 'f' is not a constant expression
3 | template constexpr auto g(F f) { return X{}; }
| ^
:3:57: note: in template argument for type 'int'
3 | template constexpr auto g(F f) { return X{}; }
|~^~
[Bug c++/88378] notes for template deduction errors mention "[with U = U]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88378 --- Comment #2 from Andrew Pinski --- That is we get: : In function 'void g(S)': :10:7: error: no matching function for call to 'S::f(int)' 10 | s.f (0); | ^~~ :5:8: note: candidate: 'template void S::f(U*&) [with T = int]' 5 | void f (U*&); |^ :5:8: note: template argument deduction/substitution failed: :10:7: note: mismatched types 'U*' and 'int' 10 | s.f (0); | ^~~
[Bug c++/88378] notes for template deduction errors mention "[with U = U]"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88378 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||needs-bisection Known to fail||10.1.0, 11.2.0, 9.1.0 Known to work||12.0 Last reconfirmed||2022-01-06 --- Comment #1 from Andrew Pinski --- Confirmed, Looks to be fixed on the trunk.
[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103931 --- Comment #7 from Andrew Pinski --- (In reply to Andrew Pinski from comment #6) > (In reply to Tomáš Trnka from comment #5) > > FWIW, this reduced testcase doesn't reproduce the bug (compiles cleanly) on > > my 11.2.1. > > But it does on the trunk, hmmm. the reduced testcase works in GCC 10.1.0, 10.2.0, 10.3.0, 11.1.0, and 11.2.0. maybe there is some kind of memory issue even.
[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103931 --- Comment #6 from Andrew Pinski --- (In reply to Tomáš Trnka from comment #5) > FWIW, this reduced testcase doesn't reproduce the bug (compiles cleanly) on > my 11.2.1. But it does on the trunk, hmmm.
[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103931 --- Comment #5 from Tomáš Trnka --- (In reply to anlauf from comment #2) > Created attachment 52138 [details] > Somewhat reduced reproducer > > The issue can be reproduced with a few less modules FWIW, this reduced testcase doesn't reproduce the bug (compiles cleanly) on my 11.2.1.
[Bug analyzer/103546] Analyzer reports null dereference in flex scanners
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103546 --- Comment #2 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:d564a83d14252d7db01381f71900b7a68357803b commit r12-6323-gd564a83d14252d7db01381f71900b7a68357803b Author: David Malcolm Date: Thu Jan 6 11:39:54 2022 -0500 analyzer: make use of may_be_aliased in alias detection [PR103546] Whilst debugging PR analyzer/103546 (false +ve in flex-generated lexers) I noticed that the analyzer was considering that writes through symbolic pointers could be treated as clobbering static globals such as: static YY_BUFFER_STATE * yy_buffer_stack = NULL; even for such variables that never have their address taken. This patch fixes this issue at least, so that the analyzer can preserve knowledge of such globals on code paths with writes through symbolic pointers. It does not fix the false +ve in the lexer code. gcc/analyzer/ChangeLog: PR analyzer/103546 * store.cc (store::eval_alias_1): Refactor handling of decl regions, adding a test for may_be_aliased, rejecting those for which it returns false. gcc/testsuite/ChangeLog: PR analyzer/103546 * gcc.dg/analyzer/aliasing-3.c: New test. Signed-off-by: David Malcolm
