* bug#16492: Emacs won't bootstrap with clang 3.4 on Cygwin
@ 2014-01-19 7:55 Paul Eggert
2014-01-19 8:07 ` bug#16492: can't reproduce it with clang 3.4 on Fedora x86-64 Paul Eggert
2014-01-19 11:22 ` bug#16492: Emacs won't bootstrap with clang 3.4 on Cygwin Angelo Graziosi
0 siblings, 2 replies; 5+ messages in thread
From: Paul Eggert @ 2014-01-19 7:55 UTC (permalink / raw
To: 16492
[This bug was originally reported by mirek.kaim in
http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01702.html and
I'm taking the liberty of copying its contents below.]
editfns.c gets miscompiled at -O > 0, causing emacs to crash.
backtrace:
(gdb) run
Starting program: /y/build/emacs/src/temacs --batch --load loadup bootstrap
[New Thread 3728.0x10dc]
[New Thread 3728.0x10c0]
Loading loadup.el (source)...
Using load-path (/y/emacs/lisp /y/emacs/lisp/emacs-lisp
/y/emacs/lisp/language /y/emacs/lisp/international
/y/emacs/lisp/textmodes /y/emacs/lisp/vc)
[New Thread 3728.0xdd4]
Loading emacs-lisp/byte-run (source)...
Loading emacs-lisp/backquote (source)...
Loading subr (source)...
Loading version (source)...
Program received signal SIGSEGV, Segmentation fault.
strftime_case_ (upcase=false, s=0x228f00 "\001\212\210",
maxsize=<optimized out>, format=0x0, tp=0xa, ut=<optimized out>,
ns=<optimized out>) at ../../../emacs/lib/strftime.c:507
507 for (f = format; *f != '\0'; ++f)
(gdb) backtrace
#0 strftime_case_ (upcase=false, s=0x228f00 "\001\212\210",
maxsize=<optimized out>, format=0x0, tp=0xa, ut=<optimized out>,
ns=<optimized out>) at ../../../emacs/lib/strftime.c:507
#1 0x005a80c2 in nstrftime (s=0x228f00 "\001\212\210", maxsize=0,
format=0x0,
tp=0x61256e80 <tm>, ut=1, ns=484375000)
at ../../../emacs/lib/strftime.c:1449
#2 0x00513ef0 in format_time_string (format=0x0, formatlen=0, t=...,
ut=<optimized out>, tmp=<optimized out>)
at ../../../emacs/src/editfns.c:1672
#3 0x00513d44 in Fformat_time_string (format_string=<optimized out>,
timeval=2268888, universal=<optimized out>)
at ../../../emacs/src/editfns.c:1756
#4 0x0051d61c in eval_sub (form=<optimized out>)
at ../../../emacs/src/eval.c:2182
#5 0x0051d429 in eval_sub (form=<optimized out>)
at ../../../emacs/src/eval.c:2140
#6 0x0051e6e1 in Flet (args=<optimized out>) at
../../../emacs/src/eval.c:937
#7 0x0051d397 in eval_sub (form=<optimized out>)
at ../../../emacs/src/eval.c:2124
#8 0x0052175b in funcall_lambda (fun=<optimized out>, nargs=<optimized
out>,
arg_vector=<optimized out>) at ../../../emacs/src/eval.c:459
#9 0x00520346 in apply_lambda (fun=9104334, args=<optimized out>)
at ../../../emacs/src/eval.c:2915
---Type <return> to continue, or q <return> to quit---
#10 0x0051d53d in eval_sub (form=<optimized out>)
at ../../../emacs/src/eval.c:2221
#11 0x0052030b in apply_lambda (fun=9361006, args=<optimized out>)
at ../../../emacs/src/eval.c:2906
#12 0x0051d53d in eval_sub (form=<optimized out>)
at ../../../emacs/src/eval.c:2221
#13 0x0051d429 in eval_sub (form=<optimized out>)
at ../../../emacs/src/eval.c:2140
#14 0x0051d4d9 in eval_sub (form=<optimized out>)
at ../../../emacs/src/eval.c:2161
#15 0x0053e568 in readevalloop (readcharfun=8496874,
stream=0x864080 <bss_sbrk_buffer+671560>, sourcename=<optimized out>,
printflag=<optimized out>, unibyte=<optimized out>, readfun=8130560,
start=<optimized out>, end=<optimized out>)
at ../../../emacs/src/lread.c:1934
#16 0x0053d3f4 in Fload (file=<optimized out>, noerror=<optimized out>,
nomessage=<optimized out>, nosuffix=<optimized out>,
must_suffix=<optimized out>) at ../../../emacs/src/lread.c:1370
#17 0x0051d675 in eval_sub (form=<optimized out>)
at ../../../emacs/src/eval.c:2190
#18 0x0053e568 in readevalloop (readcharfun=8496874,
stream=0x864010 <bss_sbrk_buffer+671448>, sourcename=<optimized out>,
printflag=<optimized out>, unibyte=<optimized out>, readfun=8130560,
---Type <return> to continue, or q <return> to quit---
start=<optimized out>, end=<optimized out>)
at ../../../emacs/src/lread.c:1934
#19 0x0053d3f4 in Fload (file=<optimized out>, noerror=<optimized out>,
nomessage=<optimized out>, nosuffix=<optimized out>,
must_suffix=<optimized out>) at ../../../emacs/src/lread.c:1370
#20 0x0051d675 in eval_sub (form=<optimized out>)
at ../../../emacs/src/eval.c:2190
#21 0x005200d7 in Feval (form=8430502, lexical=<optimized out>)
at ../../../emacs/src/eval.c:1994
#22 0x004bd1bd in top_level_2 () at ../../../emacs/src/keyboard.c:1179
#23 0x0051f4af in internal_condition_case (bfun=0x77e170 <pbm_format+676>,
handlers=<optimized out>, hfun=<optimized out>)
at ../../../emacs/src/eval.c:1345
#24 0x004bd183 in top_level_1 (ignore=8450074)
at ../../../emacs/src/keyboard.c:1187
#25 0x0051ee24 in internal_catch (tag=<optimized out>, func=0x0,
arg=7856496)
at ../../../emacs/src/eval.c:1109
#26 0x004ac41a in recursive_edit_1 () at ../../../emacs/src/keyboard.c:1148
#27 0x004ac5d5 in Frecursive_edit () at ../../../emacs/src/keyboard.c:841
#28 0x004ab10a in main (
argc=<error reading variable: Cannot access memory at address 0x0>,
argv=<optimized out>) at ../../../emacs/src/emacs.c:1637
(gdb)
exact steps to reproduce:
http://aurora.irc.arloria.net/~unic0rn/emacs_clang_optimization_bug.html
my workaround is kinda silly, but at least it works. i've tried to
modify editfns.c to trick llvm's optimizers into generating something
that will work, to no avail. it seems like the first param doesn't end
up on the stack somehow. since llvm/clang 3.4 is a current release
version, i guess it'll land on osx and freebsd sooner than later, and
if they won't fix that until then - well, it may cause some problems.
unfortunately, i can't test it with higher -march settings, because my
cpu doesn't even support SSE2.
i've filled a bug for llvm, but i'm not sure how far it'll go:
http://llvm.org/bugs/show_bug.cgi?id=18537
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#16492: can't reproduce it with clang 3.4 on Fedora x86-64
2014-01-19 7:55 bug#16492: Emacs won't bootstrap with clang 3.4 on Cygwin Paul Eggert
@ 2014-01-19 8:07 ` Paul Eggert
2014-01-19 20:50 ` unic0rn
2014-01-19 11:22 ` bug#16492: Emacs won't bootstrap with clang 3.4 on Cygwin Angelo Graziosi
1 sibling, 1 reply; 5+ messages in thread
From: Paul Eggert @ 2014-01-19 8:07 UTC (permalink / raw
To: 16492; +Cc: unic0rn
For what it's worth, I cannot reproduce the problem with clang 3.4
(which I downloaded and built myself) on Fedora 20 x86-64. 'make
bootstrap' works just fine, with trunk bzr 116067. Most likely the
problem is specific to x86, and perhaps it needs the optimization
parameters '-march=pentium3 -mtune=pentium3 -O3' that were given in the
exact steps to reproduce.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#16492: Emacs won't bootstrap with clang 3.4 on Cygwin
2014-01-19 7:55 bug#16492: Emacs won't bootstrap with clang 3.4 on Cygwin Paul Eggert
2014-01-19 8:07 ` bug#16492: can't reproduce it with clang 3.4 on Fedora x86-64 Paul Eggert
@ 2014-01-19 11:22 ` Angelo Graziosi
1 sibling, 0 replies; 5+ messages in thread
From: Angelo Graziosi @ 2014-01-19 11:22 UTC (permalink / raw
To: 16492
Paul Eggert wrote:
> This bug was originally reported by mirek.kaim
For the sake of completeness, Emacs (GTK on Cygwin 32) builds just fine
with the official Cygwin CLANG package, i.e. version 3.1. I do this
weekly and it is more than an year... The last build is from yesterday
trunk... But, perhaps, the issue regards only CLANG 3.4..
Ciao,
Angelo.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#16492: can't reproduce it with clang 3.4 on Fedora x86-64
2014-01-19 8:07 ` bug#16492: can't reproduce it with clang 3.4 on Fedora x86-64 Paul Eggert
@ 2014-01-19 20:50 ` unic0rn
2016-08-09 1:43 ` npostavs
0 siblings, 1 reply; 5+ messages in thread
From: unic0rn @ 2014-01-19 20:50 UTC (permalink / raw
To: Paul Eggert; +Cc: 16492
looks like the bug exists in clang 3.3 as well, and that's quite old
actually (3.1 packaged for cygwin is ancient). but you may be right
that this is x86-specific problem. if that's the case, it may take
some time until llvm devs will try to fix it.
http://llvm.org/bugs/show_bug.cgi?id=18171
On Sun, Jan 19, 2014 at 9:07 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
> For what it's worth, I cannot reproduce the problem with clang 3.4 (which I
> downloaded and built myself) on Fedora 20 x86-64. 'make bootstrap' works
> just fine, with trunk bzr 116067. Most likely the problem is specific to
> x86, and perhaps it needs the optimization parameters '-march=pentium3
> -mtune=pentium3 -O3' that were given in the exact steps to reproduce.
^ permalink raw reply [flat|nested] 5+ messages in thread
* bug#16492: can't reproduce it with clang 3.4 on Fedora x86-64
2014-01-19 20:50 ` unic0rn
@ 2016-08-09 1:43 ` npostavs
0 siblings, 0 replies; 5+ messages in thread
From: npostavs @ 2016-08-09 1:43 UTC (permalink / raw
To: unic0rn; +Cc: Paul Eggert, 16492
close 16492
quit
unic0rn <mirek.kaim@gmail.com> writes:
> looks like the bug exists in clang 3.3 as well, and that's quite old
> actually (3.1 packaged for cygwin is ancient). but you may be right
> that this is x86-specific problem. if that's the case, it may take
> some time until llvm devs will try to fix it.
>
> http://llvm.org/bugs/show_bug.cgi?id=18171
According to this link, it was fixed in clang.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-08-09 1:43 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2014-01-19 7:55 bug#16492: Emacs won't bootstrap with clang 3.4 on Cygwin Paul Eggert
2014-01-19 8:07 ` bug#16492: can't reproduce it with clang 3.4 on Fedora x86-64 Paul Eggert
2014-01-19 20:50 ` unic0rn
2016-08-09 1:43 ` npostavs
2014-01-19 11:22 ` bug#16492: Emacs won't bootstrap with clang 3.4 on Cygwin Angelo Graziosi
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.