[Bug c++/97974] [9/10/11 Regression] ICE tree check: expected overload, have function_decl in get_class_binding_direct, at cp/name-lookup.c:1332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97974 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:936d500dfc17f58f2507ecd0f7f26e4f197052ee commit r11-8120-g936d500dfc17f58f2507ecd0f7f26e4f197052ee Author: Jason Merrill Date: Sat Apr 10 14:00:15 2021 -0400 c++: ICE with anonymous union [PR97974] Here lookup got confused by finding a conversion operator from lookup_anon_field. Let's avoid this by pruning functions from CLASSTYPE_MEMBER_VEC as well as TYPE_FIELDS. gcc/cp/ChangeLog: PR c++/97974 * decl.c (fixup_anonymous_aggr): Prune all functions from CLASSTYPE_MEMBER_VEC. gcc/testsuite/ChangeLog: PR c++/97974 * g++.dg/lookup/pr84962.C: Adjust diagnostic. * g++.dg/other/anon-union5.C: New test.
[Bug target/100028] [9/10/11 Regression] arm64 failure to generate bfxil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100028 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target Milestone|--- |9.4 Last reconfirmed||2021-04-11 Summary|arm64 failure to generate |[9/10/11 Regression] arm64 |bfxil |failure to generate bfxil --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug target/100028] New: arm64 failure to generate bfxil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100028
Bug ID: 100028
Summary: arm64 failure to generate bfxil
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: luc.vanoostenryck at gmail dot com
Target Milestone: ---
Target: aarch64
Created attachment 50555
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50555=edit
should generate bfxil but doesn't
The attached code reproduced here:
#define W 3
#define L 11
int bfxil(int d, int s)
{
int wmask = (1 << W) - 1;
return (d & ~wmask) | ((s >> L) & wmask);
}
Should return:
bfxil:
bfxil w0, w1, 11, 3
ret
but instead returns:
bfxil:
ubfxx1, x1, 11, 3
and w0, w0, -8
orr w0, w1, w0
ret
The problem is still present in trunk, was also present in 9.3 but wasn't in
GCC 8.2 (see https://gcc.godbolt.org/z/E6z31hr9r ).
[Bug fortran/84006] [8/9/10/11 Regression] ICE in storage_size() with CLASS entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84006 José Rui Faustino de Sousa changed: What|Removed |Added CC||jrfsousa at gmail dot com --- Comment #8 from José Rui Faustino de Sousa --- Patch posted https://gcc.gnu.org/pipermail/fortran/2021-April/055922.html
[Bug fortran/100027] ICE on storage_size with polymorphic argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100027 --- Comment #1 from José Rui Faustino de Sousa --- Patch posted https://gcc.gnu.org/pipermail/fortran/2021-April/055922.html
[Bug fortran/100025] ICE on subroutine missing explicit interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100025 --- Comment #1 from José Rui Faustino de Sousa --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2021-April/055921.html
[Bug fortran/100024] ICE on subroutine missing explicit interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100024 --- Comment #1 from José Rui Faustino de Sousa --- Patch posted: https://gcc.gnu.org/pipermail/fortran/2021-April/055921.html
[Bug fortran/100027] New: ICE on storage_size with polymorphic argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100027 Bug ID: 100027 Summary: ICE on storage_size with polymorphic argument Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50554 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50554=edit Fortran code showing problem Hi All! ICE on storage_size with pointer (or allocatable) array argument. Tested on: GNU Fortran (GCC) 11.0.1 20210410 (experimental) GNU Fortran (GCC) 10.3.1 20210410 GNU Fortran (GCC) 9.3.1 20210410 Thank you very much. Best regards, José Rui
[Bug bootstrap/100026] cross build GCC from clang fails: configure: error: *** A compiler with support for C++11 language features is required.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100026 cqwrteur changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from cqwrteur --- clang crashing
[Bug bootstrap/100026] New: cross GCC from clang fails: configure: error: *** A compiler with support for C++11 language features is required.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100026 Bug ID: 100026 Summary: cross GCC from clang fails: configure: error: *** A compiler with support for C++11 language features is required. Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- Created attachment 50553 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50553=edit error message I try to build a GCC cross-toolchain by using clang, targeting MacOS. However, it looks like clang does not support -static-libgcc and -static-libstdc++. Any solution on this?
[Bug fortran/100025] New: ICE on subroutine missing explicit interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100025 Bug ID: 100025 Summary: ICE on subroutine missing explicit interface Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50552 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50552=edit Fortran code showing problem Hi All! ICE on assumed-rank subroutine call with missing explicit interface. Tested on: GNU Fortran (GCC) 11.0.1 20210410 (experimental) GNU Fortran (GCC) 10.3.1 20210410 Does not ICE on: GNU Fortran (GCC) 9.3.1 20210410 Thank you very much. Best regards, José Rui
[Bug fortran/100024] New: ICE on subroutine missing explicit interface
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100024 Bug ID: 100024 Summary: ICE on subroutine missing explicit interface Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Created attachment 50551 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50551=edit Fortran code showing problem Hi All! ICE on assumed-rank subroutine call with missing explicit interface. Tested on: GNU Fortran (GCC) 11.0.1 20210410 (experimental) GNU Fortran (GCC) 10.3.1 20210410 Does not ICE on: GNU Fortran (GCC) 9.3.1 20210410 Thank you very much. Best regards, José Rui
[Bug fortran/100018] ICE on missing polymorphic argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100018 --- Comment #1 from José Rui Faustino de Sousa --- Path posted: https://gcc.gnu.org/pipermail/fortran/2021-April/055916.html
[Bug c++/98800] [8/9/10/11 Regression] ICE on invalid use of non-static member function in trailing return type since r8-2724
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98800 --- Comment #5 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:82198676c80764ca7cf05f891afaee83b9179dd1 commit r11-8118-g82198676c80764ca7cf05f891afaee83b9179dd1 Author: Jason Merrill Date: Sat Apr 10 10:55:58 2021 -0400 c++: ICE with invalid use of 'this' with static memfn [PR98800] Here instantiation of the fake 'this' parameter we used when parsing the trailing return type of func() was failing because there is no actual 'this' parameter in the instantiation. For PR97399 I told Patrick to do the 'this' injection even for statics, but now I think I was wrong; the out-of-class definition case I was concerned about does not break with this patch. And we don't set current_class_ptr in the body of a static member function. And the OMP code should continue to parse 'this' and complain about it rather than give a syntax error. gcc/cp/ChangeLog: PR c++/98800 PR c++/97399 * parser.c (cp_parser_direct_declarator): Don't inject_this_parameter if static_p. (cp_parser_omp_var_list_no_open): Parse 'this' even if current_class_ptr isn't set for a better diagnostic. gcc/testsuite/ChangeLog: PR c++/98800 * g++.dg/gomp/this-1.C: Adjust diagnostic. * g++.dg/cpp0x/constexpr-this1.C: New test.
[Bug c++/97399] [9/10 Regression] g++ 9.3 cannot compile SFINAE code with separated declaration and definition, g++ 7.3 compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97399 --- Comment #7 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:82198676c80764ca7cf05f891afaee83b9179dd1 commit r11-8118-g82198676c80764ca7cf05f891afaee83b9179dd1 Author: Jason Merrill Date: Sat Apr 10 10:55:58 2021 -0400 c++: ICE with invalid use of 'this' with static memfn [PR98800] Here instantiation of the fake 'this' parameter we used when parsing the trailing return type of func() was failing because there is no actual 'this' parameter in the instantiation. For PR97399 I told Patrick to do the 'this' injection even for statics, but now I think I was wrong; the out-of-class definition case I was concerned about does not break with this patch. And we don't set current_class_ptr in the body of a static member function. And the OMP code should continue to parse 'this' and complain about it rather than give a syntax error. gcc/cp/ChangeLog: PR c++/98800 PR c++/97399 * parser.c (cp_parser_direct_declarator): Don't inject_this_parameter if static_p. (cp_parser_omp_var_list_no_open): Parse 'this' even if current_class_ptr isn't set for a better diagnostic. gcc/testsuite/ChangeLog: PR c++/98800 * g++.dg/gomp/this-1.C: Adjust diagnostic. * g++.dg/cpp0x/constexpr-this1.C: New test.
[Bug analyzer/100011] [11 Regression] ICE in analyzer when generating path for -Wanalyzer-unsafe-call-within-signal-handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100011 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from David Malcolm --- Should be fixed by the above commit.
[Bug analyzer/100011] [11 Regression] ICE in analyzer when generating path for -Wanalyzer-unsafe-call-within-signal-handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100011 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:ec633d3777bd71f7bde5e671b61ec18e5b7b43ea commit r11-8117-gec633d3777bd71f7bde5e671b61ec18e5b7b43ea Author: David Malcolm Date: Sat Apr 10 16:23:23 2021 -0400 analyzer: fix ICE on assignment from STRING_CST when building path [PR100011] gcc/analyzer/ChangeLog: PR analyzer/100011 * region-model.cc (region_model::on_assignment): Avoid NULL dereference if ctxt is NULL when assigning from a STRING_CST. gcc/testsuite/ChangeLog: PR analyzer/100011 * gcc.dg/analyzer/pr100011.c: New test.
[Bug target/100000] non-leaf epologue/prologue used if MVE v4sf is used for load/return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Summary|arm: Missed optimisation|non-leaf epologue/prologue |storing MVE V4SF vector |used if MVE v4sf is used ||for load/return
[Bug target/100023] apple target cross compilation: fails configure: error: cannot compute suffix of object files: cannot compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100023 --- Comment #2 from cqwrteur --- Created attachment 50550 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50550=edit config.log
[Bug target/100023] apple target cross compilation: fails configure: error: cannot compute suffix of object files: cannot compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100023 Marek Polacek changed: What|Removed |Added Resolution|--- |INVALID CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Marek Polacek --- configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details So do just that. Please stop opening these nonsensical "bug" reports.
[Bug target/100023] New: apple target cross compilation: fails configure: error: cannot compute suffix of object files: cannot compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100023 Bug ID: 100023 Summary: apple target cross compilation: fails configure: error: cannot compute suffix of object files: cannot compile Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- Created attachment 50549 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50549=edit build error message then i tried to build a "hello world" with the new cqwrteur@Home-Server:~/myhome/apple_cross/target_gcc$ x86_64-apple-darwin19.6.0-gcc -o b b.c -Ofast -s Assembler messages: Fatal error: invalid listing option `r' it sounds like an issue related to as script https://stackoverflow.com/questions/26197735/how-to-make-arm-cross-compilation-on-mac-os-x-error-invalid-listing-option-r
[Bug c++/100022] Parameter packs not expanded with alignas specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100022 --- Comment #1 from 康桓瑋 --- I think this is a dup of PR 16, correct me if i am wrong.
[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212 David Malcolm changed: What|Removed |Added Priority|P3 |P5 --- Comment #10 from David Malcolm --- Reducing the priority of this from P3 to P5: this is a synthetic test case to try to exercise bitfields (and check that we don't ICE), but the impact of the failure is minimal, I think - beyond the noise for test runs on the affected targets (sorry).
[Bug analyzer/98599] [11 Regression] fatal error: Cgraph edge statement index out of range with -Os -flto -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98599 David Malcolm changed: What|Removed |Added Summary|fatal error: Cgraph edge|[11 Regression] fatal |statement index out of |error: Cgraph edge |range with -Os -flto|statement index out of |-fanalyzer |range with -Os -flto ||-fanalyzer --- Comment #12 from David Malcolm --- Am fairly sure this is a regression relative to GCC 10, so updating Summary accordingly; I'd like -fanalyzer to be usable with -flto again (even with its current limitations) Honza; any thoughts on the stuff in comment #10?
[Bug c++/100022] New: Parameter packs not expanded with alignas specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100022
Bug ID: 100022
Summary: Parameter packs not expanded with alignas specifier
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
https://godbolt.org/z/49KvrsM9W
template
void g() {
([] { struct alignas(Ns) S {}; }, ...);
}
gcc rejects it.
[Bug middle-end/99928] [OpenMP] reduction variable in combined target construct wrongly mapped as firstprivate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99928 --- Comment #2 from Tobias Burnus --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567838.html
[Bug c++/87403] [Meta-bug] Issues that suggest a new warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 Bug 87403 depends on bug 100020, which changed state. Bug 100020 Summary: RFE: Wmisleading-indentation (or similar warning) for certain missing semicolons? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100020 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c/88887] Warn on unexpected continuation of 'return' to new line in if statement.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=7 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #2 from Eric Gallager --- *** Bug 100020 has been marked as a duplicate of this bug. ***
[Bug c/100020] RFE: Wmisleading-indentation (or similar warning) for certain missing semicolons?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100020 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Eric Gallager --- Dup of bug 7 *** This bug has been marked as a duplicate of bug 7 ***
[Bug target/100021] New: [9/10/11 Regression] std::clamp unprofitable vectorization on -march=nehalem/.../broadwell
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100021
Bug ID: 100021
Summary: [9/10/11 Regression] std::clamp unprofitable
vectorization on -march=nehalem/.../broadwell
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
//#include
namespace std
{
template
constexpr const _Tp&
clamp(const _Tp& __val, const _Tp& __lo, const _Tp& __hi)
{
return (__val < __lo) ? __lo : (__hi < __val) ? __hi : __val;
}
}
int foo(int x, int y) {
return std::clamp(x - y, -1, 1);
}
https://godbolt.org/z/6534c1ff1 either GCC makes unprofitable vectorization or
LLVM MCA calculation is wrong.
Affected targets are
-march=nehalem/westmere/sandybridge/ivybridge/haswell/broadwell.
I do not know why it is vectorized on -O2 in the first place; could not find a
switch which triggers it, and doing -O1 + everything -O2 supposed to be
enabling does not reproduce the -O2 behavior.
[Bug c/100020] RFE: Wmisleading-indentation (or similar warning) for certain missing semicolons?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100020 Jonathan Wakely changed: What|Removed |Added Severity|normal |enhancement Blocks||87403 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug c/100020] RFE: Wmisleading-indentation (or similar warning) for certain missing semicolons?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100020 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-04-10
[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 --- Comment #30 from Piotr Kubaj --- With default flags: during RTL pass: cprop_hardreg In file included from /wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210327/libgcc/unwind-c.c:32: /wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210327/libgcc/unwind-pe.h: In function 'base_of_encoded_value': /wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210327/libgcc/unwind-pe.h:121:1: internal compiler error: Segmentation fault With my hack that allows gcc9 to build: during RTL pass: reload In file included from /wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210327/libiberty/regex.c:639: /wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210327/libiberty/regex.c: In function 'byte_regex_compile': /wrkdirs/usr/ports/lang/gcc10-devel/work/gcc-10-20210327/libiberty/regex.c:4223:1: internal compiler error: Segmentation fault 4223 | } /* regex_compile */ The hack is: CFLAGS_FOR_TARGET="-O0" CXXFLAGS_FOR_TARGET="-O0" BOOT_CFLAGS="-O0" And the patch: --- libgcc/config/rs6000/t-crtstuff.orig2020-04-07 15:17:50 UTC +++ libgcc/config/rs6000/t-crtstuff @@ -3,4 +3,4 @@ # Do not build crtend.o with -Os as that can result in references to # out-of-line register save/restore functions, which may be unresolved # as crtend.o is linked after libgcc.a. See PR45053. -CRTSTUFF_T_CFLAGS = -msdata=none -O2 -fno-asynchronous-unwind-tables +CRTSTUFF_T_CFLAGS = -msdata=none -O0 -fno-asynchronous-unwind-tables
[Bug c++/100019] ICE Segmentation fault with try-catch block in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100019 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Last reconfirmed||2021-04-10 Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/100019] New: ICE Segmentation fault with try-catch block in lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100019
Bug ID: 100019
Summary: ICE Segmentation fault with try-catch block in lambda
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
https://godbolt.org/z/WajPza5fM
void f(auto... args) {
[] {
try {} catch (decltype(args)) {}
};
}
int main() {
f(0);
}
:3:19: internal compiler error: Segmentation fault
3 | try {} catch (decltype(args)) {}
| ^~
0x1d00a79 internal_error(char const*, ...)
???:0
0x98c0ff finish_decltype_type(tree_node*, bool, int)
???:0
0x9170e3 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x9177e7 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x94acb2 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x91d61f instantiate_decl(tree_node*, bool, bool)
???:0
0x95f4eb instantiate_pending_templates(int)
???:0
0x7ccff9 c_parse_final_cleanups()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug c/100020] New: RFE: Wmisleading-indentation (or similar warning) for certain missing semicolons?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100020 Bug ID: 100020 Summary: RFE: Wmisleading-indentation (or similar warning) for certain missing semicolons? Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dmalcolm at gcc dot gnu.org Target Milestone: --- >From a discussion on Freenode's #gcc: https://git.sr.ht/~rkta/irssi/commit/76c00f5ee29df9f66a4162891d41515ebc829f4b @@ 307,6 307,8 @@ void printtext(void *server, const char *target, int level, const char *text, .. g_return_if_fail(text != NULL); format_create_dest(, server, target, level, NULL); + if (!dest.window) + return va_start(va, text); printtext_dest_args(, text, va); Spot the mistake? The compiler "sees" it as: if (!dest.window) return va_start(va, text); and chaos ensues. This feels a lot like -Wmisleading-indentation, in that it's a case where how the parser is "seeing" the code is very different from how a human reader might see the code. I'm not sure if it should be part of -Wmisleading-indentation or a separate warning, but it seemed promising in terms of helping the user avoid a 2 hour debugging session...
[Bug fortran/100018] New: ICE on missing polymorphic argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100018 Bug ID: 100018 Summary: ICE on missing polymorphic argument Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jrfsousa at gmail dot com Target Milestone: --- Hi All! ICE with simple subroutine missing a dummy argument. subroutine foo(that) implicit none class(*), target, intent(in) :: this class(*), pointer, intent(out) :: that that => this return end subroutine foo Tested on: GNU Fortran (GCC) 11.0.1 20210410 (experimental) GNU Fortran (GCC) 10.3.1 20210410 GNU Fortran (GCC) 9.3.1 20210410 Thank you very much. Best regards, José Rui
[Bug analyzer/100011] [11 Regression] ICE in analyzer when generating path for -Wanalyzer-unsafe-call-within-signal-handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100011 David Malcolm changed: What|Removed |Added Last reconfirmed||2021-04-10 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Summary|internal compiler error in |[11 Regression] ICE in |analyzer during IPA pass|analyzer when generating ||path for ||-Wanalyzer-unsafe-call-with ||in-signal-handler --- Comment #2 from David Malcolm --- Thanks for filing this bug; sorry about the breakage. I'm working on a fix.
[Bug c++/99008] [10/11 Regression] ICE in set_constraints, at cp/constraint.cc:1256
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99008 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/97974] [9/10/11 Regression] ICE tree check: expected overload, have function_decl in get_class_binding_direct, at cp/name-lookup.c:1332
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97974 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c/99990] [8/9/10 Regression] ICE in gimplifier on invalid va_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10/11 Regression] ICE |[8/9/10 Regression] ICE in |in gimplifier on invalid|gimplifier on invalid |va_arg |va_arg --- Comment #7 from Jakub Jelinek --- Fixed on the trunk.
[Bug c/99990] [8/9/10/11 Regression] ICE in gimplifier on invalid va_arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 --- Comment #6 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9f7d77bd6d65aa1cf2e195d3776052705c6e636b commit r11-8116-g9f7d77bd6d65aa1cf2e195d3776052705c6e636b Author: Jakub Jelinek Date: Sat Apr 10 17:01:54 2021 +0200 c: Avoid clobbering TREE_TYPE (error_mark_node) [PR0] The following testcase ICEs during error recovery, because finish_decl overwrites TREE_TYPE (error_mark_node), which better should stay always to be error_mark_node. 2021-04-10 Jakub Jelinek PR c/0 * c-decl.c (finish_decl): Don't overwrite TREE_TYPE of error_mark_node. * gcc.dg/pr0.c: New test.
[Bug c++/98800] [8/9/10/11 Regression] ICE on invalid use of non-static member function in trailing return type since r8-2724
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98800 Marek Polacek changed: What|Removed |Added Priority|P2 |P4 Keywords||error-recovery --- Comment #4 from Marek Polacek --- I can see that error message now. So, error-recovery and I suspect P4.
[Bug c++/98800] [8/9/10/11 Regression] ICE on invalid use of non-static member function in trailing return type since r8-2724
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98800 --- Comment #3 from Jason Merrill --- I'm getting a correct (if obscure) error message before the ICE: wa.C:4:71: error: use of ‘this’ in a constant expression 4 | template static auto func() -> enable_if_t()>; | ^ wa.C:4: confused by earlier errors, bailing out are you still not?
[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #5 from cqwrteur --- Created attachment 50548 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50548=edit linux build, FreeBSD host, Windows target The error still exists. It looks MSVCRT does not always define those C11 cfenv functions and the feature testing macro does not detect them correctly???
[Bug d/99812] [11 regression] Many libphobos.druntime_shared etc. tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99812 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Iain Buclaw --- Re-added -fno-moduleinfo for now. Will fix -fbuilding-libphobos-tests later after 11 release.
[Bug d/99812] [11 regression] Many libphobos.druntime_shared etc. tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99812 --- Comment #1 from CVS Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:38258326dc9e5581e2cd6318ae1b5e675dd00d4a commit r11-8110-g38258326dc9e5581e2cd6318ae1b5e675dd00d4a Author: Iain Buclaw Date: Sat Apr 10 12:01:04 2021 +0200 libphobos: Re-add -fno-moduleinfo flag to dg-runtest [PR99812] libphobos/ChangeLog: PR d/99812 * testsuite/libphobos.druntime_shared/druntime_shared.exp: Re-add -fno-moduleinfo flag to dg-runtest. * testsuite/libphobos.phobos_shared/phobos_shared.exp: Likewise.
[Bug target/99744] __attribute__ ((target("general-regs-only"))) doesn't work with GPR intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99744 --- Comment #9 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:71958f740f1b8c47a86ea222418abee395d254a0 commit r11-8109-g71958f740f1b8c47a86ea222418abee395d254a0 Author: H.J. Lu Date: Fri Apr 9 11:44:32 2021 -0700 x86: Define _serialize as macro Define _serialize as macro for callers with general-regs-only target attribute to avoid inline failure with always_inline attribute. gcc/ PR target/99744 * config/i386/serializeintrin.h (_serialize): Defined as macro. gcc/testsuite/ PR target/99744 * gcc.target/i386/pr99744-2.c: New test.
[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #4 from cqwrteur --- (In reply to cqwrteur from comment #2) > not a bug it looks like it is a bug here.
[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 cqwrteur changed: What|Removed |Added Resolution|INVALID |--- Status|RESOLVED|UNCONFIRMED --- Comment #3 from cqwrteur --- (In reply to cqwrteur from comment #2) > not a bug it is weird tbh. There must be something to do with cfenv header or charconv
[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 cqwrteur changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from cqwrteur --- not a bug
[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 --- Comment #1 from cqwrteur --- I tried to build a full host GCC toolchain from Linux to Windows and fenv_t does not exist.
[Bug libstdc++/100017] New: error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017 Bug ID: 100017 Summary: error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- Created attachment 50547 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50547=edit error message /home/cqwrteur/myhome/mingw-w64-cross/gcc/x86_64-w64-mingw32/libstdc++-v3/include/fenv.h:58:11: error: 'fenv_t' has not been declared in '::' 58 | using ::fenv_t;
[Bug target/100016] multilib mingw-w64 links to the wrong multilib path because of libtool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100016 --- Comment #1 from cqwrteur --- BTW. ucrt multilib should also provide as an option I think. m32 m64 mucrt32 mucrt64
[Bug ipa/98265] [10 Regression] gcc-10 has significantly worse code generated with -O2 compared to -O1 (or gcc-9 -O2) when using the Eigen C++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98265 Bug 98265 depends on bug 99989, which changed state. Bug 99989 Summary: [11 regression] -Wmaybe-uninitialized warning breaks bootstrap on riscv64 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 99989, which changed state. Bug 99989 Summary: [11 regression] -Wmaybe-uninitialized warning breaks bootstrap on riscv64 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug middle-end/99989] [11 regression] -Wmaybe-uninitialized warning breaks bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989 Andreas Schwab changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #10 from Andreas Schwab --- Verified.
[Bug middle-end/99857] [11 Regression] FAIL: libgomp.c/declare-variant-1.c (test for excess errors) by r11-7926
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99857 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug lto/99849] [8/9/10 Regression] ICE in expand_expr_real_1, at expr.c:11556 since r5-5407-g30d5d8c5189064c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99849 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10/11 Regression] ICE |[8/9/10 Regression] ICE in |in expand_expr_real_1, at |expand_expr_real_1, at |expr.c:11556 since |expr.c:11556 since |r5-5407-g30d5d8c5189064c8 |r5-5407-g30d5d8c5189064c8 --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/99989] [11 regression] -Wmaybe-uninitialized warning breaks bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989 --- Comment #9 from Jakub Jelinek --- Can't verify it the above commit fixes it though, so keeping the PR open until somebody confirms it (or attaches preprocessed source so that I could verify with cross-compiler).
[Bug rtl-optimization/98601] [8/9/10 Regression] aarch64: ICE in rtx_addr_can_trap_p_1, at rtlanal.c:467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98601 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8/9/10 Regression] |aarch64: ICE in |aarch64: ICE in |rtx_addr_can_trap_p_1, at |rtx_addr_can_trap_p_1, at |rtlanal.c:467 |rtlanal.c:467 --- Comment #8 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug lto/99849] [8/9/10/11 Regression] ICE in expand_expr_real_1, at expr.c:11556 since r5-5407-g30d5d8c5189064c8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99849 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:22aede7a1228617661105048a91fddd8797e141b commit r11-8108-g22aede7a1228617661105048a91fddd8797e141b Author: Jakub Jelinek Date: Sat Apr 10 12:49:01 2021 +0200 expand: Fix up LTO ICE with COMPOUND_LITERAL_EXPR [PR99849] The gimplifier optimizes away COMPOUND_LITERAL_EXPRs, but they can remain in the form of ADDR_EXPR of COMPOUND_LITERAL_EXPRs in static initializers. By the TREE_STATIC check I meant to check that the underlying decl of the compound literal is a global rather than automatic variable which obviously can't be referenced in static initializers, but unfortunately with LTO it might end up in another partition and thus be DECL_EXTERNAL instead. 2021-04-10 Jakub Jelinek PR lto/99849 * expr.c (expand_expr_addr_expr_1): Test is_global_var rather than just TREE_STATIC on COMPOUND_LITERAL_EXPR_DECLs. * gcc.dg/lto/pr99849_0.c: New test.
[Bug middle-end/99989] [11 regression] -Wmaybe-uninitialized warning breaks bootstrap on riscv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99989 --- Comment #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:3e350d8539a4e28ddc30d0f08a4040f10b699135 commit r11-8107-g3e350d8539a4e28ddc30d0f08a4040f10b699135 Author: Jakub Jelinek Date: Sat Apr 10 12:48:04 2021 +0200 gimple-ssa-warn-alloca: Always initialize limit [PR99989] This PR is about a -W*uninitialized warning on riscv64. alloca_type_and_limit is documented to have limit member only defined when type is ALLOCA_BOUND_MAYBE_LARGE or ALLOCA_BOUND_DEFINITELY_LARGE and otherwise just default constructs limit, which for wide_int means no initialization at all. IMHO it is fine not to use the limit member otherwise, but trying to not initialize it when it can be e.g. copied around and then invoke UB doesn't look like a good idea. 2021-04-10 Jakub Jelinek PR middle-end/99989 * gimple-ssa-warn-alloca.c (alloca_type_and_limit::alloca_type_and_limit): Initialize limit to 0 with integer precision unconditionally.
[Bug rtl-optimization/98601] [8/9/10/11 Regression] aarch64: ICE in rtx_addr_can_trap_p_1, at rtlanal.c:467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98601 --- Comment #7 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7a493fcd27d6a1af896c4f5ef4ab1e0afe8a839d commit r11-8106-g7a493fcd27d6a1af896c4f5ef4ab1e0afe8a839d Author: Jakub Jelinek Date: Sat Apr 10 12:46:09 2021 +0200 rtlanal: Another fix for VOIDmode MEMs [PR98601] This is a sequel to the PR85022 changes, inline-asm can (unfortunately) introduce VOIDmode MEMs and in PR85022 they have been changed so that we don't pretend we know their size (as opposed to assuming they have zero size). This time we ICE in rtx_addr_can_trap_p_1 because it assumes that all memory but BLKmode has known size. The patch just treats VOIDmode MEMs like BLKmode in that regard. And, the STRICT_ALIGNMENT change is needed because VOIDmode has GET_MODE_SIZE of 0 and we don't want to check if something is a multiple of 0. 2021-04-10 Jakub Jelinek PR rtl-optimization/98601 * rtlanal.c (rtx_addr_can_trap_p_1): Allow in assert unknown size not just for BLKmode, but also for VOIDmode. For STRICT_ALIGNMENT unaligned_mems handle VOIDmode like BLKmode. * gcc.dg/torture/pr98601.c: New test.
[Bug target/100009] [9 Regression] -march=native doesn't recognize tigerlake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-04-10 Known to fail||9.3.1 Summary|-march=native doesn't |[9 Regression] |recognize tigerlake |-march=native doesn't ||recognize tigerlake CC||hjl.tools at gmail dot com Status|UNCONFIRMED |NEW Known to work||9.3.0 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- The "tigerlake" string was added to the branch by r9-8652, which is after the 9.3.0 release, so Ubuntu must have backported it (but not changed the version number to 9.3.1?)
[Bug bootstrap/100013] libiberty error PATH_MAX does not exist on DJGPP host.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100013 Eric Gallager changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=21823 CC||egallager at gcc dot gnu.org --- Comment #3 from Eric Gallager --- Yeah it's probably a bad idea for GUESSPATHLEN to use MAXPATHLEN; see bug 21823
[Bug ipa/99862] [meta-issue] various missed optimizations for dead code elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99862 Eric Gallager changed: What|Removed |Added Keywords||meta-bug --- Comment #10 from Eric Gallager --- ok now that this depends on other bugs I'm adding the "meta-bug" keyword
[Bug target/97726] simd intrinsics tests fail on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97726 --- Comment #3 from Christophe Lyon --- Almost, but I still see vstn_lane_bf16_1.c failures in check-function-bodies on armeb. vdot-2-[12].c still fail, but I see failures on little-endian configs too, so probably a different issue (I didn't check the logs/details)
[Bug middle-end/99857] [11 Regression] FAIL: libgomp.c/declare-variant-1.c (test for excess errors) by r11-7926
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99857 --- Comment #8 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:1c9744fb3bf2fbf7cec5722f4b187eb553d98280 commit r11-8105-g1c9744fb3bf2fbf7cec5722f4b187eb553d98280 Author: Jan Hubicka Date: Sat Apr 10 11:17:56 2021 +0200 Do not release body of declare_variant_alt gcc/ChangeLog: 2021-04-10 Jan Hubicka PR lto/99857 * tree.c (free_lang_data_in_decl): Do not release body of declare_variant_alt.
[Bug libgcc/100016] New: multilib mingw-w64 links to the wrong multilib path because of libtool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100016 Bug ID: 100016 Summary: multilib mingw-w64 links to the wrong multilib path because of libtool Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: --- Created attachment 50546 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50546=edit error message The issue is that 32bit mulitlib incorrectly links to /lib (which is 64 bits) instead of linking to /lib32 This happens for all multilibs sublibs. including libgcc, libquadmath, libatomic and libstdc++ There is even a very old webpage talking about this. https://pete.akeo.ie/2010/07/compiling-mingw-w64-with-multilib-on.html Time for a fix.
[Bug c++/100012] MSDOS DJGPP host no socket while libcody does not block this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100012 --- Comment #3 from cqwrteur --- Created attachment 50545 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50545=edit libgcov should include
[Bug c++/100012] MSDOS DJGPP host no socket while libcody does not block this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100012 --- Comment #2 from cqwrteur --- Created attachment 50544 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50544=edit there are more issues related to this I think the problem is that DJGPP toolchain defines __unix__ macro while it is actually not a POSIX compliant system. We need to block them in a lot of places
[Bug c++/95486] ICE for alias CTAD with non-dependent argument and constrained constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95486 Jason Merrill changed: What|Removed |Added CC||lnwirz at chem dot helsinki.fi --- Comment #8 from Jason Merrill --- *** Bug 99675 has been marked as a duplicate of this bug. ***
[Bug c++/99675] [10/11 Regression] ICE during template deduction since r10-5020-g1a291106384cabc7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99675 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jason Merrill --- Fixed already, probably by the patch for 95486. *** This bug has been marked as a duplicate of bug 95486 ***
[Bug c++/93085] ICE in get_class_binding_direct and alias_ctad_tweaks, with C++20 NTTP + CTAD + alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93085 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|WAITING |ASSIGNED CC||jason at gcc dot gnu.org --- Comment #5 from Jason Merrill --- The ICEs are fixed, I want to address the second testcase in comment #3.
[Bug target/100015] MSDOS DJGPP host build mallinfo was not declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100015 --- Comment #1 from cqwrteur --- Created attachment 50543 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50543=edit Demo patch
[Bug target/100015] New: MSDOS DJGPP host build mallinfo was not declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100015
Bug ID: 100015
Summary: MSDOS DJGPP host build mallinfo was not declared
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: unlvsur at live dot com
Target Milestone: ---
In file included from ../../../gcc/gcc/ggc-common.c:25:
../../../gcc/gcc/ggc-common.c: In function 'void report_heap_memory_use()':
../../../gcc/gcc/ggc-common.c:1020:23: error: 'mallinfo' was not declared in
this scope; did you mean 'mmap_info'?
1020 | #define MALLINFO_FN mallinfo
| ^~~~
../../../gcc/gcc/system.h:1262:26: note: in definition of macro 'SIZE_SCALE'
1262 | #define SIZE_SCALE(x) (((x) < 10 * ONE_K \
| ^
../../../gcc/gcc/ggc-common.c:1024:14: note: in expansion of macro
'SIZE_AMOUNT'
1024 | SIZE_AMOUNT (MALLINFO_FN ().arena));
| ^~~
../../../gcc/gcc/ggc-common.c:1024:27: note: in expansion of macro
'MALLINFO_FN'
1024 | SIZE_AMOUNT (MALLINFO_FN ().arena));
| ^~~
../../../gcc/gcc/cp/mapper-client.cc:25:10: fatal error: sys/socket.h: No such
file or directory
25 | #include
| ^~
compilation terminated.
make[2]: *** [Makefile:1143: cp/mapper-client.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[2]: *** [Makefile:1142: ggc-common.o] Error 1
In file included from ../../../gcc/gcc/cp/error.c:29:
../../../gcc/gcc/cp/error.c: In function 'void
dump_aggr_type(cxx_pretty_printer*, tree, int)':
../../../gcc/gcc/cp/error.c:799:27: warning: spurious leading punctuation
sequence '<' in format [-Wformat-diag]
799 | pp_printf (pp, M_(""), variety);
../../../gcc/gcc/intl.h:40:26: note: in definition of macro 'gettext'
40 | # define gettext(msgid) (msgid)
| ^
../../../gcc/gcc/cp/error.c:52:56: note: in expansion of macro '_'
52 | #define M_(msgid) (pp_translate_identifiers (cxx_pp) ? _(msgid) :
(msgid))
|^
../../../gcc/gcc/cp/error.c:799:24: note: in expansion of macro 'M_'
799 | pp_printf (pp, M_(""), variety);
|^~
../../../gcc/gcc/cp/error.c:799:27: warning: spurious trailing punctuation
sequence '>' in format [-Wformat-diag]
799 | pp_printf (pp, M_(""), variety);
../../../gcc/gcc/intl.h:40:26: note: in definition of macro 'gettext'
40 | # define gettext(msgid) (msgid)
| ^
../../../gcc/gcc/cp/error.c:52:56: note: in expansion of macro '_'
52 | #define M_(msgid) (pp_translate_identifiers (cxx_pp) ? _(msgid) :
(msgid))
|^
../../../gcc/gcc/cp/error.c:799:24: note: in expansion of macro 'M_'
799 | pp_printf (pp, M_(""), variety);
|^~
make[1]: *** [Makefile:4453: all-gcc] Error 2
make: *** [Makefile:979: all] Error 2
