[Bug libstdc++/104191] New: Incorrect max_size() for node-based containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104191
Bug ID: 104191
Summary: Incorrect max_size() for node-based containers
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: frankhb1989 at gmail dot com
Target Milestone: ---
Case:
#include
#include
template
struct one_alloc : std::allocator
{
template struct rebind { using other = one_alloc;};
T* allocate(std::size_t n)
{
if(n > 1)
throw std::bad_array_new_length();
return std::allocator::allocate(n);
}
std::size_t max_size() const noexcept
{
return 1;
}
};
int main()
{
std::list> l;
l.push_back(0);
l.push_back(0);
assert(l.size() <= l.max_size());
}
This looks very wrong. The changes in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29134 seem too aggressive on
containers like list.
Logically, the container's max_size() should have nothing to do with the
allocator's max_size() (which limits the number of object of value_type in a
single allocation), and it should be solely determined by the internal node
count type. This is also consistent to the cases where the container's
size_type is always size_t (instead of size_type of the allocator).
There are some more subtleties concerned with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78448. Not sure if extra checks
are required to make it conforming.
[Bug c++/104182] [12 Regression] Wrong code since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104182 --- Comment #1 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:9718bc4b03c1a94f7cf64860bbc828aa53c56234 commit r12-6822-g9718bc4b03c1a94f7cf64860bbc828aa53c56234 Author: Jason Merrill Date: Sat Jan 22 17:11:54 2022 -0500 c++: array temporary at file scope [PR104182] This is the same issue as PR104031, but that patch doesn't fix this testcase because in this case, current_function_decl isn't set when we get to cp_genericize_target_expr. But there seems to be no need for is_local_temp to check for function scope; !TREE_STATIC should be enough. PR c++/104182 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_genericize_target_expr): Make sure nothing has set DECL_INITIAL on a TARGET_EXPR slot. * tree.cc (is_local_temp): Don't check DECL_CONTEXT. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/initlist127.C: New test.
[Bug c++/101072] [12 Regression] ICE in build_target_expr_with_type, at cp/tree.c:845 since r11-5681-gd9288bd28e24c755
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101072
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:053bcc97f4a59e3f2811b8a1edf60fd733a580a0
commit r12-6821-g053bcc97f4a59e3f2811b8a1edf60fd733a580a0
Author: Jason Merrill
Date: Thu Jan 20 05:45:02 2022 -0500
c++: constexpr and -fno-elide-constructors [PR101072]
We've been trying for a while to avoid TARGET_EXPRs in template code, but
there were still a few that snuck through, and the one in this case broke
the code that tried to handle it. Fixed by using IMPLICIT_CONV_EXPR, as we
have done elsewhere.
I also noticed that finish_compound_literal was assuming that all T{init}
were for aggregate T, and we got a few more TARGET_EXPRs from that. Fixed
by only messing with TARGET_EXPR if we actually have an aggregate init.
PR c++/101072
gcc/cp/ChangeLog:
* cp-tree.h (build_implicit_conv_flags): Declare.
* call.cc (build_implicit_conv_flags): Split out from...
(perform_implicit_conversion_flags): ...here.
* decl.cc (check_initializer): Use it.
* pt.cc (tsubst_copy_and_build): Remove TARGET_EXPR handling.
* semantics.cc (finish_compound_literal): Don't treat
scalar values like CONSTRUCTORs.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-empty14a.C: New test.
[Bug libstdc++/104190] arm-linux-gnueabi shows warnings of use-after-free of libstdc++?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104190 --- Comment #1 from cqwrteur --- Created attachment 52271 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52271&action=edit warnings
[Bug libstdc++/104190] New: arm-linux-gnueabi shows warnings of use-after-free?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104190 Bug ID: 104190 Summary: arm-linux-gnueabi shows warnings of use-after-free? Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: unlvsur at live dot com Target Milestone: ---
[Bug target/104189] New: [sparc] Inconsistent behavior for -mcpu=v9 -m32 on Linux and Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104189 Bug ID: 104189 Summary: [sparc] Inconsistent behavior for -mcpu=v9 -m32 on Linux and Solaris Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: glaubitz at physik dot fu-berlin.de CC: ebotcazou at gcc dot gnu.org, jrtc27 at jrtc27 dot com, matorola at gmail dot com Target Milestone: --- Target: sparc-*-*-* On Solaris and Linux, 32-bit V9 behave differently in regards to what size of atomic operations are supported. On Linux, the maximum size for an atomic operation on 32-bit V9 is 32 bits, on Solaris it is 64 bits. Moreover, setting -mcpu=ultrasparc3 makes the two match again. Linux: glaubitz@gcc202:~$ echo | gcc -m32 -mcpu=v9 -E -dM -|grep -i SWAP #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1 glaubitz@gcc202:~$ echo | gcc -m32 -mcpu=ultrasparc3 -E -dM -|grep -i SWAP #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1 glaubitz@gcc202:~$ Solaris: sysadmin@deimos:~$ echo | gcc -m32 -mcpu=v9 -E -dM -|grep -i SWAP #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1 sysadmin@deimos:~$ echo | gcc -m32 -mcpu=ultrasparc3 -E -dM -|grep -i SWAP #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1 sysadmin@deimos:~$ Unless there is a specific reason, it would nice if the behavior was consistent for both Linux and Solaris such that code that wants to use 64-bit atomics would behave the same on the two platforms.
[Bug c++/104184] [11/12 Regression] ICE Error reporting routines re-entered. xref_basetypes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104184 --- Comment #4 from Marc Glisse --- https://geometrica.saclay.inria.fr/team/Marc.Glisse/tmp/mybug.cc.xz (1.7M after compression still exceeds the limit) With -Wall -Wextra Internal compiler error: Error reporting routines re-entered. 0xec0348 xref_basetypes(tree_node*, tree_node*) ../../src/gcc/cp/decl.cc:15783 0x101d194 instantiate_class_template_1 ../../src/gcc/cp/pt.cc:11953 0x101ec31 instantiate_class_template(tree_node*) ../../src/gcc/cp/pt.cc:12311 0x10714d8 complete_type(tree_node*) ../../src/gcc/cp/typeck.cc:143 0xff0ad6 get_template_base ../../src/gcc/cp/pt.cc:23282 0xff2720 unify ../../src/gcc/cp/pt.cc:24348 0xff10d4 unify ../../src/gcc/cp/pt.cc:24499 0xfee75b unify_one_argument ../../src/gcc/cp/pt.cc:22472 0xfffd65 type_unification_real ../../src/gcc/cp/pt.cc:22595 0x1019da9 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node* const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool, bool) ../../src/gcc/cp/pt.cc:21923 0xe146d9 add_template_candidate_real ../../src/gcc/cp/call.cc:3544 0xe15633 add_template_candidate ../../src/gcc/cp/call.cc:3632 0xe15633 add_candidates ../../src/gcc/cp/call.cc:6165 0xe1c362 add_candidates ../../src/gcc/cp/call.cc:6051 0xe1c362 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int) ../../src/gcc/cp/call.cc:11012 0x1039e3d finish_call_expr(tree_node*, vec**, bool, bool, int) ../../src/gcc/cp/semantics.cc:2788 0xfe96d4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) ../../src/gcc/cp/pt.cc:20780 0xff5e8c tsubst(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.cc:16162 0x100494e tsubst_template_args(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.cc:13423 0xff635e tsubst(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.cc:15461
[Bug target/104188] [11/12 Regression] gcc omitting AVX-512 broadcast instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104188 --- Comment #10 from Zbynek Vyskovsky --- Thanks for quick fix!
[Bug c++/104184] [11/12 Regression] ICE Error reporting routines re-entered. xref_basetypes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104184
--- Comment #3 from Marc Glisse ---
comment #1 actually reduces to
struct voider {
using type = void;
};
template struct rename : P {};
template using ignore = voider;
template typename ignore::type>::type g(T a) {}
void f() { g(1); }
(still questionable and rejected by clang, I think I'll also attach the
compressed initial preprocessed file, in case the reductions hit different
bugs)
[Bug target/104172] [9/10/11/12 Regression] ppc64le mangling ICE with -flto -ffat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104172 Orion Poplawski changed: What|Removed |Added CC||orion at cora dot nwra.com --- Comment #7 from Orion Poplawski --- I believe this is causing the ccache compile failure in Fedora rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1881086
[Bug target/104188] [11/12 Regression] gcc omitting AVX-512 broadcast instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104188 H.J. Lu changed: What|Removed |Added Keywords||patch --- Comment #9 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589109.html
[Bug tree-optimization/104156] [12 Regression] -fcompare-debug failure with -O2 -funswitch-loops since r12-4526-gd8edfadfc7a9795b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104156 --- Comment #9 from Chengnian Sun --- Thanks, Andrew. What about -flto? Does GCC still guarantee such a compilation consistency wrt to debug info in the presence of -flto? If yes, I can enable this flag for several testing runs. Thanks.
[Bug c/92479] missing warnings for unreachable codes with break (i.e. revive the subset of -Wunreachable-code that fits under clang's -Wunreachable-code-break)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92479
--- Comment #14 from Eric Gallager ---
(In reply to David Binderman from comment #12)
> Interestingly, both gcc and clang have nothing to say about this code:
>
> extern void g( int);
>
> void f( int a)
> {
> if (a >= 0)
> {
> if (a < 0)
> {
> g(a);
> }
> }
> }
>
> $ /home/dcb/gcc/results/bin/gcc -c -g -O2 -Wall -Wextra -Wunreachable-code
> jan20e.cc
> $
>
> cppcheck finds the problem:
>
> $ cppcheck --enable=all jan20e.cc
> Checking jan20e.cc ...
> jan20e.cc:10:9: warning: Opposite inner 'if' condition leads to a dead code
> block. [oppositeInnerCondition]
> if (a < 0)
> ^
> jan20e.cc:8:8: note: outer condition: a>=0
> if (a >= 0)
>^
That's bug 82100, which is already linked under "See Also"
[Bug target/101785] aarch64-linux-android is not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101785 --- Comment #9 from cqwrteur --- Created attachment 52270 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52270&action=edit fix linker searching issue for aarch64-linux-android
[Bug target/101785] aarch64-linux-android is not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101785 --- Comment #8 from cqwrteur --- (In reply to Andrew Pinski from comment #5) > *** Bug 104155 has been marked as a duplicate of this bug. *** https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589107.html Hi Andrew pinski, Can you review this patch?
[Bug libstdc++/104166] Implement C++20 std::format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104166 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2022-01-22 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/104179] Truncated representation of character arrays as non-type template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104179 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-01-22 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/104156] [12 Regression] -fcompare-debug failure with -O2 -funswitch-loops since r12-4526-gd8edfadfc7a9795b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104156 --- Comment #8 from Andrew Pinski --- (In reply to Chengnian Sun from comment #7) > A quick question. Besides the flags `-fcompare-debug -g3 -O3`, are there any > other flags I should enable to better/faster find such -fcompare-debug > failures? -fcompare-debug failures will be spread out through the compiler so I really doubt there are any flag besides -O2 or -O3 will help in finding the failures really. Most passes are designed to ignore the debug information statements (instructions in the case of RTL) but some mistakes happen so I doubt there is any pattern to them really.
[Bug c++/104173] [12 Regression] wrong overload resolution for ref-qualifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104173 --- Comment #3 from Andrew Pinski --- (In reply to Patrick Palka from comment #2) > Interestingly, here's a non-template variant of the testcase that seems to > be rejected by every GCC version: Yes this one is definitely interesting. Changing applicationName to be non-static choses a different overload too.
[Bug c++/104182] [12 Regression] Wrong code since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104182 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/104188] [11/12 Regression] gcc omitting AVX-512 broadcast instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104188 --- Comment #8 from H.J. Lu --- Created attachment 52269 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52269&action=edit A patch This this.
[Bug target/104188] [11/12 Regression] gcc omitting AVX-512 broadcast instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104188
--- Comment #7 from H.J. Lu ---
Since vbroadcastf32x4 != vbroadcastss, we can't replace vbroadcastf32x4
with {1to16} broadcast.
[Bug target/104188] [11/12 Regression] gcc omitting AVX-512 broadcast instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104188 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |11.3 Summary|gcc omitting AVX-512|[11/12 Regression] gcc |broadcast instruction |omitting AVX-512 broadcast ||instruction --- Comment #6 from Jakub Jelinek --- Started with r11-4203-g7026bb9504eb0f95e114f832cd6dd14302376861
[Bug target/104188] gcc omitting AVX-512 broadcast instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104188
Jakub Jelinek changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Jakub Jelinek ---
I came up with:
#include
union U {
float m[4][4];
__m128 r[4];
__m512 s;
};
__attribute__((noipa)) void
foo (union U *x, union U *a, union U *b)
{
__m512 c = _mm512_loadu_ps (&a->s);
__m512 d = _mm512_broadcast_f32x4 (b->r[0]);
__m512 e = _mm512_broadcast_f32x4 (b->r[1]);
__m512 f = _mm512_broadcast_f32x4 (b->r[2]);
__m512 g = _mm512_broadcast_f32x4 (b->r[3]);
__m512 h = _mm512_mul_ps (_mm512_permute_ps (c, 0x00), d);
h = _mm512_fmadd_ps (_mm512_permute_ps (c, 0x55), e, h);
h = _mm512_fmadd_ps (_mm512_permute_ps (c, 0xaa), f, h);
h = _mm512_fmadd_ps (_mm512_permute_ps (c, 0xff), g, h);
_mm512_storeu_ps (&x->s, h);
}
int
main ()
{
union U a = { .m = { { 1.0f, 2.0f, 3.0f, 4.0f },
{ 5.0f, 6.0f, 7.0f, 8.0f },
{ 9.0f, 10.0f, 11.0f, 12.0f },
{ 13.0f, 14.0f, 15.0f, 16.0f } } };
union U b = { .m = { { 17.0f, 18.0f, 19.0f, 20.0f },
{ 21.0f, 22.0f, 23.0f, 24.0f },
{ 25.0f, 26.0f, 27.0f, 28.0f },
{ 29.0f, 30.0f, 31.0f, 32.0f } } };
union U c;
foo (&c, &a, &b);
if (c.m[0][0] != 250.0f || c.m[0][1] != 260.0f || c.m[0][2] != 270.0f ||
c.m[0][3] != 280.0f)
__builtin_abort ();
if (c.m[1][0] != 618.0f || c.m[1][1] != 644.0f || c.m[1][2] != 670.0f ||
c.m[1][3] != 696.0f)
__builtin_abort ();
if (c.m[2][0] != 986.0f || c.m[2][1] != 1028.0f || c.m[2][2] != 1070.0f ||
c.m[2][3] != 1112.0f)
__builtin_abort ();
if (c.m[3][0] != 1354.0f || c.m[3][1] != 1412.0f || c.m[3][2] != 1470.0f ||
c.m[3][3] != 1528.0f)
__builtin_abort ();
return 0;
}
[Bug target/104188] gcc omitting AVX-512 broadcast instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104188
--- Comment #4 from Zbynek Vyskovsky ---
Sure, the code:
#include
#ifndef NO_VECTORIZE
#ifdef __x86_64__
#include
#include
#endif
#ifdef __aarch64__
#include
#endif
#endif
typedef union Mat44 {
float m[4][4];
#ifndef NO_VECTORIZE
#ifdef __x86_64__
__m128 row[4];
__m256 rowDuet[2];
__m512 rowQuad;
#endif
#ifdef __aarch64__
float32x4_t row[4];
#endif
#endif
} Mat44;
__attribute__((noipa)) void matmult_avx512(union Mat44 *out, const Mat44 *a,
const Mat44 *b)
{
__m512 a0123 = _mm512_loadu_ps(a->m[0]);
__m512 b = _mm512_broadcast_f32x4(b->row[0]);
__m512 b = _mm512_broadcast_f32x4(b->row[1]);
__m512 b = _mm512_broadcast_f32x4(b->row[2]);
__m512 b = _mm512_broadcast_f32x4(b->row[3]);
__m512 result = _mm512_mul_ps(_mm512_permute_ps(a0123, 0x00), b);
result = _mm512_fmadd_ps(_mm512_permute_ps(a0123, 0x55), b,
result);
result = _mm512_fmadd_ps(_mm512_permute_ps(a0123, 0xaa), b,
result);
result = _mm512_fmadd_ps(_mm512_permute_ps(a0123, 0xff), b,
result);
_mm512_storeu_ps(out->m[0], result);
}
__attribute__((noipa)) void matmult_ref(Mat44 *out, const Mat44 *a, const Mat44
*b)
{
Mat44 t;
for (int i = 0; i < 4; i++) {
for (int j = 0; j < 4; j++) {
t.m[i][j] = a->m[i][0]*b->m[0][j] +
a->m[i][1]*b->m[1][j] + a->m[i][2]*b->m[2][j] + a->m[i][3]*b->m[3][j];
}
}
*out = t;
}
int main(void)
{
Mat44 in = { m: { { 1, 2, 3, 4 }, { 5, 6, 7, 8 }, { 9, 10, 11, 12 }, {
13, 14, 15, 16 } } };
Mat44 avx512_out;
Mat44 ref_out;
matmult_ref(&ref_out, &in, &in);
matmult_avx512(&avx512_out, &in, &in);
for (int r = 0; r < 4; ++r) {
printf("%5.0f %5.0f %5.0f %5.0f %5.0f %5.0f %5.0f
%5.0f\n", avx512_out.m[r][0], avx512_out.m[r][1], avx512_out.m[r][2],
avx512_out.m[r][3], ref_out.m[r][0], ref_out.m[r][1], ref_out.m[r][2],
ref_out.m[r][3]);
}
return 0;
}
Output (note the repeating first column on first side, caused by duplicating
single element instead of four):
90909090 90 100 110 120
202 202 202 202202 228 254 280
314 314 314 314314 356 398 440
426 426 426 426426 484 542 600
[Bug other/104176] [12 Regression] opts-global.cc:420:62: error: unquoted option name '--enable-plugin' in format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104176 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug other/104176] [12 Regression] opts-global.cc:420:62: error: unquoted option name '--enable-plugin' in format
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104176
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:9ea451e27934939d490553d3a394e8cbf9cefda8
commit r12-6819-g9ea451e27934939d490553d3a394e8cbf9cefda8
Author: Jakub Jelinek
Date: Sat Jan 22 19:04:41 2022 +0100
ootstrap: Fix bootstrap with --disable-plugin [PR104176]
With --disable-plugin, bootstrap fails on x86_64-linux or probably
all other targets with:
../../gcc/opts-global.cc: In function âvoid
handle_common_deferred_options()â:
../../gcc/opts-global.cc:420:62: error: unquoted option name
â--enable-pluginâ in format [-Werror=format-diag]
420 | error ("plugin support is disabled; configure with
--enable-plugin");
|
^~~
../../gcc/opts-global.cc:428:62: error: unquoted option name
â--enable-pluginâ in format [-Werror=format-diag]
428 | error ("plugin support is disabled; configure with
--enable-plugin");
|
^~~
The following patch fixes that.
2022-01-22 Jakub Jelinek
PR other/104176
* opts-global.cc (handle_common_deferred_options): Quote
--enable-plugin in diagnostics to avoid -Werror=format-diag.
[Bug demangler/99935] Stack exhaustion demangling rust mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99935 Andrew Pinski changed: What|Removed |Added CC||terrynini38514 at gmail dot com --- Comment #8 from Andrew Pinski --- *** Bug 100968 has been marked as a duplicate of this bug. ***
[Bug demangler/100968] libiberty: stuck in infinite loop in nm-new while demangling rust symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100968 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- Dup of bug 99935. *** This bug has been marked as a duplicate of bug 99935 ***
[Bug demangler/99935] Stack exhaustion demangling rust mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99935 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-22
[Bug target/104188] gcc omitting AVX-512 broadcast instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104188 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- So, can you please turn add main to your testcase, add __attribute__((noipa)) on the function and add a caller that prepares arguments and check the result?
[Bug demangler/99935] Stack exhaustion demangling rust mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99935 Andrew Pinski changed: What|Removed |Added CC||featherrain26 at gmail dot com --- Comment #7 from Andrew Pinski --- *** Bug 98889 has been marked as a duplicate of this bug. ***
[Bug demangler/98889] stack overflow in cxxfilt, peek, rust-demangle.c:85
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98889 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 99935. *** This bug has been marked as a duplicate of bug 99935 ***
[Bug demangler/99935] Stack exhaustion demangling rust mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99935 Andrew Pinski changed: What|Removed |Added CC||eliz at gnu dot org --- Comment #6 from Andrew Pinski --- *** Bug 101779 has been marked as a duplicate of this bug. ***
[Bug demangler/101779] Compilation of rust-demangle.c fails on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101779 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Andrew Pinski --- Dup of bug 99935. *** This bug has been marked as a duplicate of bug 99935 ***
[Bug demangler/99935] Stack exhaustion demangling rust mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99935 --- Comment #5 from Andrew Pinski --- *** Bug 104186 has been marked as a duplicate of this bug. ***
[Bug demangler/104186] Stack overflow in demangle_type() -> print_str() in libiberty/rust-demangle.c:869, cxxfilt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104186 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 99935. *** This bug has been marked as a duplicate of bug 99935 ***
[Bug demangler/99935] Stack exhaustion demangling rust mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99935 Andrew Pinski changed: What|Removed |Added CC||sanjayr at ymail dot com --- Comment #4 from Andrew Pinski --- *** Bug 104185 has been marked as a duplicate of this bug. ***
[Bug demangler/104185] Stack Overflow in str_buf_append(): rust-demangle.c:1493 in cxxfilt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104185 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 99935. *** This bug has been marked as a duplicate of bug 99935 ***
[Bug target/104188] gcc omitting AVX-512 broadcast instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104188
--- Comment #2 from Zbynek Vyskovsky ---
> {1to16} says to broadcast from first element to all 16.
The vbroadcastf32x4 is supposed to copy first four elmenents to 4-7, 8-11 and
12-15 .
> Why do you think this is wrong code?
It doesn't work. It produces the same number for each column for the same row,
likely as a result of above as it uses single element to multiply instead of
four different elements.
[Bug ipa/104187] Call site specific attribute to control inliner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104187 Andrew Pinski changed: What|Removed |Added CC||marxin at gcc dot gnu.org Keywords||missed-optimization Severity|normal |enhancement Component|c |ipa
[Bug target/104188] gcc omitting AVX-512 broadcast instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104188
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2022-01-22
Ever confirmed|0 |1
Keywords||wrong-code
--- Comment #1 from Andrew Pinski ---
There is a broadcast as part of the other instruction, optimizing it correctly:
vfmadd132ps 16(%rdx){1to16}, %zmm1, %zmm2
{1to16} says to broadcast from first element to all 16.
Why do you think this is wrong code?
[Bug target/104188] New: gcc omitting AVX-512 broadcast instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104188
Bug ID: 104188
Summary: gcc omitting AVX-512 broadcast instruction
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kvr000 at gmail dot com
Target Milestone: ---
Hi,
there is a bug when generating AVX-512 instructions from intrinsics. The code
is generated correctly in gcc-10 but gcc-11 completely omits the
vbroadcastf32x4 .
gcc version: 11.2.0-7ubuntu2 - 11.2.0
Source code of minimal working example:
// Matrix 4*4 multiplication:
#ifndef NO_VECTORIZE
#ifdef __x86_64__
#include
#include
#endif
#ifdef __aarch64__
#include
#endif
#endif
union Mat44 {
float m[4][4];
#ifndef NO_VECTORIZE
#ifdef __x86_64__
__m128 row[4];
__m256 rowDuet[2];
__m512 rowQuad;
#endif
#ifdef __aarch64__
float32x4_t row[4];
#endif
#endif
};
void matmult_avx512(union Mat44 *out, union Mat44 *a, union Mat44 *b)
{
__m512 a0123 = _mm512_loadu_ps(a->m[0]);
__m512 b = _mm512_broadcast_f32x4(b->row[0]);
__m512 b = _mm512_broadcast_f32x4(b->row[1]);
__m512 b = _mm512_broadcast_f32x4(b->row[2]);
__m512 b = _mm512_broadcast_f32x4(b->row[3]);
__m512 result = _mm512_mul_ps(_mm512_permute_ps(a0123, 0x00), b);
result = _mm512_fmadd_ps(_mm512_permute_ps(a0123, 0x55), b,
result);
result = _mm512_fmadd_ps(_mm512_permute_ps(a0123, 0xaa), b,
result);
result = _mm512_fmadd_ps(_mm512_permute_ps(a0123, 0xff), b,
result);
_mm512_storeu_ps(out->m[0], result);
}
gcc-10 (correct):
endbr64
vmovups (%rsi), %zmm0
vbroadcastf32x4 (%rdx), %zmm6 // note here
vpermilps $0, %zmm0, %zmm1
vmulps %zmm6, %zmm1, %zmm1
vbroadcastf32x4 16(%rdx), %zmm5 // note here
vpermilps $85, %zmm0, %zmm2
vbroadcastf32x4 32(%rdx), %zmm4 // note here
vbroadcastf32x4 48(%rdx), %zmm3 // note here
vfmadd132ps %zmm5, %zmm1, %zmm2
vpermilps $170, %zmm0, %zmm1
vpermilps $255, %zmm0, %zmm0
vfmadd132ps %zmm4, %zmm2, %zmm1
vfmadd132ps %zmm3, %zmm1, %zmm0
vmovups %zmm0, (%rdi)
vzeroupper
ret
gcc-11 (missing vbroadcasatf32x4) :
endbr64
vmovups (%rsi), %zmm0
vpermilps $0, %zmm0, %zmm1
vmulps (%rdx){1to16}, %zmm1, %zmm1
vpermilps $85, %zmm0, %zmm2
vfmadd132ps 16(%rdx){1to16}, %zmm1, %zmm2
vpermilps $170, %zmm0, %zmm1
vpermilps $255, %zmm0, %zmm0
vfmadd132ps 32(%rdx){1to16}, %zmm2, %zmm1
vfmadd132ps 48(%rdx){1to16}, %zmm1, %zmm0
vmovups %zmm0, (%rdi)
vzeroupper
ret
[Bug c/104187] New: Call site specific attribute to control inliner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104187
Bug ID: 104187
Summary: Call site specific attribute to control inliner
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david.bolvansky at gmail dot com
Target Milestone: ---
It could be useful to have more control over inlining. Use cases:
int foo();
void bar();
int g;
void test()
{
g = __builtin_always_inline(foo()); // force inlining of foo() here
__builtin_noinline(bar()); // never inline bar to this function
}
[Bug other/104181] [12 Regression] The redundant build.log file in the root directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104181 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Keywords||build See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103331 --- Comment #3 from Eric Gallager --- How does build.log even get generated, anyways? Wondering for bug 103331...
[Bug analyzer/104159] ICE: in finalize, at vector-builder.h:513 with -O -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104159 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from David Malcolm --- Should be fixed by the above patch.
[Bug analyzer/104150] New test case gcc.dg/analyzer/pr104089.c fails after its introduction in r12-6700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104150 David Malcolm changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from David Malcolm --- Thanks for filing this bug; hopefully the above patch fixes it. Marking as resolved; please reopen it if I messed up.
[Bug analyzer/104150] New test case gcc.dg/analyzer/pr104089.c fails after its introduction in r12-6700
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104150 --- Comment #1 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:a1fb81bda97014ba14d55c4c2e143d31ffe2e264 commit r12-6818-ga1fb81bda97014ba14d55c4c2e143d31ffe2e264 Author: David Malcolm Date: Fri Jan 21 16:50:11 2022 -0500 testsuite: guard usage of _Float16 in analyzer test [PR104150] gcc/testsuite/ChangeLog: PR analyzer/104150 * gcc.dg/analyzer/pr104089.c: Add "dg-add-options float16" and "dg-require-effective-target float16" directives. Signed-off-by: David Malcolm
[Bug analyzer/104159] ICE: in finalize, at vector-builder.h:513 with -O -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104159 --- Comment #4 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:45b999f642a531c083c982dda79fa6ad65730a7c commit r12-6817-g45b999f642a531c083c982dda79fa6ad65730a7c Author: David Malcolm Date: Fri Jan 21 09:56:56 2022 -0500 analyzer: fix ICE on vector casts [PR104159] PR analyzer/104159 describes an ICE attempting to convert a vector_cst, which occurs when symbolically executing within a recursive call on: _4 = BIT_FIELD_REF ; _1 = VIEW_CONVERT_EXPR(_4); where the BIT_FIELD_REF leads to a get_or_create_cast from VEC to VEC which get_code_for_cast erroneously picks NOP_EXPR for the cast, leading to a bogus input to the VIEW_CONVERT_EXPR. This patch fixes the issue by giving up on attempts to cast symbolic values of vector types, treating the result of such casts as unknowable. gcc/analyzer/ChangeLog: PR analyzer/104159 * region-model-manager.cc (region_model_manager::get_or_create_cast): Bail out if the types are the same. Don't attempt to handle casts involving vector types. gcc/testsuite/ChangeLog: PR analyzer/104159 * gcc.dg/analyzer/torture/pr104159.c: New test. Signed-off-by: David Malcolm
[Bug demangler/104186] New: Stack overflow in demangle_type() -> print_str() in libiberty/rust-demangle.c:869, cxxfilt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104186 Bug ID: 104186 Summary: Stack overflow in demangle_type() -> print_str() in libiberty/rust-demangle.c:869, cxxfilt Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: sanjayr at ymail dot com Target Milestone: --- Created attachment 52268 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52268&action=edit Commandline input for the crash (cxxfilt < PoV) Hello, While evaluating our new fuzzer on cxxfilt, we found several stack overflows in libiberty/rust-demangle.c. This issue is specific to a stack overflow in demangle_type(), which internally called a macro PRINT() that unfolds in calling to print_str(). Looks like, the copy operation in this function does not check buf length properly. We compiled the utility (binutils cxxfilt) with ASAN. Comandline: cxxfilt < input_file (PoV that is attached) ASan outupt: === status: 1 sanitizer: ASAN error class: stack-overflow location:__interceptor_strlen.part.0 in /home/xyzz/build/llvm_tools/llvm-11.0.0.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:370:31 backtrace: #0 46ec57 __interceptor_strlen.part.0 in /home/xyzz/build/llvm_tools/llvm-11.0.0.src/projects/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:370:31 #1 857cb1 demangle_type in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:869:7 #3 853d83 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:747:7 #4 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #5 8542e4 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:774:11 #6 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #7 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #8 8542e4 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:774:11 #9 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #10 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #11 8542e4 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:774:11 #12 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #13 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #14 8542e4 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:774:11 #15 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #16 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #17 8542e4 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:774:11 #18 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #19 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #20 8542e4 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:774:11 #21 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #22 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #23 8542e4 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/buil
[Bug fortran/104127] [9/10/11/12 Regression] ICE in get_array_charlen, at fortran/trans-array.c:7244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104127 --- Comment #6 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:6c1a93102b41a558f3ad49a7c66015257535c747 commit r12-6816-g6c1a93102b41a558f3ad49a7c66015257535c747 Author: Harald Anlauf Date: Thu Jan 20 22:36:50 2022 +0100 Fortran: fix simplification of TRANSFER for zero-sized character array result gcc/fortran/ChangeLog: PR fortran/104127 * simplify.cc (gfc_simplify_transfer): Ensure that the result typespec is set up for TRANSFER with MOLD of type CHARACTER including character length even if the result is a zero-sized array. gcc/testsuite/ChangeLog: PR fortran/104127 * gfortran.dg/transfer_simplify_11.f90: Fix logic. * gfortran.dg/transfer_simplify_13.f90: New test.
[Bug middle-end/103641] [11/12 regression] Severe compile time regression in SLP vectorize step
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103641 --- Comment #20 from Roger Sayle --- IMHO, the problem is in tree-vect-patterns.cc's vect_synth_mult_by_constant. The comment above line 3054 reads: /* Use MAX_COST here as we don't want to limit the sequence on rtx costs. The vectorizer's benefit analysis will decide whether it's beneficial to do this. */ bool possible = choose_mult_variant (mode, hwval, &alg, &variant, MAX_COST); By using MAX_COST here, synth_mult is being allowed to take an unbounded amount of time, considering all possible permutations/implementations to find an optimal synthetic multiply sequence. A more pragmatic bound might be to compare the target's vector_multiply cost, or failing that use an arbitrary, but reasonable limit, say COSTS_N_INSNS(8) machine instructions. In the worst case, if it takes 100 instructions to do a vector multiply, then the loop probably shouldn't be vectorized.
[Bug demangler/104185] New: Stack Overflow in str_buf_append(): rust-demangle.c:1493 in cxxfilt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104185 Bug ID: 104185 Summary: Stack Overflow in str_buf_append(): rust-demangle.c:1493 in cxxfilt Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: sanjayr at ymail dot com Target Milestone: --- Created attachment 52267 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52267&action=edit PoV input for the above mentioned crash. Hello, While evaluating our new fuzzer on cxxfilt (binutils 2.37), we found a stack overflow in str_buf_append() of libiberty/rust-demangle.c:1493. This function calls memcpy, which probably copies more data to the destination that it can hold. Commit id (of github repo of binutils-gdb/libiberty/rust-demangle.c): 1657026ccd commandline: cxxfilt < input_file (PoV) ASan enabled binary execution output: sanitizer: ASAN error class: stack-overflow location:__asan_memcpy in /home/xyzz/build/llvm_tools/llvm-11.0.0.src/projects/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 backtrace: #0 4c120e __asan_memcpy in /home/xyzz/build/llvm_tools/llvm-11.0.0.src/projects/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:22:3 #1 85735b str_buf_append in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:1493:3 #2 85735b str_buf_demangle_callback in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:1500:3 #3 85832e print_str in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:273:5 #4 85832e demangle_type in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:877:7 #5 853d83 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:747:7 #6 8542e4 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:774:11 #7 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #8 8542e4 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:774:11 #9 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #10 8542e4 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:774:11 #11 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #12 8542e4 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:774:11 #13 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #14 8542e4 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:774:11 #15 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #16 8542e4 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:774:11 #17 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #18 8542e4 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:774:11 #19 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #20 8542e4 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:774:11 #21 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:751:11 #22 8542e4 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/build/libiberty/../../libiberty/rust-demangle.c:774:11 #23 853e11 demangle_path in /home/xyzz/MyProject/remote_fuzz_suite/target_src/binutils-gdb/bui
[Bug c++/104180] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104180 Jakub Jelinek changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- If it is because of -gstatement-frontiers, I've ran out of ideas how to fix them. So unless Alexandre is willing to look at it, I'd suggest to at least turn -gstatement-frontiers off by default.
[Bug c++/104182] [12 Regression] Wrong code since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104182 Andrew Pinski changed: What|Removed |Added Severity|normal |critical
[Bug c++/104180] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104180 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100733, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103788 --- Comment #3 from Andrew Pinski --- Similar in nature to PR 100733 and PR 103788.
[Bug c++/104180] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104180
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |c++
--- Comment #2 from Andrew Pinski ---
[apinski@xeond2 src]$ diff -up t.cc.*original t.gk.cc.*original |less
--- t.cc.005t.original 2022-01-22 03:44:26.901343652 -0800
+++ t.gk.cc.005t.original 2022-01-22 03:44:27.005343663 -0800
@@ -6,13 +6,19 @@
{
unsigned int b;
+ # DEBUG BEGIN STMT;
unsigned int b;
+ # DEBUG BEGIN STMT;
<;
:;
+ # DEBUG BEGIN STMT;
<;
+(void) (a[b] = # DEBUG BEGIN STMT;
+a[b + 1];) >;
+ # DEBUG BEGIN STMT;
<>;
+ # DEBUG BEGIN STMT;
goto ;
}
And then we gimplify:
+ # DEBUG BEGIN_STMT
+ # DEBUG BEGIN_STMT
b = 3;
:
- _1 = b + 1;
- _2 = a[_1];
- a[b] = _2;
+ # DEBUG BEGIN_STMT
+ _1 = &a[b];
+ # DEBUG BEGIN_STMT
+ _2 = b + 1;
+ _3 = a[_2];
+ *_1 = _3;
+ # DEBUG BEGIN_STMT
b = b + 4294967295;
+ # DEBUG BEGIN_STMT
goto ;
[Bug target/104183] gcc6 error with building icu for ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104183 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX Keywords||rejects-valid Last reconfirmed||2022-1-22 --- Comment #1 from Iain Sandoe --- Yes, I can repeat this, it is quite possible that there are several/many C++11 bugs on this branch, however GCC-6 branch has been closed for some time now (so we cannot update it here). If you can determine which patch(es) fixed this on the 7 branch then perhaps you could back port them locally for the macports GCC-6.5 branch.
[Bug tree-optimization/104178] [12 Regreession] -fcompare-debug failure at -O3 -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104178 Andrew Pinski changed: What|Removed |Added Component|middle-end |tree-optimization --- Comment #4 from Andrew Pinski --- The first difference shows up in 194t.dom3 .
[Bug c++/104184] [11/12 Regression] ICE Error reporting routines re-entered. xref_basetypes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104184 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |11.3
[Bug c++/104184] [11/12 Regression] ICE Error reporting routines re-entered. xref_basetypes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104184 --- Comment #2 from Marc Glisse --- And the stack trace for comment #1 Internal compiler error: Error reporting routines re-entered. 0xff6b0d tsubst(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.cc:16068 0xff5f6d tsubst(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.cc:16055 0x100494e tsubst_template_args(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.cc:13423 0xff635e tsubst(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.cc:15461 0xff5f6d tsubst(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.cc:16055 0x100494e tsubst_template_args(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.cc:13423 0xff635e tsubst(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.cc:15461 0x1005a77 tsubst_decl ../../src/gcc/cp/pt.cc:14815 0x101d842 instantiate_class_template_1 ../../src/gcc/cp/pt.cc:12076 0x101ec31 instantiate_class_template(tree_node*) ../../src/gcc/cp/pt.cc:12311 0x10714d8 complete_type(tree_node*) ../../src/gcc/cp/typeck.cc:143 0x107163d complete_type_or_maybe_complain(tree_node*, tree_node*, int) ../../src/gcc/cp/typeck.cc:156 0xff73d0 tsubst(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.cc:16081 0x100494e tsubst_template_args(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.cc:13423 0xff635e tsubst(tree_node*, tree_node*, int, tree_node*) ../../src/gcc/cp/pt.cc:15461 0xee6e31 dump_template_bindings ../../src/gcc/cp/error.cc:486 0xee0619 dump_function_decl ../../src/gcc/cp/error.cc:1805 0xee8602 decl_to_string ../../src/gcc/cp/error.cc:3225 0xee8602 cp_printer ../../src/gcc/cp/error.cc:4396 0x281b82f pp_format(pretty_printer*, text_info*) ../../src/gcc/pretty-print.cc:1475
[Bug c++/104184] [11/12 Regression] ICE Error reporting routines re-entered. xref_basetypes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104184
--- Comment #1 from Marc Glisse ---
A different reduction from the same code. This one does not compile with clang
anymore. ICEs with -Wall -W, but not if I remove one of them.
using mp_false = struct mp_identity { using type = void; };
template using mp_if_c = typename T ::type;
template using mp_at_c = typename mp_if_c::type;
template using make_arg_list = List;
template using make_parameter_spec_items = SpecSeq;
template struct argument_pack {
using type =
mp_at_c::type,
typename Parameters::deduced_listboosttag_keyword_arg,
mp_false>::type,
0>;
};
void no_exude();
template using boost_param_result_465refine_mesh_3 = mp_identity;
template
typename boost_param_result_465refine_mesh_3<
typename argument_pack::type>::type
refine_mesh_3(ParameterArgumentType0, ParameterArgumentType1,
ParameterArgumentType2, ParameterArgumentType3,
ParameterArgumentType4, ParameterArgumentType5 a5) {}
int verify___trans_tmp_1, image_domain;
struct Tester {
template
void verify(C3t3 c3t3, Domain domain, Criteria criteria, Domain_type_tag) {
refine_mesh_3(c3t3, domain, criteria, no_exude, verify___trans_tmp_1,
verify___trans_tmp_1);
}
} image_c3t3;
struct Image_tester : Tester {
void image() {
void criteria();
verify(image_c3t3, image_domain, criteria, int());
}
};
[Bug debug/104180] [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104180 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2022-01-22 Target Milestone|--- |10.4 Status|UNCONFIRMED |NEW CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r11-963-g80d6f89e78fc3b772701988cc73aa8e8006283be which has been backported to 10.x in r10-8355-g7d919c33fbd29
[Bug c++/104184] New: [11/12 Regression] ICE Error reporting routines re-entered. xref_basetypes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104184
Bug ID: 104184
Summary: [11/12 Regression] ICE Error reporting routines
re-entered. xref_basetypes
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
This is reduced from valid code (I think) and it still compiles with "g++ -c
-w" or "clang++ -c", although the undefined inline function seems to play a
strong role, so this may not be exactly the same as the original ICE. The call
stack starts the same (xref_basetypes) but in the original it went through
"unify" and only failed with gcc-12 (not 11) with -Wall and -Wextra.
template using mp_size_t = int;
template struct mp_list;
template struct mp_identity { using type = int; };
template struct mp_inherit : T... {};
template using mpmf_wrap = mp_identity;
template using mpmf_unwrap = typename T::type;
template struct mp_map_find_impl;
template class M, class... T, class K>
struct mp_map_find_impl, K> {
using U = mp_inherit...>;
static mp_identity f(mp_identity *);
using type = mpmf_unwrap;
};
template
using mp_map_find = typename mp_map_find_impl::type;
template using mp_second = int;
template struct mp_at_c_impl {
using _map = mp_list, int>;
using type = mp_second>>;
};
template using make_arg_list = mp_identity;
template struct argument_pack {
using type = typename mp_at_c_impl<
typename make_arg_list::type,
0>::type;
};
struct parameters {
typedef mp_list<> parameter_spec;
};
template
using boost_param_result_39refine_mesh_3 = mp_identity;
template
inline typename boost_param_result_39refine_mesh_3<
typename argument_pack::type>::type
refine_mesh_3();
int main() { refine_mesh_3(); }
Internal compiler error: Error reporting routines re-entered.
0xec0348 xref_basetypes(tree_node*, tree_node*)
../../src/gcc/cp/decl.cc:15783
0x101d194 instantiate_class_template_1
../../src/gcc/cp/pt.cc:11953
0x101ec31 instantiate_class_template(tree_node*)
../../src/gcc/cp/pt.cc:12311
0x10714d8 complete_type(tree_node*)
../../src/gcc/cp/typeck.cc:143
0x102d168 lookup_base(tree_node*, tree_node*, int, base_kind*, int)
../../src/gcc/cp/search.cc:229
0xe0ea26 standard_conversion
../../src/gcc/cp/call.cc:1403
0xe12484 implicit_conversion_1
../../src/gcc/cp/call.cc:2031
0xe12484 implicit_conversion
../../src/gcc/cp/call.cc:2131
0xe13d7e add_function_candidate
../../src/gcc/cp/call.cc:2465
0xe15349 add_candidates
../../src/gcc/cp/call.cc:6182
0xe1c362 add_candidates
../../src/gcc/cp/call.cc:6051
0xe1c362 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../src/gcc/cp/call.cc:11012
0x1039e3d finish_call_expr(tree_node*, vec**,
bool, bool, int)
../../src/gcc/cp/semantics.cc:2788
0xfe96d4 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.cc:20780
0xff5e8c tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:16162
0x100494e tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:13423
0xff635e tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.cc:15461
0x1005a77 tsubst_decl
../../src/gcc/cp/pt.cc:14815
0x101d842 instantiate_class_template_1
../../src/gcc/cp/pt.cc:12076
0x101ec31 instantiate_class_template(tree_node*)
../../src/gcc/cp/pt.cc:12311
[Bug other/104181] [12 Regression] The redundant build.log file in the root directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104181 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0f4f9c0085eb68e0546804b156aa8bb388f2d3e0 commit r12-6815-g0f4f9c0085eb68e0546804b156aa8bb388f2d3e0 Author: Jakub Jelinek Date: Sat Jan 22 12:03:14 2022 +0100 toplevel: Remove accedentally checked in file This has been added in r12-6342-ge7a7dbb5ca5dd69689f1a probably by accident. 2022-01-22 Jakub Jelinek PR other/104181 * build.log: Remove.
[Bug target/104172] [9/10/11/12 Regression] ppc64le mangling ICE with -flto -ffat-lto-objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104172
--- Comment #6 from Jakub Jelinek ---
>From my side, I think best would be just to partially revert
r9-1033-gc765c8cb73b0bb91e9f0401ab6567b6218b910e5
(all the rs6000_passes_ieee128 and ieee128_mangling_gcc_8_1 related stuff in
there, don't set those and when testing assume false).
Rationale, -mabi=ieeelongdouble has been an undocumented unsupported option
before GCC 8, it is true it was "supported" option in 8.1, but still far from
being fully usable both because of the missing libstdc++ support and important
bugfixes. And in 8.2 the ABI we have now has been backported -
r8-8265-gd8f96ab114a977d9 . So, we are taking a lot of pain for compatibility
with something that likely nobody used, glibc support wasn't there until the
2.32 release done after 8.2 was released.
If not and we do want the pain, then all the mangling has to be done before
free_lang_data (so can't be driven by rs6000_passes_ieee128 which is RTL-ish
time, but on whether u9__ieee128 has been emitted into the mangled name),
ideally through a target hook in mangle_decl where it also does the
record_mangling (decl, G.need_abi_warning);
if (!G.need_abi_warning)
return;
flag_abi_version = flag_abi_compat_version;
id2 = mangle_decl_string (decl);
id2 = targetm.mangle_decl_assembler_name (decl, id2);
flag_abi_version = save_ver;
if (id2 != id)
note_mangling_alias (decl, id2);
stuff (perhaps right before that if (!G.need_abi_warning) spot).
Note, some Fedora packages fail with weirdo errors like:
{standard input}: Assembler messages:
{standard input}:43720: Error: junk at end of line, first unrecognized
character is `['
{standard input}:43721: Error: expected comma after "operator"
{standard input}:45644: Error: junk at end of line, first unrecognized
character is `.'
{standard input}:45645: Error: expected comma after "__ct_base"
{standard input}:46051: Error: junk at end of line, first unrecognized
character is `.'
{standard input}:46052: Error: expected comma after "__ct_base"
{standard input}:46794: Error: junk at end of line, first unrecognized
character is `.'
{standard input}:46795: Error: expected comma after "__ct_base"
{standard input}:48803: Error: junk at end of line, first unrecognized
character is `='
{standard input}:48804: Error: expected comma after "operator"
{standard input}:49232: Error: junk at end of line, first unrecognized
character is `.'
{standard input}:49233: Error: expected comma after "__ct_base"
and I strongly believe it is the same thing, lto1 and the identifier being
mangled in a weirdo way.
[Bug target/104183] New: gcc6 error with building icu for ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104183 Bug ID: 104183 Summary: gcc6 error with building icu for ppc64 Product: gcc Version: 6.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: vital.had at gmail dot com CC: iains at gcc dot gnu.org Target Milestone: --- Target: powerpc64-apple-darwin9.8.0 Created attachment 52266 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52266&action=edit ii files for errors Build fails with the following: ld: duplicate symbol icu_67::number::NumberFormatterSettings::copyErrorTo(UErrorCode&) const in number_skeletons.o and number_fluent.o collect2: error: ld returned 1 exit status make[1]: *** [../lib/libicui18n.67.1.dylib] Error 1 make: *** [all-recursive] Error 2 Commands producing the faulty objects: /opt/local/bin/g++-mp-6 -m64 -O2 -DU_ATTRIBUTE_DEPRECATED= -DU_I18N_IMPLEMENTATION -DU_HAVE_STRTOD_L=1 -DU_HAVE_XLOCALE_H=1 -I. -I../common -O2 -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long -std=c++11 -fvisibility=hidden -fno-common -c -dynamic -MMD -MT "number_skeletons.d number_skeletons.o number_skeletons.ao" -o number_skeletons.o number_skeletons.cpp /opt/local/bin/g++-mp-6 -m64 -O2 -DU_ATTRIBUTE_DEPRECATED= -DU_I18N_IMPLEMENTATION -DU_HAVE_STRTOD_L=1 -DU_HAVE_XLOCALE_H=1 -I. -I../common -O2 -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long -std=c++11 -fvisibility=hidden -fno-common -c -dynamic -MMD -MT "number_fluent.d number_fluent.o number_fluent.ao" -o number_fluent.o number_fluent.cpp P. S. Error unrelated to Macports, I have redone the build outside with cleared path, and it fails identically. ii files in attachment are from the build outside of Macports.
[Bug target/104117] [9,10,11,12 Regression] Darwin ppc64 uses invalid non-PIC address to access constants (in PIC code).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104117 --- Comment #12 from Sergey Fedorov --- Not sure if the error is related, but trying to build icu with gcc6 in Macports gives this: /opt/local/bin/g++-mp-6 -DU_ATTRIBUTE_DEPRECATED= -DU_I18N_IMPLEMENTATION -DU_HAVE_STRTOD_L=1 -DU_HAVE_XLOCALE_H=1 -I. -I../common -pipe -Os -m32 -D_GLIBCXX_USE_CXX11_ABI=0 -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long -std=c++11 -fvisibility=hidden -fno-common -c -dynamic -MMD -MT "formatted_string_builder.d formatted_string_builder.o formatted_string_builder.ao" -o formatted_string_builder.o formatted_string_builder.cpp ar r -c ../lib/libicui18n.a ucln_in.ao fmtable.ao format.ao msgfmt.ao umsg.ao numfmt.ao unum.ao decimfmt.ao dcfmtsym.ao fmtable_cnv.ao choicfmt.ao datefmt.ao smpdtfmt.ao reldtfmt.ao dtfmtsym.ao udat.ao dtptngen.ao udatpg.ao nfrs.ao nfrule.ao nfsubs.ao rbnf.ao numsys.ao unumsys.ao ucsdet.ao ucal.ao calendar.ao gregocal.ao timezone.ao simpletz.ao olsontz.ao astro.ao taiwncal.ao buddhcal.ao persncal.ao islamcal.ao japancal.ao gregoimp.ao hebrwcal.ao indiancal.ao chnsecal.ao cecal.ao coptccal.ao dangical.ao ethpccal.ao coleitr.ao coll.ao sortkey.ao bocsu.ao ucoleitr.ao ucol.ao ucol_res.ao ucol_sit.ao collation.ao collationsettings.ao collationdata.ao collationtailoring.ao collationdatareader.ao collationdatawriter.ao collationfcd.ao collationiterator.ao utf16collationiterator.ao utf8collationiterator.ao uitercollationiterator.ao collationsets.ao collationcompare.ao collationfastlatin.ao collationkeys.ao rulebasedcollator.ao collationroot.ao collationrootelements.ao collationdatabuilder.ao collationweights.ao collationruleparser.ao collationbuilder.ao collationfastlatinbuilder.ao listformatter.ao ulistformatter.ao strmatch.ao usearch.ao search.ao stsearch.ao translit.ao utrans.ao esctrn.ao unesctrn.ao funcrepl.ao strrepl.ao tridpars.ao cpdtrans.ao rbt.ao rbt_data.ao rbt_pars.ao rbt_rule.ao rbt_set.ao nultrans.ao remtrans.ao casetrn.ao titletrn.ao tolowtrn.ao toupptrn.ao anytrans.ao name2uni.ao uni2name.ao nortrans.ao quant.ao transreg.ao brktrans.ao regexcmp.ao rematch.ao repattrn.ao regexst.ao regextxt.ao regeximp.ao uregex.ao uregexc.ao ulocdata.ao measfmt.ao currfmt.ao curramt.ao currunit.ao measure.ao utmscale.ao csdetect.ao csmatch.ao csr2022.ao csrecog.ao csrmbcs.ao csrsbcs.ao csrucode.ao csrutf8.ao inputext.ao wintzimpl.ao windtfmt.ao winnmfmt.ao basictz.ao dtrule.ao rbtz.ao tzrule.ao tztrans.ao vtzone.ao zonemeta.ao standardplural.ao upluralrules.ao plurrule.ao plurfmt.ao selfmt.ao dtitvfmt.ao dtitvinf.ao udateintervalformat.ao tmunit.ao tmutamt.ao tmutfmt.ao currpinf.ao uspoof.ao uspoof_impl.ao uspoof_build.ao uspoof_conf.ao smpdtfst.ao ztrans.ao zrule.ao vzone.ao fphdlimp.ao fpositer.ao ufieldpositer.ao decNumber.ao decContext.ao alphaindex.ao tznames.ao tznames_impl.ao tzgnames.ao tzfmt.ao compactdecimalformat.ao gender.ao region.ao scriptset.ao uregion.ao reldatefmt.ao quantityformatter.ao measunit.ao measunit_extra.ao sharedbreakiterator.ao scientificnumberformatter.ao dayperiodrules.ao nounit.ao number_affixutils.ao number_compact.ao number_decimalquantity.ao number_decimfmtprops.ao number_fluent.ao number_formatimpl.ao number_grouping.ao number_integerwidth.ao number_longnames.ao number_modifiers.ao number_notation.ao number_output.ao number_padding.ao number_patternmodifier.ao number_patternstring.ao number_rounding.ao number_scientific.ao number_utils.ao number_asformat.ao number_mapper.ao number_multiplier.ao number_currencysymbols.ao number_skeletons.ao number_capi.ao double-conversion-string-to-double.ao double-conversion-double-to-string.ao double-conversion-bignum-dtoa.ao double-conversion-bignum.ao double-conversion-cached-powers.ao double-conversion-fast-dtoa.ao double-conversion-strtod.ao string_segment.ao numparse_parsednumber.ao numparse_impl.ao numparse_symbols.ao numparse_decimal.ao numparse_scientific.ao numparse_currency.ao numparse_affixes.ao numparse_compositions.ao numparse_validators.ao numrange_fluent.ao numrange_impl.ao erarules.ao formattedvalue.ao formattedval_iterimpl.ao formattedval_sbimpl.ao formatted_string_builder.ao /opt/local/bin/ranlib: file: ../lib/libicui18n.a(wintzimpl.ao) has no symbols /opt/local/bin/ranlib: file: ../lib/libicui18n.a(windtfmt.ao) has no symbols /opt/local/bin/ranlib: file: ../lib/libicui18n.a(winnmfmt.ao) has no symbols ranlib ../lib/libicui18n.a ranlib: file: ../lib/libicui18n.a(wintzimpl.ao) has no symbols ranlib: file: ../lib/libicui18n.a(windtfmt.ao) has no symbols ranlib: file: ../lib/libicui18n.a(winnmfmt.ao) has no symbols /opt/local/bin/g++-mp-6 -dynamiclib -dynamic -pipe -Os -m32 -D_GLIBCXX_USE_CXX11_ABI=0 -W -Wall -pedantic -Wpointer-arith -Wwrite-strings -Wno-long-long -std=c++11-fvisibility=hidden -Wl,-headerpad_max_install_names -Wl,-read_only_relocs,suppress -m32 -Wl,-compatibility_version -Wl,67 -Wl,-current_version -Wl,67.1 -install_name /opt/local/lib/libicui18n.67.dylib -o ../lib/libicui18n.67.1.dy
[Bug c++/104182] [12 Regression] Wrong code since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104182 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=103984 Priority|P3 |P1 Target Milestone|--- |12.0 Last reconfirmed||2022-01-22
[Bug c++/104182] New: [12 Regression] Wrong code since r12-6329-g4f6bc28fc7dd86bd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104182
Bug ID: 104182
Summary: [12 Regression] Wrong code since
r12-6329-g4f6bc28fc7dd86bd
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org
Target Milestone: ---
Originally reported here:
https://gitlab.kitware.com/cmake/cmake/-/issues/23126#note_696
for the following we emit a wrong code:
$ cat cmake-repro.C
#include
#include
#include
struct S
{
int A;
std::string B;
};
struct V
{
std::vector v;
};
static const V v{ { { { 1, "2" } } } };
int main()
{
if (v.v[0].A != 1 || v.v[0].B[0] != '2')
__builtin_abort();
return 0;
}
$ g++ cmake-repro.C && ./a.out
Aborted (core dumped)
[Bug middle-end/104178] [12 Regreession] -fcompare-debug failure at -O3 -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104178 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Started with r12-4790-g4b3a325f07acebf47e82de227ce1d5ba62f5bcae
[Bug other/104181] [12 Regression] The redundant build.log file in the root directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104181 Jonathan Wakely changed: What|Removed |Added CC||crazylht at gmail dot com Summary|The redundant build.log |[12 Regression] The |file in the root directory |redundant build.log file in ||the root directory Status|UNCONFIRMED |NEW Target Milestone|--- |12.0 Ever confirmed|0 |1 Last reconfirmed||2022-01-22 --- Comment #1 from Jonathan Wakely --- Added by g:e7a7dbb5ca5dd69689f1a462ba7620180acfe8b0 How did the commit hooks not reject this?
[Bug other/104181] New: The redundant build.log file in the root directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104181 Bug ID: 104181 Summary: The redundant build.log file in the root directory Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: yansendao at 126 dot com Target Milestone: --- Created attachment 52265 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52265&action=edit NA
[Bug debug/104180] New: [10/11/12 Regression] '-fcompare-debug' failure (length) w/ -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104180
Bug ID: 104180
Summary: [10/11/12 Regression] '-fcompare-debug' failure
(length) w/ -O1
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: compare-debug-failure
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++ 12.0.0 20220109 snapshot (g:90045c5df5b3c8853e7740fb72a11aead1c489bb) fails
-fcompare-debug check when compiling the following testcase, reduced from
gcc/testsuite/gcc.dg/torture/pr89223.c, w/ -O1:
int a[5];
void
c ()
{
unsigned int b;
for (b = 3; ; b--)
a[b] = ({ a[b + 1]; });
}
% g++-12.0.0 -O1 -fcompare-debug -c lluhupiv.c
g++-12.0.0: error: lluhupiv.c: '-fcompare-debug' failure (length)
--- lluhupiv.c.gkd 2022-01-22 15:27:16.168639041 +0700
+++ lluhupiv.gk.c.gkd 2022-01-22 15:27:16.239634334 +0700
@@ -33,7 +33,7 @@
(nil))
(insn # 0 0 3 (set (mem:SI (plus:DI (mult:DI (reg:DI 2 cx [orig:87 b ] [87])
(const_int 4 [0x4]))
-(reg/f:DI 5 di [86])) [ a[b_3]+0 S4 A32])
+(reg/f:DI 5 di [86])) [ MEM [(int *)&a][b_3]+0 S4
A32])
(reg:SI 4 si [orig:82 _2 ] [82])) "lluhupiv.c":9:10# {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 4 si [orig:82 _2 ] [82])
(expr_list:REG_DEAD (reg:DI 2 cx [orig:87 b ] [87])
[Bug middle-end/104178] [12 Regreession] -fcompare-debug failure at -O3 -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104178 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Version|unknown |12.0 Summary|-fcompare-debug failure at |[12 Regreession] |-O3 -m32|-fcompare-debug failure at ||-O3 -m32 Status|UNCONFIRMED |NEW Last reconfirmed||2022-01-22 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed.
