[Bug testsuite/82132] FAIL: gcc.dg/vect/vect-tail-nomask-1.c (test for excess errors) due to missing posix_memalign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82132 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Yes, but that "builtin" will simply end up calling posix_memalign in the end. I'm copying the boilerplate from gcc.dg/torture/pr60092.c.
[Bug testsuite/82132] FAIL: gcc.dg/vect/vect-tail-nomask-1.c (test for excess errors) due to missing posix_memalign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82132 --- Comment #4 from Richard Biener --- Author: rguenth Date: Tue Jan 16 08:04:28 2018 New Revision: 256723 URL: https://gcc.gnu.org/viewcvs?rev=256723&root=gcc&view=rev Log: 2018-01-16 Richard Biener PR testsuite/82132 * gcc.dg/vect/vect-tail-nomask-1.c: Copy posix_memalign boiler-plate from gcc.dg/torture/pr60092.c. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vect/vect-tail-nomask-1.c
[Bug target/83888] New: [8 regression] new failures after r256639 on armhf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83888 Bug ID: 83888 Summary: [8 regression] new failures after r256639 on armhf Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- As I mentioned in PR83836, r256639 introduced new regressions on arm-none-linux-gnueabihf: gcc.dg/vect/no-fast-math-vect16.c scan-tree-dump-times vect "using an in-order \\(fold-left\\) reduction" 1 (found 0 times) gcc.dg/vect/vect-reduc-6.c -flto -ffat-lto-objects scan-tree-dump-times vect "using an in-order \\(fold-left\\) reduction" 1 (found 0 times) gcc.dg/vect/vect-reduc-6.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1 (found 0 times) gcc.dg/vect/vect-reduc-6.c scan-tree-dump-times vect "using an in-order \\(fold-left\\) reduction" 1 (found 0 times) gcc.dg/vect/vect-reduc-6.c scan-tree-dump-times vect "vectorized 1 loops" 1 (found 0 times) Seen on arm-none-linux-gnueabihf --with-mode arm --with-cpu cortex-a9 --with-fpu neon-fp16
[Bug middle-end/83889] New: [8 regression] new failures on some arm targets after r256644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83889 Bug ID: 83889 Summary: [8 regression] new failures on some arm targets after r256644 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- After r256644, I've noticed a few new failures on some arm targets: * on arm-none-linux-gnueabihf --with-mode arm --with-cpu arm10tdmi --with-fpu vfp * same on arm-none-eabi with default mode/cpu/fpu gcc.dg/vect/vect-alias-check-10.c -flto -ffat-lto-objects execution test gcc.dg/vect/vect-alias-check-10.c execution test gcc.dg/vect/vect-alias-check-11.c -flto -ffat-lto-objects execution test gcc.dg/vect/vect-alias-check-11.c execution test gcc.dg/vect/vect-alias-check-12.c -flto -ffat-lto-objects execution test gcc.dg/vect/vect-alias-check-12.c execution test gcc.dg/vect/vect-alias-check-8.c -flto -ffat-lto-objects execution test gcc.dg/vect/vect-alias-check-8.c execution test gcc.dg/vect/vect-alias-check-9.c -flto -ffat-lto-objects execution test gcc.dg/vect/vect-alias-check-9.c execution test Maybe it's just a matter of a missing effective-target, since most of the other tests have vect_int/vect_double, More restrictive guards are also needed for arm-none-eabi --with-mode thumb --with-cpu cortex-m3 because I build with --disable-multilib and these testcases are compiled/linked with -mfpu=neon -mfloat-abi=softfp -march=armv7-a, resulting in: /aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/tools/arm-none-eabi/bin/ld: error: /cclmCTmv.o: Conflicting architecture profiles A/M /aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/tools/arm-none-eabi/bin/ld: failed to merge target specific data of file /cclmCTmv.o
[Bug target/83838] Many gcc.target/i386/indirect-thunk*.c tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83838 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from H.J. Lu --- [...] >> > Does Solaris ld support comdat? >> >> ... like this one: complete Solaris ld support for comdat started >> sometime in the Solaris 11 timeframe, cf. configure.ac (comdat_group). >> Solaris 10 did not (at least not in a way that could cope with >> everything gcc might generate). > > G++ uses comdat extensively. Without comdat, g++ generates very > odd codes. Please double check if libstdc++ object files on Solaris > have any comdat sections. It's exactly as I said: sol10 $ readelf -g i386-pc-solaris2.10/libstdc++-v3/src/.libs/libstdc++.a File: i386-pc-solaris2.10/libstdc++-v3/src/.libs/libstdc++.a(compatibility.o) There are no section groups in this file. [... and so on for every object] sol11 $ elfdump -g i386-pc-solaris2.11/libstdc++-v3/src/.libs/libstdc++.a i386-pc-solaris2.11/libstdc++-v3/src/.libs/libstdc++.a(compatibility.o): Group Section: .group%DW.ref._ZTIN10__cxxabiv115__forced_unwindE Signature Symbol: DW.ref._ZTIN10__cxxabiv115__forced_unwindE Members: index flags / section [0] [ COMDAT ] [1] .data.DW.ref._ZTIN10__cxxabiv115__forced_unwindE%DW.ref._ZTIN10__cxxabiv115__forced_unwindE [2] .rel.data.DW.ref._ZTIN10__cxxabiv115__forced_unwindE%DW.ref._ZTIN10__cxxabiv115__forced_unwindE [...] Even without comdat support, C++ testresults on Solaris 10 are as good as on Solaris 11. Rainer
[Bug target/83890] New: [8 regression] new failures on aarch64 -mabi=ilp32 after r256644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83890 Bug ID: 83890 Summary: [8 regression] new failures on aarch64 -mabi=ilp32 after r256644 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- After r256644, I've noticed that some of the new tests fail on aarch64 -mabi=ilp32: gcc.target/aarch64/sve/strided_load_8.c -march=armv8.2-a+sve scan-assembler-times \\tcbz\\tw1, 1 (found 0 times) gcc.target/aarch64/sve/var_stride_2.c -march=armv8.2-a+sve scan-assembler-times \\tadd\\tx[0-9]+, x[0-9]+, x[0-9]+, lsl 10\\n 2 (found 0 times) gcc.target/aarch64/sve/var_stride_3.c -march=armv8.2-a+sve scan-assembler \\tcmp\\tw2, 0 gcc.target/aarch64/sve/var_stride_3.c -march=armv8.2-a+sve scan-assembler-times \\tcsel\\tx[0-9]+ 2 (found 0 times) gcc.target/aarch64/sve/var_stride_4.c -march=armv8.2-a+sve scan-assembler \\tcmp\\tw2, 0 gcc.target/aarch64/sve/var_stride_4.c -march=armv8.2-a+sve scan-assembler \\tcmp\\tw3, 0 gcc.target/aarch64/sve/var_stride_4.c -march=armv8.2-a+sve scan-assembler-times \\tcsel\\tx[0-9]+ 4 (found 0 times) gcc.target/aarch64/sve/var_stride_4.c -march=armv8.2-a+sve scan-assembler-times \\tlsl\\tx[0-9]+, x[0-9]+, 10\\n 2 (found 0 times) gcc.target/aarch64/sve/var_stride_5.c -march=armv8.2-a+sve scan-assembler \\tcmp\\tx[0-9]+, 0 gcc.target/aarch64/sve/var_stride_5.c -march=armv8.2-a+sve scan-assembler-not \\tcmp\\tw[0-9]+, 0 gcc.target/aarch64/sve/var_stride_5.c -march=armv8.2-a+sve scan-assembler-times \\tcsel\\tx[0-9]+ 2 (found 0 times) gcc.target/aarch64/sve/var_stride_6.c -march=armv8.2-a+sve scan-assembler \\tcmp\\tx[0-9]+, 0 gcc.target/aarch64/sve/var_stride_6.c -march=armv8.2-a+sve scan-assembler \\tld1d\\tz[0-9]+ gcc.target/aarch64/sve/var_stride_6.c -march=armv8.2-a+sve scan-assembler \\tldr\\tx[0-9]+ gcc.target/aarch64/sve/var_stride_6.c -march=armv8.2-a+sve scan-assembler \\tst1d\\tz[0-9]+ gcc.target/aarch64/sve/var_stride_6.c -march=armv8.2-a+sve scan-assembler \\tstr\\tx[0-9]+ gcc.target/aarch64/sve/var_stride_6.c -march=armv8.2-a+sve scan-assembler-not \\tcmp\\tw[0-9]+, 0 gcc.target/aarch64/sve/var_stride_6.c -march=armv8.2-a+sve scan-assembler-times \\tcsel\\tx[0-9]+ 4 (found 0 times) gcc.target/aarch64/sve/var_stride_6.c -march=armv8.2-a+sve scan-assembler-times lsl\\tx[0-9]+, x[0-9]+, 11 2 (found 0 times) gcc.target/aarch64/sve/var_stride_7.c -march=armv8.2-a+sve scan-assembler \\tcmp\\tx[0-9]+, 0 gcc.target/aarch64/sve/var_stride_7.c -march=armv8.2-a+sve scan-assembler-not \\tcmp\\tw[0-9]+, 0 gcc.target/aarch64/sve/var_stride_7.c -march=armv8.2-a+sve scan-assembler-times \\tadd\\tx[0-9]+, x1, 2048 1 (found 0 times) gcc.target/aarch64/sve/var_stride_7.c -march=armv8.2-a+sve scan-assembler-times \\tcsel\\tx[0-9]+ 2 (found 0 times) gcc.target/aarch64/sve/var_stride_7.c -march=armv8.2-a+sve scan-assembler-times lsl\\tx[0-9]+, x[0-9]+, 11 1 (found 0 times) gcc.target/aarch64/sve/var_stride_8.c -march=armv8.2-a+sve scan-assembler \\tcmp\\tx[0-9]+, 0 gcc.target/aarch64/sve/var_stride_8.c -march=armv8.2-a+sve scan-assembler \\tld1d\\tz[0-9]+ gcc.target/aarch64/sve/var_stride_8.c -march=armv8.2-a+sve scan-assembler \\tldr\\tx[0-9]+ gcc.target/aarch64/sve/var_stride_8.c -march=armv8.2-a+sve scan-assembler \\tst1d\\tz[0-9]+ gcc.target/aarch64/sve/var_stride_8.c -march=armv8.2-a+sve scan-assembler \\tstr\\tx[0-9]+ gcc.target/aarch64/sve/var_stride_8.c -march=armv8.2-a+sve scan-assembler-not \\tcmp\\tw[0-9]+, 0 gcc.target/aarch64/sve/var_stride_8.c -march=armv8.2-a+sve scan-assembler-times \\tadd\\tx[0-9]+, x0, 2048 1 (found 0 times) gcc.target/aarch64/sve/var_stride_8.c -march=armv8.2-a+sve scan-assembler-times \\tcsel\\tx[0-9]+ 2 (found 0 times) gcc.target/aarch64/sve/var_stride_8.c -march=armv8.2-a+sve scan-assembler-times lsl\\tx[0-9]+, x[0-9]+, 11 1 (found 0 times)
[Bug c++/83825] [8 Regression] ICE on invalid C++ code with shadowed identifiers: in operator[], at vec.h:826
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83825 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue Jan 16 08:43:31 2018 New Revision: 256725 URL: https://gcc.gnu.org/viewcvs?rev=256725&root=gcc&view=rev Log: PR c++/83825 * name-lookup.c (member_vec_dedup): Return early if len is 0. (resort_type_member_vec, set_class_bindings, insert_late_enum_def_bindings): Use vec qsort method instead of calling qsort directly. * g++.dg/template/pr83825.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/pr83825.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog
[Bug c++/83817] [7/8 Regression] internal compiler error: tree check: expected call_expr, have aggr_init_expr in tsubst_copy_and_build, at cp/pt.c:17822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83817 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Tue Jan 16 08:44:48 2018 New Revision: 256726 URL: https://gcc.gnu.org/viewcvs?rev=256726&root=gcc&view=rev Log: PR c++/83817 * pt.c (tsubst_copy_and_build) : If function is AGGR_INIT_EXPR rather than CALL_EXPR, set AGGR_INIT_FROM_THUNK_P instead of CALL_FROM_THUNK_P. * g++.dg/cpp1y/pr83817.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1y/pr83817.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/83891] New: std::filesystem::path::is_absolute for Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83891
Bug ID: 83891
Summary: std::filesystem::path::is_absolute for Windows
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: faithandbrave at gmail dot com
Target Milestone: ---
Current is_absolute implementation is follow:
inline bool
path::is_absolute() const
{
#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
return has_root_name();
#else
return has_root_directory();
#endif
}
This means path("C:").is_absolute() == true. However, Windows GetFullPathName()
API says:
> If you specify "U:" the path returned is the current directory on the "U:\"
> drive
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364963(v=vs.85).aspx
I think path("C:").is_absolute() should return false.
As additional information, libc++/msvc experimental implementation returns
false.
[Bug tree-optimization/83843] [8 Regression] wrong code at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83843 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Tue Jan 16 08:53:09 2018 New Revision: 256727 URL: https://gcc.gnu.org/viewcvs?rev=256727&root=gcc&view=rev Log: PR tree-optimization/83843 * gimple-ssa-store-merging.c (imm_store_chain_info::output_merged_store): Handle bit_not_p on store_immediate_info for bswap/nop orig_stores. * gcc.dg/store_merging_18.c: New test. Added: trunk/gcc/testsuite/gcc.dg/store_merging_18.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-store-merging.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/83213] [8 Regression] peephole bug with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83213 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Tue Jan 16 08:54:03 2018 New Revision: 256728 URL: https://gcc.gnu.org/viewcvs?rev=256728&root=gcc&view=rev Log: PR rtl-optimization/83213 * recog.c (peep2_attempt): Copy over CROSSING_JUMP_P from peepinsn to last if both are JUMP_INSNs. Modified: trunk/gcc/ChangeLog trunk/gcc/recog.c
[Bug middle-end/83858] [8 Regression] error: invalid cast from type 'poly_uint16' to type 'long long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83858 Richard Biener changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org Target Milestone|--- |8.0
[Bug c++/83825] [8 Regression] ICE on invalid C++ code with shadowed identifiers: in operator[], at vec.h:826
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83825 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/83843] [8 Regression] wrong code at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83843 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug c++/83817] [7 Regression] internal compiler error: tree check: expected call_expr, have aggr_init_expr in tsubst_copy_and_build, at cp/pt.c:17822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83817 Jakub Jelinek changed: What|Removed |Added Summary|[7/8 Regression] internal |[7 Regression] internal |compiler error: tree check: |compiler error: tree check: |expected call_expr, have|expected call_expr, have |aggr_init_expr in |aggr_init_expr in |tsubst_copy_and_build, at |tsubst_copy_and_build, at |cp/pt.c:17822 |cp/pt.c:17822 --- Comment #7 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug rtl-optimization/83213] [8 Regression] peephole bug with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83213 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug c/83859] Please add new attribute which will establish relation between parameters for buffer and its size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83859 --- Comment #6 from Richard Biener --- Note you are partly exposing features of "fn spec".
[Bug libstdc++/83860] [6/7/8 Regression] valarray replacement type breaks with auto and more than one operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83860
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||5.4.0
Keywords||wrong-code
Last reconfirmed||2018-01-16
Ever confirmed|0 |1
Summary|valarray replacement type |[6/7/8 Regression] valarray
|breaks with auto and more |replacement type breaks
|than one operation |with auto and more than one
||operation
Target Milestone|--- |7.3
Known to fail||6.4.1, 7.2.1
--- Comment #1 from Richard Biener ---
Confirmed. Works with GCC 5, requires -O1+ to segfault. Doesn't segfault when
using clang++.
#include
int main()
{
std::valarray va(16), vb(16), vc(16);
auto sum = va + vb + vc;
std::valarray vsum = sum;
}
[Bug target/83862] powerpc: ICE in signbit testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83862 Richard Biener changed: What|Removed |Added Target Milestone|8.0 |---
[Bug fortran/83866] [8 Regression] ICE in gfc_release_symbol, at fortran/symbol.c:3087
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83866 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |8.0
[Bug tree-optimization/83867] [8 Regression] ICE: Segmentation fault in nested_in_vect_loop_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83867 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-16 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug c++/81054] [7/8 Regression] ICE with volatile variable in constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81054 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #3 from Paolo Carlini --- Mine.
[Bug middle-end/83837] [8 regression] libgomp.fortran/pointer[12].f90 FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83837 --- Comment #9 from paul.richard.thomas at gmail dot com --- Hi Jakub, Thanks truly for fixing this bug. I was planning to revert the change that I made because I couldn't find any way of correcting the problem from the fortran frontend. Cheers Paul On 15 January 2018 at 22:20, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83837 > > Jakub Jelinek changed: > >What|Removed |Added > > Status|ASSIGNED|RESOLVED > Resolution|--- |FIXED > > --- Comment #8 from Jakub Jelinek --- > Should be fixed now. > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug middle-end/83858] [8 Regression] error: invalid cast from type 'poly_uint16' to type 'long long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83858 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-16 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from rsandifo at gcc dot gnu.org --- Sorry about that. I'd used hppa64-hp-hpux11.23 for the hppa testing, and like you say, that doesn't seem to be affected. I agree moving it to pa.c is the right fix.
[Bug tree-optimization/83867] [8 Regression] ICE: Segmentation fault in nested_in_vect_loop_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83867
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment #2 from Richard Biener ---
The issue is that vectorized stmts replacing scalar stmts via
vect_finish_replace_stmt leave the scalar stmt def dangling in no BB. Here
9525 /* Handle inner-loop stmts whose DEF is used in the loop-nest that
9526 is being vectorized, but outside the immediately enclosing loop.
*/
9527 if (vec_stmt
9528 && STMT_VINFO_LOOP_VINFO (stmt_info)
9529 && nested_in_vect_loop_p (LOOP_VINFO_LOOP (
9530STMT_VINFO_LOOP_VINFO (stmt_info)),
stmt)
passes the dangling 'stmt' to nested_in_vect_loop_p.
Replacing the scalar def in this way is somewhat hacky given the caller still
has its hand on 'stmt' :/
We could fix this particular fallout but why do we need to re-use the original
SSA def? This is from vectorize_fold_left_reduction.
Anyway, I see it is convenient but I do expect more fallout from this.
Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c (revision 256722)
+++ gcc/tree-vect-stmts.c (working copy)
@@ -9426,6 +9426,11 @@ vect_transform_stmt (gimple *stmt, gimpl
gcc_assert (slp_node || !PURE_SLP_STMT (stmt_info));
gimple *old_vec_stmt = STMT_VINFO_VEC_STMT (stmt_info);
+ bool nested_p = (STMT_VINFO_LOOP_VINFO (stmt_info)
+ && nested_in_vect_loop_p
+ (LOOP_VINFO_LOOP (STMT_VINFO_LOOP_VINFO (stmt_info)),
+stmt));
+
switch (STMT_VINFO_TYPE (stmt_info))
{
case type_demotion_vec_info_type:
@@ -9525,9 +9530,7 @@ vect_transform_stmt (gimple *stmt, gimpl
/* Handle inner-loop stmts whose DEF is used in the loop-nest that
is being vectorized, but outside the immediately enclosing loop. */
if (vec_stmt
- && STMT_VINFO_LOOP_VINFO (stmt_info)
- && nested_in_vect_loop_p (LOOP_VINFO_LOOP (
-STMT_VINFO_LOOP_VINFO (stmt_info)), stmt)
+ && nested_p
&& STMT_VINFO_TYPE (stmt_info) != reduc_vec_info_type
&& (STMT_VINFO_RELEVANT (stmt_info) == vect_used_in_outer
|| STMT_VINFO_RELEVANT (stmt_info) ==
[Bug tree-optimization/57503] Missing warning for signed overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503 Georg-Johann Lay changed: What|Removed |Added Keywords|wrong-code |diagnostic Summary|[6/7/8 Regression] Wrong|Missing warning for signed |extension of multiply |overflow |operand | --- Comment #20 from Georg-Johann Lay --- (In reply to Marc Glisse from comment #18) > (In reply to Georg-Johann Lay from comment #17) > > Observation that -fno-wrapv also leads to correct code, hence there is > > somewhere a wrong assumption that signed overflow occurs (which doesn't). > > (you probably meant -fwrapv instead of -fno-wrapv?) Yes. > Why do you say wrong? > unsigned ab = a * b; > in C, that means: > unsigned ab = (int)a * (int)b; Thanks, I stared too much at the 2nd multiplication. > Since a is in [0, 255], so is (int)a. Multiplication may not overflow for a > signed type, so (int)a*(int)b must be nonnegative. Converting it to long > directly or through unsigned int is thus equivalent. -Wstrict-overflow= used to issue a warning like "assuming signed overflow might not occur", and maybe I was misguidid by the missing warning. Hence this is just a "missing warning" type of PR, if at all.
[Bug target/81481] [7 Regression] Spills %xmm to stack in glibc strspn SSE 4.2 variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81481 --- Comment #10 from Richard Biener --- Author: rguenth Date: Tue Jan 16 09:51:57 2018 New Revision: 256731 URL: https://gcc.gnu.org/viewcvs?rev=256731&root=gcc&view=rev Log: 2018-01-16 Richard Biener Backport from mainline 2017-09-29 Vladimir Makarov PR target/81481 * ira-costs.c (scan_one_insn): Don't take into account PIC equiv with a symbol for LRA. * gcc.target/i386/pr81481.c: New. Added: branches/gcc-7-branch/gcc/testsuite/gcc.target/i386/pr81481.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/ira-costs.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug libgomp/82428] Builtins for openacc gang/worker/vector id/size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82428 --- Comment #5 from Tom de Vries --- Created attachment 43147 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43147&action=edit Updated patch, using new interface New interface (as agreed upon here: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01331.html ): - int __builtin_goacc_parlevel_id (int); - int __builtin_goacc_parlevel_size (int); with arguments 0, 1, and 2 meaning gang, worker and vector. To be retested.
[Bug target/83737] [nvptx] FAIL: gcc.dg/stdint-width-1.c (test for excess errors) for with newlib stdint.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83737 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Tom de Vries --- Patch committed, no test-case required, marking resolved-fixed.
[Bug libstdc++/83834] [6/7/8 Regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83834
--- Comment #12 from nsz at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #10)
> This should fix it:
>
> --- a/libstdc++-v3/config/abi/pre/gnu.ver
> +++ b/libstdc++-v3/config/abi/pre/gnu.ver
> @@ -58,9 +58,7 @@ GLIBCXX_3.4 {
> # std::basic_stringbuf
> # std::basic_stringstream;
>std::basic_[t-z]*;
> - std::ba[t-z]*;
> - std::b[b-z]*;
> - std::c[a-g]*;
> + std::cerr;
> # std::char_traits;
> # std::c[i-z]*;
>std::c[i-n]*;
>
the patch looks good, please apply it.
i guess it should be backported too, so new binutils
keeps linking libstdc++ as expected.
> IMHO it's a bad idea to have such greedy patterns in the base GLIBCXX_3.4
> version anyway, because we never want them to match new symbols, only the
> ones that already exist in GLIBCXX_3.4
then this file could be cleaned up further.
[Bug bootstrap/83839] [8 Regression] bootstrap fails in gcc/config/i386/i386.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83839 --- Comment #8 from hjl at gcc dot gnu.org --- Author: hjl Date: Tue Jan 16 11:10:44 2018 New Revision: 256734 URL: https://gcc.gnu.org/viewcvs?rev=256734&root=gcc&view=rev Log: x86: Add -mfunction-return= Add -mfunction-return= option to convert function return to call and return thunks. The default is 'keep', which keeps function return unmodified. 'thunk' converts function return to call and return thunk. 'thunk-inline' converts function return to inlined call and return thunk. 'thunk-extern' converts function return to external call and return thunk provided in a separate object file. You can control this behavior for a specific function by using the function attribute function_return. Function return thunk is the same as memory thunk for -mindirect-branch= where the return address is at the top of the stack: __x86_return_thunk: call L2 L1: pause lfence jmp L1 L2: lea 8(%rsp), %rsp|lea 4(%esp), %esp ret and function return becomes jmp __x86_return_thunk -mindirect-branch= tests are updated with -mfunction-return=keep to avoid false test failures when -mfunction-return=thunk is added to RUNTESTFLAGS for "make check". gcc/ Backport from mainline 2018-01-14 H.J. Lu * config/i386/i386-protos.h (ix86_output_function_return): New. * config/i386/i386.c (ix86_set_indirect_branch_type): Also set function_return_type. (indirect_thunk_name): Add ret_p to indicate thunk for function return. (output_indirect_thunk_function): Pass false to indirect_thunk_name. (ix86_output_indirect_branch_via_reg): Likewise. (ix86_output_indirect_branch_via_push): Likewise. (output_indirect_thunk_function): Create alias for function return thunk if regno < 0. (ix86_output_function_return): New function. (ix86_handle_fndecl_attribute): Handle function_return. (ix86_attribute_table): Add function_return. * config/i386/i386.h (machine_function): Add function_return_type. * config/i386/i386.md (simple_return_internal): Use ix86_output_function_return. (simple_return_internal_long): Likewise. * config/i386/i386.opt (mfunction-return=): New option. (indirect_branch): Mention -mfunction-return=. * doc/extend.texi: Document function_return function attribute. * doc/invoke.texi: Document -mfunction-return= option. gcc/testsuite/ Backport from mainline 2018-01-14 H.J. Lu * gcc.target/i386/indirect-thunk-1.c (dg-options): Add -mfunction-return=keep. * gcc.target/i386/indirect-thunk-2.c: Likewise. * gcc.target/i386/indirect-thunk-3.c: Likewise. * gcc.target/i386/indirect-thunk-4.c: Likewise. * gcc.target/i386/indirect-thunk-5.c: Likewise. * gcc.target/i386/indirect-thunk-6.c: Likewise. * gcc.target/i386/indirect-thunk-7.c: Likewise. * gcc.target/i386/indirect-thunk-attr-1.c: Likewise. * gcc.target/i386/indirect-thunk-attr-2.c: Likewise. * gcc.target/i386/indirect-thunk-attr-3.c: Likewise. * gcc.target/i386/indirect-thunk-attr-4.c: Likewise. * gcc.target/i386/indirect-thunk-attr-5.c: Likewise. * gcc.target/i386/indirect-thunk-attr-6.c: Likewise. * gcc.target/i386/indirect-thunk-attr-7.c: Likewise. * gcc.target/i386/indirect-thunk-attr-8.c: Likewise. * gcc.target/i386/indirect-thunk-bnd-1.c: Likewise. * gcc.target/i386/indirect-thunk-bnd-2.c: Likewise. * gcc.target/i386/indirect-thunk-bnd-3.c: Likewise. * gcc.target/i386/indirect-thunk-bnd-4.c: Likewise. * gcc.target/i386/indirect-thunk-extern-1.c: Likewise. * gcc.target/i386/indirect-thunk-extern-2.c: Likewise. * gcc.target/i386/indirect-thunk-extern-3.c: Likewise. * gcc.target/i386/indirect-thunk-extern-4.c: Likewise. * gcc.target/i386/indirect-thunk-extern-5.c: Likewise. * gcc.target/i386/indirect-thunk-extern-6.c: Likewise. * gcc.target/i386/indirect-thunk-extern-7.c: Likewise. * gcc.target/i386/indirect-thunk-inline-1.c: Likewise. * gcc.target/i386/indirect-thunk-inline-2.c: Likewise. * gcc.target/i386/indirect-thunk-inline-3.c: Likewise. * gcc.target/i386/indirect-thunk-inline-4.c: Likewise. * gcc.target/i386/indirect-thunk-inline-5.c: Likewise. * gcc.target/i386/indirect-thunk-inline-6.c: Likewise. * gcc.target/i386/indirect-thunk-inline-7.c: Likewise. * gcc.target/i386/ret-thunk-1.c: New test. * gcc.target/i386/ret-thunk-10.c: Likewise. * gcc.target/i386/ret-thunk-11.c: Likewise. * gcc.target/i386/ret-thunk-12.c: Likewise. * gcc.target/i386/ret-thunk-13.c: Likewise. * gcc.target/i386/ret-thunk-14.c: Likewise. * gcc.target/i386
[Bug ada/83892] New: Various ICEs and link-errors with running ACATS with -O2 -g -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83892 Bug ID: 83892 Summary: Various ICEs and link-errors with running ACATS with -O2 -g -flto Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- Target: x86_64-linux-gnu You have to patch gcc/testsuite/ada/acats/run_all.sh to change flags. Result: === acats tests === FAIL: c330001 FAIL: c37010a FAIL: c371003 FAIL: c390011 FAIL: c3a0001 FAIL: c3a0006 FAIL: c52008b FAIL: c52103x FAIL: c52104x FAIL: c52104y FAIL: c731001 FAIL: c854002 FAIL: cc50a01 FAIL: cc50a02 FAIL: cdd2a01 FAIL: cdd2a02 FAIL: cdd2a03 FAIL: cxg2004 FAIL: cxg2013 FAIL: cxg2015 ICEs include 'error: type mismatch in component reference', 'error: type variant has different TREE_TYPE', 'internal compiler error: in get_alias_set, at alias.c:910' And some regular link-errors (some testcases may not support -flto).
[Bug target/83789] __builtin_altivec_lvx fails for powerpc for altivec-4.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83789 --- Comment #2 from Segher Boessenkool --- (In reply to Kaushikp from comment #0) > Should we modify the testcase so it runs only for 64-bit targets, > or should this builtin work for 32-bit targets as well? It shouldn't ICE for 32-bit either, whether the testcase really applies to 32-bit or not (I haven't looked).
[Bug libstdc++/83893] New: gnu.ver linker script has overly loose wildcard patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83893
Bug ID: 83893
Summary: gnu.ver linker script has overly loose wildcard
patterns
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
There is no reason to have patterns like these in the GLIBCXX_3.4 node in
config/abi/pre/gnu.ver
std::[ABD-Z]*;
std::a[a-c]*;
std::ad[a-n]*;
std::ad[p-z]*;
std::a[e-z]*;
The only symbols that matches any of these are std::allocator specializations,
so having the other patterns just risks unintentionally matching new symbols
and giving them the wrong symbol version (e.g. see PR 83834).
Tightening the patterns was attempted in r211355 but reverted due to PR 61536.
We should revisit this in stage 1.
For a start:
--- a/libstdc++-v3/config/abi/pre/gnu.ver
+++ b/libstdc++-v3/config/abi/pre/gnu.ver
@@ -24,43 +24,25 @@ GLIBCXX_3.4 {
# Names inside the 'extern' block are demangled names.
extern "C++"
{
- std::[ABD-Z]*;
- std::a[a-c]*;
- std::ad[a-n]*;
- std::ad[p-z]*;
- std::a[e-z]*;
-# std::ba[a-r]*;
- std::basic_[a-e]*;
- std::basic_f[a-h]*;
+# std::adopt_lock;
+ std::allocator::*;
+ std::allocator::*;
+# std::bad_*;
# std::basic_filebuf;
- std::basic_f[j-r]*;
# std::basic_fstream;
- std::basic_f[t-z]*;
- std::basic_[g-h]*;
- std::basic_i[a-e]*;
# std::basic_ifstream;
# std::basic_ios;
# std::basic_iostream;
- std::basic_istr[a-d]*;
# std::basic_istream;
# std::basic_istringstream;
- std::basic_i[t-z]*;
- std::basic_[j-n]*;
- std::basic_o[a-e]*;
# std::basic_ofstream;
-# std::basic_o[g-z]*;
- std::basic_o[g-r]*;
- std::basic_ostr[a-d]*;
+# std::basic_ostream;
# std::basic_ostringstream;
- std::basic_[p-r]*;
# std::basic_streambuf
# std::basic_string
# std::basic_stringbuf
# std::basic_stringstream;
- std::basic_[t-z]*;
- std::ba[t-z]*;
- std::b[b-z]*;
std::cerr;
# std::char_traits;
# std::c[i-z]*;
[Bug libstdc++/83834] [6/7/8 Regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83834
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #13 from Jonathan Wakely ---
(In reply to nsz from comment #12)
> (In reply to Jonathan Wakely from comment #10)
> > This should fix it:
> >
> > --- a/libstdc++-v3/config/abi/pre/gnu.ver
> > +++ b/libstdc++-v3/config/abi/pre/gnu.ver
> > @@ -58,9 +58,7 @@ GLIBCXX_3.4 {
> > # std::basic_stringbuf
> > # std::basic_stringstream;
> >std::basic_[t-z]*;
> > - std::ba[t-z]*;
> > - std::b[b-z]*;
> > - std::c[a-g]*;
> > + std::cerr;
> > # std::char_traits;
> > # std::c[i-z]*;
> >std::c[i-n]*;
> >
>
> the patch looks good, please apply it.
I think I'll just replace the std::c[a-g]* one for now.
> i guess it should be backported too, so new binutils
> keeps linking libstdc++ as expected.
Yes, I think it's safe to do so. I searched all the baseline_symbols.txt files
and only std::cerr matches any of those patterns.
I wonder if it's even worth adding a special case to binutils to
> > IMHO it's a bad idea to have such greedy patterns in the base GLIBCXX_3.4
> > version anyway, because we never want them to match new symbols, only the
> > ones that already exist in GLIBCXX_3.4
>
> then this file could be cleaned up further.
Oh definitely. I've created PR 83893 to track that (and noted some history
there).
[Bug target/81481] [7 Regression] Spills %xmm to stack in glibc strspn SSE 4.2 variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81481 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Richard Biener --- Fixed.
[Bug libstdc++/77704] Data race on std::ctype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77704 Boris Kolpackov changed: What|Removed |Added CC||boris at kolpackov dot net --- Comment #4 from Boris Kolpackov --- Ran into this in 7.2.0 and considering workarounds. Are there plans to fix this some time soon or is this low-priority?
[Bug rtl-optimization/83620] [8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1470: unable to find a register to spill with -flive-range-shrinkage --param=max-sched-ready-insns=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83620 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug rtl-optimization/83620] [8 Regression] ICE: in assign_by_spills, at lra-assigns.c:1470: unable to find a register to spill with -flive-range-shrinkage --param=max-sched-ready-insns=0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83620 --- Comment #8 from Jakub Jelinek --- I've mistyped the PR number: Author: jakub Date: Tue Jan 16 08:55:14 2018 New Revision: 256729 URL: https://gcc.gnu.org/viewcvs?rev=256729&root=gcc&view=rev Log: PR rtl-optimization/86620 * params.def (max-sched-ready-insns): Bump minimum value to 1. * gcc.dg/pr64935-2.c: Use --param=max-sched-ready-insns=1 instead of --param=max-sched-ready-insns=0. * gcc.target/i386/pr83620.c: New test. * gcc.dg/pr83620.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr83620.c trunk/gcc/testsuite/gcc.target/i386/pr83620.c Modified: trunk/gcc/ChangeLog trunk/gcc/params.def trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr64935-2.c
[Bug fortran/83874] [6/7/8 Regression] ICE initializing character array from derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83874 Richard Biener changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |6.5
[Bug c++/83875] [feature request] target_clones compatible SIMD capability/length check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83875 --- Comment #1 from Richard Biener --- __AVX__ is constexpr enough, no?
[Bug tree-optimization/83847] [8 Regression] ICE in vectorizable_load, at tree-vect-stmts.c:7365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83847 Allan Jensen changed: What|Removed |Added CC||linux at carewolf dot com --- Comment #3 from Allan Jensen --- Affects building Qt 5.10 QtCore, but only if optimizing for certain architectures. I triggered it with /opt/gcc/bin/g++-8 -c -pipe -march=skylake -g -O3 -std=c++1z -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -Wvla -Wdate-time -Wshift-overflow=2 -Wduplicated-cond -Wno-stringop-overflow -D_REENTRANT -fPIC -DQT_NO_USING_NAMESPACE -DQT_NO_FOREACH -DELF_INTERPRETER=\"/lib64/ld-linux-x86-64.so.2\" -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x05 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DPCRE2_CODE_UNIT_WIDTH=16 -I/src/qt5/qtbase/src/corelib -I. -Iglobal -I/src/qt5/qtbase/src/3rdparty/harfbuzz/src -I/src/qt5/qtbase/src/3rdparty/md5 -I/src/qt5/qtbase/src/3rdparty/md4 -I/src/qt5/qtbase/src/3rdparty/sha3 -I/src/qt5/qtbase/src/3rdparty/forkfd -I../../include -I../../include/QtCore -I../../include/QtCore/5.10.1 -I../../include/QtCore/5.10.1/QtCore -I.moc -I/src/qt5/qtbase/src/3rdparty/pcre2/src -isystem /usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/src/qt5/qtbase/mkspecs/linux-g++ -o .obj/qmetaobjectbuilder.o /src/qt5/qtbase/src/corelib/kernel/qmetaobjectbuilder.cpp Removing -march=skylake worked.
[Bug testsuite/83882] FAIL: g++.dg/opt/pr81715.C -std=gnu++98 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83882 Richard Biener changed: What|Removed |Added CC||jakub at gcc dot gnu.org Component|tree-optimization |testsuite --- Comment #1 from Richard Biener --- Possibly caused by PAs callee-copy handling for struct S? Thus just needs upping for PA?
[Bug testsuite/83883] FAIL: gcc.dg/tree-ssa/ssa-dse-26.c scan-tree-dump-times dse1 "Deleted dead store" 2 (found 4 times)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83883 Richard Biener changed: What|Removed |Added CC||law at gcc dot gnu.org Component|tree-optimization |testsuite --- Comment #1 from Richard Biener --- Again possibly callee-copy handling exposes more dead stores. Is there a dg-effective target for that "feature"?
[Bug tree-optimization/83847] [8 Regression] ICE in vectorizable_load, at tree-vect-stmts.c:7365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83847 --- Comment #4 from Allan Jensen --- Full output from the ICE: during GIMPLE pass: vect /src/qt5/qtbase/src/corelib/kernel/qmetaobjectbuilder.cpp: In function ‘int buildMetaObject(QMetaObjectBuilderPrivate*, char*, int, bool)’: /src/qt5/qtbase/src/corelib/kernel/qmetaobjectbuilder.cpp:1174:12: internal compiler error: in vectorizable_load, at tree-vect-stmts.c:7365 static int buildMetaObject(QMetaObjectBuilderPrivate *d, char *buf, ^~~ 0x74c949 vectorizable_load ../../gcc/tree-vect-stmts.c:7365 0x10a40b4 vect_analyze_stmt(gimple*, bool*, _slp_tree*, _slp_instance*) ../../gcc/tree-vect-stmts.c:9355 0x10bddee vect_analyze_loop_operations ../../gcc/tree-vect-loop.c:1875 0x10bddee vect_analyze_loop_2 ../../gcc/tree-vect-loop.c:2254 0x10bddee vect_analyze_loop(loop*, _loop_vec_info*) ../../gcc/tree-vect-loop.c:2546 0x10d6b2d vectorize_loops() ../../gcc/tree-vectorizer.c:664 Please submit a full bug report,
[Bug rtl-optimization/83886] [8 Regression] ICE in cfg_layout_redirect_edge_and_branch, at cfgrtl.c:4433
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83886 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug target/83890] [8 regression] new failures on aarch64 -mabi=ilp32 after r256644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83890 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug tree-optimization/83887] [8 Regression] [graphite] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 3 should be 21, not 18)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83887 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-16 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Hmm. Mine.
[Bug target/83888] [8 regression] new failures after r256639 on armhf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83888 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug middle-end/83889] [8 regression] new failures on some arm targets after r256644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83889 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug target/83894] New: [missed optimization] __v16qu shift instruction sequence on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83894 Bug ID: 83894 Summary: [missed optimization] __v16qu shift instruction sequence on x86 Product: gcc Version: 7.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: --- Created attachment 43148 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43148&action=edit benchmark shifts of vector builtins with 8-bit integral element type can be optimized better. I.e. `v << n` can be implemented as 1. load 0x00ff00ff00ff... and 16-bit shift by n 2. xor (1) with 0xff00ff00ff00... to produce a bitmask 3. 16-bit shift v by n 4. bitwise and of (2) and (3) I'll attach a benchmark with an intrinsics based implementation.
[Bug target/83894] [missed optimization] __v16qu shift instruction sequence on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83894 --- Comment #1 from Matthias Kretz --- Created attachment 43149 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43149&action=edit tsc.h Header required for the benchmark code.
[Bug libstdc++/83834] [6/7/8 Regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83834 --- Comment #14 from Jonathan Wakely --- Author: redi Date: Tue Jan 16 12:43:08 2018 New Revision: 256739 URL: https://gcc.gnu.org/viewcvs?rev=256739&root=gcc&view=rev Log: PR libstdc++/83834 replace wildcard pattern in linker script PR libstdc++/83834 * config/abi/pre/gnu.ver (GLIBCXX_3.4): Replace std::c[a-g]* wildcard pattern with exact match for std::cerr. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/abi/pre/gnu.ver
[Bug target/83894] [missed optimization] __v16qu shift instruction sequence on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83894 --- Comment #2 from Matthias Kretz --- I compiled with: g++-7 -march=haswell -std=c++17 -O3 -flax-vector-conversions -o char_shift char_shift.cpp
[Bug tree-optimization/83847] [8 Regression] ICE in vectorizable_load, at tree-vect-stmts.c:7365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83847 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from rsandifo at gcc dot gnu.org --- Patch applied.
[Bug libstdc++/83893] gnu.ver linker script has overly loose wildcard patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83893 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-16 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=83834 Ever confirmed|0 |1
[Bug c++/71468] explicit ctor and overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71468 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- See PR 60027 comment 1 which argues this is what the standard requires (which is unfortunate IMHO). *** This bug has been marked as a duplicate of bug 60027 ***
[Bug c++/77386] Explicit constructor is allowed causing ambiguous initialization call when it shouldn't be allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77386 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- See PR 60027 comment 1 which argues this is what the standard requires (which is unfortunate IMHO). *** This bug has been marked as a duplicate of bug 60027 ***
[Bug c++/60027] Problem with braced-init-lists and explicit ctors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60027 Jonathan Wakely changed: What|Removed |Added CC||g...@axel-naumann.de --- Comment #3 from Jonathan Wakely --- *** Bug 71468 has been marked as a duplicate of this bug. ***
[Bug c++/60027] Problem with braced-init-lists and explicit ctors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60027 Jonathan Wakely changed: What|Removed |Added CC||hpmv at google dot com --- Comment #2 from Jonathan Wakely --- *** Bug 77386 has been marked as a duplicate of this bug. ***
[Bug c++/60027] Problem with braced-init-lists and explicit ctors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60027 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #4 from Jonathan Wakely --- That's unfortunate, I much prefer the Clang and EDG behaviour, which is to resolve the ambiguity in favour of the converting constructor. In the Clang bug Ed links to https://wg21.link/cwg1228 So this is INVALID.
[Bug target/81481] [7 Regression] Spills %xmm to stack in glibc strspn SSE 4.2 variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81481 --- Comment #12 from Aurelien Jarno --- (In reply to Richard Biener from comment #11) > Fixed. Thanks!
[Bug c++/83895] New: -Wparentheses warns about pointer-to-member typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83895 Bug ID: 83895 Summary: -Wparentheses warns about pointer-to-member typedefs Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ville.voutilainen at gmail dot com Target Milestone: --- Test: struct X; typedef int (X::*foo); gcc diagnoses this with warning: unnecessary parentheses in declaration of 'foo' [-Wparentheses] There's no danger of the code being interpreted as a function call. The parentheses are superfluous but harmless.
[Bug testsuite/83882] FAIL: g++.dg/opt/pr81715.C -std=gnu++98 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83882
--- Comment #2 from Jakub Jelinek ---
Created attachment 43150
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43150&action=edit
gcc8-pr83882.patch
Possible untested fix. Can't test it even with a cross-compiler on the
testcase, because hppa seems be completely broken since the GET_MODE_*SIZE
changes:
../../gcc/config/pa/pa.h:601:43: error: invalid cast from type 'poly_uint16
{aka poly_int<1, short unsigned int>}' to type 'long int'
[Bug ada/83884] FAIL: gnat.dg/check_displace_generation.adb (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83884 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-16 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from rsandifo at gcc dot gnu.org --- Started with r256152
[Bug c++/83814] [8 Regression] ICE: in fold_binary_loc, at fold-const.c:9733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83814
--- Comment #9 from David Binderman ---
This similar code:
extern "C" void *memset(void *, int, unsigned long) ;
char *a ;
template < class b > void c() {
memset(a + sizeof(b), 0, 0);
}
does this:
bug411-b.cc: In function ‘void c()’:
bug411-b.cc:6:28: internal compiler error: in build2, at tree.c:4682
memset(a + sizeof(b), 0, 0);
^
0x1359c45 build2(tree_code, tree_node*, tree_node*, tree_node*)
../../trunk/gcc/tree.c:4681
0xb8cc4f build2_loc
../../trunk/gcc/tree.h:4112
0xb8cc4f fold_build2_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_n
ode*)
../../trunk/gcc/fold-const.c:12330
0xb8321d fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*,
tree_n
ode*)
I am not sure if your candidate patch fixes this code too.
[Bug middle-end/83858] [8 Regression] error: invalid cast from type 'poly_uint16' to type 'long long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83858 --- Comment #4 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Tue Jan 16 14:47:49 2018 New Revision: 256744 URL: https://gcc.gnu.org/viewcvs?rev=256744&root=gcc&view=rev Log: Move pa.h FUNCTION_ARG_SIZE to pa.c (PR83858) The port-local FUNCTION_ARG_SIZE: MODE) != BLKmode \ ? (HOST_WIDE_INT) GET_MODE_SIZE (MODE) \ : int_size_in_bytes (TYPE)) + UNITS_PER_WORD - 1) / UNITS_PER_WORD) is used by code in pa.c and by ASM_DECLARE_FUNCTION_NAME in som.h. Treating GET_MODE_SIZE as a constant is OK for the former but not the latter, which is used in target-independent code. This caused a build failure on hppa2.0w-hp-hpux11.11. 2018-01-16 Richard Sandiford gcc/ PR target/83858 * config/pa/pa.h (FUNCTION_ARG_SIZE): Delete. * config/pa/pa-protos.h (pa_function_arg_size): Declare. * config/pa/som.h (ASM_DECLARE_FUNCTION_NAME): Use pa_function_arg_size instead of FUNCTION_ARG_SIZE. * config/pa/pa.c (pa_function_arg_advance): Likewise. (pa_function_arg, pa_arg_partial_bytes): Likewise. (pa_function_arg_size): New function. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa-protos.h trunk/gcc/config/pa/pa.c trunk/gcc/config/pa/pa.h trunk/gcc/config/pa/som.h
[Bug testsuite/83882] FAIL: g++.dg/opt/pr81715.C -std=gnu++98 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83882 Jakub Jelinek changed: What|Removed |Added Attachment #43150|0 |1 is obsolete|| Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-16 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jakub Jelinek --- Created attachment 43151 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43151&action=edit gcc8-pr83882.patch Updated patch (TREE_TYPE (t) with non-existent t, should have been type). With Richard S. patch and this updated one the testcase in a cross-compiler doesn't trigger the warning. Can't really test this on hppa.
[Bug middle-end/83858] [8 Regression] error: invalid cast from type 'poly_uint16' to type 'long long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83858 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from rsandifo at gcc dot gnu.org --- Patch applied.
[Bug c++/83814] [8 Regression] ICE: in fold_binary_loc, at fold-const.c:9733
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83814 --- Comment #10 from Lars Gullik Bjønnes --- (In reply to David Malcolm from comment #8) > Sorry about the breakage. > > Here's a candidate patch: > https://gcc.gnu.org/ml/gcc-patches/2018-01/msg01133.html This fixes the ICE for me, with the patch appleid I am not able to reproduce the ice in comment #9 either. gcc --version gcc (GCC) 8.0.1 20180116 (experimental) with the proposed patched applied.
[Bug c/83896] New: ice in tree_to_shwi, at tree.c:6847
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83896
Bug ID: 83896
Summary: ice in tree_to_shwi, at tree.c:6847
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
Somewhere from revision 256420 to 256556, the following C code,
with flag -O2, does this:
during GIMPLE pass: strlen
bug412-min.c: In function ‘e’:
bug412-min.c:4:1: internal compiler error: in tree_to_shwi, at tree.c:6847
e() {
^
0x10f170f tree_to_shwi(tree_node const*)
../../trunk/gcc/tree.c:6847
0x58aafd get_string_len
../../trunk/gcc/tree-ssa-strlen.c:2793
0x58aafd handle_char_store
../../trunk/gcc/tree-ssa-strlen.c:2970
C source code is
typedef struct { char a[5] } b;
c;
b d;
e() {
if (strlen(&c) != 4)
memcpy(d.a, &c, sizeof(d));
}
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #39 from Alexey Salmin --- Thank you, this patch works for me. Gives a warning in the attached test case, but still allows to take an address of a packed struct members when the packed attribute is preserved in the pointer.
[Bug c/83844] [8 Regression] ICE with warn_if_not_aligned attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83844 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Tue Jan 16 15:08:32 2018 New Revision: 256745 URL: https://gcc.gnu.org/viewcvs?rev=256745&root=gcc&view=rev Log: PR c/83844 * stor-layout.c (handle_warn_if_not_align): Use byte_position and multiple_of_p instead of unchecked tree_to_uhwi and UHWI check. If off is not INTEGER_CST, issue a may not be aligned warning rather than isn't aligned. Use isn%'t rather than isn't. * fold-const.c (multiple_of_p) : Don't fall through into MULT_EXPR. : Improve the case when bottom and one of the MULT_EXPR operands are INTEGER_CSTs and bottom is multiple of that operand, in that case check if the other operand is multiple of bottom divided by the INTEGER_CST operand. * gcc.dg/pr83844.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr83844.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/stor-layout.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/83867] [8 Regression] ICE: Segmentation fault in nested_in_vect_loop_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83867 --- Comment #3 from Richard Biener --- Author: rguenth Date: Tue Jan 16 15:13:05 2018 New Revision: 256746 URL: https://gcc.gnu.org/viewcvs?rev=256746&root=gcc&view=rev Log: 2018-01-16 Richard Biener PR tree-optimization/83867 * tree-vect-stmts.c (vect_transform_stmt): Precompute nested_in_vect_loop_p since the scalar stmt may get invalidated. * gcc.dg/vect/pr83867.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr83867.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/83857] [8 Regression] internal compiler error: in exact_div, at poly-int.h:2139
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83857 --- Comment #6 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Tue Jan 16 15:13:32 2018 New Revision: 256747 URL: https://gcc.gnu.org/viewcvs?rev=256747&root=gcc&view=rev Log: Two fixes for live-out SLP inductions (PR 83857) vect_analyze_loop_operations was calling vectorizable_live_operation for all live-out phis, which led to a bogus ncopies calculation in the pure SLP case. I think v_a_l_o should only be passing phis that are vectorised using normal loop vectorisation, since vect_slp_analyze_node_operations handles the SLP side (and knows the correct slp_index and slp_node arguments to pass in, via vect_analyze_stmt). With that fixed we hit an older bug that vectorizable_live_operation didn't handle live-out SLP inductions. Fixed by using gimple_phi_result rather than gimple_get_lhs for phis. 2018-01-16 Richard Sandiford gcc/ PR tree-optimization/83857 * tree-vect-loop.c (vect_analyze_loop_operations): Don't call vectorizable_live_operation for pure SLP statements. (vectorizable_live_operation): Handle PHIs. gcc/testsuite/ PR tree-optimization/83857 * gcc.dg/vect/pr83857.c: New test. Added: trunk/gcc/testsuite/gcc.dg/vect/pr83857.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/83867] [8 Regression] ICE: Segmentation fault in nested_in_vect_loop_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83867 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug libstdc++/83860] [6/7/8 Regression] valarray replacement type breaks with auto and more than one operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83860 --- Comment #2 from Bruno Manganelli --- Just to clarify, it still segfaults when using clang++ with libstdc++.
[Bug libgomp/83590] [nvptx] openacc reduction C regressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83590 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Tue Jan 16 15:18:24 2018 New Revision: 256748 URL: https://gcc.gnu.org/viewcvs?rev=256748&root=gcc&view=rev Log: PR libgomp/83590 * gimplify.c (gimplify_one_sizepos): For is_gimple_constant (expr) return early, inline manually is_gimple_sizepos. Make sure if we call gimplify_expr we don't end up with a gimple constant. * tree.c (variably_modified_type_p): Don't return true for is_gimple_constant (_t). Inline manually is_gimple_sizepos. * gimplify.h (is_gimple_sizepos): Remove. Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/gimplify.h trunk/gcc/tree.c
[Bug tree-optimization/83857] [8 Regression] internal compiler error: in exact_div, at poly-int.h:2139
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83857 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug c++/83895] [8 Regression] -Wparentheses warns about pointer-to-member typedefs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83895 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-16 CC||jakub at gcc dot gnu.org, ||nathan at gcc dot gnu.org Target Milestone|--- |8.0 Summary|-Wparentheses warns about |[8 Regression] |pointer-to-member typedefs |-Wparentheses warns about ||pointer-to-member typedefs Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r253446.
[Bug tree-optimization/83887] [8 Regression] [graphite] ICE in verify_dominators, at dominance.c:1184 (error: dominator of 3 should be 21, not 18)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83887 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at redhat dot com
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #40 from H.J. Lu --- (In reply to Alexey Salmin from comment #39) > Thank you, this patch works for me. > > Gives a warning in the attached test case, but still allows to take an > addre of a packed struct members when the packed attribute is preserved in > the pointer. Do you have such a testcase with the packed attribute preserved in the pointer?
[Bug libstdc++/83834] [6/7 Regression] FAIL: libstdc++-abi/abi_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83834 Jakub Jelinek changed: What|Removed |Added Summary|[6/7/8 Regression] FAIL:|[6/7 Regression] FAIL: |libstdc++-abi/abi_check |libstdc++-abi/abi_check --- Comment #15 from Jakub Jelinek --- Fixed on the trunk.
[Bug tree-optimization/83896] [8 Regression] ice in tree_to_shwi, at tree.c:6847
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83896 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Component|c |tree-optimization Target Milestone|--- |8.0 Summary|ice in tree_to_shwi, at |[8 Regression] ice in |tree.c:6847 |tree_to_shwi, at ||tree.c:6847
[Bug c/61240] [6/7/8 Regression] Incorrect warning "integer overflow in expression" on pointer-pointer subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61240 --- Comment #14 from Jakub Jelinek --- Marek, are you still on the hook to remove this premature optimization from the FE and let it be folded in c_fully_fold or later?
[Bug tree-optimization/78972] [6/7/8 Regression] poor x86 simd instruction scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972 Maxim Egorushkin changed: What|Removed |Added CC||maxim.yegorushkin at gmail dot com --- Comment #12 from Maxim Egorushkin --- (In reply to Bernd Schmidt from comment #11) > For reference: patch and discussion here. > https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01058.html Has this issue been resolved please? It is not clear what happened to that patch.
[Bug c/61240] [6/7/8 Regression] Incorrect warning "integer overflow in expression" on pointer-pointer subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61240 --- Comment #15 from Marek Polacek --- I've been meaning to address this PR (for too long, apparently), but it seems it's too late for GCC 8 now. If you want, you can take it. If not, hopefully I'll get to it for GCC 9.
[Bug c/61240] [6/7/8 Regression] Incorrect warning "integer overflow in expression" on pointer-pointer subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61240 --- Comment #16 from Jakub Jelinek --- It is a regression, so it isn't too late yet.
[Bug tree-optimization/78972] [6/7/8 Regression] poor x86 simd instruction scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972 --- Comment #13 from Jeffrey A. Law --- Folks where unhappy with various aspects of that patch. Bernd left Red Hat shortly thereafter and the patch hasn't been updated since his departure.
[Bug middle-end/83758] ICE building gccgo on powerpc64le --with-cpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83758
boger at us dot ibm.com changed:
What|Removed |Added
CC||boger at us dot ibm.com
--- Comment #5 from boger at us dot ibm.com ---
The gccgo command that actually results in the ICE is not what is shown above.
The original posting must have been based on a build using a -j option so some
of the compile output was interspersed. Here is the actual command that results
in the ICE:
/home/boger/gccgo.work/trunk/bld/./gcc/gccgo
-B/home/boger/gccgo.work/trunk/bld/./gcc/
-B/usr/local/gccgo.trunk/powerpc64le-linux/bin/
-B/usr/local/gccgo.trunk/powerpc64le-linux/lib/ -isystem
/usr/local/gccgo.trunk/powerpc64le-linux/include -isystem
/usr/local/gccgo.trunk/powerpc64le-linux/sys-include -O2 -g -I . -c
-fgo-pkgpath=cmd/go/internal/work
../../../src/libgo/go/cmd/go/internal/work/action.go
../../../src/libgo/go/cmd/go/internal/work/build.go
../../../src/libgo/go/cmd/go/internal/work/buildid.go
../../../src/libgo/go/cmd/go/internal/work/exec.go
../../../src/libgo/go/cmd/go/internal/work/gc.go
../../../src/libgo/go/cmd/go/internal/work/gccgo.go
../../../src/libgo/go/cmd/go/internal/work/init.go -o cmd/go/internal/work.o
during RTL pass: vartrack
../../../src/libgo/go/cmd/go/internal/work/gccgo.go: In function
\u2018work.gc.N35_cmd_go_internal_work.gccgoToolchain\u2019:
../../../src/libgo/go/cmd/go/internal/work/gccgo.go:54:1: internal compiler
error: in vt_expand_var_loc_chain, at var-tracking.c:8331
func (tools gccgoToolchain) gc(b *Builder, a *Action, archive string,
importcfg []byte, asmhdr bool, gofiles []string) (ofile string, output []byte,
err error) {
^
0x10d37b27 vt_expand_var_loc_chain
../../src/gcc/var-tracking.c:8331
0x10d37b27 vt_expand_loc_callback
../../src/gcc/var-tracking.c:8527
0x1041aad3 cselib_expand_value_rtx_1
../../src/gcc/cselib.c:1715
0x1041a797 cselib_expand_value_rtx_1
../../src/gcc/cselib.c:1753
0x1041a797 cselib_expand_value_rtx_1
../../src/gcc/cselib.c:1753
0x1041d837 cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../src/gcc/cselib.c:1561
0x10d375d3 vt_expand_var_loc_chain
../../src/gcc/var-tracking.c:8365
0x10d375d3 vt_expand_loc_callback
../../src/gcc/var-tracking.c:8527
0x1041aad3 cselib_expand_value_rtx_1
../../src/gcc/cselib.c:1715
0x1041a797 cselib_expand_value_rtx_1
../../src/gcc/cselib.c:1753
0x1041d837 cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../src/gcc/cselib.c:1561
0x10d375d3 vt_expand_var_loc_chain
../../src/gcc/var-tracking.c:8365
0x10d375d3 vt_expand_loc_callback
../../src/gcc/var-tracking.c:8527
0x1041aad3 cselib_expand_value_rtx_1
../../src/gcc/cselib.c:1715
0x1041d837 cselib_expand_value_rtx_cb(rtx_def*, bitmap_head*, int, rtx_def*
(*)(rtx_def*, bitmap_head*, int, void*), void*)
../../src/gcc/cselib.c:1561
0x10d38263 vt_expand_var_loc_chain
../../src/gcc/var-tracking.c:8365
0x10d38263 vt_expand_1pvar
../../src/gcc/var-tracking.c:8640
0x10d38263 emit_note_insn_var_location(variable**, emit_note_data*)
../../src/gcc/var-tracking.c:8695
0x10d396df void hash_table::traverse_noresize(emit_note_data*)
../../src/gcc/hash-table.h:969
0x10d396df void hash_table::traverse(emit_note_data*)
../../src/gcc/hash-table.h:990
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
Also note that the file it is complaining about
src/libgo/go/cmd/go/internal/work/gccgo.go is brand new with the latest update
to the go1.10beta1.
[Bug rtl-optimization/83424] [6/7 Regression] wrong code with -O -fno-tree-ccp -fno-tree-coalesce-vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83424 --- Comment #5 from Segher Boessenkool --- Author: segher Date: Tue Jan 16 16:20:10 2018 New Revision: 256750 URL: https://gcc.gnu.org/viewcvs?rev=256750&root=gcc&view=rev Log: rtlanal: dead_or_set_regno_p should handle CLOBBER (PR83424) In PR83424 combine's move_deaths puts a REG_DEAD note in the wrong place because dead_or_set_regno_p does not account for CLOBBER insns. This fixes it. PR rtl-optimization/83424 * rtlanal.c (dead_or_set_regno_p): Handle CLOBBER just like SET. gcc/testsuite/ PR rtl-optimization/83424 * gcc.dg/pr83424.c: New testsuite. Added: branches/gcc-7-branch/gcc/testsuite/gcc.dg/pr83424.c Modified: branches/gcc-7-branch/gcc/ChangeLog branches/gcc-7-branch/gcc/rtlanal.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug lto/83816] [7 Regression] lto1: internal compiler error: compressed stream: data error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 --- Comment #12 from Oleg Endo --- Created attachment 43152 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43152&action=edit preprocessed c++ source I was able to reduce it somewhat. However, I'd be surprised if it does not reproduce the error on some other system. I get the error only with the RX cross compiler rx-elf-gcc -v Using built-in specs. COLLECT_GCC=rx-elf-gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/rx-elf/6.4.1/lto-wrapper Target: rx-elf Configured with: ../gcc-6-branch-rx/configure --target=rx-elf --prefix=/usr/local --enable-languages=c,c++ --disable-nls --disable-werror --with-newlib --enable-lto --enable-multilib --with-system-zlib --disable-libstdcxx-verbose --disable-symvers Thread model: single gcc version 6.4.1 20180114 (GCC)
[Bug lto/83816] [7 Regression] lto1: internal compiler error: compressed stream: data error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 --- Comment #13 from Oleg Endo --- (In reply to Oleg Endo from comment #12) > I was able to reduce it somewhat. However, I'd be surprised if it does not > reproduce the error on some other system. I meant: I'd be surprised if it does reproduce the error .. still, would be interesting to see if somebody else can reproduce it.
[Bug lto/83816] [7 Regression] lto1: internal compiler error: compressed stream: data error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83816 --- Comment #14 from Oleg Endo --- (In reply to rguent...@suse.de from comment #11) > > Smells odd indeed. Can you try building with > --enable-valgrind-annotations and run valgrind on the thing? My theory > would still be a wild write somewhere... I can give it a try in a couple of days
[Bug tree-optimization/78972] [6/7/8 Regression] poor x86 simd instruction scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972 --- Comment #14 from Maxim Egorushkin --- (In reply to Jeffrey A. Law from comment #13) > Folks where unhappy with various aspects of that patch. Bernd left Red Hat > shortly thereafter and the patch hasn't been updated since his departure. I hit this issue too, the performance regression is 10-15% since gcc-4.9. We have to use -fno-tree-ter to mitigate.
[Bug rtl-optimization/83424] [6/7 Regression] wrong code with -O -fno-tree-ccp -fno-tree-coalesce-vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83424 --- Comment #6 from Segher Boessenkool --- Author: segher Date: Tue Jan 16 16:30:43 2018 New Revision: 256752 URL: https://gcc.gnu.org/viewcvs?rev=256752&root=gcc&view=rev Log: rtlanal: dead_or_set_regno_p should handle CLOBBER (PR83424) In PR83424 combine's move_deaths puts a REG_DEAD note in the wrong place because dead_or_set_regno_p does not account for CLOBBER insns. This fixes it. PR rtl-optimization/83424 * rtlanal.c (dead_or_set_regno_p): Handle CLOBBER just like SET. gcc/testsuite/ PR rtl-optimization/83424 * gcc.dg/pr83424.c: New testsuite. Added: branches/gcc-6-branch/gcc/testsuite/gcc.dg/pr83424.c Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/rtlanal.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/79405] [8 Regression] Infinite loop in fwprop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79405 Jeffrey A. Law changed: What|Removed |Added Target Milestone|8.0 |9.0
[Bug c++/83739] [8 Regression] error: range-based 'for' expression of type 'auto' has incomplete type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83739 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED CC||nathan at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug c++/79937] [6/7/8 Regression] ICE in replace_placeholders_r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79937
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 from Jakub Jelinek ---
--- gcc/cp/tree.c.jj2018-01-11 18:58:48.348391787 +0100
+++ gcc/cp/tree.c 2018-01-16 17:15:52.510371663 +0100
@@ -3101,7 +3101,12 @@ replace_placeholders_r (tree* t, int* wa
for (; !same_type_ignoring_top_level_qualifiers_p (TREE_TYPE (*t),
TREE_TYPE (x));
x = TREE_OPERAND (x, 0))
- gcc_assert (TREE_CODE (x) == COMPONENT_REF);
+ if (TREE_CODE (x) != COMPONENT_REF)
+ {
+ /* PLACEHOLDER_EXPR for some other object. */
+ *walk_subtrees = false;
+ break;
+ }
*t = x;
*walk_subtrees = false;
d->seen = true;
avoids the ICE, but whether it is correct or not I have no idea. So, not
really working on this.
[Bug middle-end/82694] [8 regression] Linux kernel miscompiled since r250765
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82694 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Markus Trippelsdorf --- (In reply to Jakub Jelinek from comment #17) > Does the kernel boot now with the latest trunk? Yes. (Sorry for the delay.)
