[Bug middle-end/77357] strlen of constant strings not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77357 eggert at cs dot ucla.edu changed: What|Removed |Added CC||eggert at cs dot ucla.edu --- Comment #8 from eggert at cs dot ucla.edu --- (In reply to Martin Sebor from comment #7) > Committed in r262522. Unfortunately this commit apparently causes GCC to generate incorrect code when compiling Emacs. See Bug#86528.
[Bug middle-end/86528] strlen of constant string malfunction -- had to back out fix for PR middle-end/77357
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86528 --- Comment #1 from jim at meyering dot net --- I have just noticed that the two /p/... filename dates are wrong. The real pass/fail bracketing dates are listed below: July 7 works, July 11 fails.
[Bug middle-end/86528] New: strlen of constant string malfunction -- had to back out fix for PR middle-end/77357
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86528 Bug ID: 86528 Summary: strlen of constant string malfunction -- had to back out fix for PR middle-end/77357 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: jim at meyering dot net Target Milestone: --- gcc miscompiles latest emacs' fileio.c(file_accessible_directory_p) It all started with a new unwarranted warning from emacs. This one is ok: /p/emacs-2018-07-11.10h58/bin/emacs k this one and all subsequent (up to at least 2018-07-15) emit a warning: /p/emacs-2018-07-12.10h35/bin/emacs k Here's the warning: Warning (initialization): Unable to access `user-emacs-directory' (~/.emacs.d/). Any data that would normally be written there may be lost! If you never want to see this message again, customize the variable `user-emacs-directory-warning'. That's obviously wrong, because that directory *does* exist. Running it under strace shows a suspicious file name. It looks like use of uninitialized memory: $ strace -efile -ok.log emacs -q k $ grep -m3 x/.ema k.log faccessat(AT_FDCWD, "/m/.emacs.d/abbrev_defs", R_OK) = 0 openat(AT_FDCWD, "/m/.emacs.d", O_RDONLY|O_DIRECTORY|O_CLOEXEC|O_PATH) = 7 faccessat(AT_FDCWD, "/m/.emacs.d/\10YY|\376\177", F_OK) = -1 ENOENT (No such file or directory) Once the debugger showed which lines were involved, I found that this patch works around it. Besides, I have a tiny preference for memcpy over strcpy, since the length is known. diff --git a/src/fileio.c b/src/fileio.c index 5a1c7ae10e..3363cc0cf6 100644 --- a/src/fileio.c +++ b/src/fileio.c @@ -2861,9 +2861,11 @@ file_accessible_directory_p (Lisp_Object file) here. After appending '.', append another '/' to work around a macOS bug (Bug#30350). */ static char const appended[] = "/./"; + bool trailing_slash = data[len - 1] == '/'; char *buf = SAFE_ALLOCA (len + sizeof appended); memcpy (buf, data, len); - strcpy (buf + len, [data[len - 1] == '/']); + memcpy (buf + len, [trailing_slash], + sizeof appended - trailing_slash); dir = buf; } Then, I realized: it's related to a recent change in gcc and optimization. I had built latest emacs with latest built-from-git gcc. Emacs works when built with gcc from around July 8: rm src/fileio.o;make CC=/p/p/gcc-2018-07-08.16h57/bin/gcc CFLAGS='-ggdb3 -O2' Yet fails when built with gcc from July 11: rm src/fileio.o;make CC=/p/p/gcc-2018-07-11.11h00/bin/gcc CFLAGS='-ggdb3 -O2' Also, -O0 works in either case. Bisecting gcc led me to a commit that involves strlen of constant, which is what the replaced strcpy uses. 47d2cd73185a207ecc90970a73f5b38b114c48c2 PR middle-end/77357 - strlen of constant strings not folded Revert that, and emacs once again works when compiled with latest gcc.
[Bug debug/86455] var-tracking mishandles pre_dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86455 Tom de Vries changed: What|Removed |Added Keywords||patch --- Comment #4 from Tom de Vries --- https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00780.html
[Bug fortran/69654] ICE in gfc_trans_structure_assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69654 Andrew Pinski changed: What|Removed |Added Target Milestone|7.2 |---
[Bug fortran/86527] New: gfortran console I/O not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86527
Bug ID: 86527
Summary: gfortran console I/O not working
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: rdawson at ieee dot org
Target Milestone: ---
The following sample used to work:
program test
write(6,700)
700 format('hello from write')
print *, 'hello from print'
end
No compile errors with gfortran (gcc version 7.3.0)
I am using cygwin64 terminal, it executes and returns to the console prompt,
but outputs nothing.
[Bug c++/57401] 'Conflicting declaration' involving using declaration and dependent name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57401 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- .
[Bug c++/79736] [5 Regression] Please submit a full bug report: unable to create precompiled headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79736 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- Closing as fixed.
[Bug target/85993] config/sh/sh.c:10878: suspicious if .. else chain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85993 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #5 from Jeffrey A. Law --- Fixed on the trunk.
[Bug target/85993] config/sh/sh.c:10878: suspicious if .. else chain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85993 --- Comment #4 from Jeffrey A. Law --- Author: law Date: Sun Jul 15 20:28:15 2018 New Revision: 262671 URL: https://gcc.gnu.org/viewcvs?rev=262671=gcc=rev Log: PR target/85993 * config/sh/sh.c (output_mi_thunk): Remove dead conditional block. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c
[Bug tree-optimization/86526] ICE in builtin_memcpy_read_str, at builtins.c:3017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86526 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-07-15 Known to work||8.1.0 Ever confirmed|0 |1 Known to fail||9.0
[Bug tree-optimization/86526] New: ICE in builtin_memcpy_read_str, at builtins.c:3017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86526
Bug ID: 86526
Summary: ICE in builtin_memcpy_read_str, at builtins.c:3017
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: msebor at gcc dot gnu.org, qinzhao at gcc dot gnu.org
Target Milestone: ---
Starting from r262636 we ICE on:
$ cat strlen.i
void a() {
if (__builtin_memcmp(a, "ABCDEFGH\0", 14))
__builtin_abort();
}
$ gcc strlen.i -O1 -c --param builtin-string-cmp-inline-length=14
during RTL pass: expand
strlen.i: In function ‘a’:
strlen.i:2:7: internal compiler error: in builtin_memcpy_read_str, at
builtins.c:3017
if (__builtin_memcmp(a, "ABCDEFGH\0", 14))
^
0x5e261b builtin_memcpy_read_str
/home/marxin/Programming/gcc/gcc/builtins.c:3015
0x866d3f inline_string_cmp
/home/marxin/Programming/gcc/gcc/builtins.c:6796
0x866d3f inline_expand_builtin_string_cmp
/home/marxin/Programming/gcc/gcc/builtins.c:6879
0x86f1fc expand_builtin_memcmp
/home/marxin/Programming/gcc/gcc/builtins.c:4471
0x8734da expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/home/marxin/Programming/gcc/gcc/builtins.c:7333
0x99cc41 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/marxin/Programming/gcc/gcc/expr.c:10911
0x9a6caf store_expr(tree_node*, rtx_def*, int, bool, bool)
/home/marxin/Programming/gcc/gcc/expr.c:5614
0x9a80db expand_assignment(tree_node*, tree_node*, bool)
/home/marxin/Programming/gcc/gcc/expr.c:5398
0x8952c2 expand_call_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:2685
0x8952c2 expand_gimple_stmt_1
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3575
0x8952c2 expand_gimple_stmt
/home/marxin/Programming/gcc/gcc/cfgexpand.c:3734
0x89667f expand_gimple_basic_block
/home/marxin/Programming/gcc/gcc/cfgexpand.c:5769
0x89b417 execute
/home/marxin/Programming/gcc/gcc/cfgexpand.c:6372
[Bug target/84266] mmintrin.h intrinsic headers for PowerPC code fails on power9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84266 --- Comment #12 from Bill Schmidt --- Author: wschmidt Date: Sun Jul 15 18:04:00 2018 New Revision: 262670 URL: https://gcc.gnu.org/viewcvs?rev=262670=gcc=rev Log: [gcc] 2018-07-15 Bill Schmidt Backport from mainline 2018-07-13 Bill Schmidt Steve Munroe * config/rs6000/emmintrin.h (_mm_and_si128): New function. (_mm_andnot_si128): Likewise. (_mm_or_si128): Likewise. (_mm_xor_si128): Likewise. Backport from mainline 2017-11-16 Steven Munroe * config/rs6000/mmintrin.h (_mm_add_pi32[_ARCH_PWR]): Correct parameter list for vec_splats. Backport from mainline 2018-02-11 Steven Munroe PR target/84266 * config/rs6000/mmintrin.h (_mm_cmpeq_pi32 [_ARCH_PWR9]): Cast vec_cmpeq result to correct type. * config/rs6000/mmintrin.h (_mm_cmpgt_pi32 [_ARCH_PWR9]): Cast vec_cmpgt result to correct type. [gcc/testsuite] 2018-07-15 Bill Schmidt Backport from mainline 2018-07-13 Bill Schmidt Steve Munroe * gcc.target/powerpc/sse2-pand-1.c: New file. * gcc.target/powerpc/sse2-pandn-1.c: Likewise. * gcc.target/powerpc/sse2-por-1.c: Likewise. * gcc.target/powerpc/sse2-pxor-1.c: Likewise. Added: branches/ibm/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/sse2-pand-1.c branches/ibm/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/sse2-pandn-1.c branches/ibm/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/sse2-por-1.c branches/ibm/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/sse2-pxor-1.c Modified: branches/ibm/gcc-7-branch/gcc/ChangeLog.ibm branches/ibm/gcc-7-branch/gcc/config/rs6000/emmintrin.h branches/ibm/gcc-7-branch/gcc/config/rs6000/mmintrin.h branches/ibm/gcc-7-branch/gcc/testsuite/ChangeLog.ibm
[Bug tree-optimization/86520] AArch64: Two 8-bit accesses coalesced into a single 16-bit access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86520 --- Comment #3 from Andrew Pinski --- >When this happens in the real code I'm compiling/execution Also if you are accessing device memory, you are required to use volatile to force the memory accesses not to combine.
[Bug target/86525] New: [missed-optimization] extraneous instruction emitted in switch converted to look-uptable load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86525
Bug ID: 86525
Summary: [missed-optimization] extraneous instruction emitted
in switch converted to look-uptable load
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: a...@cloudius-systems.com
Target Milestone: ---
The code
enum xx { x1 = 1, x2 = 2, x3 = 3, x4, x5, x6 };
unsigned char f(xx x) {
switch (x) {
case xx::x1:
return 2;
case xx::x2:
return 2;
case xx::x3:
return 7;
case xx::x4:
return 7;
case xx::x5:
return 7;
case xx::x6:
return 9;
}
}
compiles to (thanks godbolt)
f(xx):
leal -1(%rdi), %eax
movzbl CSWTCH.1(%rax), %eax
ret
CSWTCH.1:
.byte 2
.byte 2
.byte 7
.byte 7
.byte 7
.byte 9
which is lovely, but the lea instruction can be folded into the movzbl
instruction:
movzbl CSWTCH.1 - 1(%rax), %eax
This assumes that CSWTCH.1 is placed at offset != 0.
[Bug tree-optimization/86520] AArch64: Two 8-bit accesses coalesced into a single 16-bit access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86520 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Earnshaw --- If your system cannot tolerate unaligned accesses, you'll need to rebuild all your code with -mstrict-align. Note that library code also assumes that misaligned accesses are safe: that is the default for AArch64.
[Bug middle-end/86471] GCC/libstdc++ outputs inferior code for std::fill and std::fill_n vs std::memset on c-style arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86471
--- Comment #10 from Matt Bentley ---
(In reply to Marc Glisse from comment #9)
> (In reply to Andrew Pinski from comment #7)
> We could also use __builtin_constant_p, if the function is inlined often
> enough (don't know if it is).
Right - so then the proposed function becomes:
template
inline typename
__gnu_cxx::__enable_if<__is_pointer_helper<_Tp>::__value ||
__is_integral_helper<_Tp>::__value, void>::__type
__fill_a(_ForwardIterator __first, _ForwardIterator __last,
const _Tp& __value)
{
if (__builtin_constant_p(__value) == 1)
{
if (__value != reinterpret_cast<_Tp>(0))
{
const _Tp __tmp = __value;
for (; __first != __last; ++__first)
*__first = __tmp;
}
else
{
if (const size_t __len = __last - __first)
__builtin_memset(reinterpret_cast(__first), 0,
__len *
sizeof(_Tp));
}
}
else
{
const _Tp __tmp = __value;
for (; __first != __last; ++__first)
*__first = __tmp;
}
}
, if I'm getting the enable_if syntax correct?
[Bug c++/86522] gcc-7.3.0 on x86-only fails to compile mariadb/mysql: error: unsupported size for integer register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86522 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Andrew Pinski --- Basically you are getting a 64bit register assignment happening and that is not what they really want. This is not a compiler bug but a bug in the inline-asm for SDT.
[Bug c++/86522] gcc-7.3.0 on x86-only fails to compile mariadb/mysql: error: unsupported size for integer register
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86522 --- Comment #4 from Andrew Pinski --- https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00016.html
