unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* bleeding-edge gcc miscompiles latest emacs' fileio.c(file_accessible_directory_p)
@ 2018-07-16  4:01 Jim Meyering
  2018-07-16  5:02 ` Paul Eggert
  0 siblings, 1 reply; 6+ messages in thread
From: Jim Meyering @ 2018-07-16  4:01 UTC (permalink / raw)
  To: emacs-devel

FYI, building latest emacs with gcc from July 8 or newer led to an
annoying new warning...

---------- Forwarded message ----------
From: jim at meyering dot net <gcc-bugzilla@gcc.gnu.org>
Date: Sun, Jul 15, 2018 at 8:58 PM
Subject: [Bug middle-end/86528] New: strlen of constant string
malfunction -- had to back out fix for PR middle-end/77357
To: jim@meyering.net


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, &appended[data[len - 1] == '/']);
+      memcpy (buf + len, &appended[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.

--
You are receiving this mail because:
You reported the bug.



^ permalink raw reply related	[flat|nested] 6+ messages in thread

* Re: bleeding-edge gcc miscompiles latest emacs' fileio.c(file_accessible_directory_p)
  2018-07-16  4:01 bleeding-edge gcc miscompiles latest emacs' fileio.c(file_accessible_directory_p) Jim Meyering
@ 2018-07-16  5:02 ` Paul Eggert
  2018-07-16 14:25   ` Eli Zaretskii
  2018-07-16 21:34   ` Brett Gilio
  0 siblings, 2 replies; 6+ messages in thread
From: Paul Eggert @ 2018-07-16  5:02 UTC (permalink / raw)
  To: Jim Meyering, emacs-devel

Thanks for the heads-up. I'd rather not make that change to Emacs to
work around the bleeding-edge GCC bug, since the change causes the Emacs
code to be harder to follow. Let's hope they fix GCC soon, since the
problem was so recently introduced. I left a note about it here:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77357#c8



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: bleeding-edge gcc miscompiles latest emacs' fileio.c(file_accessible_directory_p)
  2018-07-16  5:02 ` Paul Eggert
@ 2018-07-16 14:25   ` Eli Zaretskii
  2018-07-16 21:17     ` Paul Eggert
  2018-07-16 21:34   ` Brett Gilio
  1 sibling, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2018-07-16 14:25 UTC (permalink / raw)
  To: Paul Eggert; +Cc: jim, emacs-devel

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Mon, 16 Jul 2018 00:02:26 -0500
> 
> Thanks for the heads-up. I'd rather not make that change to Emacs to
> work around the bleeding-edge GCC bug, since the change causes the Emacs
> code to be harder to follow. Let's hope they fix GCC soon, since the
> problem was so recently introduced. I left a note about it here:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77357#c8

Thanks, I agree that it's better to let GCC folks fix this.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: bleeding-edge gcc miscompiles latest emacs' fileio.c(file_accessible_directory_p)
  2018-07-16 14:25   ` Eli Zaretskii
@ 2018-07-16 21:17     ` Paul Eggert
  0 siblings, 0 replies; 6+ messages in thread
From: Paul Eggert @ 2018-07-16 21:17 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: jim, emacs-devel

On 07/16/2018 07:25 AM, Eli Zaretskii wrote:
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77357#c8
> Thanks, I agree that it's better to let GCC folks fix this.

Looks like it has been fixed in bleeding-edge GCC, so we should be OK:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86528#c6




^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: bleeding-edge gcc miscompiles latest emacs' fileio.c(file_accessible_directory_p)
  2018-07-16  5:02 ` Paul Eggert
  2018-07-16 14:25   ` Eli Zaretskii
@ 2018-07-16 21:34   ` Brett Gilio
  2018-07-16 23:52     ` Paul Eggert
  1 sibling, 1 reply; 6+ messages in thread
From: Brett Gilio @ 2018-07-16 21:34 UTC (permalink / raw)
  To: Paul Eggert; +Cc: Jim Meyering, emacs-devel


Paul Eggert writes:

> Thanks for the heads-up. I'd rather not make that change to 
> Emacs to
> work around the bleeding-edge GCC bug, since the change causes 
> the Emacs
> code to be harder to follow. Let's hope they fix GCC soon, since 
> the
> problem was so recently introduced. I left a note about it here:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77357#c8

Do we know if they gave an ETA on the upstream fix?



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: bleeding-edge gcc miscompiles latest emacs' fileio.c(file_accessible_directory_p)
  2018-07-16 21:34   ` Brett Gilio
@ 2018-07-16 23:52     ` Paul Eggert
  0 siblings, 0 replies; 6+ messages in thread
From: Paul Eggert @ 2018-07-16 23:52 UTC (permalink / raw)
  To: Brett Gilio; +Cc: Jim Meyering, emacs-devel

On 07/16/2018 02:34 PM, Brett Gilio wrote:
> Do we know if they gave an ETA on the upstream fix? 

It's fixed already in GCC trunk, which is the only place the bug was, as 
far as I know; it was never in any released GCC version. The GCC folks 
are generally pretty good about fixing wrong-code bugs.




^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2018-07-16 23:52 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-07-16  4:01 bleeding-edge gcc miscompiles latest emacs' fileio.c(file_accessible_directory_p) Jim Meyering
2018-07-16  5:02 ` Paul Eggert
2018-07-16 14:25   ` Eli Zaretskii
2018-07-16 21:17     ` Paul Eggert
2018-07-16 21:34   ` Brett Gilio
2018-07-16 23:52     ` Paul Eggert

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).