[Bug c/101838] New: sizeof of struct with array of unspecified bound folded to constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101838
Bug ID: 101838
Summary: sizeof of struct with array of unspecified bound
folded to constant
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
Target Milestone: ---
In this example the size of is folded to zero:
int foo(struct { int z[*]; } v, int (*y)[sizeof v]);
c_vla_type_p should probably be replaced by C_VARIABLE_SIZE
in c_expr_sizeof_type.
[Bug c/29970] mixing ({...}) with VLA leads to massive breakage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29970 --- Comment #10 from CVS Commits --- The master branch has been updated by Martin Uecker : https://gcc.gnu.org/g:0631faf87a197145acd833249bf8f20a1c4aaabf commit r12-2830-g0631faf87a197145acd833249bf8f20a1c4aaabf Author: Martin Uecker Date: Tue Aug 10 07:42:51 2021 +0200 Evaluate arguments of sizeof that are structs of variable size. Evaluate arguments of sizeof for all types of variable size and not just for VLAs. This fixes some issues related to [PR29970] where statement expressions need to be evaluated so that the size is well defined. 2021-08-10 Martin Uecker gcc/c/ PR c/29970 * c-typeck.c (c_expr_sizeof_expr): Evaluate size expressions for structs of variable size. gcc/testsuite/ PR c/29970 * gcc.dg/vla-stexp-1.c: New test.
[Bug c++/95517] [coroutines] suggested warning when co_return and return_void() are missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95517 --- Comment #5 from Iain Sandoe --- (In reply to mengjun wei from comment #4) > GCC 11.2 no longer allow return_value and return_void be both defined, may > this restriction be removed? The restriction is part of the C++ standard (for the record, there was discussion about allowing both to be present, but that was rejected by the committee). https://eel.is/c++draft/dcl.fct.def.coroutine#6 So, we cannot remove the restriction.
[Bug c++/91873] -Wreturn-type diagnostic location changes depending on optimization level and destructor declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91873 --- Comment #3 from Dov Murik --- Looks related to bug #99938.
[Bug c++/101811] Error not helpful for misplaced 'template'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101811
--- Comment #2 from Tobias Schlüter ---
Hi Jonathan,
actually I found clang's error message a lot more helpful, I just didn't bother
to write it explicitly, especially given that my compiler explorer link shows
it for everybody else to make the same observation. Well, you came to a
different conclusion comparing the two and so I was wondering why I would find
clang's message more helpful and you didn't.
Here's clang's error message:
:6:9: error: out-of-line definition of 'f' does not match any
declaration in 'X'
void X::f()
^
:2:10: note: member declaration nearly matches
void f();
When I read that I know 1) there are two 'f's. 2) the one on line 6 doesn't
match the one on line 2. 3) yet it ought to match (the) one in 'struct X'. So
I as s user am left with wondering "how does it not match" which is sufficient
to resolve the problem.
Let me point to three things where gcc ends up making things harder to
understand in my opinion:
1) clang uses (almost) complete sentences. One doesn't have to figure out how
the parts of the error message relate to then form a logical whole from the set
of "error" and "note"s.
2) "candidate" in gcc's error message appears to be a technical term or a
gcc-specific term, one has to make sense of what it means from the context
("nothing matches -> oh, so this was a candidate for a match and this is what
'candidate' means here" whereas clang's error implies directly that the 'f' on
line 2 was really close to the one on line 6.
3) gcc's second note, which points to the struct declaration isn't really
helpful, it just floats in the ether for the user to make sense of. I would go
so far as to claim that it doesn't add any helpful information and thus does
more bad than good.
Anyway, I'm well aware that the C++ frontend unfortunately doesn't get much
developer attention, so I'm not writing these PRs to complain, but to give a
potential future FE developer a good starting point to get their hands dirty :)
[Bug tree-optimization/89163] Missed optimization: sar and shr equivalent for non-negative numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89163 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2019-02-04 00:00:00 |2021-8-9
[Bug tree-optimization/88854] redundant store after load that would makes aliasing UB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88854 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2019-01-15 00:00:00 |2021-8-9 Severity|normal |enhancement
[Bug tree-optimization/88844] poor range info for number of loop iterations with a known upper bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88844 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2019-01-15 00:00:00 |2021-8-9
[Bug tree-optimization/88314] range calculation of shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88314 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Depends on||96542 Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- Fixed by the patch which fixed PR 96542. See PR 96542 on the details but basically subranges are done now for some cases. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96542 [Bug 96542] Failure to optimize simple code to a constant when storing part of the operation in a variable
[Bug target/101804] float_vector_all_ones_operand should be used more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101804 --- Comment #2 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:3d7ccbc1efbd475031a9a4a6110c531f71fbf631 commit r12-2829-g3d7ccbc1efbd475031a9a4a6110c531f71fbf631 Author: H.J. Lu Date: Fri Aug 6 12:32:01 2021 -0700 x86: Optimize load of const FP all bits set vectors Check float_vector_all_ones_operand for vector floating-point modes to optimize load of const floating-point all bits set vectors. gcc/ PR target/101804 * config/i386/constraints.md (BC): Document for integer SSE constant all bits set operand. (BF): New constraint for const floating-point all bits set vectors. * config/i386/i386.c (standard_sse_constant_p): Likewise. (standard_sse_constant_opcode): Likewise. * config/i386/sse.md (sseconstm1): New mode attribute. (mov_internal): Replace BC with . gcc/testsuite/ PR target/101804 * gcc.target/i386/avx2-gather-2.c: Pass -march=skylake instead of "-mavx2 -mtune=skylake". Scan vpcmpeqd.
[Bug tree-optimization/88314] range calculation of shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88314 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Known to work||12.0 Known to fail||11.1.0
[Bug tree-optimization/87849] Missed optimization: useless for-loop must be eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87849 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2018-11-02 00:00:00 |2021-8-9 Severity|normal |enhancement
[Bug tree-optimization/83353] Missed optimization in math expression: sin(asin(a)) == a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83353 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2017-12-11 00:00:00 |2021-8-9
[Bug tree-optimization/83350] Missed optimization in math expression: missing cube of the sum formula
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83350 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2017-12-11 00:00:00 |2021-8-9 Severity|normal |enhancement
[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77899 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=94356 Severity|normal |enhancement --- Comment #11 from Andrew Pinski --- We just don't fold ptr < ptr that well: _1 = (sizetype) i_5(D); p_6 = [1] + _1; if ( [(void *) + 1B] > p_6) If we change d to be a pointer argument we get: p_5 = d_4(D) + 1; _1 = (sizetype) i_6(D); _10 = _1 + 1; p_7 = d_4(D) + _10; if (p_5 > p_7) goto ; [INV] else goto ; [INV] But that is PR 94356 (well if change pointer from type char to being int or something different).
[Bug c++/79249] Lambda call does not create exception handler.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79249 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Depends on||77369 Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- Fixed in GCC 8+, most likely by the patch which fixed PR 77369 . Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77369 [Bug 77369] incorrect noexcept specification deduction
[Bug c++/78754] incorrectly accepts non-deductible template parameter pack in function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78754 --- Comment #1 from Andrew Pinski --- clang, ICC and GCC all accept it. ICC warns though: (4): warning #2922: template parameter "Ts" cannot be used because it follows a parameter pack and cannot be deduced from the parameters of function template "foo" template ^ And MSVC errors out: (5): error C3547: template parameter 'Ts' cannot be used because it follows a template parameter pack and cannot be deduced from the function parameters of 'foo'
[Bug c++/69054] g++ fails to diagnose ambiguous overload resolution when implicit conversions are involved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69054 --- Comment #2 from Andrew Pinski --- If we change operator double to operator int, GCC is able to diagnostic the issue. So is this code valid or invalid?
[Bug c++/101367] [coroutines] destructor for capture in lambda temporary operand to co_yield expression called twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101367 --- Comment #5 from Noah Watkins --- Got it. Thanks for clarifying, I must have misinterpreted your earlier comment. On Mon, Aug 9, 2021 at 8:06 PM davidledger at live dot com.au wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101367 > > --- Comment #4 from David Ledger --- > Yeah, I'm just saying I suspect the problem was still there with the empty > capture list, its just not observable. > > -- > You are receiving this mail because: > You reported the bug.
[Bug c++/77935] uninstantiated template constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77935 Andrew Pinski changed: What|Removed |Added Depends on||82336 Resolution|--- |FIXED Known to work||4.7.4 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Fixed in GCC 7.4.0 by the patch which fixes PR 82336. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82336 [Bug 82336] [6 Regression] GCC requires but does not emit defaulted constructors in certain cases
[Bug c++/71113] Adding "const" to value in constexpr constructor places const object in .bss instead of .rodata
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71113 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-08-10 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug c++/71449] builtins accepted in default template arguments but rejected when explicitly specified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71449 --- Comment #3 from Andrew Pinski --- Note this is now accepted for C++11-C++20 and has since 4.6.
[Bug c++/94264] Array-to-pointer conversion not performed on array prvalues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94264 Andrew Pinski changed: What|Removed |Added CC||dchneric at gmail dot com --- Comment #2 from Andrew Pinski --- *** Bug 89931 has been marked as a duplicate of this bug. ***
[Bug c++/89931] Incorrect compiler error with temporary object used as function arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89931 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 94264. *** This bug has been marked as a duplicate of bug 94264 ***
[Bug c++/95517] [coroutines] suggested warning when co_return and return_void() are missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95517
mengjun wei changed:
What|Removed |Added
CC||wei_mj at 139 dot com
--- Comment #4 from mengjun wei ---
GCC 11.2 no longer allow return_value and return_void be both defined, may this
restriction be removed? This makes the co_return statement necessary:
CTask workflow_work(CTaskScheduler::RawPtr scheduler,
co_comm_ctx::co_comm_workflow* workflow, const char* buf, int len)
{
co_comm_resp_impl::ptr response(new co_comm_resp_impl);
co_await co_comm_ctx::short_req_task::create(workflow, 1, buf, len,
response);
co_await co_comm_ctx::short_req_task::create(workflow, 2, buf, len,
response);
co_await co_comm_ctx::resp_task::create(workflow,
response->result.c_str(), response->result.length());
co_return 0;
}
[Bug c++/100764] Internal compiler error when unable to deduce template parameter value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100764 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-08-10 --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug c++/87570] Rejects valid alias template usage (as a type pack size requirement)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87570 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-08-10 Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=56190 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/101367] [coroutines] destructor for capture in lambda temporary operand to co_yield expression called twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101367 --- Comment #4 from David Ledger --- Yeah, I'm just saying I suspect the problem was still there with the empty capture list, its just not observable.
[Bug c++/56190] GCC fails deducing a "void(*)(int, float, double)" to a "void(*)(T..., float, double)" with T={int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56190 Andrew Pinski changed: What|Removed |Added CC||mohsen.tamiz at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 69205 has been marked as a duplicate of this bug. ***
[Bug c++/69205] Place a variadic template in front of function parameter when it is known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69205
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED |RESOLVED
--- Comment #5 from Andrew Pinski ---
Note I think I might have reduced it too far.
Here is one which at least removes std::string usage:
#include
struct string1{};
using namespace std;
template
void print_action(function action_factory)
{}
int main(int argc, char *argv[])
{
print_action(function());
return 0;
}
-- CUT -
This works on ICC, clang and MSVC.
Still fails on the trunk.
And this is a dup of bug 56190.
*** This bug has been marked as a duplicate of bug 56190 ***
[Bug c++/59716] variadic template multiple parameter pack expansion fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59716 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |7.4
[Bug c++/60799] access checking within injected friend functions does not happen in the context of the enclosing class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60799 --- Comment #6 from Andrew Pinski --- GCC, ICC and MSVC all rejects this with is private error.
[Bug c++/69500] friend of enclosed class not allowed access to private move method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69500 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |9.0 Status|NEW |RESOLVED --- Comment #1 from Andrew Pinski --- Fixed in GCC 9+.
[Bug c++/68888] No Warning when converting an array of a subclass to its parent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Severity|normal |enhancement
[Bug c++/59716] variadic template multiple parameter pack expansion fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59716 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- Fixed in GCC 7.4.0+ and GCC 8+.
[Bug analyzer/101837] New: ICE with -O3 -fsanitize=undefined -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101837 Bug ID: 101837 Summary: ICE with -O3 -fsanitize=undefined -fanalyzer Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: eggert at cs dot ucla.edu Target Milestone: --- Created attachment 51283 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51283=edit Compile with "-O3 -fsanitize=undefined -fanalyzer -S" to reproduce the ICE While building the time zone code I got an internal compiler error. This is with cc (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1) on Fedora 34 x86-64. Compile the attached program u.c with: cc -O3 -fsanitize=undefined -fanalyzer -S u.i I briefly attempted to simplify u.c but the simplifications made the compiler error go away.
[Bug c++/66590] switch statement: incorrect warning "reaches end of non-void function"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66590
Andrew Pinski changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #7 from Andrew Pinski ---
I have a patch.
diff --git a/gcc/cp/cp-objcp-common.c b/gcc/cp/cp-objcp-common.c
index beef0123b04..43888507b85 100644
--- a/gcc/cp/cp-objcp-common.c
+++ b/gcc/cp/cp-objcp-common.c
@@ -317,6 +317,15 @@ cxx_block_may_fallthru (const_tree stmt)
return true;
return block_may_fallthru (ELSE_CLAUSE (stmt));
+case CLEANUP_STMT:
+ /* Just handle the try/finally cases. */
+ if (!CLEANUP_EH_ONLY (stmt))
+ {
+ return (block_may_fallthru (CLEANUP_BODY (stmt))
+ && block_may_fallthru (CLEANUP_EXPR (stmt)));
+ }
+ return true;
+
default:
return c_block_may_fallthru (stmt);
}
[Bug tree-optimization/101830] [12 Regression] Incorrect error messages beginning with r12-2591 (backward jump threader)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101830 --- Comment #4 from Segher Boessenkool --- (In reply to Bill Schmidt from comment #0) > (1) linebuf and pos are global variables, and the compiler cannot tell > whether or not there are problems with array bounds accesses here. Indeed, > pos is only incremented by a function called "safe_inc_pos" that ensures we > *don't* ever access beyond the end of linebuf. Most warnings are heuristic, largely by need, and this is true here as well. -Werror is a terrible idea. You can use it during development if you don't trust the programmers (which might be yourself) will see the messages, but otherwise it is just a destructive hindrance. That said... > (2) The error message is far too certain of itself! It says that we have > definitely addressed out of bounds when that is certainly not known to be > true. And its language claims it is even more certain that this was linepos+1024, which you say can never be true? It is possible there is some other bug in your program, which combined with aggressive optimisations elsewhere gives the access to that address, but :-/ (Looking at -fdump-tree-all-all dumps should tell). More likely is the heuristic just gets the wrong result. This happens so often that this warning does not belong in -Wall, and not even in -W (since there is no simple workaround for it at all, not even any reliable workaround). And yes, whenever some warning includes any heuristic (i.e. almost all warnings), the warning message should not say "is wrong". Diagnostics should never lie. Not ever. This used to be a big strength of GCC's diagnostics. All such messages should say something like "may be wrong". This is a much nicer, more respectful way to talk to the compiler user anyway, even if it could not be wrong :-) > This is holding up committing some approved patches, so I appreciate > anything you can do to sort this out. Configure with --disable-werror if you want more sanity. Of course people will then be angry with you if you commit something that triggers something bad :-/ Maybe that builds character?
[Bug c/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 --- Comment #3 from Kees Cook --- Eww. That means _FORTIFY_SOURCE doesn't work correctly. Can there please be a -fstrict-flex-arrays or something to turn off all the heuristics so a code base can declare it only uses flex arrays for dynamic trailing objects?
[Bug c++/66590] switch statement: incorrect warning "reaches end of non-void function"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66590
--- Comment #6 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #5)
> Oh yes this issue:
> case 1: { A tmp; return 1; } break;
Which was PR 20681 but that didn't handle this case.
[Bug c++/66590] switch statement: incorrect warning "reaches end of non-void function"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66590
--- Comment #5 from Andrew Pinski ---
Oh yes this issue:
case 1: { A tmp; return 1; } break;
[Bug c++/66590] switch statement: incorrect warning "reaches end of non-void function"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66590
--- Comment #4 from Andrew Pinski ---
This is what we have now:
;; Function f (_Z1fi, funcdef_no=0, decl_uid=2362, cgraph_uid=1,
symbol_order=0)
Removing basic block 6
Removing basic block 8
Merging blocks 3 and 4
Removing basic block 11
Merging blocks 12 and 14
Merging blocks 3 and 5
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2 3 4 5 6 7 8 9
;; 2 succs { 4 3 }
;; 3 succs { 5 }
;; 4 succs { 5 }
;; 5 succs { 8 6 }
;; 6 succs { 7 }
;; 7 succs { 1 }
;; 8 succs { 9 }
;; 9 succs { 1 }
int f (int x)
{
int finally_tmp.0;
struct A tmp;
struct A a;
int D.2384;
:
if (x == 1)
goto ; [INV]
else
goto ; [INV]
:
:
D.2384 = 1;
A::~A ();
tmp = {CLOBBER};
finally_tmp.0 = 0;
goto ; [INV]
:
:
D.2384 = 0;
finally_tmp.0 = 0;
:
A::~A ();
if (finally_tmp.0 == 1)
goto ; [INV]
else
goto ; [INV]
:
:
:
a = {CLOBBER};
return;
:
a = {CLOBBER};
:
:
return D.2384;
}
Looks like there was a case where we thought finally_tmp.0 could be equal to 1.
Note this is all internal.
[Bug c++/25689] missed diagnostic about assignment used as truth value.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25689 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2014-10-12 00:00:00 |2021-8-9 Severity|minor |enhancement
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 71222, which changed state. Bug 71222 Summary: [concepts] ill-formed code taking the address of a function concept not rejected https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71222 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/71222] [concepts] ill-formed code taking the address of a function concept not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71222 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Andrew Pinski --- Fixed in GCC 10+
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 79711, which changed state. Bug 79711 Summary: [concepts] ICE in instantiate_decl, at cp/pt.c:22474 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79711 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/71222] [concepts] ill-formed code taking the address of a function concept not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71222 Andrew Pinski changed: What|Removed |Added CC||hstong at ca dot ibm.com --- Comment #2 from Andrew Pinski --- *** Bug 79711 has been marked as a duplicate of this bug. ***
[Bug c++/79711] [concepts] ICE in instantiate_decl, at cp/pt.c:22474
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79711 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 71222. *** This bug has been marked as a duplicate of bug 71222 ***
[Bug c++/86385] calling wrong constructors?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86385 Andrew Pinski changed: What|Removed |Added CC||st at quanttec dot com --- Comment #4 from Andrew Pinski --- *** Bug 92467 has been marked as a duplicate of this bug. ***
[Bug c++/92467] gcc miscompiles ternary expression with omitted first operand ?: involving C++ prvalues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92467 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- Dup of bug 86385. *** This bug has been marked as a duplicate of bug 86385 ***
[Bug c++/57846] CRTP, templates, metaprogramming, forwarding and static member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57846 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=83160 --- Comment #4 from Andrew Pinski --- Fixed in GCC 8, most likely by the patch which fixed PR 83160.
[Bug c++/63515] Deduced number of parameters can be deduced from unrelated type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63515
--- Comment #4 from Andrew Pinski ---
The shorter example works in C++17 mode in GCC 7+. It is still rejected in
C++11 and C++14 (hitting the assert).
clang accepts the shorter example in all modes.
ICC rejects it with the assert in all modes.
MSVC accepts it in at least C++latest mode (I did not try others).
The original example fails in C++17 mode still (and gives the same error
message as C++14 mode):
: In instantiation of 'struct CurriedImpl<-894, std::function, int, int>':
:16:8: recursively required from 'struct CurriedImpl<-2,
std::function, int, int>'
:16:8: required from 'struct CurriedImpl<-1, std::function, int, int>'
/opt/compiler-explorer/gcc-trunk-20210809/include/c++/12.0.0/type_traits:2924:69:
required by substitution of 'template static std::true_type
std::__is_invocable_impl, int, int>&, int, int>, int, false,
void>::_S_test(int) [with _Tp = int; = ]'
/opt/compiler-explorer/gcc-trunk-20210809/include/c++/12.0.0/type_traits:2933:42:
required from 'struct
std::__is_invocable_impl, int, int>&, int, int>, int, false, void>'
/opt/compiler-explorer/gcc-trunk-20210809/include/c++/12.0.0/bits/std_function.h:334:9:
required from 'struct std::function::_Callable, int, int>, std::__invoke_result, int, int>&, int, int> >'
/opt/compiler-explorer/gcc-trunk-20210809/include/c++/12.0.0/bits/std_function.h:344:8:
required by substitution of 'template
template using _Requires = typename
std::enable_if<_Cond::value, _Tp>::type [with _Cond = std::function::_Callable, int, int>,
std::__invoke_result, int, int>&,
int, int> >; _Tp = void; _Res = int; _ArgTypes = {int, int}]'
/opt/compiler-explorer/gcc-trunk-20210809/include/c++/12.0.0/bits/std_function.h:413:9:
required by substitution of 'template
std::function::function(_Functor) [with _Functor =
CurriedImpl<1, std::function, int, int>;
= void; = ]'
:25:17: required from 'CurriedImpl<(Depth - 1), F, Args ...>
CurriedImpl::operator()(const First&) [with First = int; int
Depth = 1; F = std::function; Args = {int, int}]'
:49:9: required from here
:16:8: fatal error: template instantiation depth exceeds maximum of 900
(use '-ftemplate-depth=' to increase the maximum)
16 | struct CurriedImpl : public CurriedImpl
|^~~
clang accepts it in C++11-C++20 modes.
ICC hits assert.
MSVC hits the recursiveness.
[Bug c++/62202] g++ does not accept typedef-name after struct even if -fpermissive is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62202 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- C is not C++ :). Note for the C front-end we do warn if you have -Wc++-compat on there (since 4.5.0 which was released over 11 years ago): :4:16: warning: using 'test_t' as both a typedef and a tag is invalid in C++ [-Wc++-compat] 4 | typedef struct test_t* something_t; |^~ :3:23: note: originally defined here 3 | typedef struct test_s test_t; | ^~ Since we already have an option to warn about this in the C front-end, I am just close this as won't fix.
[Bug c++/52959] Missing typo suggestions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52959 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2014-08-20 00:00:00 |2021-8-9 Keywords||diagnostic
[Bug c++/53822] spell out typedefs in ambiguous call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53822 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/53822] spell out typedefs in ambiguous call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53822 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2013-04-16 00:00:00 |2021-8-9 --- Comment #8 from Andrew Pinski --- clang does not even print out the argument type :). NOTE that is actually worse. ICC and MSVC both print out the typedef name.
[Bug c/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 --- Comment #2 from Andrew Pinski --- See PR 44386.
[Bug c/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 --- Comment #1 from Andrew Pinski --- GCC treats all trailing arrays no matter what their size as flexible sized arrays. This is by design because of many code out there assumes that.
[Bug c++/64758] [C++11] Give better error message when name of enum's base type cannot be resolved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64758
--- Comment #2 from Andrew Pinski ---
It got worse (maybe better) in GCC 9.4.0 and 10+:
:3:14: error: found ':' in nested-name-specifier, expected '::'
3 | enum Waldo : uint32_t { // oops, forgot to include
| ^
| ::
:3:8: error: 'Waldo' has not been declared
3 | enum Waldo : uint32_t { // oops, forgot to include
|^
:3:25: error: expected unqualified-id before '{' token
3 | enum Waldo : uint32_t { // oops, forgot to include
| ^
[Bug c/101836] New: __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836
Bug ID: 101836
Summary: __builtin_object_size(P->M, 1) where M is an array and
the last member of a struct fails
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: kees at outflux dot net
Target Milestone: ---
Created attachment 51282
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51282=edit
struct layout changes bos1 behavior
When bos1 is used on a member who is both an array and at the end of a
structure, it fails to correctly resolve. This kind of behavior should only
happen for flexible array members:
struct trailing_array {
int a;
int b;
unsigned char c[16];
};
struct middle_array {
int a;
unsigned char c[16];
int b;
};
ok: sizeof(*working) == 24
ok: sizeof(working->c) == 16
ok: __builtin_object_size(working, 1) == -1
ok: __builtin_object_size(working->c, 1) == 16
ok: sizeof(*broken) == 24
ok: sizeof(broken->c) == 16
ok: __builtin_object_size(broken, 1) == -1
WAT: __builtin_object_size(broken->c, 1) == -1 (expected 16)
[Bug fortran/101835] New: Fortran 128-bit float support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101835 Bug ID: 101835 Summary: Fortran 128-bit float support Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org Target Milestone: --- Per discussion here https://gcc.gnu.org/pipermail/fortran/2021-August/056334.html there seems to be some confusion in the Fortran front end re gfc_real16_is_float128 and gfc_float128_type_node. The C __float128 type must correspond to an IEEE representation and that isn't being checked where those variables are being set. In cases where __float128 interoperability is required, it should be using float128_type_node with some additional check to make sure Fortran recognizes that mode (as in the patch for c_float128 and c_float128_complex attached to the mail linked above). In cases where all that matters is that it's kind=16 and not the same kind as long double, it would be less confusing to rename gfc_float128_type_node to gfc_real16_type_node. Also, note that on PowerPC there are 3 different 128-bit float modes, and the one that is defined to have precision 128 is the explicit IBM encoding, not IEEE, so the check for mode_precision == 128 in gfc_build_real_type is guaranteed not to find the __float128 equivalent on that target. (The long double size on that target is configurable by command-line option but I don't know what actually makes sense from an ABI/CPU support point of view; it's at least conceivable that it could trip over that test, though.)
[Bug c++/44521] unhelpful candidates for ambiguous lookup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44521 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2014-08-21 00:00:00 |2021-8-9
[Bug c++/52099] Incorrectly applying conversion when catching pointer-to-members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52099
--- Comment #4 from Jonathan Wakely ---
Further discussion from PR 67772:
Consider:
namespace std { struct type_info {}; }
struct A {};
auto x = typeid(void(A::*)() const);
Clang emits the type info as:
_ZTIM1AKFvvE:
.quad _ZTVN10__cxxabiv129__pointer_to_member_type_infoE+16
.quad _ZTSM1AKFvvE
.long 0 # 0x0
.zero 4
.quad _ZTIKFvvE
.quad _ZTI1A
GCC emits it as:
_ZTIM1AKFvvE:
.quad _ZTVN10__cxxabiv129__pointer_to_member_type_infoE+16
.quad _ZTSM1AKFvvE
.long 0
.zero 4
.quad _ZTIFvvE
.quad _ZTI1A
It appears that Clang is correct here; the 'const' in this case is not a
qualifier, so should not be removed when forming the pointee type_info. If GCC
really did think this was a const qualifier applied to a function type, it
would be emitting the wrong flags (should be .long 1, not .long 0 in that
case).
This translates into a wrong-code bug in a case like this:
struct A;
extern "C" void puts(const char*);
int main() {
try {
throw (void(A::*)())0;
} catch (void (A::*)() const) {
puts("bad catch");
}
}
... where GCC erroneously catches a pointer to non-const member function as a
pointer to const member function.
[Bug c++/66108] incorrect cv-qualification deduction on conversion operator template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66108 --- Comment #2 from Andrew Pinski --- GCC, clang, ICC and MSVC all produce cause the static_assert to happen.
[Bug c++/23257] Incorrect exception-handling behavior with references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23257 --- Comment #8 from Jonathan Wakely --- LLVM's libc++abi.so gives the same result, because it's a property of the Itanium ABI not GCC's implementation of it.
[Bug c++/63217] template conversion operator returning const reference not used for conversion in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63217
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=85250
Last reconfirmed|2017-01-08 00:00:00 |2021-8-9
--- Comment #5 from Andrew Pinski ---
Here is a C++98 version which shows this has always been rejected (well at
least since 4.1.2):
struct foo {
template
operator const T & () { static T t =0; return t;}
};
int t = foo();
[Bug c++/85576] A template union containing a friend function causes non-template type used as a template error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85576 --- Comment #2 from Andrew Pinski --- Looks fixed in GCC 11+.
[Bug c++/93809] bogus error class tag used in naming union on typedef typename ::U U2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93809 Andrew Pinski changed: What|Removed |Added CC||haoxintu at gmail dot com --- Comment #3 from Andrew Pinski --- *** Bug 96145 has been marked as a duplicate of this bug. ***
[Bug c++/96145] Weird output in compiling a typedef union as a function return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96145 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 93809. *** This bug has been marked as a duplicate of bug 93809 ***
[Bug c++/93809] bogus error class tag used in naming union on typedef typename ::U U2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93809 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-08-09 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug c++/83469] union is not accepted as a valid class-key in template name resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83469
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2021-08-09
Keywords||accepts-invalid,
||rejects-valid
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #2 from Andrew Pinski ---
Confirmed.
here is an example where we should reject it instead:
struct S {
union U { int m; };
};
template
void f()
{ struct T::U u; }
int
main()
{
f();
}
[Bug c++/80943] [DR2327] Conversion function selected in list-initialization in C++1z mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80943 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-08-09 Summary|Conversion function |[DR2327] Conversion |selected in |function selected in |list-initialization in |list-initialization in |C++1z mode |C++1z mode Ever confirmed|0 |1 Status|UNCONFIRMED |SUSPENDED --- Comment #4 from Andrew Pinski --- (In reply to Barry Revzin from comment #3) > This is CWG 2327 > (http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2327). > > It's still active, but gcc/clang's behavior (printing 2) seems like the > superior choice. Suspending then.
[Bug c++/83447] parameter after function parameter pack gets improperly deduced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83447 --- Comment #1 from Andrew Pinski --- GCC, ICC and clang all accept this code.
[Bug c++/80943] Conversion function selected in list-initialization in C++1z mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80943 --- Comment #3 from Barry Revzin --- This is CWG 2327 (http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#2327). It's still active, but gcc/clang's behavior (printing 2) seems like the superior choice.
[Bug c++/83000] Constraints for union-templates do not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83000 Andrew Pinski changed: What|Removed |Added Known to work||10.1.0 Keywords||accepts-invalid --- Comment #2 from Andrew Pinski --- Seems fixed in GCC 10.
[Bug c++/80943] Conversion function selected in list-initialization in C++1z mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80943 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86521 --- Comment #2 from Andrew Pinski --- GCC 8.1.0-8.3.0 selected the one which printed 1 for C++17. GCC 8.4.0 and GCC 9+ all select the one which prints 2 for C++17. GCC 7.x all print 2. clang also prints 2 for C++17 and 1 for C++14. ICC prints 1 for both C++14 and C++17. See related to PR 86521 . Maybe someone with better understanding of the differences between C++14 and C++17 than I can help here. It is definitely related to C++17 mandatory of copy elision.
[Bug c++/80804] Default constructor improperly invoked in C++1z mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80804 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Known to fail||7.5.0 Target Milestone|--- |8.0 Known to work||8.1.0 Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Fixed in GCC 8+.
[Bug c++/78924] hiding of template parameter of member template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78924 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-08-09 Keywords||rejects-valid Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski --- Confirmed.
[Bug c++/66439] Diagnostic on failed function template lookup is missing a line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66439 Andrew Pinski changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #5 from Andrew Pinski --- *** Bug 60916 has been marked as a duplicate of this bug. ***
[Bug c++/60916] truncated error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60916 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Dup of bug 66439. *** This bug has been marked as a duplicate of bug 66439 ***
[Bug c++/60916] truncated error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60916 --- Comment #2 from Andrew Pinski --- Seems fixed in GCC 11+: The extra output is now: :20:27: error: type/value mismatch at argument 2 in template parameter list for 'template int wrapper()' 20 | return wrapper (); | ~^~ :20:27: note: expected a type, got 'f'
[Bug c++/67631] brace initialization bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67631 Andrew Pinski changed: What|Removed |Added CC||tomaszkam at gmail dot com --- Comment #11 from Andrew Pinski --- *** Bug 63999 has been marked as a duplicate of this bug. ***
[Bug c++/63999] Explicit conversion operators are not considered for explicit cast using braces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63999 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- Dup of bug 67631. *** This bug has been marked as a duplicate of bug 67631 ***
[Bug c++/77565] `typdef int Int;` --> did you mean `typeof`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77565 Andrew Pinski changed: What|Removed |Added Last reconfirmed|2016-09-12 00:00:00 |2021-8-9 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > We don't give any suggestion any more: Never mind, I had use -std=c++98 with -std=gnu++98, get: :1:1: error: 'typdef' does not name a type; did you mean 'typeof'? 1 | typdef int Int; | ^~ | typeof
[Bug c++/77565] `typdef int Int;` --> did you mean `typeof`?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77565 --- Comment #1 from Andrew Pinski --- We don't give any suggestion any more: :1:1: error: 'typdef' does not name a type typdef int Int; ^~
[Bug c++/77465] [DR909] rejected C-style cast involving casting away constness from result of conversion operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77465 --- Comment #2 from Andrew Pinski --- I love how all 4 different compilers (GCC, clang, ICC and MSVC) have this same bug.
[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 Hans-Peter Nilsson changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Hans-Peter Nilsson --- This report no longer matches the current behavior. I see errors for some of the listed tests at 2eff2a3cb521 for cris-elf, but there has also been periods of zero regressions since the report, last known at 13586172d0b7. Closing this one, opening a new one.
[Bug c++/77335] templates and ambiguous call to overloaded function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77335 --- Comment #1 from Andrew Pinski --- This seems fixed on the trunk.
[Bug c++/71377] SFINAE expression compiles, but it should not because of 14.5.5p8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71377 --- Comment #3 from Andrew Pinski --- Hmm, GCC 10.1.0, 10.2.0, and 10.3.0 all reject it but GCC 9.4.0 and 11.1.0 accepts it :).
[Bug c++/69712] Storing and reusing a method pointer as compile time value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69712 Andrew Pinski changed: What|Removed |Added Blocks||101603 --- Comment #3 from Andrew Pinski --- clang rejects the code at C++14 with a similar error message as GCC but accepts it at C++17. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603 [Bug 101603] [meta-bug] pointer to member functions issues
[Bug tree-optimization/101755] [12 regression] gcc.target/arm/reg_equal_test.c fails on arm since r12-2637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101755 --- Comment #2 from Andrew Pinski --- d = a | -2; b = (d == 0) ? c : (c % d); d can never be 0, VRP figures this out now. so we end up with: d = a | -2; b = 0xc7d24b5e % d; if (b != 0xc7d24b5e) abort(); and b cannot be 0xc7d24b5e because d is negative :). So VRP is optimizing this all the way out. The test was trying to make sure the value 0xc7d24b5e was emitted as a REG_EQUAL note when splitting up the constant (for the forming) in RTL. https://gcc.gnu.org/pipermail/gcc-patches/2015-June/422430.html https://gcc.gnu.org/pipermail/gcc-patches/2015-June/422432.html
[Bug c++/65350] [C++14] operator new[] should not be called if # of initializer elements exceeds # of elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65350 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code --- Comment #3 from Andrew Pinski --- Clang gets it way wrong (-1): my operator new[](18446744073709551615) caught unkown exception ICC gets it right though: std::bad_array_new_length So I think GCC ordering is just wrong.
[Bug tree-optimization/101755] [12 regression] gcc.target/arm/reg_equal_test.c fails on arm since r12-2637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101755 --- Comment #1 from Andrew Macleod --- What is that suppose to test? The range ecosystem has gotten smarter and we basically fold that function away to return 0 now. between EVRP, VRP and threading, you'd have to turn off a lot of optimizations to return to the original state.. I can't find a sequence.
[Bug c++/101603] [meta-bug] pointer to member functions issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603 Bug 101603 depends on bug 67772, which changed state. Bug 67772 Summary: wrong type_info emitted for cv-qualified pointer to member types https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67772 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/52099] Incorrectly applying conversion when catching pointer-to-members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52099 Andrew Pinski changed: What|Removed |Added CC||richard-gccbugzilla@metafoo ||.co.uk --- Comment #3 from Andrew Pinski --- *** Bug 67772 has been marked as a duplicate of this bug. ***
[Bug c++/67772] wrong type_info emitted for cv-qualified pointer to member types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67772 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- This is a dup of bug 52099. *** This bug has been marked as a duplicate of bug 52099 ***
[Bug c++/67772] wrong type_info emitted for cv-qualified pointer to member types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67772 Andrew Pinski changed: What|Removed |Added Blocks||101603 Status|UNCONFIRMED |NEW Keywords||wrong-code Last reconfirmed||2021-08-09 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101603 [Bug 101603] [meta-bug] pointer to member functions issues
[Bug c++/67574] Misleading error message for method explicitly defaulted two times
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67574 --- Comment #1 from Andrew Pinski --- The location was fixed in GCC 10+: :7:1: error: definition of explicitly-defaulted 'X::X()' 7 | X::X() = default; | ^ :6:1: note: 'X::X()' explicitly defaulted here 6 | X::X() = default; | ^ Is that enough to fix this issue? Note here is clang produces: :7:4: error: redefinition of 'X' X::X() = default; ^ :6:4: note: previous definition is here X::X() = default; ^
[Bug c++/67402] outside definition of member class of an explicitly specialized member class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67402 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |9.0 Resolution|--- |FIXED --- Comment #1 from Andrew Pinski --- Fixed in GCC 9+, I am 90% sure it was fixed by r9-282.
[Bug target/101697] [11/12 regression] ICE compiling uClibc-ng for h8300-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101697
--- Comment #3 from Mikael Pettersson ---
As far as I can tell the problem is introduced by reload.
With a gcc-11.2.0 cross, getaddrinfo.i.290r.ira has
(insn 161 159 163 31 (set (reg/f:SI 185)
(reg/f:SI 7 sp)) "libc/inet/getaddrinfo.c":465:13 13 {*movsi}
(nil))
(insn 163 161 164 31 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [3 S4 A32])
(reg/f:SI 185)) "libc/inet/getaddrinfo.c":466:11 13 {*movsi}
(expr_list:REG_ARGS_SIZE (const_int 4 [0x4])
(nil)))
these are adjacent.
Then getaddrinfo.i.291r.reload has
Reloads for insn # 161
Reload 0: reload_out (SI) = (reg/f:SI 185)
NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
reload_out_reg: (reg/f:SI 185)
Reloads for insn # 163
Reload 0: reload_out (SI) = (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [3 S4 A32])
NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
reload_out_reg: (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [3 S4 A32])
Reload 1: reload_in (SI) = (reg/f:SI 185)
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (reg/f:SI 185)
reload_reg_rtx: (reg/f:SI 7 sp)
and later
(insn 161 159 995 31 (set (mem/c:SI (plus:SI (reg/f:SI 6 r6)
(const_int -140 [0xff74])) [30 %sfp+-132 S4 A32])
(reg/f:SI 7 sp)) "libc/inet/getaddrinfo.c":465:13 13 {*movsi}
(nil))
(insn 995 161 163 31 (set (reg/f:SI 7 sp)
(mem/c:SI (plus:SI (reg/f:SI 6 r6)
(const_int -140 [0xff74])) [30 %sfp+-132 S4 A32]))
"libc/inet/getaddrinfo.c":466:11 13 {*movsi}
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil)))
(insn 163 995 164 31 (set (mem/f:SI (pre_dec:SI (reg/f:SI 7 sp)) [3 S4 A32])
(reg/f:SI 7 sp)) "libc/inet/getaddrinfo.c":466:11 13 {*movsi}
(expr_list:REG_ARGS_SIZE (const_int 4 [0x4])
(nil)))
It's strange you can't reproduce. My current build is literally:
> mkdir objdir-binutils; cd objdir-binutils
> /tmp/binutils-2.37/configure --target=h8300-unknown-linux-uclibc
> --prefix=/tmp/cross-h8300 --with-sysroot=/tmp/cross-h8300
> make -jN
> make install
> cd ..
> mkdir objdir-gcc; cd objdir-gcc
> PATH=/tmp/cross-h8300/bin:/usr/bin /tmp/gcc-11.2.0/configure
> --target=h8300-unknown-linux-uclibc --prefix=/tmp/cross-h8300
> --with-sysroot=/tmp/cross-h8300 --with-newlib --disable-libquadmath
> --disable-libssp --disable-threads --disable-libatomic --disable-libgomp
> --enable-languages=c --enable-checking=release
> PATH=/tmp/cross-h8300/bin:/usr/bin make -jN
> gcc/xgcc -Bgcc -fno-builtin -Os -S /tmp/getaddrinfo.i
