[Bug tree-optimization/83605] [6/7/8 Regression] ICE: verify_gimple failed (error: dead STMT in EH table)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83605 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Jan 5 08:51:32 2018 New Revision: 256274 URL: https://gcc.gnu.org/viewcvs?rev=256274&root=gcc&view=rev Log: PR tree-optimization/83605 * gimple-ssa-strength-reduction.c: Include tree-eh.h. (find_candidates_dom_walker::before_dom_children): Ignore stmts that can throw. * gcc.dg/pr83605.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr83605.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-strength-reduction.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/83697] New: Integer overflows in dynamically-sized stack allocations with -fstack-clash-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83697 Bug ID: 83697 Summary: Integer overflows in dynamically-sized stack allocations with -fstack-clash-protection Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: fw at gcc dot gnu.org Target Milestone: --- Created attachment 43039 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43039&action=edit reproducer.c Reported downstream by John Reiser. Reproducer slightly adjusted (here used with -O2 -fstack-clash-protection -fno-asynchronous-unwind-tables). When computing the stack allocation size for alloca, an unchecked addition is performed on the passed argument value: with_alloca: pushq %rbp addq$23, %rdi This can result in a wrapround and a smaller-than-requested value. Only this value is passed into the probing machinery, so taken together, the code fails to detect the invalid alloca argument. A similar thing happens for VLAs, the original size argument is replaced immediately: with_vla_1: pushq %rbp addq$15, %rdi For VLAs, the multiplication also needs to be guarded against overflow: with_vla_4: pushq %rbp leaq15(,%rdi,4), %rax
[Bug target/78117] gcc on tilegx builds faulty strstr() function (from glibc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78117 --- Comment #7 from Henrik Grindal Bakken --- We received a patch from Mellanox ages ago which fixed the issue (at least for us). I'll attach the patch.
[Bug target/78117] gcc on tilegx builds faulty strstr() function (from glibc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78117 --- Comment #8 from Henrik Grindal Bakken --- Created attachment 43040 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43040&action=edit Patch from Mellanox fixing vector handling
[Bug tree-optimization/83685] [8 Regression] ICE: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83685
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-01-05
CC||jakub at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek ---
Cleaned up testcase:
int _setjmp (void *);
void foo (int);
void
bar (int e, int b, char c, void *d)
{
while (b)
{
if (_setjmp (d))
foo (e);
if (c)
{
e--;
foo (0);
}
e++;
}
}
Started with r247049.
[Bug c/83698] New: [8 Regression] -Wrestrict oddities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83698 Bug ID: 83698 Summary: [8 Regression] -Wrestrict oddities Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: msebor at gcc dot gnu.org Target Milestone: --- 1) warning: ‘__builtin_strcat’ accessing 0 or more bytes at offsets 36 and 20 may overlap 1 byte at offset [36, -9223372036854775773] [-Wrestrict] ??? 2) warning: ‘__builtin_memcpy’ accessing 32 bytes at offsets 0 and 0 overlaps 32 bytes at offset 0 [-Wrestrict] "offsets 0 and 0" looks redundant. "offset 0" would be better.
[Bug c++/83692] Rejects valid constexpr with unrelated code fixing problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83692 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-05 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- This started to giving this error with r217663 when C++14 constexpr support has been introduced and for C++14 mode it went away with r255788 (but not C++17 mode).
[Bug ipa/82801] [6 Regression] Internal compiler error with Eigen and __attribute__((always_inline, flatten))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82801
--- Comment #11 from Jakub Jelinek ---
(In reply to gcc-bugs from comment #10)
> I could extract this minimal code snippet from our code base that does not
> work with g++-8, but with gcc version 7.2.1 20171128 (GCC).
>
> ```
> class a {};
> class b {};
> class c : b, a {
> __attribute__((always_inline)) c operator=(c);
> };
> ```
>
> ~~~
> Error log:
>
> internal compiler error: Segmentation fault
>__attribute__((always_inline)) c operator=(c);
>^
> 0xc0092f crash_signal
> /home/marehr/Packages/gcc-git/src/gcc/gcc/toplev.c:325
> 0x828832 cxx11_attribute_p(tree_node const*)
> /home/marehr/Packages/gcc-git/src/gcc/gcc/attribs.c:802
That is clearly something completely different, and has been fixed by r255844
for quite some time.
[Bug middle-end/83699] [8 regression] Many 64-bit SPARC gcc.dg/vect tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83699 Rainer Orth changed: What|Removed |Added Target Milestone|--- |8.0
[Bug middle-end/83699] New: [8 regression] Many 64-bit SPARC gcc.dg/vect tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83699 Bug ID: 83699 Summary: [8 regression] Many 64-bit SPARC gcc.dg/vect tests FAIL Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: ebotcazou at gcc dot gnu.org, rsandifo at gcc dot gnu.org Target Milestone: --- Host: sparc-sun-solaris2.* Target: sparc-sun-solaris2.* Build: sparc-sun-solaris2.* Between 20180103 (r256181) and 20180104 (r256254), many gcc.dg/vect tests started to FAIL on 64-bit SPARC: +FAIL: gcc.dg/vect/no-scevccp-outer-10.c (test for excess errors) +WARNING: gcc.dg/vect/no-scevccp-outer-10.c compilation failed to produce executable +FAIL: gcc.dg/vect/no-scevccp-outer-10a.c (test for excess errors) +WARNING: gcc.dg/vect/no-scevccp-outer-10a.c compilation failed to produce execu table +FAIL: gcc.dg/vect/no-scevccp-outer-10b.c (test for excess errors) +WARNING: gcc.dg/vect/no-scevccp-outer-10b.c compilation failed to produce execu table +FAIL: gcc.dg/vect/no-scevccp-outer-16.c (test for excess errors) +WARNING: gcc.dg/vect/no-scevccp-outer-16.c compilation failed to produce executable +FAIL: gcc.dg/vect/no-scevccp-outer-17.c (test for excess errors) +WARNING: gcc.dg/vect/no-scevccp-outer-17.c compilation failed to produce executable +FAIL: gcc.dg/vect/no-scevccp-outer-21.c (test for excess errors) +WARNING: gcc.dg/vect/no-scevccp-outer-21.c compilation failed to produce executable +FAIL: gcc.dg/vect/no-scevccp-outer-7.c (test for excess errors) +WARNING: gcc.dg/vect/no-scevccp-outer-7.c compilation failed to produce executable +FAIL: gcc.dg/vect/slp-24-big-array.c (test for excess errors) +FAIL: gcc.dg/vect/slp-24-big-array.c -flto -ffat-lto-objects (test for excess errors) +WARNING: gcc.dg/vect/slp-24-big-array.c -flto -ffat-lto-objects compilation failed to produce executable +WARNING: gcc.dg/vect/slp-24-big-array.c compilation failed to produce executable +FAIL: gcc.dg/vect/slp-24.c (test for excess errors) +FAIL: gcc.dg/vect/slp-24.c -flto -ffat-lto-objects (test for excess errors) +WARNING: gcc.dg/vect/slp-24.c -flto -ffat-lto-objects compilation failed to produce executable +WARNING: gcc.dg/vect/slp-24.c compilation failed to produce executable +FAIL: gcc.dg/vect/slp-45.c -flto -ffat-lto-objects execution test +FAIL: gcc.dg/vect/slp-45.c execution test +FAIL: gcc.dg/vect/vect-62.c -flto -ffat-lto-objects execution test +FAIL: gcc.dg/vect/vect-62.c execution test +FAIL: gcc.dg/vect/vect-double-reduc-3.c -flto -ffat-lto-objects execution test +FAIL: gcc.dg/vect/vect-double-reduc-3.c execution test +FAIL: gcc.dg/vect/vect-double-reduc-7.c -flto -ffat-lto-objects execution test +FAIL: gcc.dg/vect/vect-double-reduc-7.c execution test +FAIL: gcc.dg/vect/vect-reduc-1char-big-array.c (test for excess errors) +FAIL: gcc.dg/vect/vect-reduc-1char-big-array.c -flto -ffat-lto-objects (test for excess errors) +WARNING: gcc.dg/vect/vect-reduc-1char-big-array.c -flto -ffat-lto-objects compilation failed to produce executable +WARNING: gcc.dg/vect/vect-reduc-1char-big-array.c compilation failed to produce executable +FAIL: gcc.dg/vect/vect-reduc-1char.c (test for excess errors) +FAIL: gcc.dg/vect/vect-reduc-1char.c -flto -ffat-lto-objects (test for excess errors) +WARNING: gcc.dg/vect/vect-reduc-1char.c -flto -ffat-lto-objects compilation failed to produce executable +WARNING: gcc.dg/vect/vect-reduc-1char.c compilation failed to produce executable +FAIL: gcc.dg/vect/vect-reduc-1short.c (test for excess errors) +FAIL: gcc.dg/vect/vect-reduc-1short.c -flto -ffat-lto-objects (test for excess errors) +WARNING: gcc.dg/vect/vect-reduc-1short.c -flto -ffat-lto-objects compilation failed to produce executable +WARNING: gcc.dg/vect/vect-reduc-1short.c compilation failed to produce executable +FAIL: gcc.dg/vect/vect-reduc-3.c -flto -ffat-lto-objects execution test +FAIL: gcc.dg/vect/vect-reduc-3.c execution test +FAIL: gcc.dg/vect/wrapv-vect-reduc-2char.c (test for excess errors) +WARNING: gcc.dg/vect/wrapv-vect-reduc-2char.c compilation failed to produce executable +FAIL: gcc.dg/vect/wrapv-vect-reduc-2short.c (test for excess errors) +WARNING: gcc.dg/vect/wrapv-vect-reduc-2short.c compilation failed to produce executable +WARNING: program timed out. +FAIL: gfortran.dg/vect/no-fre-no-copy-prop-O3-pr51704.f90 -O (test for excess errors) +WARNING: program timed out. This happens both with sparc-sun-solaris2.11 and sparcv9-sun-solaris2.11 compilers. A reghunt identified the following patch as the culprit: The first bad revision is: changeset: 43149:587cc1cada02 user:rsandifo@138bc75d-0d04-0410-961f-82ee72b054a4 date:Wed Jan 03 21:46:38 2018 + summary: Use extract_bit_field_as_subreg for vectors * expmed.c (extract_bit_field
[Bug tree-optimization/83695] [8 Regression] ICE on valid code at -O3: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83695 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-05 CC||amker at gcc dot gnu.org, ||jakub at gcc dot gnu.org Version|unknown |8.0 Target Milestone|--- |8.0 Summary|ICE on valid code at -O3: |[8 Regression] ICE on valid |Segmentation fault |code at -O3: Segmentation ||fault Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r255472.
[Bug tree-optimization/83695] [8 Regression] ICE on valid code at -O3: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83695 amker at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org --- Comment #2 from amker at gcc dot gnu.org --- Sorry for the breakage. I will investigate it.
[Bug rtl-optimization/83682] [8 Regression] ICE in simplify_subreg, at simplify-rtx.c:6296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83682
Uroš Bizjak changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-01-05
Component|target |rtl-optimization
Ever confirmed|0 |1
--- Comment #1 from Uroš Bizjak ---
Confirmed:
(gdb) bt
#0 internal_error (gmsgid=gmsgid@entry=0x1c07213 "in %s, at %s:%d") at
/home/uros/gcc-svn/trunk/gcc/diagnostic.c:1430
#1 0x0082809b in fancy_abort (file=file@entry=0x1630d88
"/home/uros/gcc-svn/trunk/gcc/simplify-rtx.c", line=line@entry=6319,
function=function@entry=0x1632310 )::__FUNCTION__> "simplify_subreg")
at /home/uros/gcc-svn/trunk/gcc/diagnostic.c:1500
#2 0x00d0c30c in simplify_subreg(machine_mode, rtx_def*, machine_mode,
poly_int<1u, unsigned long>) () at
/home/uros/gcc-svn/trunk/gcc/simplify-rtx.c:6422
#3 0x013a879e in combine_simplify_rtx (x=0x7fffeff01ee8,
op0_mode=E_SFmode, in_dest=in_dest@entry=0, in_cond=in_cond@entry=0) at
/home/uros/gcc-svn/trunk/gcc/combine.c:5877
#4 0x013aa654 in subst(rtx_def*, rtx_def*, rtx_def*, int, int, int) ()
at /home/uros/gcc-svn/trunk/gcc/combine.c:5604
#5 0x013aa6f5 in subst(rtx_def*, rtx_def*, rtx_def*, int, int, int) ()
at /home/uros/gcc-svn/trunk/gcc/combine.c:5542
#6 0x013ad821 in try_combine(rtx_insn*, rtx_insn*, rtx_insn*,
rtx_insn*, int*, rtx_insn*) () at /home/uros/gcc-svn/trunk/gcc/combine.c:3398
#7 0x013b3bd7 in combine_instructions (nregs=,
f=) at /home/uros/gcc-svn/trunk/gcc/combine.c:1320
#8 rest_of_handle_combine () at /home/uros/gcc-svn/trunk/gcc/combine.c:14856
#9 (anonymous namespace)::pass_combine::execute(function*) () at
/home/uros/gcc-svn/trunk/gcc/combine.c:14901
#10 0x00c5d7c9 in execute_one_pass(opt_pass*) () at
/home/uros/gcc-svn/trunk/gcc/passes.c:2497
#11 0x00c5df75 in execute_pass_list_1(opt_pass*) () at
/home/uros/gcc-svn/trunk/gcc/passes.c:2586
#12 0x00c5df87 in execute_pass_list_1(opt_pass*) () at
/home/uros/gcc-svn/trunk/gcc/passes.c:2587
#13 0x00c5dfb9 in execute_pass_list(function*, opt_pass*) () at
/home/uros/gcc-svn/trunk/gcc/passes.c:2597
#14 0x00993213 in cgraph_node::expand() () at
/home/uros/gcc-svn/trunk/gcc/context.h:48
#15 0x009943ac in expand_all_functions () at
/home/uros/gcc-svn/trunk/gcc/cgraphunit.c:2275
#16 symbol_table::compile() [clone .part.75] () at
/home/uros/gcc-svn/trunk/gcc/cgraphunit.c:2624
#17 0x009966ea in symbol_table::compile (this=0x7fffefda5100) at
/home/uros/gcc-svn/trunk/gcc/cgraphunit.c:2717
#18 symbol_table::finalize_compilation_unit (this=0x7fffefda5100) at
/home/uros/gcc-svn/trunk/gcc/cgraphunit.c:2717
#19 0x00d2b888 in compile_file () at
/home/uros/gcc-svn/trunk/gcc/toplev.c:480
#20 0x0082af50 in do_compile () at
/home/uros/gcc-svn/trunk/gcc/toplev.c:2076
#21 toplev::main(int, char**) () at /home/uros/gcc-svn/trunk/gcc/toplev.c:2211
#22 0x0082d23b in main (argc=3, argv=0x7fffdae8) at
/home/uros/gcc-svn/trunk/gcc/main.c:39
(gdb) f 2
#2 0x00d0c30c in simplify_subreg(machine_mode, rtx_def*, machine_mode,
poly_int<1u, unsigned long>) () at
/home/uros/gcc-svn/trunk/gcc/simplify-rtx.c:6422
6422 SUBREG_PROMOTED_SET (newx, SUBREG_PROMOTED_GET (op));
(gdb) list
6417 && known_ge (outersize, innersize)
6418 && known_le (outersize, innermostsize)
6419 && subreg_lowpart_p (newx))
6420{
6421 SUBREG_PROMOTED_VAR_P (newx) = 1;
6422 SUBREG_PROMOTED_SET (newx, SUBREG_PROMOTED_GET (op));
6423}
6424 return newx;
6425}
6426 return NULL_RTX;
[Bug rtl-optimization/83682] [8 Regression] ICE in simplify_subreg, at simplify-rtx.c:6296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83682
--- Comment #2 from Uroš Bizjak ---
Line numbers are wrong for some reason, the compilation crashes in
rtx
simplify_subreg (machine_mode outermode, rtx op,
machine_mode innermode, poly_uint64 byte)
{
/* Little bit of sanity checking. */
gcc_assert (innermode != VOIDmode);
gcc_assert (outermode != VOIDmode);
gcc_assert (innermode != BLKmode);
gcc_assert (outermode != BLKmode);
> gcc_assert (GET_MODE (op) == innermode
|| GET_MODE (op) == VOIDmode);
where:
5877temp = simplify_subreg (mode, SUBREG_REG (x), op0_mode,
(gdb) p op0_mode
$3 = E_SFmode
(gdb) p debug_rtx (x)
(subreg:SI (float_truncate:V2SF (mem/c:V2DF (symbol_ref:DI ("c") [flags 0x2]
) [1 c+0 S16 A128])) 0)
So, SFmode != V2SFmode.
[Bug fortran/31298] [F03] use mod, operator(+) => operator(.userOp.) not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298 Jürgen Reuter changed: What|Removed |Added CC||juergen.reuter at desy dot de --- Comment #18 from Jürgen Reuter --- Contrary to what Tobias Burnus claimed, I think this case is indeed forbidden. Section 11.2.2 of the Fortran 2003 status (version from Apr 27, 2010) says in R for rename: local-name => use-name or OPERATOR(local-defined-operator) => OPERATOR (use-defined-operator). R1114 says that local-defined-operator is defined-unary-op or defined-binary-op, and Sec. 7.1.2.3 with C703 says that defined-unary-op shall not contain more than 63 letters and shall not be the same as any intrinsic-operator or logical-literal-constant. Sec. 7.1.2.8 (C704) says the same for defined-binary-op. This would preclude the example give in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298#c13 by Tobias Burnus. ifort vetoes such a construction with the message "error #8007: Intrinsic operator can not be used as the name of a locally defined operator in an OPERATOR rename clause." [This error, however, is not further documented: https://software.intel.com/en-us/articles/fdiag8007 ]
[Bug target/82439] Missing (x | y) == x simplifications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82439 --- Comment #7 from sudi at gcc dot gnu.org --- Author: sudi Date: Fri Jan 5 10:45:37 2018 New Revision: 256275 URL: https://gcc.gnu.org/viewcvs?rev=256275&root=gcc&view=rev Log: [PATCH PR82439][simplify-rtx] Simplify (x | y) == x -> (y & ~x) == 0 This patch add support for the missing transformation of (x | y) == x -> (y & ~x) == 0. The transformation for (x & y) == x case already exists in simplify-rtx.c since 2014 as of r218503 and this patch only adds a couple of extra patterns for the IOR case. This benefits targets that have the BICS instruction to generate better code. For targets that do not have the BICS instructions, it still results in no worse code generation and gives out 2 instructions. ChangeLog Entries: *** gcc/ChangeLog *** 2018-01-05 Sudakshina Das PR target/82439 * simplify-rtx.c (simplify_relational_operation_1): Add simplifications of (x|y) == x for BICS pattern. *** gcc/testsuite/ChangeLog *** 2018-01-05 Sudakshina Das PR target/82439 * gcc.target/aarch64/bics_5.c: New test. * gcc.target/arm/bics_5.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/aarch64/bics_5.c trunk/gcc/testsuite/gcc.target/arm/bics_5.c Modified: trunk/gcc/ChangeLog trunk/gcc/simplify-rtx.c trunk/gcc/testsuite/ChangeLog
[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763 --- Comment #14 from Mike Lothian --- I've been playing around with GCC 7.2.0 again When compiling a 32bit LLVM with -O2 -march=native, llvm-tblgen runs indefinitely during the build so it never completes Doing the same with -O2 -march=native -mno-bmi or using GCC 6.4.0 allows it to build From what I can see llvm-tblgen is a C++ program
[Bug other/83694] [8 Regression] New test case gcc.dg/pr83666.c from r256232 ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83694 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|New test case |[8 Regression] New test |gcc.dg/pr83666.c from |case gcc.dg/pr83666.c from |r256232 ICEs|r256232 ICEs
[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81763 --- Comment #15 from Mike Lothian --- Created attachment 43041 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43041&action=edit llvm-tblgen Working and Broken binaries
[Bug debug/83694] [8 Regression] New test case gcc.dg/pr83666.c from r256232 ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83694 --- Comment #2 from Jakub Jelinek --- Created attachment 43042 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43042&action=edit gcc8-pr83694.patch Untested fix.
[Bug target/83524] [8 Regression] bootstrap fails build a nvptx cross: ICE in get_insn_template, at final.c:2099
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83524 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug fortran/29550] Optimize -fexternal-blas calls for conjg()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29550 --- Comment #9 from Thomas Koenig --- I think I will defer this until gcc-9.
[Bug fortran/24878] subroutine getting called illegally as a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24878 Thomas Koenig changed: What|Removed |Added Last reconfirmed|2006-06-04 10:01:56 |2018-1-5 CC||tkoenig at gcc dot gnu.org Severity|minor |enhancement --- Comment #4 from Thomas Koenig --- Still no error issues, not even with -flto.
[Bug tree-optimization/83518] [8 Regression] Missing optimization: useless instructions should be dropped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83518
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work||7.2.1
Version|tree-ssa|8.0
Keywords||missed-optimization
Last reconfirmed||2018-01-05
CC||rguenth at gcc dot gnu.org
Ever confirmed|0 |1
Summary|Missing optimization: |[8 Regression] Missing
|useless instructions should |optimization: useless
|be dropped |instructions should be
||dropped
Target Milestone|--- |8.0
--- Comment #1 from Richard Biener ---
Works fine with GCC 7. I suppose unroller limits hit and/or we're just lucky
that GCC 7 doesn't vectorize the reduction loop ...
Trunk has
t.C:16:20: note: loop vectorized
t.C:21:10: note: basic block vectorized
resulting in
[local count: 178992762]:
MEM[(int *)&arr] = { 5, 4, 3, 2 };
t_2 = arr[0];
_65 = arr[1];
_46 = MEM[(int *)&arr + 8B];
MEM[(int *)&arr] = _46;
arr[2] = 1;
arr[3] = t_2;
vect__2.5_38 = MEM[(int *)&arr];
vect_sum_21.8_30 = VEC_PERM_EXPR ;
vect_sum_21.8_15 = vect_sum_21.8_30 + vect__2.5_38;
vect_sum_21.8_59 = VEC_PERM_EXPR ;
vect_sum_21.8_60 = vect_sum_21.8_15 + vect_sum_21.8_59;
stmp_sum_21.7_61 = BIT_FIELD_REF ;
sum_27 = stmp_sum_21.7_61 + _65;
_23 = (unsigned int) sum_27;
arr ={v} {CLOBBER};
return _23;
while GCC 7 simply unrolls the loop. DOM is not able to simplify the
vector load from MEM[(int *)&arr] but the scalar loads from the unrolled
variant.
[Bug tree-optimization/83517] Missed optimization in math expression: (x+x)/x == 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83517 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-05 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Yeah. Testing that.
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug other/83508] [8 regression][arm] c-c++-common/Wrestrict.c fails since r255836
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83508 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug c++/83504] incorrect attribute const interpretation on function overloads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83504 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- It seems that the behavior of GCC is at least unexpected even if other compilers follow GCCs current behavior. How do we behave for template specializations?
[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug c++/83502] [6/7/8 Regression] bogus -Wattributes for always_inline and noinline on function template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83502 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.5
[Bug target/83497] [8 Regression] CPU2000 172.mgrid starts failing with r254730
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83497 Richard Biener changed: What|Removed |Added Keywords||wrong-code Component|other |target Target Milestone|--- |8.0 Summary|CPU2000 172.mgrid starts|[8 Regression] CPU2000 |failing with r254730|172.mgrid starts failing ||with r254730
[Bug tree-optimization/83651] [7/8 regression] 20% slowdown of linux kernel AES cipher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Known to work||7.1.0 Target Milestone|--- |7.3 Summary|[7.2 regression] 20%|[7/8 regression] 20% |slowdown of linux kernel|slowdown of linux kernel |AES cipher |AES cipher
[Bug middle-end/83653] [6 Regression] GCC fails to remove a can't-happen call on ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83653 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Target Milestone|--- |6.5 Summary|GCC fails to remove a |[6 Regression] GCC fails to |can't-happen call on ia64 |remove a can't-happen call ||on ia64 --- Comment #1 from Richard Biener --- Do GCC 7 or trunk work?
[Bug c++/83692] Rejects valid constexpr with unrelated code fixing problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83692 --- Comment #3 from Marek Polacek --- I plan to investigate this one.
[Bug tree-optimization/83661] sincos does not handle sin(2x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83661 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-05 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug target/83663] [8 regression] aarch64_be regressions after r255946
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83663 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug tree-optimization/83668] [8 Regression] wrong code with -O -fno-tree-dominator-opts -fgraphite-identity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83668 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |8.0 --- Comment #2 from Richard Biener --- Mine.
[Bug middle-end/83665] [8 regression] Big code size regression and some code quality improvement at Jan 2 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83665 --- Comment #5 from Richard Biener --- Bisection of one or another example with the big_speedup_p fix manually patched in would be appreciated I guess.
[Bug tree-optimization/83685] [8 Regression] ICE: SSA corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83685 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- I will have a looksee.
[Bug tree-optimization/83695] [8 Regression] ICE on valid code at -O3: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83695 --- Comment #3 from Richard Biener --- possibly failure to release the SCEV cache after invalidating it (DCEing stmts).
[Bug c/83698] [8 Regression] -Wrestrict oddities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83698 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug middle-end/82177] Alias analysis too aggressive with integer-to-pointer cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82177 --- Comment #8 from Eric Gallager --- (In reply to Eric Gallager from comment #7) > (In reply to rguent...@suse.de from comment #6) > > On Wed, 20 Sep 2017, kristerw at gcc dot gnu.org wrote: > > > > > --- Comment #5 from Krister Walfridsson --- > > > Did you mean PR61502 - "== comparison on "one-past" pointer gives wrong > > > result"? > > > > Yes, but I believe there's another one where I posted a similar > > incomplete patch and explained why we can't possibly fix this > > without making points-to analysis useless. > > bug 65752 perhaps? So Richard, I see you've since had this bug depend on bug 65752, but I thought you said it originally was a dup? If it's not a dup, then this one can be confirmed, right?
[Bug target/80865] broken compilation on Mac OS X 10.5 / powerpc: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80865 --- Comment #11 from Eric Gallager --- (In reply to Iain Sandoe from comment #9) > (In reply to Christian Cornelssen from comment #7) > > I have made the time-consuming effort of building and testing gcc-7.2.0 with > > varying subsets of the four patchsets proposed with attachment 42124 > > [details] > > [details]. > > Thanks for doing this! > > I have building work going on here (to repair water damage to my office) and > temporarily had to relocate - at present, I don't have access to my PPC > Darwin machines. Hopefully, the works will complete in a month or so, and > i'll be back to normal (please be patient - but I don't believe another 7.x > release is scheduled in that time). Has the work completed yet?
[Bug fortran/83525] open(newunit=funit, status="scratch") fails if an internal file (characters) was read previously.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83525 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- This looks very much like a dup of PR83436. Close as duplicate?
[Bug tree-optimization/83580] [6/7/8 Regression] Wrong code caused by vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83580 --- Comment #8 from Richard Biener --- OK, so this is all a bit fishy. We're basically looking at (ssizetype)exp splitting exp recursively into X + CST where we keep the overall CST in ssizetype. For plus/minus we associate for mult we distribute. Given we do all this in effective ssizetype we may not cross a conversion boundary to unsigned, but STRIP_NOPS just does that. It might be the very outermost STRIP_NOPS is ok (not 100% sure), but at least I'm testing the fallout of removing the STRIP_NOPS from split_constant_offset.
[Bug preprocessor/83492] [7 Regression] Optimized search_line_fast breaks preprocessor on aarch64_be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83492 --- Comment #7 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Fri Jan 5 13:58:54 2018 New Revision: 256278 URL: https://gcc.gnu.org/viewcvs?rev=256278&root=gcc&view=rev Log: [PATCH, PR83492] Fix selection of aarch64 big-endian shift parameters based on __AARCH64EB__ 2018-01-05 Michael Weiser Backport from trunk 2017-12-20 Michael Weiser PR preprocessor/83492 * lex.c (search_line_fast) [__ARM_NEON && __ARM_64BIT_STATE]: Fix selection of big-endian shift parameters by using __ARM_BIG_ENDIAN. Modified: branches/gcc-7-branch/libcpp/ChangeLog branches/gcc-7-branch/libcpp/lex.c
[Bug preprocessor/83492] [7 Regression] Optimized search_line_fast breaks preprocessor on aarch64_be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83492 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from ktkachov at gcc dot gnu.org --- Fixed on GCC 7 branch too. Thank you for the report and your work on fixing this.
[Bug c++/81327] [8 Regression] cast to void* does not suppress -Wclass-memaccess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81327 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Created attachment 43043 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43043&action=edit gcc8-pr81327.patch Untested fix.
[Bug fortran/83700] New: [Meta-bug] Fortran Coarray issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700 Bug ID: 83700 Summary: [Meta-bug] Fortran Coarray issues Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: tkoenig at gcc dot gnu.org Target Milestone: --- There are quite a few, time to gather them...
[Bug rtl-optimization/83682] [8 Regression] ICE in simplify_subreg, at simplify-rtx.c:6296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83682
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Cleaned up testcase:
typedef float V __attribute__((__vector_size__(16)));
typedef double W __attribute__((__vector_size__(16)));
V b;
W c;
void
foo (void *p)
{
V e = __builtin_ia32_cvtsd2ss (b, c);
V g = e;
float f = g[0];
__builtin_memcpy (p, &f, sizeof (f));
}
Started with r254294.
[Bug tree-optimization/83651] [7/8 regression] 20% slowdown of linux kernel AES cipher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83651 --- Comment #1 from Arnd Bergmann --- Before posting a new workaround for PR83356 (the workaround is to use -Os instead of O2 for this file), I retested the performance numbers as well, and got slightly different numbers this time. I don't know what caused that difference, but now this is what I see is slightly different: -O2 -Os gcc-6.3.1 14.915.1 gcc-7.0.1 14.715.3 gcc-7.1.1 15.314.7 gcc-7.2.1 16.815.9 gcc-8.0.0 15.515.6 In particular, the gcc-7.1.1 results are a bit worse than they were, leading to a less significant regression from 7.1.1 to 7.2.2, and the numbers are now closer to what I saw with libressl. In both cases, we still have a 5% to 9% regression between gcc-7.1.1 (20170717) and gcc-7.2.1 (20180102), and a 14% to 23% regression between 6.3.1 and 7.2.1. I also found my mistake in the libressl numbers I showed in comment #1, they are listed exactly factor 3 higher than they should have been, and the actual results are close to the kernel implementation. I've measure these again now as well and come to the following results, using identical compilers as above: -O2 -Os gcc-6.3.1 16.716.7 gcc-7.0.1 17.516.0 gcc-7.1.1 17.516.0 gcc-7.2.1 17.616.0 gcc-8.0.0 16.815.5 To reproduce with libressl, one could use the following steps: $ git clone https://github.com/libressl-portable/portable.git $ cd portable $ ./autogen.sh $ sed -i 's/undef FULL_UNROLL/define FULL_UNROLL/' crypto/aes/aes_locl.h $ CC=x86_64-linux-gcc-7.2.1 ./configure --disable-asm $ make -sj8 $ ./apps/openssl/openssl speed aes-256-cbc The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256 cbc 168004.61k 174024.74k 174855.76k 176270.13k 176608.14k $ CC=x86_64-linux-gcc-6.3.1 ./configure --disable-asm $ touch crypto/aes/aes_core.c $ make -sj8 $ ./apps/openssl/openssl speed aes-256-cbc The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes256 bytes 1024 bytes 8192 bytes aes-256 cbc 175366.81k 182261.29k 183131.80k 184369.21k 184611.37k
[Bug rtl-optimization/83480] [8 Regression] ICE in create_block_for_bookkeeping, at sel-sched.c:4557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83480 --- Comment #6 from Alexandre Oliva --- It seems like sel-sched really can't deal with debug insns; I agree it makes sense to disable all sorts of debug insns when sel-sched is selected/enabled.
[Bug rtl-optimization/83682] [8 Regression] ICE in simplify_subreg, at simplify-rtx.c:6296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83682 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 43044 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43044&action=edit gcc8-pr83682.patch Untested fix.
[Bug debug/83694] [8 Regression] New test case gcc.dg/pr83666.c from r256232 ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83694 --- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #2 from Jakub Jelinek --- > Created attachment 43042 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43042&action=edit > gcc8-pr83694.patch > > Untested fix. I've just tried it on sparc-sun-solaris2.11 and (for good measure) i386-pc-solaris2.11. The failures are gone. Thanks. Rainer
[Bug target/83681] epiphany: config/epiphany/epiphany.h:883:8: error: unknown type name 'rtl_opt_pass'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83681 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-05 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Same issue as for nios2 and same fix if it works.
[Bug rtl-optimization/83480] [8 Regression] ICE in create_block_for_bookkeeping, at sel-sched.c:4557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83480 --- Comment #7 from Jakub Jelinek --- Apparently we only disable -fvar-tracking-assignments by default if sel-sched, not disable it unconditionally. So, while we could and should change: if (debug_nonbind_markers_p == AUTODETECT_VALUE) debug_nonbind_markers_p = optimize && debug_info_level >= DINFO_LEVEL_NORMAL && (write_symbols == DWARF2_DEBUG || write_symbols == VMS_AND_DWARF2_DEBUG); to if (debug_nonbind_markers_p == AUTODETECT_VALUE) debug_nonbind_markers_p = (optimize && debug_info_level >= DINFO_LEVEL_NORMAL && (write_symbols == DWARF2_DEBUG || write_symbols == VMS_AND_DWARF2_DEBUG) && !(flag_selective_scheduling || flag_selective_scheduling2)); the testcase would still ICE with -gstatement-frontiers.
[Bug debug/83480] [8 Regression] ICE in create_block_for_bookkeeping, at sel-sched.c:4557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83480 --- Comment #8 from Jakub Jelinek --- Created attachment 43045 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43045&action=edit gcc8-pr83480.patch In any case, I think this patch is a small step towards the right direction.
[Bug fortran/83525] open(newunit=funit, status="scratch") fails if an internal file (characters) was read previously.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83525 --- Comment #3 from Jerry DeLisle --- (In reply to Thomas Koenig from comment #2) > This looks very much like a dup of PR83436. > > Close as duplicate? I am going to add the test case and then close this.
[Bug c++/83690] [8 regression] spurious unused variable warings for variables used only in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83690 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-05 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r253266. Jason?
[Bug c++/83690] [8 regression] spurious unused variable warings for variables used only in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83690 --- Comment #2 from Jakub Jelinek --- Created attachment 43046 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43046&action=edit gcc8-pr83690.patch This does seem to do the job.
[Bug middle-end/83699] [8 regression] Many 64-bit SPARC gcc.dg/vect tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83699 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-05 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 --- Seems to be an LRA problem.
[Bug rtl-optimization/83628] [8 Regression] performance regression when accessing arrays on alpha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83628 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- P4 unless it affects also primary/secondary targets.
[Bug tree-optimization/83605] [6/7 Regression] ICE: verify_gimple failed (error: dead STMT in EH table)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83605 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Summary|[6/7/8 Regression] ICE: |[6/7 Regression] ICE: |verify_gimple failed|verify_gimple failed |(error: dead STMT in EH |(error: dead STMT in EH |table) |table) --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/83518] [8 Regression] Missing optimization: useless instructions should be dropped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83518 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- We do vectorize this and thus not unroll it since r253975. With -O3 -fno-vect-cost-model we've generated what GCC 8 emits or something similar for many years, including 4.4+ (r140264 already shows this behavior).
[Bug c++/83504] incorrect attribute const interpretation on function overloads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83504
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from Martin Sebor ---
Template specializations are handled correctly.
But the test case doesn't actually show a bug in how overloads are handled -- I
forgot that GCC eliminates the calls to the non-const function because it sees
its definition. My bad. With that fixed like below the test case shows that
GCC behaves correctly even for overloads.
$ cat u.C && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout u.C
int i;
int __attribute__ ((noclone, noinline)) f (int) { return i; }
int __attribute__ ((const)) f ();
void g (void)
{
i = 0;
int j = f (0);
i = 1;
if (j == f (0))
__builtin_abort ();
}
...
g ()
{
int j;
int _1;
[local count: 1073741825]:
i = 0;
j_4 = f (0);
i = 1;
_1 = f (0);
if (_1 == j_4)
goto ; [0.00%]
else
goto ; [99.96%]
[count: 0]:
__builtin_abort ();
[local count: 1073312327]:
return;
}
[Bug target/83604] [8 Regression] ICE in copy_to_mode_reg, at explow.c:630
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83604 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri Jan 5 16:38:17 2018 New Revision: 256280 URL: https://gcc.gnu.org/viewcvs?rev=256280&root=gcc&view=rev Log: PR target/83604 * config/i386/sse.md (VI248_VLBW): Rename to ... (VI248_AVX512VL): ... this. Don't guard V32HI with TARGET_AVX512BW. (vpshrd_, vpshld_, vpshrdv_, vpshrdv__mask, vpshrdv__maskz, vpshrdv__maskz_1, vpshldv_, vpshldv__mask, vpshldv__maskz, vpshldv__maskz_1): Use VI248_AVX512VL mode iterator instead of VI248_VLBW. * gcc.target/i386/pr83604.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr83604.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug target/83604] [8 Regression] ICE in copy_to_mode_reg, at explow.c:630
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83604 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Jan 5 16:40:24 2018 New Revision: 256281 URL: https://gcc.gnu.org/viewcvs?rev=256281&root=gcc&view=rev Log: PR target/83604 * config/i386/i386-builtin.def (__builtin_ia32_vgf2p8affineinvqb_v64qi, __builtin_ia32_vgf2p8affineqb_v64qi, __builtin_ia32_vgf2p8mulb_v64qi): Require also OPTION_MASK_ISA_AVX512F in addition to OPTION_MASK_ISA_GFNI. (__builtin_ia32_vgf2p8affineinvqb_v16qi_mask, __builtin_ia32_vgf2p8affineqb_v16qi_mask): Require OPTION_MASK_ISA_AVX512VL instead of OPTION_MASK_ISA_SSE in addition to OPTION_MASK_ISA_GFNI. (__builtin_ia32_vgf2p8mulb_v32qi_mask): Require OPTION_MASK_ISA_AVX512VL in addition to OPTION_MASK_ISA_GFNI and OPTION_MASK_ISA_AVX512BW. (__builtin_ia32_vgf2p8mulb_v16qi_mask): Require OPTION_MASK_ISA_AVX512VL instead of OPTION_MASK_ISA_AVX512BW in addition to OPTION_MASK_ISA_GFNI. (__builtin_ia32_vgf2p8affineinvqb_v16qi, __builtin_ia32_vgf2p8affineqb_v16qi, __builtin_ia32_vgf2p8mulb_v16qi): Require OPTION_MASK_ISA_SSE2 instead of OPTION_MASK_ISA_SSE in addition to OPTION_MASK_ISA_GFNI. * config/i386/i386.c (def_builtin): Change to builtin isa/isa2 being a requirement for all ISAs rather than any of them with a few exceptions. (ix86_add_new_builtins): Clear OPTION_MASK_ISA_64BIT from isa before processing. (ix86_expand_builtin): Require all ISAs from builtin's isa and isa2 bitmasks to be enabled with 3 exceptions, instead of requiring any enabled ISA with lots of exceptions. * config/i386/sse.md (vgf2p8affineinvqb_, vgf2p8affineqb_, vgf2p8mulb_): Change avx512bw in isa attribute to avx512f. * config/i386/sgxintrin.h: Add license boilerplate. * config/i386/vaesintrin.h: Likewise. Fix macro spelling __AVX512F to __AVX512F__ and __AVX512VL to __AVX512VL__. (_mm256_aesdec_epi128, _mm256_aesdeclast_epi128, _mm256_aesenc_epi128, _mm256_aesenclast_epi128): Enable temporarily avx if __AVX__ is not defined. * config/i386/gfniintrin.h (_mm_gf2p8mul_epi8, _mm_gf2p8affineinv_epi64_epi8, _mm_gf2p8affine_epi64_epi8): Enable temporarily sse2 rather than sse if not enabled already. * gcc.target/i386/sse-26.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/sse-26.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/gfniintrin.h trunk/gcc/config/i386/i386-builtin.def trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/sgxintrin.h trunk/gcc/config/i386/sse.md trunk/gcc/config/i386/vaesintrin.h trunk/gcc/testsuite/ChangeLog
[Bug target/83604] [8 Regression] ICE in copy_to_mode_reg, at explow.c:630
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83604 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug middle-end/83699] [8 regression] Many 64-bit SPARC gcc.dg/vect tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83699 --- Comment #2 from rsandifo at gcc dot gnu.org --- Created attachment 43047 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43047&action=edit Hacky patch In no-scevccp-outer-10.c, LRA enters a cycle trying to move (subreg:SI (reg:V2SI R) 0) into a GPR. It emits: (set (reg:SI tmp) (subreg:SI (reg:V2SI R) 0)) (set (reg:SI dest) (reg:SI tmp)) and sets the class of "tmp" to ALL_REGS. We then assign a GPR to it, creating the same problem again. The subreg is valid for SPARC because of REGMODE_NATURAL_SIZE. I think the problem is that TMP needs to be restricted to EXTRA_FP_REGS. The attached patch does that in a hacky way. I think a more correct way of achieving the same thing would be to make LRA take simplifiable_subregs into account when picking the register for a subreg reload, just as IRA does. I'm not sure whether this is the problem for all the mentioned tests or not.
[Bug middle-end/83699] [8 regression] Many 64-bit SPARC gcc.dg/vect tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83699 --- Comment #3 from rsandifo at gcc dot gnu.org --- The expmed.c patch is probably a pessimisation in this case. extract_bit_field_as_Subreg should probably check that the REGMODE_NATURAL_SIZE of the inner and outer modes are the same. I'll do that as well, but we should probably fix the LRA problem while it's visible.
[Bug tree-optimization/83701] New: missing -Wrestrict on strcat to an array depending on offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83701
Bug ID: 83701
Summary: missing -Wrestrict on strcat to an array depending on
offset
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Calling strcat to append to the same string as the source always overlaps
exactly 1 byte: the terminating NUL. This is true regardless of the source and
destination offsets. The test case below shows that the -Wrestict warning
doesn't detect this problem with complete consistency.
$ cat b.c && gcc -O2 -S -Wall b.c
extern char* stpcpy (char*, const char*);
extern char* strcat (char*, const char*);
extern char* strcpy (char*, const char*);
void f1 (char *d)
{
strcpy (d, "01234");
strcat (d + 2, d + 1); // -Wrestrict (good)
}
void f2 (char *d)
{
strcpy (d, "12345");
strcat (d + 2, d + 1); // -Wrestrict (good)
}
extern char d[];
void f3 (void)
{
strcpy (d, "23456");
strcat (d + 2, d + 1); // missing -Wrestrict
}
void f4 (void)
{
strcpy (d, "34567");
strcat (d + 2, d + 1); // missing -Wrestrict
}
void f5 (void)
{
strcpy (d, "23456");
strcat (d + 1, d + 2); // -Wrestrict (good)
}
b.c: In function ‘f1’:
b.c:8:3: warning: ‘strcat’ accessing 5 bytes at offsets 2 and 1 overlaps 1 byte
at offset 5 [-Wrestrict]
strcat (d + 2, d + 1); // -Wrestrict (good)
^
b.c: In function ‘f2’:
b.c:14:3: warning: ‘strcat’ accessing 5 bytes at offsets 2 and 1 overlaps 1
byte at offset 5 [-Wrestrict]
strcat (d + 2, d + 1); // -Wrestrict (good)
^
b.c: In function ‘f5’:
b.c:35:3: warning: ‘strcat’ accessing 4 bytes at offsets 1 and 2 overlaps 1
byte at offset 5 [-Wrestrict]
strcat (d + 1, d + 2); // -Wrestrict (good)
^
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Started with r253530. Bisecting when it went away.
[Bug middle-end/83699] [8 regression] Many 64-bit SPARC gcc.dg/vect tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83699 --- Comment #4 from Eric Botcazou --- > The expmed.c patch is probably a pessimisation in this case. > extract_bit_field_as_Subreg should probably check that the > REGMODE_NATURAL_SIZE of the inner and outer modes are the same. > I'll do that as well, but we should probably fix the LRA > problem while it's visible. But then we wouldn't have caught the pessimization if there is one. In cases like this, I think that it's OK, if not better, to fix only the pessimization. Thanks for looking into this in any case.
[Bug fortran/83700] [Meta-bug] Fortran Coarray issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-05 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Thanks!
[Bug tree-optimization/83698] bogus offset in -Wrestrict messages for strcat of unknown strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83698
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-01-05
Component|c |tree-optimization
Summary|[8 Regression] -Wrestrict |bogus offset in -Wrestrict
|oddities|messages for strcat of
||unknown strings
Ever confirmed|0 |1
--- Comment #1 from Martin Sebor ---
Confirmed, though I don't consider it a regression. Here's a test case for the
bogus strcat offset:
$ cat b.c && gcc -O2 -S -Wall b.c
extern char* strcat (char*, const char*);
extern char d[];
void f (unsigned i)
{
strcat (d + 36, d + 20);
}
b.c: In function ‘f’:
b.c:7:3: warning: ‘strcat’ accessing 0 or more bytes at offsets 36 and 20 may
overlap 1 byte at offset [36, -9223372036854775773] [-Wrestrict]
The weird looking upper bound of the offset range is due to converting a very
large offset_int value that the pass computes offsets and sizes in to
HOST_WIDE_INT for printing. This conversion is necessary because GCC's pretty
printer has no formatting directive for any of the wide int flavors. There are
likely other issues like this one that will disappear once the pretty printer
is enhanced to format wide ints and the conversions removed from -Wrestrict
code. I'll try to find the time to fix this one for GCC 8.
I also tend to agree with the comment about the redundancy. I considered
avoiding it when I wrote the code but decided it wasn't worthwhile. To help
you appreciate the challenges in producing meaningful messages from the
-Wrestrict pass (and others like it) I invite you to look at the code in the
maybe_diag_overlap function in gimple-ssa-warn-restrict.c and consider the
different forms of warnings it already issues. Avoiding the redundancy would
nearly double the number of messages the function issues, from 20 to 40. That
said, I am interested in making the messages more useful and informative so if
you have suggestions for how to rephrase them without unduly growing their
number or losing detail I'd love to hear them. Until some good ideas surface I
don't expect to make a change here.
PS Even to the author of a feature it's not terribly helpful to just paste a
random warning message without a test case. I know the numbers in some of the
warnings could be improved so a report without one doesn't tell me anything
new.
[Bug libstdc++/83626] std::experimental::filesystem::remove_all throws exception instead of returning 0 if path doesn't exist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83626 --- Comment #5 from Jonathan Wakely --- Author: redi Date: Fri Jan 5 18:02:18 2018 New Revision: 256283 URL: https://gcc.gnu.org/viewcvs?rev=256283&root=gcc&view=rev Log: PR libstdc++/83626 handle ENOENT due to filesystem race PR libstdc++/83626 * src/filesystem/ops.cc (remove(const path&, error_code&)): Do not report an error for ENOENT. (remove_all(const path&)): Fix type of result variable. (remove_all(const path&, error_code&)): Use non-throwing increment for directory iterator. Call POSIX remove directly to avoid redundant calls to symlink_status. Do not report errors for ENOENT. * src/filesystem/std-ops.cc: Likewise. * testsuite/27_io/filesystem/operations/remove_all.cc: Test throwing overload. * testsuite/experimental/filesystem/operations/remove_all.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/filesystem/ops.cc trunk/libstdc++-v3/src/filesystem/std-ops.cc trunk/libstdc++-v3/testsuite/27_io/filesystem/operations/remove_all.cc trunk/libstdc++-v3/testsuite/experimental/filesystem/operations/remove_all.cc
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507
--- Comment #5 from Jakub Jelinek ---
Likely just latent before. The ICE is because modulo-sched.c in
for (i_reg_move = 0; i_reg_move < nreg_moves; i_reg_move++)
{
ps_reg_move_info *move = ps_reg_move (ps, first_move + i_reg_move);
move->def = i_reg_move > 0 ? first_move + i_reg_move - 1 : i;
move->uses = sbitmap_alloc (first_move + nreg_moves);
move->old_reg = old_reg;
move->new_reg = gen_reg_rtx (GET_MODE (prev_reg));
move->num_consecutive_stages = distances[0] && distances[1] ? 2 : 1;
move->insn = gen_move_insn (move->new_reg, copy_rtx (prev_reg));
bitmap_clear (move->uses);
prev_reg = move->new_reg;
}
creates a move instruction from the ca register but rs6000 doesn't support such
a move, and apparently nothing attempts to recog that instruction and bail if
it is non-existent (or if gen_move_insn emits more than one instruction).
I think e.g. insn_latency can be only called on successfully recognized
instructions...
[Bug lto/81004] [7/8 Regression] linking failed with -flto and static libboost_program_options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81004 --- Comment #16 from Matt Godbolt --- I see the target milestone is 7.3, but this bug is still marked NEW. Has there been any further thought on this? I realise this is a tough one, but we've had to either disable LTO, or roll back to c++14 on our projects. It would be amazing if we could get this fixed :)
[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83633 Thomas Koenig changed: What|Removed |Added Keywords||ice-on-valid-code CC||tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- The code is valid; F2003 7.6.1 "Specification expression" says R729 specification-expr is scalar-int-expr C710 (R729) The scalar-int-expr shall be a restricted expression. A restricted expression is an expression in which each operation is intrinsic and each primary is [...] (8) A reference to any other standard intrinsic function where each argument is a restricted expression, One possible workaround: program main integer :: n n = command_argument_count() block integer :: A(n) A = 1 write (*,*) A end block end
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 Jakub Jelinek changed: What|Removed |Added CC||zaks at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- As SMS pass is before reload, another option would be punt on sets to hard registers. But I really know next to nothing about SMS. Is modulo-sched.c maintained at all? I've seen lately only changes to it being changes where something is changed in the whole compiler including modulo-sched.c.
[Bug debug/83480] [8 Regression] ICE in create_block_for_bookkeeping, at sel-sched.c:4557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83480 --- Comment #9 from Alexandre Oliva --- didn't we print a warning if we found VTA and sel-sched enabled at the same time, too? I guess that might be useful in this case as well. (thanks for taking care of this!)
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-05 Ever confirmed|0 |1 --- Comment #7 from Jakub Jelinek --- BTW, I can reproduce it even with latest trunk: ./cc1.256283 -quiet -O2 -fmodulo-sched -fno-tree-ter -fno-tree-coalesce-vars -mcpu=476 pr83507.c -nostdinc -m32
[Bug middle-end/83699] [8 regression] Many 64-bit SPARC gcc.dg/vect tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83699 --- Comment #5 from rsandifo at gcc dot gnu.org --- Created attachment 43048 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43048&action=edit Patch to check REGMODE_NATURAL_SIZE
[Bug fortran/83700] [Meta-bug] Fortran Coarray issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700 --- Comment #2 from Damian Rouson --- Thanks for this! For anyone looking at this, I'll be glad to assist with parallel execution testing via -fcoarray=lib.
[Bug rtl-optimization/83500] gcc.dg/tree-prof/switch-case-1.c fails on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83500 Steve Ellcey changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Steve Ellcey --- Since the test is now passing I will close this defect as fixed.
[Bug target/82439] Missing (x | y) == x simplifications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82439 Wilco changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Wilco --- Confirmed fixed
[Bug fortran/83633] gfortran internal compiler error for explicit-shape array with non-constant bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83633 --- Comment #3 from Thomas Koenig --- Also, this does not ICE: integer :: A(command_argument_count()) a = 1 write (*,*) A end
[Bug rtl-optimization/83575] [8 Regression] ICE: verify_flow_info failed (error: multiple hot/cold transitions found)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83575 --- Comment #4 from Jakub Jelinek --- Honza, can you please have a look? It is unclear to me what is supposed to fix up the aux chain after fixup_partitions turns some previously hot bbs into cold ones.
[Bug fortran/66310] Problems with intrinsic repeat for large number of copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66310 --- Comment #17 from Janne Blomqvist --- Author: jb Date: Fri Jan 5 19:01:12 2018 New Revision: 256284 URL: https://gcc.gnu.org/viewcvs?rev=256284&root=gcc&view=rev Log: PR 78534 Change character length from int to size_t In order to handle large character lengths on (L)LP64 targets, switch the GFortran character length from an int to a size_t. This is an ABI change, as procedures with character arguments take hidden arguments with the character length. I also changed the _size member in vtables from int to size_t, as there were some cases where character lengths and sizes were apparently mixed up and caused regressions otherwise. Although I haven't tested, this might enable very large derived types as well. Also, as there are some places in the frontend were negative character lengths are used as special flag values, in the frontend the character length is handled as a signed variable of the same size as a size_t, although in the runtime library it really is size_t. I haven't changed the character length variables for the co-array intrinsics, as this is something that may need to be synchronized with OpenCoarrays. This is v5 of the patch. v4 was applied but caused breakage on big endian targets. These have been fixed and tested, thanks to access to the GCC compile farm. Overview of v4 of the patch: v3 was applied but had to reverted due to breaking bootstrap. The fix is in resolve.c:resolve_charlen, where it's necessary to check that an expression is constant before using mpz_sgn. Overview of v3 of the patch: All the issues pointed out by FX's review of v2 have been fixed. In particular, there are now new functions gfc_mpz_get_hwi and gfc_mpz_set_hwi, similar to the GMP functions mpz_get_si and mpz_set_si, except that they get/set a HOST_WIDE_INT instead of a long value. Similarly, gfc_get_int_expr now takes a HOST_WIDE_INT instead of a long, gfc_extract_long is replaced by gfc_extract_hwi. Also, the preliminary work to handle gfc_charlen_type_node being unsigned has been removed. Regtested on x86_64-pc-linux-gnu, i686-pc-linux-gnu and powerpc64-unknown-linux-gnu. Also regtested all three targets by modifying gfortran-dg.exp to also test with "-g -flto", no new failures observed. frontend: 2018-01-05 Janne Blomqvist PR fortran/78534 PR fortran/66310 * array.c (got_charlen): Use gfc_charlen_int_kind. * class.c (gfc_find_derived_vtab): Use gfc_size_kind instead of hardcoded kind. (find_intrinsic_vtab): Likewise. * decl.c (match_char_length): Use gfc_charlen_int_kind. (add_init_expr_to_sym): Use gfc_charlen_t and gfc_charlen_int_kind. (gfc_match_implicit): Use gfc_charlen_int_kind. * dump-parse-tree.c (show_char_const): Use gfc_charlen_t and size_t. (show_expr): Use HOST_WIDE_INT_PRINT_DEC. * expr.c (gfc_get_character_expr): Length parameter of type gfc_charlen_t. (gfc_get_int_expr): Value argument of type HOST_WIDE_INT. (gfc_extract_hwi): New function. (simplify_const_ref): Make string_len of type gfc_charlen_t. (gfc_simplify_expr): Use HOST_WIDE_INT for substring refs. * frontend-passes.c (optimize_trim): Use gfc_charlen_int_kind. * gfortran.h (gfc_mpz_get_hwi): New prototype. (gfc_mpz_set_hwi): Likewise. (gfc_charlen_t): New typedef. (gfc_expr): Use gfc_charlen_t for character lengths. (gfc_size_kind): New extern variable. (gfc_extract_hwi): New prototype. (gfc_get_character_expr): Use gfc_charlen_t for character length. (gfc_get_int_expr): Use HOST_WIDE_INT type for value argument. * gfortran.texi: Update description of hidden string length argument. * iresolve.c (check_charlen_present): Use gfc_charlen_int_kind. (gfc_resolve_char_achar): Likewise. (gfc_resolve_repeat): Pass string length directly without temporary, use gfc_charlen_int_kind. (gfc_resolve_transfer): Use gfc_charlen_int_kind. * match.c (select_intrinsic_set_tmp): Use HOST_WIDE_INT for charlen. * misc.c (gfc_mpz_get_hwi): New function. (gfc_mpz_set_hwi): New function. * module.c (atom_int): Change type from int to HOST_WIDE_INT. (parse_integer): Don't complain about large integers. (write_atom): Use HOST_WIDE_INT for integers. (mio_integer): Handle integer type mismatch. (mio_hwi): New function. (mio_intrinsic_op): Use HOST_WIDE_INT. (mio_array_ref): Likewise. (mio_expr): Likewise. * primary.c (match_substring): Use gfc_charlen_int_kind. * resolve.c (resolve_substring_charlen): Use gfc_charlen_int_kind. (resolve_character_operator): Likewise. (resolve_assoc_var): Likewise. (resolve_select_type): Use HOST_WIDE_INT for charlen, use snprintf. (resolve_charlen): Use mpz_sgn to determine sign
[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534 --- Comment #20 from Janne Blomqvist --- Author: jb Date: Fri Jan 5 19:01:12 2018 New Revision: 256284 URL: https://gcc.gnu.org/viewcvs?rev=256284&root=gcc&view=rev Log: PR 78534 Change character length from int to size_t In order to handle large character lengths on (L)LP64 targets, switch the GFortran character length from an int to a size_t. This is an ABI change, as procedures with character arguments take hidden arguments with the character length. I also changed the _size member in vtables from int to size_t, as there were some cases where character lengths and sizes were apparently mixed up and caused regressions otherwise. Although I haven't tested, this might enable very large derived types as well. Also, as there are some places in the frontend were negative character lengths are used as special flag values, in the frontend the character length is handled as a signed variable of the same size as a size_t, although in the runtime library it really is size_t. I haven't changed the character length variables for the co-array intrinsics, as this is something that may need to be synchronized with OpenCoarrays. This is v5 of the patch. v4 was applied but caused breakage on big endian targets. These have been fixed and tested, thanks to access to the GCC compile farm. Overview of v4 of the patch: v3 was applied but had to reverted due to breaking bootstrap. The fix is in resolve.c:resolve_charlen, where it's necessary to check that an expression is constant before using mpz_sgn. Overview of v3 of the patch: All the issues pointed out by FX's review of v2 have been fixed. In particular, there are now new functions gfc_mpz_get_hwi and gfc_mpz_set_hwi, similar to the GMP functions mpz_get_si and mpz_set_si, except that they get/set a HOST_WIDE_INT instead of a long value. Similarly, gfc_get_int_expr now takes a HOST_WIDE_INT instead of a long, gfc_extract_long is replaced by gfc_extract_hwi. Also, the preliminary work to handle gfc_charlen_type_node being unsigned has been removed. Regtested on x86_64-pc-linux-gnu, i686-pc-linux-gnu and powerpc64-unknown-linux-gnu. Also regtested all three targets by modifying gfortran-dg.exp to also test with "-g -flto", no new failures observed. frontend: 2018-01-05 Janne Blomqvist PR fortran/78534 PR fortran/66310 * array.c (got_charlen): Use gfc_charlen_int_kind. * class.c (gfc_find_derived_vtab): Use gfc_size_kind instead of hardcoded kind. (find_intrinsic_vtab): Likewise. * decl.c (match_char_length): Use gfc_charlen_int_kind. (add_init_expr_to_sym): Use gfc_charlen_t and gfc_charlen_int_kind. (gfc_match_implicit): Use gfc_charlen_int_kind. * dump-parse-tree.c (show_char_const): Use gfc_charlen_t and size_t. (show_expr): Use HOST_WIDE_INT_PRINT_DEC. * expr.c (gfc_get_character_expr): Length parameter of type gfc_charlen_t. (gfc_get_int_expr): Value argument of type HOST_WIDE_INT. (gfc_extract_hwi): New function. (simplify_const_ref): Make string_len of type gfc_charlen_t. (gfc_simplify_expr): Use HOST_WIDE_INT for substring refs. * frontend-passes.c (optimize_trim): Use gfc_charlen_int_kind. * gfortran.h (gfc_mpz_get_hwi): New prototype. (gfc_mpz_set_hwi): Likewise. (gfc_charlen_t): New typedef. (gfc_expr): Use gfc_charlen_t for character lengths. (gfc_size_kind): New extern variable. (gfc_extract_hwi): New prototype. (gfc_get_character_expr): Use gfc_charlen_t for character length. (gfc_get_int_expr): Use HOST_WIDE_INT type for value argument. * gfortran.texi: Update description of hidden string length argument. * iresolve.c (check_charlen_present): Use gfc_charlen_int_kind. (gfc_resolve_char_achar): Likewise. (gfc_resolve_repeat): Pass string length directly without temporary, use gfc_charlen_int_kind. (gfc_resolve_transfer): Use gfc_charlen_int_kind. * match.c (select_intrinsic_set_tmp): Use HOST_WIDE_INT for charlen. * misc.c (gfc_mpz_get_hwi): New function. (gfc_mpz_set_hwi): New function. * module.c (atom_int): Change type from int to HOST_WIDE_INT. (parse_integer): Don't complain about large integers. (write_atom): Use HOST_WIDE_INT for integers. (mio_integer): Handle integer type mismatch. (mio_hwi): New function. (mio_intrinsic_op): Use HOST_WIDE_INT. (mio_array_ref): Likewise. (mio_expr): Likewise. * primary.c (match_substring): Use gfc_charlen_int_kind. * resolve.c (resolve_substring_charlen): Use gfc_charlen_int_kind. (resolve_character_operator): Likewise. (resolve_assoc_var): Likewise. (resolve_select_type): Use HOST_WIDE_INT for charlen, use snprintf. (resolve_charlen): Use mpz_sgn to determine sign
[Bug fortran/83700] [Meta-bug] Fortran Coarray issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700 --- Comment #3 from Dominique d'Humieres --- > Thanks for this! For anyone looking at this, I'll be glad to assist > with parallel execution testing via -fcoarray=lib. AFAIR most of (if not all) the PRs are exposed via -fcoarray=lib -lcaf_single.
[Bug target/83507] [8 Regression] ICE in internal_dfa_insn_code_* for powerpc targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83507 --- Comment #8 from Segher Boessenkool --- Ah yes, I can reproduce it with all those options and -m32. I could swear to have tried exactly that yesterday; pilot error I guess. CA is not just a hard register, but a fixed register, btw.
[Bug fortran/83700] [Meta-bug] Fortran Coarray issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700 --- Comment #4 from Damian Rouson --- (In reply to Dominique d'Humieres from comment #3) > AFAIR most of (if not all) the PRs are exposed via -fcoarray=lib > -lcaf_single. Yes, I meant to write "-fcoarray=lib -lcaf_mpi". If the errors are compile-time errors, then it probably doesn't matter, but if they are runtime errors, then it's important to test both with single-image execution (-lcaf_single) and multi-image execution (e.g., -caf_mpi). Also, if anyone is interested in related contract work, let me know. Most of the funding Sourcery Institute can contribute have been expended, but one donor to Sourcery Institute has asked about additional ways to contribute so there could be opportunities for a small amount of funding.
[Bug fortran/78534] Use a larger integer type for character lengths on 64-bit targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534 --- Comment #21 from Jerry DeLisle --- Regrssion tested on x86_64-pc-freeBSD, no failures
[Bug tree-optimization/83702] New: missing strlen range optimization for calls with an offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83702
Bug ID: 83702
Summary: missing strlen range optimization for calls with an
offset
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Testing an unrelated strlen optimization enhancement exposed another limitation
in the folding of strlen expressions. GCC 8 is able to optimize code based on
the knowledge that the length of a string is bounded by the size of the array
it is stored in. But it can only do that for strlen calls with no offset, or
for strlen calls with strings of known length and a constant offset. Calls
that involve an offset into an array are not folded, irrespective of whether
the offset is constant. Similarly, calls that involve strings of known length
and a non-const offset aren't folded. Both sets of cases could be folded.
$ cat x.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout x.c | grep -e
"^f[0-9]" -e abort -estrlen
#define S "1234567"
char a[8] = S;
char a[8];
void f0 (void)
{
if (__builtin_strlen (a) > 7) // folded
__builtin_abort ();
}
void f1 (void)
{
if (__builtin_strlen (S + 1) > 6) // folded
__builtin_abort ();
}
void f2 (void)
{
if (__builtin_strlen (a + 1) > 6) // not folded but could be
__builtin_abort ();
}
void f3 (int i)
{
if (__builtin_strlen (S + i) > 7) // not folded but could be
__builtin_abort ();
}
void f4 (int i)
{
if (__builtin_strlen (a + i) > 7) // not folded but could be
__builtin_abort ();
}
f0 ()
f1 ()
f2 ()
_1 = __builtin_strlen (&MEM[(void *)&a + 1B]);
__builtin_abort ();
f3 (int i)
__builtin_abort ();
f4 (int i)
_3 = __builtin_strlen (_2);
__builtin_abort ();
[Bug fortran/50892] Internal compiler error: in gimplify_expr, at gimplify.c:7477
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50892 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #8 from Jerry DeLisle --- (In reply to Dominique d'Humieres from comment #7) > > Likely by r240850. > > Confirmed. IMO there is no need for a new test, hence closing s FIXED.` hmm, guess we need this test case now.
[Bug middle-end/83684] [8 Regression] ICE in maybe_diag_overlap, at gimple-ssa-warn-restrict.c:1371
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83684 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-01-05 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Based on the line number in the stack trace I'd say the ICE was due to an overly restrictive assertion that was removed in r256187. Please try a more recent revision to see if the problem clears up and let us know.
[Bug target/83399] Power8 ICE During LRA with 2-op rtl pattern for lvx instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83399 --- Comment #3 from kelvin at gcc dot gnu.org --- Author: kelvin Date: Fri Jan 5 20:43:20 2018 New Revision: 256285 URL: https://gcc.gnu.org/viewcvs?rev=256285&root=gcc&view=rev Log: works without regressions - still seeing problems re: bug 83399 Modified: branches/ibm/ltc99327/gcc/config/rs6000/rs6000-p8swap.c branches/ibm/ltc99327/gcc/config/rs6000/rs6000.c branches/ibm/ltc99327/gcc/config/rs6000/vsx.md branches/ibm/ltc99327/gcc/lra-constraints.c branches/ibm/ltc99327/gcc/lra-eliminations.c branches/ibm/ltc99327/gcc/lra.c branches/ibm/ltc99327/gcc/recog.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/pr48857.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-28.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-29.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-30.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-31.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-32.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-33.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-34.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-35.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-36.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-37.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-38.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-39.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-40.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-41.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-42.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-43.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-44.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/swaps-p8-45.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/vec-extract-2.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/vec-extract-3.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/vec-extract-5.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/vec-extract-6.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/vec-extract-7.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/vec-extract-8.c branches/ibm/ltc99327/gcc/testsuite/gcc.target/powerpc/vec-extract-9.c
[Bug fortran/50892] Internal compiler error: in gimplify_expr, at gimplify.c:7477
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50892
--- Comment #9 from Janne Blomqvist ---
Following r256284 (PR 78534) the original testcase ICE's. Interestingly, the
reduced testcases in #c2 and #c3 work fine.
The patch below fixes the ICE
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 533435a..82fe424 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -8392,7 +8392,9 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gfc_expr
* expr2)
if (expr1->ts.deferred)
{
if (expr2->expr_type != EXPR_NULL && lse.string_length != NULL)
- gfc_add_modify (&block, lse.string_length, rse.string_length);
+ gfc_add_modify (&block, lse.string_length,
+ fold_convert (TREE_TYPE (lse.string_length),
+ rse.string_length));
else if (lse.string_length != NULL)
gfc_add_modify (&block, lse.string_length,
build_zero_cst (TREE_TYPE (lse.string_length)));
[Bug c/83703] New: Loop termination condition ignored in -O3, works in -O2 or with smaller values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83703
Bug ID: 83703
Summary: Loop termination condition ignored in -O3, works in
-O2 or with smaller values
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: freddie_chopin at op dot pl
Target Milestone: ---
Example code:
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
#include
#include
const int32_t limit {359};
const int32_t in[]
{
599,
600,
601,
1199,
1200,
1201,
1799,
1800,
1801,
2599,
2600,
};
const int32_t out[]
{
0,
0,
1,
1,
1,
2,
2,
2,
3,
3,
3,
};
int main()
{
for (int32_t b1 = -limit; b1 < limit; ++b1)
{
for (int32_t b0 = -limit; b0 < limit; ++b0)
{
for (int32_t a0 = -limit; a0 < limit; ++a0)
{
if (a0 == 0)
continue;
int fail = 0;
for (size_t i {}; i < sizeof(out) / sizeof(*out) && fail == 0; ++i)
{
fail |= (b1 * in[i] + b0) / a0 != out[i];
}
if (fail == 0)
{
printf("success! %i %i %i\n", (int)b1, (int)b0, (int)a0);
return 0;
}
}
}
printf("fail! %i\n", (int)b1);
}
return 0;
}
-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --
This code works as intended when compiled with -O2 - last iteration of the
outer loop is with b1 == 358. However when compiled with -O3, the outer's loop
condition is completely ignored - the loop passes well above the value of
`limit` and continues infinitely. Increasing the value of `limit` gives exactly
the same result.
This fails:
$ gcc -O3 reg.cpp -Wall -Wextra && ./a.out
fail! -359
fail! -358
...
fail! 964
fail! 965
^C
$
This works:
$ gcc -O2 reg.cpp -Wall -Wextra && ./a.out
fail! -359
fail! -358
...
fail! 357
fail! 358
$
When I change `limit` to 358, at -O3 there is only ONE iteration.
$ gcc -O3 reg.cpp -Wall -Wextra && ./a.out
fail! -358
$
When I change `limit` to 357, the program works as intended at -O3. Any value
lower and it's the same
$ gcc --version
gcc (GCC) 7.2.1 20171128
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Tested on two PCs with Arch Linux, but both are actually mostly identical in
h/w and s/w.
