[Bug c++/86218] [9 Regression] ICE in compare_ics, at cp/call.c:9769
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86218 --- Comment #6 from Alexandre Oliva --- Author: aoliva Date: Thu Feb 7 07:50:42 2019 New Revision: 268606 URL: https://gcc.gnu.org/viewcvs?rev=268606=gcc=rev Log: [PR86218] handle ck_aggr in compare_ics in both and either conversion Because of rank compares, and checks for ck_list, we know that if we see user_conv_p or ck_list in ics1, we'll also see it in ics2. This reasoning does not extend to ck_aggr, however, so we might have ck_aggr conversions starting both ics1 and ics2, which we handle correctly, or either, which we likely handle by crashing on whatever path we take depending on whether ck_aggr is in ics1 or ics2. We crash because, as we search the conversion sequences, we may very well fail to find what we are looking for, and reach the end of the sequence, which is unexpected in all paths. This patch arranges for us to take the same path when ck_aggr is in ics2 only that we would if it was in ics1 (regardless of ics2), and it deals with not finding the kind of conversion we look for there. I've changed the type of the literal constant in the testcase, so as to hopefully make it well-formed. We'd fail to reject the narrowing conversion in the original testcase, but that's a separate bug. for gcc/cp/ChangeLog PR c++/86218 * call.c (compare_ics): Deal with ck_aggr in either cs. for gcc/testsuite/ChangeLog PR c++/86218 * g++.dg/cpp0x/pr86218.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr86218.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug c++/87322] [8/9 Regression] GCC fails to parse captured lambda of 2nd inner lambda if the captured lambda has "," (having 2 arguments)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87322 --- Comment #6 from Alexandre Oliva --- The attached patch had several regressions, use the one I posted instead. https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00371.html
[Bug c++/89232] New: c++: Fail to build when and the noreturn keyword is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89232
Bug ID: 89232
Summary: c++: Fail to build when and the
noreturn keyword is used
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pere at hungry dot com
Target Milestone: ---
I ran into this issue while trying to prepare the coz profiler for Debian.
The header file seem to be inefficient when using cc and
clang, be ignored causing an build error when using c++.
I found this example code on
http://en.cppreference.com/w/c/language/_Noreturn >, and it fail
to build with c++, but build with both cc and clang:
% cat > c++-noreturn.c <
#include
#include
// causes undefined behavior if i <= 0
// exits if i > 0
noreturn void stop_now(int i) // or _Noreturn void stop_now(int i)
{
if (i > 0) exit(i);
}
int main(void)
{
puts("Preparing to stop...");
stop_now(2);
puts("This code is never executed.");
}
EOF
% gcc c++-noreturn.c
c++-noreturn.c: In function 'stop_now':
c++-noreturn.c:10:1: warning: 'noreturn' function does return
}
^
% ./a.out
Preparing to stop...
% c++ c++-noreturn.c
c++-noreturn.c:7:1: error: 'noreturn' does not name a type
noreturn void stop_now(int i) // or _Noreturn void stop_now(int i)
^~~~
c++-noreturn.c: In function 'int main()':
c++-noreturn.c:15:13: error: 'stop_now' was not declared in this scope
stop_now(2);
^
% clang c++-noreturn.c
c++-noreturn.c:10:1: warning: function declared 'noreturn' should not return
[-Winvalid-noreturn]
}
^
1 warning generated.
%
Perhaps something that should be fixed?
This issue is also reported as https://bugs.debian.org/833931 and has been
present since at least gcc 6. I find
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53182 related to the user of
, but it seem to be a different issue.
--
Happy hacking
Petter Reinholdtsen
[Bug c++/89231] New: Ambiguous template instantiation for variadic nested class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89231
Bug ID: 89231
Summary: Ambiguous template instantiation for variadic nested
class
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andreas.stoeckel at googlemail dot com
Target Milestone: ---
The following program causes an "ambiguous template instantiation" error in G++
g++ (GCC) 8.2.1 20181215, although one of the class specialisations should be
preferred.
template
struct A {
template
struct Collect {};
template >
struct Seq;
template
struct Seq> : Seq>
{};
template
struct Seq<0, I, Collect> : Collect {};
};
int main() {
A<>::Seq<4> test;
}
---
Error:
test.cpp: In instantiation of ‘struct A<>::Seq<1, 3, A<>::Collect<0, 1, 2> >’:
test.cpp:10:9: recursively required from ‘struct A<>::Seq<3, 1,
A<>::Collect<0> >’
test.cpp:10:9: required from ‘struct A<>::Seq<4>’
test.cpp:17:14: required from here
test.cpp:10:9: error: ambiguous template instantiation for ‘struct A<>::Seq<0,
4, A<>::Collect<0, 1, 2, 3> >’
struct Seq> : Seq> {};
^~~~
test.cpp:10:9: note: candidates are: ‘template template struct A::Seq::Collect > [with int C =
0; int I = 4; int ...N = {0, 1, 2, 3}; Ps = {}]’
test.cpp:13:9: note: ‘template template struct A::Seq<0, I, A::Collect > [with int I = 4; int
...N = {0, 1, 2, 3}; Ps = {}]’
struct Seq<0, I, Collect> : Collect {};
^~~~
test.cpp:10:9: error: invalid use of incomplete type ‘struct A<>::Seq<0, 4,
A<>::Collect<0, 1, 2, 3> >’
struct Seq> : Seq> {};
^~~~
test.cpp:7:9: note: declaration of ‘struct A<>::Seq<0, 4, A<>::Collect<0, 1, 2,
3> >’
struct Seq;
---
Note: this code compiles fine with clang++. It also compiles fine as long as
"struct A" is not a template.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 63197, which changed state. Bug 63197 Summary: tc-m68k.c: Wrong warning "array subscript is below array bounds" https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63197 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/63197] tc-m68k.c: Wrong warning "array subscript is below array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63197 Alan Modra changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Alan Modra --- No, it appears the bug has been fixed.
[Bug middle-end/89230] Bogus uninited usage warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89230 --- Comment #1 from Andrew Pinski --- So what is happening here is GCC does not know the properties of sprintf/printf to know they can't modify memory therefor GCC cannot figure out d->D_fid[2] does not change from the first if statement to the second one.
[Bug target/89229] [7/8/9 Regression] Unnecessary ZMM in movoi_internal_avx/movti_internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89229 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-07 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- sse.md has (define_insn "mov_internal" [(set (match_operand:VMOVE 0 "nonimmediate_operand" "=v,v ,v ,m") (match_operand:VMOVE 1 "nonimmediate_or_sse_const_operand" " C,BC,vm,v"))] "TARGET_SSE && (register_operand (operands[0], mode) || register_operand (operands[1], mode))" ... (set (attr "mode") (cond [(and (eq_attr "alternative" "1") (match_test "TARGET_AVX512VL")) (const_string "") (and (match_test " == 16") (ior (match_test "TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL") (and (eq_attr "alternative" "3") (match_test "TARGET_SSE_TYPELESS_STORES" (const_string "") (match_test "TARGET_AVX") (const_string "") (ior (not (match_test "TARGET_SSE2")) (match_test "optimize_function_for_size_p (cfun)")) (const_string "V4SF") (and (eq_attr "alternative" "0") (match_test "TARGET_SSE_LOAD0_BY_PXOR")) (const_string "TI") ] (const_string ""))) (and (eq_attr "alternative" "1") (match_test "TARGET_AVX512VL")) (const_string "") is OK.
[Bug target/89229] New: [7/8/9 Regression] Unnecessary ZMM in movoi_internal_avx/movti_internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89229 Bug ID: 89229 Summary: [7/8/9 Regression] Unnecessary ZMM in movoi_internal_avx/movti_internal Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: ubizjak at gmail dot com Target Milestone: --- Target: i386,x86-64 movoi_internal_avx and movti_internal have (set (attr "mode") (cond [(ior (match_operand 0 "ext_sse_reg_operand") (match_operand 1 "ext_sse_reg_operand")) (const_string "XI") (and (eq_attr "alternative" "1") (match_test "TARGET_AVX512VL")) (const_string "XI") (ior (match_test "TARGET_SSE_PACKED_SINGLE_INSN_OPTIMAL") (and (eq_attr "alternative" "3") (match_test "TARGET_SSE_TYPELESS_STORES"))) (const_string "V8SF") ] (const_string "OI")))]) But (and (eq_attr "alternative" "1") (match_test "TARGET_AVX512VL")) (const_string "XI") is unnecessary. As the result, we are generating vpternlogd $0xFF, %zmm0, %zmm0, %zmm0 which is only needed for %xmm16 - %xmm31/%ymm16 - %ymm31, when vpcmpeqd%ymm0, %ymm0, %ymm0 or vpcmpeqd%xmm0, %xmm0, %xmm0 are sufficient.
[Bug c/89230] New: Bogus uninited usage warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89230
Bug ID: 89230
Summary: Bogus uninited usage warning
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: lavr at ncbi dot nlm.nih.gov
Target Milestone: ---
I have a piece of code that reads like this (line numbers added):
2401 if (d->D_fid[2] || !(hdr = getfh(vol, d->D_fid[0],
tmp)) || d->D_fid[1] != hdr->H_fseq) {
2402 char temp[80];
2403 sprintf(temp, "%s.%s;%hu", name, type, d->D_fver);
2404 printf("%s%-20s ", pfx, temp);
2405 sprintf(temp, "(%ho,%ho,%ho)", d->D_fid[0],
d->D_fid[1], d->D_fid[2]);
2406 printf("%-22s ", temp);
2407 if (d->D_fid[2])
2408 printf("file header is on volume %hu.\n",
d->D_fid[2]);
2409 else if (!hdr)
2410 printf("unable to get file header\n");
2411 else
2412 printf("stale sequence no. (%ho)\n",
hdr->H_fseq);
2413 }
In the above "d" is a local variable (a pointer to a structure), unrelated to
any of the other variables shown in the fragment above (that is, not pointing
into any areas occupied by "vol" and "tmp" that are passed to "getfh()", hence,
cannot be indirectly modified by that call). When GCC compiles the code
optimized (-O6), it gives out the following warning:
rsx11io.c: In function ‘list_dir.constprop’:
rsx11io.c:2409:29: warning: ‘hdr’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
else if (!hdr)
^
Note that the warning is completely uncalled for, because of the "if" on line
2401, checking first whether "d->D_fid[2]" is non-zero, and if not, then
proceeding with the assignment of "hdr". Now, line 2409 could only be reached
if "d->D_fid[2]" was zero, meaning "hdr" was in fact initialized.
Unfortunately, I failed to reduce the above to a test case, as simplifying the
code makes the warning disappear somehow.
Moreover, the warning also disappears if I remove just the lines 2402-2407 from
the original source code, so that the outer "if" is followed by the inner "if"
immediately.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/7.4.0/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-7.4.0-1.x86_64/src/gcc-7.4.0/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-7.4.0-1.x86_64/src/gcc-7.4.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
--enable-shared --enable-shared-libgcc --enable-static
--enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit
--with-dwarf2 --with-tune=generic
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libcilkrts --enable-libgomp
--enable-libitm --enable-libquadmath --enable-libquadmath-support
--disable-libssp --enable-libada --disable-symvers --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
--with-default-libstdcxx-abi=gcc4-compatible --enable-libstdcxx-filesystem-ts
Thread model: posix
gcc version 7.4.0 (GCC)
[Bug middle-end/21014] read-rtl.c:670: warning: missing sentinel in function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21014
--- Comment #6 from Eric Gallager ---
(In reply to dave from comment #5)
> Subject: Re: read-rtl.c:670: warning: missing sentinel in function call
>
> > result = concat ("(", cond1, ") && (", cond2, ")", NULL);
> >
> >
> > Looks like someone forgot the cast. (well in most of the time there is a
> > cast, oh well).
>
> It looks like this could be fixed by including stddef.h after stdio.h
> in system.h. stddef.h would then provide an appropriate define for NULL.
> Otherwise, stdio.h needs fixing. The define for NULL in system.h is
> also probably inadequate if it's ever needed.
>
> Dave
I see already included in system.h
[Bug middle-end/63197] tc-m68k.c: Wrong warning "array subscript is below array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63197 --- Comment #4 from Eric Gallager --- (In reply to Jan-Benedict Glaw from comment #2) > With today's binutils snapshot, there's a gas_assert in front of it, which > silences this bogus warning. That needs to be reverted to test GCC wrt. this > issue. Is it still there now?
[Bug c++/88995] [8/9 Regression] internal compiler error: in lookup_template_class_1, at cp/pt.c:9471
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88995
Orion Poplawski changed:
What|Removed |Added
CC||orion at cora dot nwra.com
--- Comment #5 from Orion Poplawski ---
Created attachment 45623
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45623=edit
Preprocessed source
gcc-c++-9.0.1-0.2.fc30.x86_64
Trying to update to VTK 8.2.0 in Fedora Rawhide.
/usr/lib64/ccache/c++ -DVTK_IN_VTK -DvtkFiltersExtraction_EXPORTS
-I/builddir/build/BUILD/VTK-8.2.0/build/Filters/Extraction
-I/builddir/build/BUILD/VTK-8.2.0/Filters/Extraction
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/Core
-I/builddir/build/BUILD/VTK-8.2.0/Common/Core
-I/builddir/build/BUILD/VTK-8.2.0/build/Utilities/KWIML
-I/builddir/build/BUILD/VTK-8.2.0/Utilities/KWIML
-I/builddir/build/BUILD/VTK-8.2.0/build/Utilities/KWSys
-I/builddir/build/BUILD/VTK-8.2.0/Utilities/KWSys
-I/builddir/build/BUILD/VTK-8.2.0/build/ThirdParty/utf8
-I/builddir/build/BUILD/VTK-8.2.0/ThirdParty/utf8
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/DataModel
-I/builddir/build/BUILD/VTK-8.2.0/Common/DataModel
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/Math
-I/builddir/build/BUILD/VTK-8.2.0/Common/Math
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/Misc
-I/builddir/build/BUILD/VTK-8.2.0/Common/Misc
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/System
-I/builddir/build/BUILD/VTK-8.2.0/Common/System
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/Transforms
-I/builddir/build/BUILD/VTK-8.2.0/Common/Transforms
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/ExecutionModel
-I/builddir/build/BUILD/VTK-8.2.0/Common/ExecutionModel
-I/builddir/build/BUILD/VTK-8.2.0/build/Filters/Core
-I/builddir/build/BUILD/VTK-8.2.0/Filters/Core
-I/builddir/build/BUILD/VTK-8.2.0/build/Filters/General
-I/builddir/build/BUILD/VTK-8.2.0/Filters/General
-I/builddir/build/BUILD/VTK-8.2.0/build/Common/ComputationalGeometry
-I/builddir/build/BUILD/VTK-8.2.0/Common/ComputationalGeometry
-I/builddir/build/BUILD/VTK-8.2.0/build/Filters/Statistics
-I/builddir/build/BUILD/VTK-8.2.0/Filters/Statistics
-I/builddir/build/BUILD/VTK-8.2.0/build/Imaging/Fourier
-I/builddir/build/BUILD/VTK-8.2.0/Imaging/Fourier
-I/builddir/build/BUILD/VTK-8.2.0/build/Imaging/Core
-I/builddir/build/BUILD/VTK-8.2.0/Imaging/Core
-I/builddir/build/BUILD/VTK-8.2.0/build/ThirdParty/eigen
-I/builddir/build/BUILD/VTK-8.2.0/ThirdParty/eigen -I/usr/include/eigen3 -O2
-g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
-D_UNICODE -DHAVE_UINTPTR_T -g -fPIC -fvisibility=hidden -std=c++11 -o
CMakeFiles/vtkFiltersExtraction.dir/vtkValueSelector.cxx.o -c
/builddir/build/BUILD/VTK-8.2.0/Filters/Extraction/vtkValueSelector.cxx
*** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH_UNIT | annobin: Generate final annotations
PLUGIN_START_UNIT| annobin: Generate global annotations
PLUGIN_ALL_PASSES_START | annobin: Generate per-function annotations
PLUGIN_ALL_PASSES_END| annobin: Register per-function end symbol
/builddir/build/BUILD/VTK-8.2.0/Filters/Extraction/vtkValueSelector.cxx: In
instantiation of 'void
{anonymous}::ArrayValueMatchFunctor::operator()(InputArrayType*,
SelectionListArrayType*) [with InputArrayType = vtkAOSDataArrayTemplate;
SelectionListArrayType = vtkAOSDataArrayTemplate]':
/builddir/build/BUILD/VTK-8.2.0/Filters/Extraction/vtkValueSelector.cxx:362:76:
required from here
/builddir/build/BUILD/VTK-8.2.0/Filters/Extraction/vtkValueSelector.cxx:123:50:
internal compiler error: in lookup_template_class_1, at cp/pt.c:9471
123 | const auto valKK = faccessor.Get(cc, comp);
| ^~~~
[Bug c++/88680] [9 Regression] bogus -Wtype-limits for constant expressions after r267272
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88680 --- Comment #2 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00363.html
[Bug tree-optimization/88771] [9 Regression] Misleading -Werror=array-bounds error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #18 from Martin Sebor --- Patch to improve the diagnostic (without eliminating the false positive): https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00362.html
[Bug libbacktrace/78063] libbacktrace fails to handle cross CU DW_AT_abstract_origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78063 Ian Lance Taylor changed: What|Removed |Added CC||ian at airs dot com --- Comment #5 from Ian Lance Taylor --- Patch looks basically OK to me.
[Bug target/89226] codegen for copying a 512-bit object fails to use avx instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226
--- Comment #6 from H.J. Lu ---
Please take a look at usr/hjl/pieces/master branch:
https://gitlab.com/x86-gcc/wip
[hjl@gnu-cfl-1 gcc]$ cat x.cc
#include
// DUMB PAIR
struct dumb_pair {
alignas(2*sizeof(__m256i)) __m256i x[2];
};
void copy1(const dumb_pair& from, dumb_pair& to) {
to = from;
}
// SMART PAIR
struct foo512 {
__m256i a;
__m256i b;
auto& operator=(const foo512& f) {
a = f.a;
b = f.b;
return *this;
}
};
struct smart_pair {
union {
foo512 y;
__m256i x[2];
};
smart_pair(const smart_pair& sp) {
y = sp.y;
}
smart_pair& operator=(const smart_pair& sp) {
y = sp.y;
return *this;
}
};
void copy2(const smart_pair& from, smart_pair& to) {
to = from;
}
[hjl@gnu-cfl-1 gcc]$ ./xgcc -B./ -O3 -march=haswell x.cc -S
[hjl@gnu-cfl-1 gcc]$ cat x.s
.file "x.cc"
.text
.p2align 4
.globl _Z5copy1RK9dumb_pairRS_
.type _Z5copy1RK9dumb_pairRS_, @function
_Z5copy1RK9dumb_pairRS_:
.LFB5459:
.cfi_startproc
vmovdqa (%rdi), %ymm0
vmovaps %ymm0, (%rsi)
vmovdqa 32(%rdi), %ymm1
vmovaps %ymm1, 32(%rsi)
vzeroupper
ret
.cfi_endproc
.LFE5459:
.size _Z5copy1RK9dumb_pairRS_, .-_Z5copy1RK9dumb_pairRS_
.p2align 4
.globl _Z5copy2RK10smart_pairRS_
.type _Z5copy2RK10smart_pairRS_, @function
_Z5copy2RK10smart_pairRS_:
.LFB5465:
.cfi_startproc
vmovdqa (%rdi), %ymm0
vmovdqa 32(%rdi), %ymm1
vmovdqa %ymm0, (%rsi)
vmovdqa %ymm1, 32(%rsi)
vzeroupper
ret
.cfi_endproc
.LFE5465:
.size _Z5copy2RK10smart_pairRS_, .-_Z5copy2RK10smart_pairRS_
.ident "GCC: (GNU) 9.0.1 20190206 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-1 gcc]$
[Bug libbacktrace/89228] ARM unwinder fails to restore vfp reg $d8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89228 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup of bug 89093. *** This bug has been marked as a duplicate of bug 89093 ***
[Bug target/89093] [9 Regression] C++ exception handling clobbers d8 VFP register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89093 Andrew Pinski changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #24 from Andrew Pinski --- *** Bug 89228 has been marked as a duplicate of this bug. ***
[Bug libbacktrace/89228] New: ARM unwinder fails to restore vfp reg $d8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89228
Bug ID: 89228
Summary: ARM unwinder fails to restore vfp reg $d8
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libbacktrace
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
CC: ian at gcc dot gnu.org
Target Milestone: ---
This makes gdb enter an endless Loop, which makes the gcc test Suite hang,
becaue the gdb process does not terminate, and the Time-out only kills
the debuggee.
A debug session is in gdb bugzilla at
https://sourceware.org/bugzilla/show_bug.cgi?id=24178
It is a bit weird, but I think the reason for this is
that __gxx_personality_v0 is saving d8 on the stack,
and restores the old d8 on return.
0036f864 <__gxx_personality_v0>:
36f864: e200c003and ip, r0, #3
36f868: e92d4ff0push{r4, r5, r6, r7, r8, r9, sl, fp, lr}
36f86c: e35c0001cmp ip, #1
36f870: ed2d8b02vpush {d8}
36f874: e3a03000mov r3, #0
36f878: e24dd04csub sp, sp, #76 ; 0x4c
36f87c: e1a07002mov r7, r2
36f880: e58d100cstr r1, [sp, #12]
36f884: e58d3020str r3, [sp, #32]
36f888: 0a82beq 36fa98 <__gxx_personality_v0+0x234>
36f88c: e35c0002cmp ip, #2
36f890: 1a08bne 36f8b8 <__gxx_personality_v0+0x54>
36f894: e59d000cldr r0, [sp, #12]
36f898: e1a01007mov r1, r7
36f89c: eb005e60bl 387224 <__gnu_unwind_frame>
36f8a0: e350cmp r0, #0
36f8a4: 13a9movne r0, #9
36f8a8: 03a8moveq r0, #8
36f8ac: e28dd04cadd sp, sp, #76 ; 0x4c
36f8b0: ecbd8b02vpop{d8}
36f8b4: e8bd8ff0pop {r4, r5, r6, r7, r8, r9, sl, fp, pc}
But __gnu_unwind_frame restores the live vfp registers in violation of the ABI,
which would work, if there was a a way to avoid using vfp Registers in
the personality function.
This function is called from here:
static void __attribute__((noreturn))
unwind_phase2 (_Unwind_Control_Block * ucbp, phase2_vrs * vrs)
{
_Unwind_Reason_Code pr_result;
do
{
/* Find the entry for this routine. */
if (get_eit_entry (ucbp, VRS_PC(vrs)) != _URC_OK)
abort ();
UCB_SAVED_CALLSITE_ADDR (ucbp) = VRS_PC(vrs);
/* Call the pr to decide what to do. */
pr_result = ((personality_routine) UCB_PR_ADDR (ucbp))
(_US_UNWIND_FRAME_STARTING, ucbp, (_Unwind_Context *) vrs);
}
while (pr_result == _URC_CONTINUE_UNWIND);
if (pr_result != _URC_INSTALL_CONTEXT)
abort();
uw_restore_core_regs (vrs, >core);
}
my conclusion so far is:
The last uw_restore_core_regs restores only r0..r15, but it should
also restore vfp regs on demand. Note that phase2_vrs does not hold
enough space for the vfp Registers.
[Bug c++/89217] [9 Regression] ICE tree check: expected constructor, have error_mark in split_nonconstant_init_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89217 --- Comment #5 from Marek Polacek --- ...which means that we should most likely deal with REFERENCE_REF_P in case COMPONENT_REF in tsubst_copy_and_build. Testing a patch.
[Bug tree-optimization/88919] New test case gcc.dg/vect/pr88903-1.c in r268076 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88919 --- Comment #8 from Bill Schmidt --- My mistake. The patch did land on 1-22. I was looking at the wrong ChangeLog (this is a testsuite fix). Looks like that patch is needed to be backported to 8 now?
[Bug tree-optimization/88919] New test case gcc.dg/vect/pr88903-1.c in r268076 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88919 --- Comment #7 from Bill Schmidt --- But this test stopped failing on January 21, so maybe the patch was applied without the ChangeLog?
[Bug tree-optimization/88919] New test case gcc.dg/vect/pr88903-1.c in r268076 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88919 Bill Schmidt changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #6 from Bill Schmidt --- I see that Tamar Christina's patch (linked above) was approved but has not ever landed?
[Bug rtl-optimization/89225] [9 Regression] LRA hang on ppc64le compiling glibc starting with r268404
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89225 --- Comment #2 from Vladimir Makarov --- Author: vmakarov Date: Wed Feb 6 21:48:45 2019 New Revision: 268597 URL: https://gcc.gnu.org/viewcvs?rev=268597=gcc=rev Log: 2019-02-06 Vladimir Makarov PR rtl-optimization/89225 * lra-constaints.c (simplify_operand_subreg): Add subreg mode sizes check. 2019-02-06 Vladimir Makarov PR rtl-optimization/89225 * gcc.target/powerpc/pr89225.c: New. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr89225.c Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/testsuite/ChangeLog
[Bug go/89227] gotools test cmd/go fails with link error "call lacks nop, can't restore toc; recompile with -fPIC"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89227
--- Comment #3 from boger at gcc dot gnu.org ---
(In reply to Ian Lance Taylor from comment #1)
> Same as https://golang.org/issue/29046?
Yes same as the issue. Since we weren't sure if this was a FE or BE bug I
decided to open a bugzilla.
>
> I would bet that this has something to do with the fact that testenv.HasLink
> is inlinable. Something is wrong with the way that the frontend is passing
> the inlinable function to the backend. The specific code in
> gcc/go/go-gcc.cc is in Gcc_backend::function:
>
> if ((flags & function_only_inline) != 0)
> {
> DECL_EXTERNAL(decl) = 1;
> DECL_DECLARED_INLINE_P(decl) = 1;
> }
>
> This is intended to tell the backend to treat the function the way it treats
> a C gnu89 extern inline function. This seems to work fine on x86 but
> perhaps I am missing something on ppc64le.
[Bug tree-optimization/86020] [8 Regression] Performance regression in Eigen geometry.cpp test starting with r248334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86020 Bill Schmidt changed: What|Removed |Added Known to work||9.0 --- Comment #10 from Bill Schmidt --- Correct.
[Bug other/78063] libbacktrace fails to handle cross CU DW_AT_abstract_origin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78063 Tom de Vries changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #4 from Tom de Vries --- Created attachment 45622 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45622=edit Tentative patch "[libbacktrace] Handle DW_FORM_ref_addr" Patch passes regular bootstrap and reg-test.
[Bug target/89226] codegen for copying a 512-bit object fails to use avx instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226
--- Comment #5 from H.J. Lu ---
(In reply to Jakub Jelinek from comment #3)
> Seems most of the *by_pieces code actually uses widest_int_mode_for_size
> which already handles even the wider modes as long as they have a mov
> instruction. With this completely untested patch I get roughly the same
> code with -mavx and better with -mavx512f, just as a drawback for some
> reason the functions have frame pointer (dunno if that is caused by the
> OI/XImode, while vector modes can be handled or what else). Tried memset
> with zero too, but haven't tried other memsets (those could be problematic
> already) or comparisons.
>
> Thoughts on this? Not a GCC9 material though. Perhaps it should also
> depend on the selected preferred vector width, so that we don't e.g. enable
> AVX512F if that is undesirable from power consumption POV.
>
> --- gcc/config/i386/i386.h.jj 2019-01-01 12:37:32.988715207 +0100
> +++ gcc/config/i386/i386.h2019-02-06 21:13:01.047765193 +0100
> @@ -1886,7 +1886,9 @@ typedef struct ix86_args {
> && TARGET_SSE2 \
> && TARGET_SSE_UNALIGNED_LOAD_OPTIMAL \
> && TARGET_SSE_UNALIGNED_STORE_OPTIMAL) \
> - ? GET_MODE_SIZE (TImode) : UNITS_PER_WORD)
> + ? (TARGET_AVX512F ? GET_MODE_SIZE (XImode) \
> + : TARGET_AVX ? GET_MODE_SIZE (OImode) \
> + : GET_MODE_SIZE (TImode)) : UNITS_PER_WORD)
We need to take prefer_vector_width_type into account.
[Bug tree-optimization/88919] New test case gcc.dg/vect/pr88903-1.c in r268076 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88919 --- Comment #5 from seurer at gcc dot gnu.org --- Note that the change was backported to gcc 8 (r268578) and the test case fails there now the same way.
[Bug go/89227] gotools test cmd/go fails with link error "call lacks nop, can't restore toc; recompile with -fPIC"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89227 boger at gcc dot gnu.org changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #2 from boger at gcc dot gnu.org --- I configured without lto and I still see the error. I don't understand why the gcc-testresults show this failure intermittently, I see it consistently in my builds. This failure is in gotools cmd/go.
[Bug libstdc++/89164] can construct vector with non-copyable-but-trivially-copyable elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89164 Jonathan Wakely changed: What|Removed |Added Keywords||patch Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org --- Comment #5 from Jonathan Wakely --- Patch posted to https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00356.html but I don't plan to fix it for GCC 9.1 (maybe 9.2 though).
[Bug go/89199] libgo regression in implementation of CompareAndSwap functions resulting in intermittent testcase failures on ppc64le power9 after r268458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89199 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Ian Lance Taylor --- Should be fixed, thanks for identifying the problem.
[Bug go/89199] libgo regression in implementation of CompareAndSwap functions resulting in intermittent testcase failures on ppc64le power9 after r268458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89199 --- Comment #2 from ian at gcc dot gnu.org --- Author: ian Date: Wed Feb 6 20:46:00 2019 New Revision: 268591 URL: https://gcc.gnu.org/viewcvs?rev=268591=gcc=rev Log: PR go/89199 sync/atomic: use strong form of atomic_compare_exchange_n In the recent change to use atomic_compare_exchange_n I thought we could use the weak form, which can spuriously fail. But that is not how it is implemented in the gc library, and it is not what the rest of the library expects. Thanks to Lynn Boger for identifying the problem. Fixes https://gcc.gnu.org/PR89199 Reviewed-on: https://go-review.googlesource.com/c/161359 Modified: trunk/gcc/go/gofrontend/MERGE trunk/libgo/go/sync/atomic/atomic.c
[Bug target/89226] codegen for copying a 512-bit object fails to use avx instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226 --- Comment #4 from Jakub Jelinek --- Maybe i386.c would need its own ix86_use_by_pieces_infrastructure_p target hook if the default wouldn't do the right thing with this. Maybe we'll need to split STORE_MAX_PIECES into separately overridable CLEAR_MAX_PIECES, SET_MAX_PIECES and STORE_MAX_PIECES macros, storing 32-byte or 64-byte zeros is cheap, but for e.g. store_by_pieces that might not be the case. And see what can be done to avoid the frame pointer.
[Bug fortran/71860] [7/8 Regression] [OOP] ICE on pointing to null(mold), verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71860 Thomas Koenig changed: What|Removed |Added Keywords|ice-on-invalid-code | CC||tkoenig at gcc dot gnu.org Summary|[7/8/9 Regression] [OOP]|[7/8 Regression] [OOP] ICE |ICE on pointing to |on pointing to null(mold), |null(mold), verify_gimple |verify_gimple failed |failed | --- Comment #7 from Thomas Koenig --- I do not think it is invalid. The test case also passes with current gcc-8 and gcc-7. I have committed a test case to trunk. Let's wait for a few days to see if any regressions turn up, then we can also backport the test case to the other open branches and close.
[Bug target/89226] codegen for copying a 512-bit object fails to use avx instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-02-06
CC||hjl.tools at gmail dot com,
||jakub at gcc dot gnu.org,
||uros at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Jakub Jelinek ---
Seems most of the *by_pieces code actually uses widest_int_mode_for_size which
already handles even the wider modes as long as they have a mov
instruction. With this completely untested patch I get roughly the same code
with -mavx and better with -mavx512f, just as a drawback for some reason the
functions have frame pointer (dunno if that is caused by the OI/XImode, while
vector modes can be handled or what else). Tried memset with zero too, but
haven't tried other memsets (those could be problematic already) or
comparisons.
Thoughts on this? Not a GCC9 material though. Perhaps it should also depend
on the selected preferred vector width, so that we don't e.g. enable AVX512F if
that is undesirable from power consumption POV.
--- gcc/config/i386/i386.h.jj 2019-01-01 12:37:32.988715207 +0100
+++ gcc/config/i386/i386.h 2019-02-06 21:13:01.047765193 +0100
@@ -1886,7 +1886,9 @@ typedef struct ix86_args {
&& TARGET_SSE2 \
&& TARGET_SSE_UNALIGNED_LOAD_OPTIMAL \
&& TARGET_SSE_UNALIGNED_STORE_OPTIMAL) \
- ? GET_MODE_SIZE (TImode) : UNITS_PER_WORD)
+ ? (TARGET_AVX512F ? GET_MODE_SIZE (XImode) \
+ : TARGET_AVX ? GET_MODE_SIZE (OImode) \
+ : GET_MODE_SIZE (TImode)) : UNITS_PER_WORD)
/* If a memory-to-memory move would take MOVE_RATIO or more simple
move-instruction pairs, we will do a movmem or libcall instead.
--- gcc/expr.c.jj 2019-01-22 10:09:47.304587822 +0100
+++ gcc/expr.c 2019-02-06 21:23:18.041603623 +0100
@@ -713,14 +713,31 @@ convert_modes (machine_mode mode, machin
return temp;
}
+/* Return the widest integer mode that is narrower than SIZE bytes. */
+
+static scalar_int_mode
+widest_int_mode_for_size (unsigned int size)
+{
+ scalar_int_mode result = NARROWEST_INT_MODE;
+
+ gcc_checking_assert (size > 1);
+
+ opt_scalar_int_mode tmode;
+ FOR_EACH_MODE_IN_CLASS (tmode, MODE_INT)
+if (GET_MODE_SIZE (tmode.require ()) < size)
+ result = tmode.require ();
+
+ return result;
+}
+
/* Return the largest alignment we can use for doing a move (or store)
of MAX_PIECES. ALIGN is the largest alignment we could use. */
static unsigned int
alignment_for_piecewise_move (unsigned int max_pieces, unsigned int align)
{
- scalar_int_mode tmode
-= int_mode_for_size (max_pieces * BITS_PER_UNIT, 1).require ();
+ scalar_int_mode tmode = widest_int_mode_for_size (max_pieces + 1);
+ gcc_assert (GET_MODE_SIZE (tmode) == max_pieces);
if (align >= GET_MODE_ALIGNMENT (tmode))
align = GET_MODE_ALIGNMENT (tmode);
@@ -743,23 +760,6 @@ alignment_for_piecewise_move (unsigned i
return align;
}
-/* Return the widest integer mode that is narrower than SIZE bytes. */
-
-static scalar_int_mode
-widest_int_mode_for_size (unsigned int size)
-{
- scalar_int_mode result = NARROWEST_INT_MODE;
-
- gcc_checking_assert (size > 1);
-
- opt_scalar_int_mode tmode;
- FOR_EACH_MODE_IN_CLASS (tmode, MODE_INT)
-if (GET_MODE_SIZE (tmode.require ()) < size)
- result = tmode.require ();
-
- return result;
-}
-
/* Determine whether an operation OP on LEN bytes with alignment ALIGN can
and should be performed piecewise. */
[Bug fortran/71860] [7/8/9 Regression] [OOP] ICE on pointing to null(mold), verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71860 --- Comment #6 from Thomas Koenig --- Author: tkoenig Date: Wed Feb 6 20:34:42 2019 New Revision: 268590 URL: https://gcc.gnu.org/viewcvs?rev=268590=gcc=rev Log: 2019-02-06 Thomas Koenig PR fortran/71860 * gfortran.dg/null_10.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/null_10.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/89226] codegen for copying a 512-bit object fails to use avx instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226 --- Comment #2 from Jakub Jelinek --- That is because in copy1 it is a normal memcpy expansion. And, the generic move_by_pieces case is done in preference to target specific one. In i386.h we have: /* Max number of bytes we can move from memory to memory in one reasonably fast instruction. */ #define MOVE_MAX 16 /* MOVE_MAX_PIECES is the number of bytes at a time which we can move efficiently, as opposed to MOVE_MAX which is the maximum number of bytes we can move with a single instruction. ??? We should use TImode in 32-bit mode and use OImode or XImode if they are available. But since by_pieces_ninsns determines the widest mode with MAX_FIXED_MODE_SIZE, we can only use TImode in 64-bit mode. */ #define MOVE_MAX_PIECES \ ((TARGET_64BIT \ && TARGET_SSE2 \ && TARGET_SSE_UNALIGNED_LOAD_OPTIMAL \ && TARGET_SSE_UNALIGNED_STORE_OPTIMAL) \ ? GET_MODE_SIZE (TImode) : UNITS_PER_WORD) and in defaults.h /* MOVE_MAX_PIECES is the number of bytes at a time which we can move efficiently, as opposed to MOVE_MAX which is the maximum number of bytes we can move with a single instruction. */ #ifndef MOVE_MAX_PIECES #define MOVE_MAX_PIECES MOVE_MAX #endif /* STORE_MAX_PIECES is the number of bytes at a time that we can store efficiently. Due to internal GCC limitations, this is MOVE_MAX_PIECES limited by the number of bytes GCC can represent for an immediate constant. */ #ifndef STORE_MAX_PIECES #define STORE_MAX_PIECES MIN (MOVE_MAX_PIECES, 2 * sizeof (HOST_WIDE_INT)) #endif /* Likewise for block comparisons. */ #ifndef COMPARE_MAX_PIECES #define COMPARE_MAX_PIECES MOVE_MAX_PIECES #endif #ifndef MAX_MOVE_MAX #define MAX_MOVE_MAX MOVE_MAX #endif
[Bug go/89227] gotools test cmd/go fails with link error "call lacks nop, can't restore toc; recompile with -fPIC"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89227
--- Comment #1 from Ian Lance Taylor ---
Same as https://golang.org/issue/29046?
I would bet that this has something to do with the fact that testenv.HasLink is
inlinable. Something is wrong with the way that the frontend is passing the
inlinable function to the backend. The specific code in gcc/go/go-gcc.cc is in
Gcc_backend::function:
if ((flags & function_only_inline) != 0)
{
DECL_EXTERNAL(decl) = 1;
DECL_DECLARED_INLINE_P(decl) = 1;
}
This is intended to tell the backend to treat the function the way it treats a
C gnu89 extern inline function. This seems to work fine on x86 but perhaps I
am missing something on ppc64le.
[Bug target/89226] codegen for copying a 512-bit object fails to use avx instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226 --- Comment #1 from Marc Glisse --- The optimized dump for copy1 looks like *to_2(D) = *from_3(D); so we get essentially memcpy, while copy2 has _4 = MEM[(const struct foo512 &)from_3(D)].a; MEM[(struct foo512 *)to_2(D)].a = _4; _5 = MEM[(const struct foo512 &)from_3(D)].b; MEM[(struct foo512 *)to_2(D)].b = _5; which we expand literally. I agree that we should generate the same code for both (ideally we would reach expand with essentially the same GIMPLE representation, although I am not sure how). A question is whether the memcpy expansion is optimal for that target. It could be that as long as you are only copying a rather small object, it isn't worth switching to larger registers which cause a drop in the processor frequency. However the code generated is not impacted if I use other AVX instructions nearby. -Os can make us generate 'rep movsl' for copy1.
[Bug go/89227] New: gotools test cmd/go fails with link error "call lacks nop, can't restore toc; recompile with -fPIC"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89227 Bug ID: 89227 Summary: gotools test cmd/go fails with link error "call lacks nop, can't restore toc; recompile with -fPIC" Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: boger at gcc dot gnu.org CC: cmang at google dot com, wschmidt at gcc dot gnu.org Target Milestone: --- Target: ppc64le I'm not sure when this testcase started failing. I can get it to fail consistently if I configure my gccgo build with lto (--enable-languages=c,c++,go,lto). However after searching the gcc-testresults output, it only fails intermittently on those runs, and they don't configure with lto. gotools.log shows this: Running cmd/go cd check-go-dir/src/cmd/go && PATH=/home/boger/gccgo.work/trunk/bld/gotools:/home/boger/golang/base/go/bin:/home/boger/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin GCCGO='/home/boger/gccgo.work/trunk/bld/gotools/check-gccgo' CC='/home/boger/gccgo.work/trunk/bld/gotools/check-gcc' GCCGOTOOLDIR='/home/boger/gccgo.work/trunk/bld/gotools' GO_TESTING_GOTOOLS=yes LD_LIBRARY_PATH=/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/.libs GOROOT=/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo GOCACHE=/home/boger/gccgo.work/trunk/bld/gotools/gocache-test GOPATH=/home/boger/gccgo.work/trunk/bld/gotools/check-go-dir /home/boger/gccgo.work/trunk/bld/gotools/go test -test.short -test.timeout=600s -test.v # cmd/go.test /home/boger/gccgo.work/trunk/bld/gotools/check-go-dir/src/cmd/go/script_test.go:283: error: call lacks nop, can't restore toc; recompile with -fPIC collect2: error: ld returned 1 exit status FAILcmd/go [build failed] Here are the steps I use to get down to a compile command to test with: >cd bld/gotools >make check-go-tool This will generate the directories needed for the above command. In order to see everything, you might need to remove directory gocache_test. Submit the above command, adding -x -work before -test.short and direct that into a file like this: cd check-go-dir/src/cmd/go && PATH=/home/boger/gccgo.work/trunk/bld/gotools:/home/boger/golang/base/go/bin:/home/boger/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin GCCGO='/home/boger/gccgo.work/trunk/bld/gotools/check-gccgo' CC='/home/boger/gccgo.work/trunk/bld/gotools/check-gcc' GCCGOTOOLDIR='/home/boger/gccgo.work/trunk/bld/gotools' GO_TESTING_GOTOOLS=yes LD_LIBRARY_PATH=/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/.libs GOROOT=/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo GOCACHE=/home/boger/gccgo.work/trunk/bld/gotools/gocache-test GOPATH=/home/boger/gccgo.work/trunk/bld/gotools/check-go-dir /home/boger/gccgo.work/trunk/bld/gotools/go test -x -work -test.short -test.timeout=600s -test.v 2> link.out The error message happens because the call to testenv.HasLink does not have a nop following its 'bl' instruction. This call occurs in script_test.go. In the link.out find the value for $WORK and then the compile command that includes script_test.go. I was able to minimize the go files to these, and put the output file into the current directory instead of under $WORK. ../../../../check-gccgo -c -g -fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -fgo-pkgpath=cmd/go_test -O0 -o _go_.o -I $WORK/b104/_importcfgroot_ ./go_test.go ./proxy_test.go ./script_test.go -v Using the -v output I use this command: /home/boger/gccgo.work/trunk/bld/./gcc/go1 ./go_test.go ./proxy_test.go ./script_test.go -quiet -dumpbase go_test.go -auxbase-strip _go_.o -g -gno-record-gcc-switches -O0 -version -fdebug-prefix-map=/tmp/go-build260802146=/tmp/go-build -fgo-pkgpath=cmd/go_test -I /tmp/go-build260802146/b104/_importcfgroot_ -I /home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo -L/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo -L/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/.libs -L/home/boger/gccgo.work/trunk/bld/./gcc -L/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/../libstdc++-v3/src/.libs -L/home/boger/gccgo.work/trunk/bld/powerpc64le-linux/libgo/../libstdc++-v3/libsupc++/.libs -L/lib/powerpc64le-linux-gnu -L/lib/../lib64 -L/usr/lib/powerpc64le-linux-gnu -fdump-rtl-expand -o /tmp/ccqwFgbq.s I can see in the asm output file, that there is no nop following the call to HasLink: .LBB2080: .loc 5 283 18 bl internal..z2ftestenv.HasLink .LEHE4985: mr 9,3 But there is one after all other calls in the file including others from testenv. I did an rtl dump too although not sure what this is telling me. The call to HasLink looks like this: (call_insn 1086 1085 1973 191 (parallel [ (set (reg:DI 3 3) (call (mem:SI
[Bug c++/71302] [9 Regression] -Wzero-as-null-pointer-constant: misleading caret location for pointer in function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71302 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from David Malcolm --- Locations for -Wzero-as-null-pointer-constant for function-call arguments should be fixed by r268589; marking this as "FIXED". There are still some places in the existing testcases where the location's aren't quite right, but they don't relate to function calls.
[Bug c++/71302] [9 Regression] -Wzero-as-null-pointer-constant: misleading caret location for pointer in function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71302 --- Comment #4 from David Malcolm --- Author: dmalcolm Date: Wed Feb 6 19:44:52 2019 New Revision: 268589 URL: https://gcc.gnu.org/viewcvs?rev=268589=gcc=rev Log: Fix locations in conversion_null_warnings (PR c++/71302) PR c++/71302 reports that g++ shows poor locations for -Wzero-as-null-pointer-constant for pointers in function calls, using the close parenthesis of the call, rather than showing the pertinent argument. This particular case was fixed in GCC 8, but regressed on trunk in r260973. This patch fixes the regression, and adds column numbers to the test cases (where they're correct) to avoid regressing them in the future. There are still various places where the locations aren't correct, but fixing them isn't stage 4 material. gcc/cp/ChangeLog: PR c++/71302 * call.c (get_location_for_expr_unwinding_for_system_header): New function. (conversion_null_warnings): Use it when getting locations for EXPR, effectively adding a call to get_location_for_expr_unwinding_for_system_header for -Wconversion-null and making use of EXPR_LOCATION for -Wzero-as-null-pointer-constant. gcc/testsuite/ChangeLog: PR c++/71302 * g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C: Add expected column numbers to dg-warning directives where they are correct. * g++.dg/warn/Wzero-as-null-pointer-constant-5.C: Likewise. * g++.dg/warn/Wzero-as-null-pointer-constant-7.C: Likewise. * g++.dg/warn/Wzero-as-null-pointer-constant-8.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/Wzero-as-null-pointer-constant-1.C trunk/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-1.C trunk/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-5.C trunk/gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-7.C
[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102 Jonathan Wakely changed: What|Removed |Added Target Milestone|9.0 |8.3
[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102 --- Comment #4 from Jonathan Wakely --- Minimal fix committed to trunk, with a complete fix posted to https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00346.html for stage 1.
[Bug c++/89226] New: codegen for copying a 512-bit object fails to use avx instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89226
Bug ID: 89226
Summary: codegen for copying a 512-bit object fails to use avx
instructions
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: barry.revzin at gmail dot com
Target Milestone: ---
Consider the following example:
#include
// DUMB PAIR
struct dumb_pair {
alignas(2*sizeof(__m256i)) __m256i x[2];
};
void copy1(const dumb_pair& from, dumb_pair& to) {
to = from;
}
// SMART PAIR
struct foo512 {
__m256i a;
__m256i b;
auto& operator=(const foo512& f) {
a = f.a;
b = f.b;
return *this;
}
};
struct smart_pair {
union {
foo512 y;
__m256i x[2];
};
smart_pair(const smart_pair& sp) {
y = sp.y;
}
smart_pair& operator=(const smart_pair& sp) {
y = sp.y;
return *this;
}
};
void copy2(const smart_pair& from, smart_pair& to) {
to = from;
}
when compiled with:
g++ -mavx -O3 -march=corei7-avx -mtune=corei7-avx
on latest gcc (either trunk or 8.2 or 7.4) emits
(https://godbolt.org/z/mZj4VU):
copy1(dumb_pair const&, dumb_pair&):
vmovdqa xmm0, XMMWORD PTR [rdi]
vmovaps XMMWORD PTR [rsi], xmm0
vmovdqa xmm1, XMMWORD PTR [rdi+16]
vmovaps XMMWORD PTR [rsi+16], xmm1
vmovdqa xmm2, XMMWORD PTR [rdi+32]
vmovaps XMMWORD PTR [rsi+32], xmm2
vmovdqa xmm3, XMMWORD PTR [rdi+48]
vmovaps XMMWORD PTR [rsi+48], xmm3
ret
copy2(smart_pair const&, smart_pair&):
vmovdqa ymm0, YMMWORD PTR [rdi]
vmovdqa ymm1, YMMWORD PTR [rdi+32]
vmovdqa YMMWORD PTR [rsi], ymm0
vmovdqa YMMWORD PTR [rsi+32], ymm1
vzeroupper
ret
copy2() is better than copy1(). If we remove the user-provided copy assignment
operator from foo512 (even though the user-provided implementation is the same
as the default), the smart_pair code becomes the same as dumb_pair code.
clang++ emits the same code in both cases: the same code as copy2() in this
example.
[Bug target/89222] [7.x regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code --- Comment #4 from Andrew Pinski --- I think the bug is in the assembler or the linker: .L22: .word myhandler2-1 Basically what is happening is: (__handler != ((__sighandler_t) 2)) && (__handler != ((__sighandler_t) SIG_DFL)) is converted to: (((size_t)__handler)-1) <= 1 And then GCC emits myhandler2-1 in the constant pool which is correct but the assembler/linker decides to put 0x23a7 in that location (See the .L22 above) and then GCC adds +1 to it to try to make it myhandler2 (again). This is why using SIG_DFL of 5 works, it is just by accident because GCC decides not to do the transformation or put myhandler2-1 in the constant pool. Again I think this is an assembler/linker issue of putting the wrong value for .L22: .word myhandler2-1
[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451 --- Comment #14 from Rainer Orth --- Author: ro Date: Wed Feb 6 18:54:16 2019 New Revision: 268588 URL: https://gcc.gnu.org/viewcvs?rev=268588=gcc=rev Log: Fix gcc.dg/debug/dwarf2/inline5.c with Solaris as (PR debug/87451) PR debug/87451 * gcc.dg/debug/dwarf2/inline5.c: Allow for non-comment before "(DIE (0x[0-9a-f]*) DW_TAG_variable". xfail scan-assembler-not with Solaris as. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c
[Bug target/89222] [7.x regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222 --- Comment #3 from Jonathan Larmour --- Thanks for the quick reply. (In reply to Jakub Jelinek from comment #2) > Not confirming since it is unclear even on what OS you are using this It's an embedded OS, so from your point of view, it's essentially bare metal. There are no included headers in the testcase so I'm not expecting the OS to make a difference in terms of generated asm. I would have expected any arm-none-eabi toolchain based on 7.3 would do the same thing as the one I built at least. > and > what to look for (I don't see r5 set close to start of main etc.). I attached the generated assembly file I get with --save-temps and the compile command line I provided (using -Os). You can see r5 being set on line 50 of that file. > That > said, if hal_setjmp works similarly to setjmp, but you don't actually tell > the compiler it has that behavior through __attribute__((__returns_twice__)) > and it doesn't have one of the standard setjmp names, like setjmp, > sigsetjmp, savectx, vfork or getcontext (with optional _ or __ prefixes), > then it surprises me if it works at all. Fortunately the semantics of hal_setjmp aren't relevant for the purposes of this bug - it's just a function call. Since the processor exception occurs when attempting to call myhandler2(), the longjmp() is never reached. In fact myhandler2() can be empty... perhaps I should have done that to emphasise that point, sorry. Thanks, Jifl
[Bug target/84251] [8/9 Regression] Performance regression in gcc 8/9 when comparing floating point numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84251 --- Comment #11 from Jeffrey A. Law --- Oh, DOM is too early, it's expansion that exposes the redundancies. Seems like CSE ought to be able to pick this up though.
[Bug c++/88049] [7/8/9 Regression] ICE in lto_symtab_prevailing_virtual_decl at gcc/lto/lto-symtab.c:1075 since r231671
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88049 --- Comment #4 from Jason Merrill --- (In reply to Jan Hubicka from comment #3) > > > We ICE on the fact that _ZTV1aIN12_GLOBAL__N_11fEE which is vtable for > > > anonymous namespace type but it has EXTERNAL flag set. > > > > > > Jason, why this happens? I am changing type to C++: if there is indeed > > > legal > > > reason to have exported vtables for anonymous types, then we can simply > > > drop > > > the sanity check. > > > > It isn't exported; it has DECL_EXTERNAL set because it isn't defined, and it > > isn't defined because nothing uses it, so it isn't needed. Note that it > > isn't > > TREE_PUBLIC. > > Hmm, so perhaps just adjusting sanity check to also check || > !TREE_PUBLIC? I'd suggest changing the behavior on type_in_anonymous_namespace_p to just "return decl".
[Bug target/89222] [7.x regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222 --- Comment #2 from Jakub Jelinek --- Not confirming since it is unclear even on what OS you are using this and what to look for (I don't see r5 set close to start of main etc.). That said, if hal_setjmp works similarly to setjmp, but you don't actually tell the compiler it has that behavior through __attribute__((__returns_twice__)) and it doesn't have one of the standard setjmp names, like setjmp, sigsetjmp, savectx, vfork or getcontext (with optional _ or __ prefixes), then it surprises me if it works at all.
[Bug c++/89217] [9 Regression] ICE tree check: expected constructor, have error_mark in split_nonconstant_init_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89217
--- Comment #4 from Marek Polacek ---
Some sort of modification happens twice for the RANGE_FOR_EXPR. Originally we
have
{*((struct S *) this)->r}
which should be turned to
TARGET_EXPR r}>
but we now reprocess this again and get bogus
TARGET_EXPR r}>
[Bug rtl-optimization/88596] [9 Regression] ICE: Maximum number of LRA assignment passes is achieved (30)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88596
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-02-06
Ever confirmed|0 |1
--- Comment #7 from Jakub Jelinek ---
The above testcase reproduced, reduced to following, started with r266385.
Note, this testcase ICEd in gcc 7.x and earlier too, got fixed with r258504
(started with r225484). So, this testcase is effectively [7/9 Regression].
/* { dg-do compile } */
/* { dg-options "-O1 -fschedule-insns -fselective-scheduling -fno-tree-ter" }
*/
/* { dg-additional-options "-maccumulate-outgoing-args" { target i?86-*-*
x86_64-*-* } } */
void bar ();
void baz ();
void qux ();
_Complex char a, b, c, d, e, f, g, h, i, j, k, l, m, n, o;
void
foo ()
{
bar (b, c, d, e, 5);
baz (4, a, b, c, d);
baz (5, a, b, c, d, e);
baz (b, c, d, e, f);
baz (b, c, d, e, f, g);
baz (b, c, d, e, f, g, h);
baz (b, c, d, e, f, g, h, i);
baz (j);
baz (i, j, h, i, j, k, l, m, n, o);
qux (e, g, i, k, m, o);
}
The ICE in 6.x/7.x used to be like:
pr88596.c: In function ‘foo’:
pr88596.c:19:1: error: unable to find a register to spill
}
^
pr88596.c:19:1: error: this is the insn:
(insn 23 381 380 2 (set (zero_extract:SI (reg:SI 226 [orig:195 D.1795+1 ]
[195])
(const_int 8 [0x8])
(const_int 8 [0x8]))
(reg:SI 227)) pr88596.c:9 115 {insvsi_1}
(expr_list:REG_DEAD (reg:SI 227)
(nil)))
pr88596.c:19:1: internal compiler error: in assign_by_spills, at
lra-assigns.c:1417
[Bug libstdc++/89102] 'common_type' of single abominable function should not have a nested typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89102 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Wed Feb 6 17:25:26 2019 New Revision: 268586 URL: https://gcc.gnu.org/viewcvs?rev=268586=gcc=rev Log: PR libstdc++/89102 fix common_type<> and common_type specializations This is a partial implementation of the revised std::common_type rules from P0435R1. PR libstdc++/89102 (partial) * include/std/type_traits (common_type<>): Define. (common_type): Derive from common_type. * testsuite/20_util/common_type/requirements/explicit_instantiation.cc: Test zero-length template argument list. * testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc: Test additional single argument cases. * testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc: Adjust expected error. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/type_traits trunk/libstdc++-v3/testsuite/20_util/common_type/requirements/explicit_instantiation.cc trunk/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_1.cc trunk/libstdc++-v3/testsuite/20_util/common_type/requirements/sfinae_friendly_2.cc
[Bug rtl-optimization/87871] [9 Regression] testcases fail after r265398 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87871
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #8 from Wilco ---
(In reply to Segher Boessenkool from comment #5)
> The first one just needs an xfail. I don't know if it should be *-*-* there
> or only arm*-*-* should be added.
>
> The other two need some debugging by someone who knows the target and/or
> these tests.
The previous code for Arm was:
cbz r0, .L5
push{r4, lr}
mov r4, r0
bl foo
movwr2, #:lower16:.LANCHOR0
movtr2, #:upper16:.LANCHOR0
add r4, r4, r0
str r4, [r2]
pop {r4, pc}
.L5:
movsr0, #1
bx lr
Now it fails to shrinkwrap:
push{r4, lr}
mov r4, r0
cmp r4, #0
moveq r0, #1
beq .L3
bl foo
ldr r2, .L7
add r3, r4, r0
str r3, [r2]
.L3:
pop {r4, lr}
bx lr
It seems shrinkwrapping is more random, sometimes it's done as expected,
sometimes it is not. It was more consistent on older GCC's.
[Bug rtl-optimization/89195] [7/8 regression] Corrupted stack offset after combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89195 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[7/8/9 regression] |[7/8 regression] Corrupted |Corrupted stack offset |stack offset after combine |after combine | --- Comment #13 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/84201] 549.fotonik3d_r from SPEC2017 fails verification with recent Intel and AMD CPUs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84201
--- Comment #7 from Steve Ellcey ---
(In reply to Richard Biener from comment #6)
> If Martins bisection to power.fppized.o is correct you can bisect the loop
> via the vect_loop or vect_slp debug counters (or first try with just
> -fno-tree-{loop,slp}-vectorize to narrow down to loop vs. BB vectorization).
I will let one of the x86 experts try that. I was just surprised to find that
one of the most popular benchmarks fails on one of the most popular targets
and that it has been that way for about a year.
[Bug target/89213] Optimize V2DI shifts by a constant on power8 & above systems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89213 --- Comment #6 from Segher Boessenkool --- For 32-bit or smaller shifts you can use vspltisb always, or vspltis[hw] if you prefer. If generating code for ISA 2.07 (Power8) you don't have xxspltib but you do have vsld/vsrd/vsrad/vrld, hrm. You still can always generate the constant with just two insns of course (vspltis* and either a vsl* or a vrl* by 1, depending if you need the low bit 0 or 1, for example). But you cannot in general do it in one (non-load ;-) ) insn I think.
[Bug go/89123] Too many go test failures on s390x-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89123 --- Comment #10 from rdapp at linux dot ibm.com --- Created attachment 45621 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45621=edit Tentative patch for libgo on s390x I didn't manage to make much progress with analyzing the remaining FAILs but I guess this can wait until after this bug. Is there an easy/preferred way to build and debug a single test case without having to manually add a plethora of dependency arguments? Attached is a tentative patch that works for me on s390x and reduces the number of FAILs significantly. Does it look reasonable?
[Bug target/88856] [8/9 Regression] gfortran producing wrong code with -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #23 from Jakub Jelinek --- That said, the regression is fixed now.
[Bug target/88856] [8/9 Regression] gfortran producing wrong code with -funroll-loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88856 --- Comment #22 from Jakub Jelinek --- What we could do there is remove the first of those two splitters, remove the && !dead_or_set_p (insn, operands[1]) test from the second, and add peephole2 that would transform (set (access part 1) (subreg:SI (match_dup 1) low)) (set (match_dup 1) (rotate:DI (match_dup 1) (const_int 32))) (set (access part 2) (subreg:SI (match_dup 1) low)) with a lshiftrt instead of rotate if reg 1 is dead after the third insn (assuming rotate is more expensive as right shift, if it is the same expensive/same size, then having the two splitters makes no sense). The last rotate should have been removed by DCE already if it was truly dead (though, of course, if it for some reason isn't yet, you could have another peephole2 for that too).
[Bug tree-optimization/89223] [7/8/9 Regression] internal compiler error: in int_cst_value, at tree.c:11226
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223
Jakub Jelinek changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
The gimplifier change would be something like:
--- gimplify.c.jj 2019-01-28 23:30:53.199762928 +0100
+++ gimplify.c 2019-02-06 17:15:35.368976785 +0100
@@ -2977,6 +2977,10 @@ gimplify_compound_lval (tree *expr_p, gi
if (TREE_CODE (t) == ARRAY_REF || TREE_CODE (t) == ARRAY_RANGE_REF)
{
+ if (!error_operand_p (TREE_OPERAND (t, 1))
+ && (TYPE_PRECISION (TREE_TYPE (TREE_OPERAND (t, 1)))
+ > TYPE_PRECISION (sizetype)))
+ TREE_OPERAND (t, 1) = fold_convert (sizetype, TREE_OPERAND (t, 1));
/* Gimplify the dimension. */
if (!is_gimple_min_invariant (TREE_OPERAND (t, 1)))
{
and besides the fears about weirdo targets I think it is the right thing even
on 32-bit targets when they use long long indexes into arrays. After all, if
we gimplify it into pointer arithmetics, we'd cast to sizetype anyway.
Richard, thoughts on this?
Or if we fear too much, we could do that only if pointers have the same
precision as sizetype or something similar, I think weirdo targets will not
have support for > 64-bit integral types anyway.
[Bug tree-optimization/89223] [7/8/9 Regression] internal compiler error: in int_cst_value, at tree.c:11226
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223 --- Comment #4 from Jakub Jelinek --- I guess either we should lower ARRAY_REF indexes with precisions higher than pointer precision to that smaller precision early (during gimplification e.g.?), though not really sure what effect would that have on weirdo targets with 20/24-bit etc. pointers and sizetype say even smaller than pointers, or we should just punt somewhere in the data dependence handling for anything that involves integers with > HOST_BITS_PER_WIDE_INT precisions.
[Bug rtl-optimization/89225] [9 Regression] LRA hang on ppc64le compiling glibc starting with r268404
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89225 --- Comment #1 from Vladimir Makarov --- It seems my latest patch for PR87246 caused this: https://gcc.gnu.org/viewcvs/gcc?view=revision=268404
[Bug tree-optimization/89223] [7/8/9 Regression] internal compiler error: in int_cst_value, at tree.c:11226
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Target Milestone|--- |7.5 Summary|internal compiler error: in |[7/8/9 Regression] internal |int_cst_value, at |compiler error: in |tree.c:11226|int_cst_value, at ||tree.c:11226
[Bug tree-optimization/89223] internal compiler error: in int_cst_value, at tree.c:11226
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223
--- Comment #3 from Jakub Jelinek ---
Started with r210113.
int_cst_value changed there:
/* Make sure the sign-extended value will fit in a HOST_WIDE_INT. */
- gcc_assert (TREE_INT_CST_HIGH (x) == 0
- || TREE_INT_CST_HIGH (x) == -1);
+ gcc_assert (cst_and_fits_in_hwi (x));
which is not equivalent, as previously it wasn't testing whether it has signed
or unsigned type, now it is.
With a small modification:
int a[9];
unsigned __int128 b;
void
foo (void)
{
for (b = (((unsigned __int128) 4) << 64) + 4; b != 0; b -= unsigned
__int128) 1) << 64) + 1))
a[b] = a[b + b];
}
(where it relies on sizetype/pointers being at most 64-bit), it started to ICE
with r159879 when __int128 support has been introduced.
[Bug target/84251] [8/9 Regression] Performance regression in gcc 8/9 when comparing floating point numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84251 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #10 from Jeffrey A. Law --- Couldn't this be tackled in DOM? For A UNORDERED_EXPR B, on the true arm we record A != B must be true. A ORDERED_EXPR B, on the false arm we record A != B must be true. We might also be able to record something about the NaN status of A and B on the other arms as well.
[Bug c++/88983] [7 Regression] ICE in label_matches, at cp/constexpr.c:4035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88983 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Marek Polacek --- .
[Bug c++/89024] [7 Regression] ICE testing convertibility of incomplete enumeration types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89024 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Summary|[7/8 Regression] ICE|[7 Regression] ICE testing |testing convertibility of |convertibility of |incomplete enumeration |incomplete enumeration |types |types --- Comment #10 from Marek Polacek --- Fixed for 8 too.
[Bug c++/89024] [7/8 Regression] ICE testing convertibility of incomplete enumeration types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89024 --- Comment #9 from Marek Polacek --- Author: mpolacek Date: Wed Feb 6 15:36:20 2019 New Revision: 268583 URL: https://gcc.gnu.org/viewcvs?rev=268583=gcc=rev Log: PR c++/89024 - ICE with incomplete enum type. * call.c (standard_conversion): When converting an ARITHMETIC_TYPE_P to an incomplete type, return NULL. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/enum37.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/call.c
[Bug c++/89119] [7 Regression] internal compiler error: in tsubst_copy with RANGE_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89119 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Summary|[7/8 Regression] internal |[7 Regression] internal |compiler error: in |compiler error: in |tsubst_copy with RANGE_EXPR |tsubst_copy with RANGE_EXPR --- Comment #10 from Marek Polacek --- Fixed for 8 too.
[Bug c++/89119] [7/8 Regression] internal compiler error: in tsubst_copy with RANGE_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89119 --- Comment #9 from Marek Polacek --- Author: mpolacek Date: Wed Feb 6 15:33:18 2019 New Revision: 268582 URL: https://gcc.gnu.org/viewcvs?rev=268582=gcc=rev Log: PR c++/89119 - ICE with value-initialization in template. * pt.c (tsubst_copy_and_build): Handle RANGE_EXPR. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/initlist-value3.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/pt.c
[Bug tree-optimization/89223] internal compiler error: in int_cst_value, at tree.c:11226
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Updated testcase that doesn't have UB at runtime if it was ever called:
int a[9];
unsigned __int128 b;
void
foo (void)
{
for (b = 4; b != 0; b--)
a[b] = a[b + b];
}
[Bug c++/88983] [7 Regression] ICE in label_matches, at cp/constexpr.c:4035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88983 Marek Polacek changed: What|Removed |Added Summary|[7/8 Regression] ICE in |[7 Regression] ICE in |label_matches, at |label_matches, at |cp/constexpr.c:4035 |cp/constexpr.c:4035 --- Comment #8 from Marek Polacek --- Fixed for 8 too.
[Bug c++/88983] [7/8 Regression] ICE in label_matches, at cp/constexpr.c:4035
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88983 --- Comment #7 from Marek Polacek --- Author: mpolacek Date: Wed Feb 6 15:29:14 2019 New Revision: 268581 URL: https://gcc.gnu.org/viewcvs?rev=268581=gcc=rev Log: PR c++/88983 - ICE with switch in constexpr function. * constexpr.c (cxx_eval_switch_expr): Use SWITCH_COND and SWITCH_BODY. (cxx_eval_constant_expression) : Don't look for the label in the else branch if we found it in the then branch. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp1y/constexpr-88983.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/constexpr.c
[Bug go/89199] libgo intermittent testcase failures on ppc64le power9 after r268458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89199
boger at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
Severity|normal |major
--- Comment #1 from boger at gcc dot gnu.org ---
I have raised this priority because this looks like a bug in the Go code due to
the use of __atomic_compare_exchange_n builtin and how it is implementing the
CompareAndSwapUintptr.
In atomic.c:
_Bool
CompareAndSwapUintptr (uintptr_t *val, uintptr_t old, uintptr_t new)
{
return __atomic_compare_exchange_n (val, , new, true, __ATOMIC_SEQ_CST,
__ATOMIC_RELAXED);
}
The true argument is indicating 'weak' which results in the following code.
Note that there is no guarantee in this code that the CompareAndSwap will do
the store and return true, if it can't get the reservation it will return false
and the store won't happen.
010cc280 :
10cc280: ac 04 00 7c hwsync
10cc284: a8 18 20 7d ldarx r9,0,r3
10cc288: 00 20 29 7c cmpdr9,r4
10cc28c: 0c 00 82 40 bne 10cc298
10cc290: ad 19 a0 7c stdcx. r5,0,r3
10cc294: 2c 01 00 4c isync
10cc298: 26 00 78 7c mfocrf r3,128
10cc29c: fe 1f 63 54 rlwinm r3,r3,3,31,31
10cc2a0: 20 00 80 4e blr
If I look in sync/cond.go check() function:
func (c *copyChecker) check() {
if uintptr(*c) != uintptr(unsafe.Pointer(c)) &&
!atomic.CompareAndSwapUintptr((*uintptr)(c), 0,
uintptr(unsafe.Pointer(c))) &&
uintptr(*c) != uintptr(unsafe.Pointer(c)) {
panic("sync.Cond is copied")
}
}
This if check assumes that the CompareAndSwapUinptr will do the store if needed
which is not true with the latest implementation of CompareAndSwapUintptr. It
seems that the CompareAndSwapUinptr should be passing the argument to indicate
'strong' and not 'weak'. I made that change and that fixes this problem. I have
not checked the other CompareAndSwaps.
[Bug c++/89158] [8 Regression] by-value capture of ICE variable isn't an lvalue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89158 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Marek Polacek --- Fixed.
[Bug c++/89158] [8 Regression] by-value capture of ICE variable isn't an lvalue?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89158 --- Comment #8 from Marek Polacek --- Author: mpolacek Date: Wed Feb 6 15:26:24 2019 New Revision: 268580 URL: https://gcc.gnu.org/viewcvs?rev=268580=gcc=rev Log: PR c++/89158 - by-value capture of constexpr variable broken. * call.c (convert_like_real) : Call mark_exp_read instead of mark_rvalue_use. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-89158.C Modified: branches/gcc-8-branch/gcc/cp/ChangeLog branches/gcc-8-branch/gcc/cp/call.c
[Bug sanitizer/89215] UBSAN leaks memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89215
--- Comment #2 from Jakub Jelinek ---
E.g. the LLVM demangler even documents that leak:
const char *DemangleCXXABI(const char *name) {
// FIXME: __cxa_demangle aggressively insists on allocating memory.
// There's not much we can do about that, short of providing our
// own demangler (libc++abi's implementation could be adapted so that
// it does not allocate). For now, we just call it anyway, and we leak
// the returned value.
if (&__cxxabiv1::__cxa_demangle)
if (const char *demangled_name =
__cxxabiv1::__cxa_demangle(name, 0, 0, 0))
return demangled_name;
return name;
}
on the other side, e.g.
const char *WinSymbolizerTool::Demangle(const char *name) {
CHECK(is_dbghelp_initialized);
static char demangle_buffer[1000];
if (name[0] == '\01' &&
UnDecorateSymbolName(name + 1, demangle_buffer, sizeof(demangle_buffer),
UNDNAME_NAME_ONLY))
return demangle_buffer;
else
return name;
}
will not allocate anything and so trying to free wouldn't work.
[Bug tree-optimization/89223] internal compiler error: in int_cst_value, at tree.c:11226
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223 David Malcolm changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-06 CC||dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Confirmed via godbolt; this crashes GCC 5 onwards, including trunk. It's failing this assertion here: 11731 /* Make sure the sign-extended value will fit in a HOST_WIDE_INT. */ 11732 gcc_assert (cst_and_fits_in_hwi (x)); where: (gdb) call debug_tree (x) constant 0xfffe>
[Bug rtl-optimization/89225] [9 Regression] LRA hang on ppc64le compiling glibc starting with r268404
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89225 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-06 CC||vmakarov at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug rtl-optimization/89225] New: [9 Regression] LRA hang on ppc64le compiling glibc starting with r268404
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89225
Bug ID: 89225
Summary: [9 Regression] LRA hang on ppc64le compiling glibc
starting with r268404
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
The following testcase hangs in LRA with -O2 -fstack-protector-strong
-mlong-double-128 on powerpc64le-linux.
extern long double foo (long double);
extern double bar (double);
typedef long long int64_t;
typedef unsigned long long uint64_t;
typedef union { int64_t i[2]; long double x; double d[2]; } mynumber;
static const double t512 = 0x1p512, tm256 = 0x1p-256, two54 = 0x1p54, twom54 =
0x1p-54;
long double
foo (long double x)
{
static const long double big = 134217728.0, big1 = 134217729.0;
long double t, s, i;
mynumber a, c;
uint64_t k, l;
int64_t m, n;
double d;
a.x = x;
k = a.i[0] & 0x7fffL;
if (k > 0x000fL && k < 0x7ff0L)
{
if (x < 0)
return (big1 - big1) / (big - big);
l = (k & 0x001fL) | 0x3fe0L;
if ((a.i[1] & 0x7fffL) != 0)
{
n = (int64_t) ((l - k) * 2) >> 53;
m = (a.i[1] >> 52) & 0x7ff;
if (m == 0)
{
a.d[1] *= two54;
m = ((a.i[1] >> 52) & 0x7ff) - 54;
}
m += n;
if (m > 0)
a.i[1] = (a.i[1] & 0x800fL) | (m << 52);
else if (m <= -54)
{
a.i[1] &= 0x8000L;
}
else
{
m += 54;
a.i[1] = (a.i[1] & 0x800fL) | (m << 52);
a.d[1] *= twom54;
}
}
a.i[0] = l;
s = a.x;
d = bar (a.d[0]);
c.i[0] = 0x2000L + ((k & 0x7fe0L) >> 1);
c.i[1] = 0;
i = d;
t = 0.5L * (i + s / i);
i = 0.5L * (t + s / t);
return c.x * i;
}
else
{
if (k >= 0x7ff0L)
return x * x + x;
if (x == 0)
return x;
if (x < 0)
return (big1 - big1) / (big - big);
return tm256 * foo (x * t512);
}
}
[Bug libstdc++/88749] [9 Regression] Failure while building libstdc++-v3/src/filesystem/ops.cc on trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88749 Xi Ruoyao changed: What|Removed |Added CC||xry111 at mengyan1223 dot wang --- Comment #17 from Xi Ruoyao --- (In reply to Romain Geissler from comment #15) > Thanks for these remarks. > > FYI, what I am following are the Linux From Scratch guidelines, which build > the initial gcc like this (with both c and C++ support, disabling libstdc++ > build): > http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-pass1.html > Then after building the glibc, they do build the libstdc++ alone like this: > http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-libstdc++. > html > > With this PR I just found out that either my understanding of LFS is wrong, > either LFS itself is. Indeed I don't like much that when configured using my > bootstrap scripts libstdc++ doesn't use the C compiler but the C++ one to > find C headers. I will have a look to sort this out. LFS is not wrong but it's only tested with GCC-8.2, not GCC trunk. Its FAQ explicitly said "you can't gather all latest packages from ftp.gnu.org and expect them to work" :).
[Bug c++/71302] [9 Regression] -Wzero-as-null-pointer-constant: misleading caret location for pointer in function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71302 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org Target Milestone|--- |9.0 Summary|-Wzero-as-null-pointer-cons |[9 Regression] |tant: misleading caret |-Wzero-as-null-pointer-cons |location for pointer in |tant: misleading caret |function call |location for pointer in ||function call --- Comment #3 from David Malcolm --- (In reply to Eric Gallager from comment #2) > (In reply to Manuel López-Ibáñez from comment #1) > > I don't think this can be fixed without having locations for constants (or > > at least for the arguments of function calls, thus fixing PR43486.) > > Even though bug 43486 isn't quite fixed yet, David Malcolm still made some > major progress on it for GCC 9. In GCC 8, actually. Unfortunately, it seems to have regressed on trunk. g++ 7.4 has false positives for NULL, and uses the closing parenthesis of the call as the location: : In function 'int main()': :16:14: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] Function1(0); ^ :17:17: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] Function1(NULL); ^ :18:17: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] Function2(0, 0); ^ :19:20: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] Function2(NULL, 0); ^ g++ 8.2 gets it right: : In function 'int main()': :16:13: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] Function1(0); ^ :18:13: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] Function2(0, 0); ^ g++ trunk seems to have regressed: it uses the closing parenthesis of the call as the location (but doesn't have the false positives from above): : In function 'int main()': :16:14: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] 16 | Function1(0); | ^ :18:17: warning: zero as null pointer constant [-Wzero-as-null-pointer-constant] 18 | Function2(0, 0); | ^ I'm investigating the regression.
[Bug c++/84075] Template parameter not resolved: invalid application of ‘sizeof’ to incomplete type ‘boost::serialization::U’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075 Christoph Hertzberg changed: What|Removed |Added CC||chtz at informatik dot uni-bremen. ||de --- Comment #8 from Christoph Hertzberg --- Another case where someone hit this problem: https://stackoverflow.com/questions/54534047/eigen-matrix-boostserialization-c17/ Corresponding Bug at the Eigen-library: http://eigen.tuxfamily.org/bz/show_bug.cgi?id=1676
[Bug sanitizer/89215] UBSAN leaks memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89215
--- Comment #1 from Jakub Jelinek ---
Seems to be upstream bug, also in asan etc., Demangle(name) in there doesn't
really differentiate between cases where it allocated the memory or just
returned the passed in string or did something else.
E.g.
const char *MaybeDemangleGlobalName(const char *name) {
// We can spoil names of globals with C linkage, so use an heuristic
// approach to check if the name should be demangled.
bool should_demangle = false;
if (name[0] == '_' && name[1] == 'Z')
should_demangle = true;
else if (SANITIZER_WINDOWS && name[0] == '\01' && name[1] == '?')
should_demangle = true;
return should_demangle ? Symbolizer::GetOrInit()->Demangle(name) : name;
}
Not really sure if changing say:
Buffer->append("'%s'", Symbolizer::GetOrInit()->Demangle(A.String));
to:
char *str = Symbolizer::GetOrInit()->Demangle(A.String);
Buffer->append("'%s'", str);
if (str != A.String) InternalFree(str);
would be safe, after all, some demangling could be done with the internal
allocator, other with some other allocator, and libsanitizer supports many
different demangling styles.
[Bug target/89213] Optimize V2DI shifts by a constant on power8 & above systems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89213 --- Comment #5 from Michael Meissner --- Sure I could use XXSPLTIB all of the time if I limit the optimization to ISA 3.0 (power9). I was trying to add optimization for shift counts for 1..15 on ISA 2.07 (power8) as well, hence using VSPLTISW for the constants that fit in that range. Looking at the code for ISA 2.07, I think we need to extend the code for loading duplicated constants to consider using vspltisw/vupklsw on ISA 2.07 instead of xxspltib/vecb2d that we can use on ISA 3.0. I think I missed that the last time I was updating the code.
[Bug tree-optimization/88903] [7 Regression] wrong-code with SLP vectorized shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88903 --- Comment #8 from Richard Biener --- Author: rguenth Date: Wed Feb 6 12:56:02 2019 New Revision: 268578 URL: https://gcc.gnu.org/viewcvs?rev=268578=gcc=rev Log: 2019-02-06 Richard Biener Backport from mainline 2019-01-31 Richard Biener PR tree-optimization/89135 * tree-ssa-phiprop.c (pass_phiprop::execute): Skip blocks with abnormal preds. * gcc.dg/torture/pr89135.c: New testcase. 2019-01-18 Richard Biener PR tree-optimization/88903 * tree-vect-stmts.c (vectorizable_shift): Verify we see all scalar stmts a SLP shift amount is composed of when detecting shifts by scalars. * gcc.dg/vect/pr88903-1.c: New testcase. * gcc.dg/vect/pr88903-2.c: Likewise. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89135.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/vect/pr88903-1.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/vect/pr88903-2.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-phiprop.c branches/gcc-8-branch/gcc/tree-vect-stmts.c
[Bug tree-optimization/89135] [7 Regression] internal compiler error: in gimple_split_edge, at tree-cfg.c:2747
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89135 --- Comment #6 from Richard Biener --- Author: rguenth Date: Wed Feb 6 12:56:02 2019 New Revision: 268578 URL: https://gcc.gnu.org/viewcvs?rev=268578=gcc=rev Log: 2019-02-06 Richard Biener Backport from mainline 2019-01-31 Richard Biener PR tree-optimization/89135 * tree-ssa-phiprop.c (pass_phiprop::execute): Skip blocks with abnormal preds. * gcc.dg/torture/pr89135.c: New testcase. 2019-01-18 Richard Biener PR tree-optimization/88903 * tree-vect-stmts.c (vectorizable_shift): Verify we see all scalar stmts a SLP shift amount is composed of when detecting shifts by scalars. * gcc.dg/vect/pr88903-1.c: New testcase. * gcc.dg/vect/pr88903-2.c: Likewise. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr89135.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/vect/pr88903-1.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/vect/pr88903-2.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/tree-ssa-phiprop.c branches/gcc-8-branch/gcc/tree-vect-stmts.c
[Bug target/89224] New: subscript of NEON intrinsic discards const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89224
Bug ID: 89224
Summary: subscript of NEON intrinsic discards const
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: kretz at kde dot org
Target Milestone: ---
Test case (cf. https://godbolt.org/z/RFrftn):
#include
template
void g(T &) {
x = 1;
}
auto f(const __Int8x8_t ) {
g(x[0]);
//x[0] = 1; // ill-formed
}
decltype(x[0]) is `signed char&`, which can't be right if decltype(x) is
const-ref.
[Bug tree-optimization/89223] New: internal compiler error: in int_cst_value, at tree.c:11226
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223
Bug ID: 89223
Summary: internal compiler error: in int_cst_value, at
tree.c:11226
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gsocsameeran at gmail dot com
Target Milestone: ---
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: x86_64-linux-gnu
Created attachment 45620
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45620=edit
Preprocessed code of file named "crash1.c"
--BACKTRACK-
during GIMPLE pass: pcom
crash1.c: In function ‘func_13.constprop’:
crash1.c:701:24: internal compiler error: in int_cst_value, at tree.c:11730
701 | static const int32_t * func_13(int32_t * p_14)
|^~~
0x1fa2edc int_cst_value(tree_node const*)
../../gcc/tree.c:11730
0x31bd717 initialize_matrix_A
../../gcc/tree-data-ref.c:3194
0x31bf66d analyze_subscript_affine_affine
../../gcc/tree-data-ref.c:3614
0x31c15ff analyze_siv_subscript
../../gcc/tree-data-ref.c:3925
0x31c2b16 analyze_overlapping_iterations
../../gcc/tree-data-ref.c:4171
0x31c4e49 subscript_dependence_tester_1
../../gcc/tree-data-ref.c:4713
0x31c5074 subscript_dependence_tester
../../gcc/tree-data-ref.c:4760
0x31c54c9 compute_affine_dependence(data_dependence_relation*, loop*)
../../gcc/tree-data-ref.c:4819
0x31c5a3f compute_all_dependences(vec, vec*, vec, bool)
../../gcc/tree-data-ref.c:4886
0x31c7daf compute_data_dependences_for_loop(loop*, bool, vec*, vec*,
vec*)
../../gcc/tree-data-ref.c:5360
0x1a465ac tree_predictive_commoning_loop
../../gcc/tree-predcom.c:3191
0x1a47190 tree_predictive_commoning()
../../gcc/tree-predcom.c:3313
0x1a472eb run_tree_predictive_commoning
../../gcc/tree-predcom.c:3338
0x1a473b7 execute
../../gcc/tree-predcom.c:3367
---COMMMAND LINE
~/again_build/bin/current-gcc -O3 -fgnu-tm crash1.c -I../../runtime/ -w
GCC VERSION--
current-gcc (GCC) 9.0.0 20190108 (experimental)
--PREVIOUS REPORTING---
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=SUSPENDED_status=WAITING_status=REOPENED_status=RESOLVED_status=VERIFIED_status=CLOSED_known_to_fail_type=allwords_known_to_work_type=allwords_id=228813_format=advanced_desc=internal%20compiler%20error%3A%20in%20int_cst_value_desc_type=allwordssubstr
---REDUCED TEST CASE
a[5];
unsigned __int128 b;
c() {
b = 4;
for (;; b--)
a[b] = ({ a[b + b]; });
}
Previous reporting were on older version and reduced test case were different.
So I filed a new bug because it fails on the trunk.
[Bug c++/84075] Template parameter not resolved: invalid application of ‘sizeof’ to incomplete type ‘boost::serialization::U’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075 --- Comment #7 from Marc Schmitt --- Created attachment 45619 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45619=edit Preprocessed test case with eigen-only dependency
[Bug c++/84075] Template parameter not resolved: invalid application of ‘sizeof’ to incomplete type ‘boost::serialization::U’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075 --- Comment #6 from Marc Schmitt --- Created attachment 45618 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45618=edit Reduced test case with eigen-only dependency
[Bug c++/84075] Template parameter not resolved: invalid application of ‘sizeof’ to incomplete type ‘boost::serialization::U’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84075
Marc Schmitt changed:
What|Removed |Added
CC||schmitt.marc at gmail dot com
--- Comment #5 from Marc Schmitt ---
Hi,
we encountered a the same bug.
See:
https://stackoverflow.com/questions/54534047/eigen-matrix-boostserialization-c17
The bug is reproducible with G++8.
The bug seems to be related with the (new?) template argument deduction
mechanism in G++7/8 with --std=c++17 (or --std=gnu++17).
A simplified test case (thx @Marc Giese/SO), reproducing the problem just
including Eigen without the boost dependency is attached (see below).
//
// G++ 7
//
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
7.3.0-27ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)
//
// G++ 8
//
$ g++-8 -v
Using built-in specs.
COLLECT_GCC=g++-8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
8.2.0-1ubuntu2~18.04' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Ubuntu 8.2.0-1ubuntu2~18.04)
//
// testcase (see: https://stackoverflow.com/a/54536756/1267320)
//
#include
templateclass SPT>void f(SPT&);
template
void f(Eigen::Matrix<_Scalar, _Rows, _Cols, _Options, _MaxRows, _MaxCols> &
arMatrix){};
int main()
{
Eigen::Matrix2d m;
f(m);
}
//
compile with: (G++7 or G++8)
g++ -std=c++17 main.cpp
//
Error output:
$ g++ -std=c++17 main.cpp
In file included from /usr/local/include/Eigen/Core:365:0,
from main.cpp:1:
/usr/local/include/Eigen/src/Core/util/ForwardDeclarations.h: In instantiation
of ‘struct Eigen::internal::accessors_level’:
main.cpp:9:8: recursively required by substitution of
‘template class SPT> void f(SPT&) [with SPT = ]’
main.cpp:9:8: required from here
/usr/local/include/Eigen/src/Core/util/ForwardDeclarations.h:32:54: error:
incomplete type ‘Eigen::internal::traits’ used in nested name specifier
enum { has_direct_access = (traits::Flags & DirectAccessBit) ? 1 :
0,
^~
/usr/local/include/Eigen/src/Core/util/ForwardDeclarations.h:33:53: error:
incomplete type ‘Eigen::internal::traits’ used in nested name specifier
has_write_access = (traits::Flags & LvalueBit) ? 1 : 0,
[Bug target/89213] Optimize V2DI shifts by a constant on power8 & above systems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89213 --- Comment #4 from Segher Boessenkool --- You could just do xxspltib xx,sh vsrad 2,2,xx (only the low 6 bits of the shift count are looked at, for 64-bit shifts, in all vector insns).
[Bug other/89222] [7.x regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222 --- Comment #1 from Jonathan Larmour --- Created attachment 45617 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45617=edit Assembler file generated by GCC when compiled with -Os
[Bug other/89222] New: [7.x regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222 Bug ID: 89222 Summary: [7.x regression] ARM thumb-2 misoptimisation of func ptr call with -O2 or -Os Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: jifl-bugzilla at jifvik dot org Target Milestone: --- Created attachment 45616 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45616=edit C file to demonstrate problem [ I have set the Component as "Other" as I don't know which part of GCC's optimization is at fault] On GCC 7.3.0 I am experiencing a problem where GCC is misoptimizing code built with either -O2 or -Os. The effect of the misoptimization is that it calls a function pointer without the LS bit set, even though the function is a Thumb function (it's Cortex-M, so ARM mode isn't even allowed). The attached pared-down code demonstrates this, although I couldn't manage to divorce it from my embedded run-time, so unfortunately you will have to inspect the asm :-/ The key part is that if a certain magic constant is 1, then it fails. This constant is used to compare against function pointers (it is the value of SIG_DFL from signal.h and this sort of comparison is standard practise, e.g. in glibc etc.). Values of SIG_DFL other than 1 work - it is the fact it is 1 that confuses GCC. In the asm (I used -Os as it made more tractable output), right at the start of main(), r5 is loaded with e.g. 0x23a7. Then this value plus one is put into $r6. For most of the rest of the function r6 is left as-is, and is saved and restored around the call to the hal_setjmp function. Shortly after, there is a "blx r6" and that's when the processor gets the exception. The C file shows this when built with: arm-eabi-gcc -c -mcpu=cortex-m3 -mthumb -Os signal1.c Or -O2 equally.
[Bug rtl-optimization/89154] 5% degradation of CPU2006 473.astar starting with r266305
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89154 --- Comment #4 from Segher Boessenkool --- The r1 adjustment is establishing the stack frame. It needs to precede all stack accesses (not just those by the prologue saves!) We could separately wrap it, if that would help? You can then get multiple copies of it, that will be the only real benefit.
