From unknown Sun Jun 22 07:59:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18699: 25.0.50; Windows 7: Odd length text property list Resent-From: oscarfv@telefonica.net (=?UTF-8?Q?=C3=93scar?= Fuentes) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Oct 2014 01:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 18699 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 18699@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.141316196215131 (code B ref -1); Mon, 13 Oct 2014 01:00:03 +0000 Received: (at submit) by debbugs.gnu.org; 13 Oct 2014 00:59:22 +0000 Received: from localhost ([127.0.0.1]:42278 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdTys-0003vx-01 for submit@debbugs.gnu.org; Sun, 12 Oct 2014 20:59:22 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47241) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdTyn-0003vj-Up for submit@debbugs.gnu.org; Sun, 12 Oct 2014 20:59:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XdTyg-00079S-22 for submit@debbugs.gnu.org; Sun, 12 Oct 2014 20:59:17 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:54415) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdTyf-00079N-VP for submit@debbugs.gnu.org; Sun, 12 Oct 2014 20:59:09 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48827) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdTyZ-0001xn-Go for bug-gnu-emacs@gnu.org; Sun, 12 Oct 2014 20:59:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XdTyT-00074a-9A for bug-gnu-emacs@gnu.org; Sun, 12 Oct 2014 20:59:03 -0400 Received: from smtp10.acens.net ([86.109.99.134]:58571 helo=smtp.movistar.es) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdTyS-00074P-U2 for bug-gnu-emacs@gnu.org; Sun, 12 Oct 2014 20:58:57 -0400 X-CTCH-RefID: str=0001.0A0B0208.543B23CC.00B2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-Spam: Unknown Received: from qcore (79.158.173.198) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 54074B0E012DB66A for bug-gnu-emacs@gnu.org; Mon, 13 Oct 2014 00:58:52 +0000 From: oscarfv@telefonica.net (=?UTF-8?Q?=C3=93scar?= Fuentes) Date: Mon, 13 Oct 2014 02:58:50 +0200 Message-ID: <87eguclr91.fsf@telefonica.net> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.3 (----) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.3 (----) Emacs -Q won't start on a Windows 7 32 bits laptop. It prints the mentioned message on the console. Same for a Windows 7 64 bits VM. However, the same binary has no issues on Windows XP 32 bits nor on Windows 8 64 bits. It was compiled on a Windows XP machine with MinGW-w64. The sources are the same used for this instance of Emacs on GNU Linux that I'm using for writing this report. There is bug#18559 on Sep 25 about the same problem but it was confirmed as fixed that same day. My sources are from Oct 4. Also tried an emacs.exe binary with current trunk. In GNU Emacs 25.0.50.2 (x86_64-unknown-linux-gnu, X toolkit) of 2014-10-04 on qcore Windowing system distributor `The X.Org Foundation', version 11.0.11501000 System Description: Ubuntu 14.04.1 LTS From unknown Sun Jun 22 07:59:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18699: 25.0.50; Windows 7: Odd length text property list Resent-From: oscarfv@telefonica.net (=?UTF-8?Q?=C3=93scar?= Fuentes) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Oct 2014 02:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18699 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 18699@debbugs.gnu.org Received: via spool by 18699-submit@debbugs.gnu.org id=B18699.141316658023645 (code B ref 18699); Mon, 13 Oct 2014 02:17:01 +0000 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 02:16:20 +0000 Received: from localhost ([127.0.0.1]:42310 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdVBK-00069H-CP for submit@debbugs.gnu.org; Sun, 12 Oct 2014 22:16:19 -0400 Received: from relayin10.dominioabsoluto.net ([217.116.26.78]:36487) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdVBD-000690-38 for 18699@debbugs.gnu.org; Sun, 12 Oct 2014 22:16:15 -0400 Received: from relaycp01.dominioabsoluto.net ([217.116.26.68]) by relayin10.dominioabsoluto.net with esmtp (Exim 4.84) (envelope-from ) id 1XdVB3-0004CF-F0 for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 04:16:06 +0200 Received: from smtp.movistar.es (smtp22.acens.net [86.109.99.146]) by relaycp01.dominioabsoluto.net (Postfix) with ESMTP id EDBF944F8 for <18699@debbugs.gnu.org>; Mon, 13 Oct 2014 04:35:34 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B020B.543B32AF.00E6, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-Spam: Unknown Received: from qcore (79.158.173.198) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 5408820F014B7831 for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 02:02:23 +0000 From: oscarfv@telefonica.net (=?UTF-8?Q?=C3=93scar?= Fuentes) References: <87eguclr91.fsf@telefonica.net> Date: Mon, 13 Oct 2014 04:02:22 +0200 In-Reply-To: (GNU bug Tracking System's message of "Mon, 13 Oct 2014 01:00:04 +0000") Message-ID: <87a950lob5.fsf_-_@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Filter-ID: s0sct1PQhAABKnZB5plbIdivVjmWowShOp3/r5dMZLlA5ZUGyMBfXHmCqrn81lAQwS9kmloc0QPc 6NojePGshPhnewWNrpLu7jNERT14J6IJb3UEbL+7L4L46DrOC6xAG6YnCJP7ZutaZCXOQshxeK+k gfhqDoEz/673Kb4EDbe9ER1b6OaWZfaymrHy+DiNeIIxnlMJ7/m0L4gC+YfjxrTvWPYXU5L8HSuo 24hjxYqCPb5F/okT2lUPzXgjp+zgHAkk7g6W7v9zZ9HLerco52Hxc6Y1QhxqpkqCFMvQ8d7piqok eqT/++QdwkybH3MHP99nvuX1asuLDeNsLqAm3S4AvugwjHw1A7wsiJS9c6FW2rmRLdTVKi4KPywK neY5RAxvAWm/6xyf1hJp+0TVv52U+OqTltqdLUs9npyk6BVDHBIG0U1IYXErR0k7H8/2MNfrht2X 69J0m0cX16o3P9MXqwtzm3QF2tzj3+P0hUrp8O8NlDymrBcRiWamYZuhc5iuu8ul6HWByhfM/cd3 FtwlIcuco922P9B3v1HX6QoV3BdsZd4UrEG+1W4D4NgkPnb7rI0VfeqD9XJhW9OTh2Hxc6Y1Qhxq pkqCFMvQ8d7piqokeqT/++QdwkybH3MHy9XUM2wxpPwCncXmP1ltNOlchNIE65G1NKBqyMZ4mJE8 4fwweFjR+gGwCKbvOGwDAoO85BYtSoRw6SW8HWhiJNNy3rQv/dN44EU2ZcLdit8= X-Report-Abuse-To: spam@relayin10.dominioabsoluto.net X-Filter-Fingerprint: IFrWXGses7OKB5S5G8/dJR8Z5VD7FZiiT9tK6RAzQuhA3cTUQ1R++keuE7RDJ8Kg3RbMLUalw1oC mj99/u+PoqoVy8a3lsStJtAvpObFX0W9pwnCLfzqMQ4SqlQant4mUpndEJ0YoaLytXXo8BMTaX2p Mk7LBarWD9Fj4R3eIu6C5spubTEXAEkuBKN3yOZvUxf7JO+oAUByCkP7cAJnEooJtGZFyF6tI/I5 CWVQH2sjWUvnt4XQmbZjx+Gtm4/p X-Originating-IP: 217.116.26.68 X-SpamExperts-Domain: out.example.com X-SpamExperts-Username: 217.116.26.68 Authentication-Results: dominioabsoluto.net; auth=pass smtp.auth=217.116.26.68 X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.28) X-Recommended-Action: accept X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Backtrace: #0 validate_plist (list=8577862) at ../../emacs/src/textprop.c:235 #1 0x0114d240 in add_text_properties_1 (start=start@entry=4, end=end@entry=48, properties=properties@entry=8577862, object=object@entry=22450013, set_type=set_type@entry=TEXT_PROPERTY_REPLACE) at ../../emacs/src/textprop.c:1181 #2 0x0114d607 in Fadd_text_properties (object=22450013, properties=8577862, end=end@entry=48, start=4) at ../../emacs/src/textprop.c:1306 #3 Fput_text_property (start=4, end=end@entry=48, property=21207346, value=22318226, object=22450013) at ../../emacs/src/textprop.c:1324 #4 0x01071e04 in produce_charset (coding=, pos=12, charbuf=0x82e39c) at ../../emacs/src/coding.c:7285 #5 produce_annotation (pos=12, coding=) at ../../emacs/src/coding.c:7328 #6 decode_coding (coding=coding@entry=0x82e5e0) at ../../emacs/src/coding.c:7423 #7 0x01076e6e in decode_coding_object (coding=, coding@entry=0x82e5e0, src_object=, src_object@entry=14478465, from=, from@entry=0, from_byte=, from_byte@entry=0, to=, to_byte=, dst_object=, dst_object@entry=21139106) at ../../emacs/src/coding.c:8149 #8 0x01078aea in code_convert_string (string=string@entry=14478465, coding_system=, coding_system@entry=22318258, dst_object=, encodep=encodep@entry=false, nocopy=nocopy@entry=false, norecord=norecord@entry=true) at ../../emacs/src/coding.c:9491 #9 0x01078f09 in code_convert_string_norecord (string=14478465, coding_system=coding_system@entry=22318258, encodep=encodep@entry=false) at ../../emacs/src/coding.c:9511 #10 0x01167840 in intern_font_name ( string=string@entry=0x82eb2c "Courier New") at ../../emacs/src/w32font.c:289 #11 0x01167ca7 in w32_enumfont_pattern_entity (frame=, requested_font=0x82ecd4, backend=21295146, font_type=4, physical_font=0x82e928, logical_font=0x82eb10) at ../../emacs/src/w32font.c:1085 #12 add_font_entity_to_list (logical_font=0x82eb10, physical_font=0x82e928, font_type=4, lParam=8580308) at ../../emacs/src/w32font.c:1500 #13 0x777004b5 in SetPixelV () from C:\Windows\system32\gdi32.dll #14 0x7770041e in SetPixelV () from C:\Windows\system32\gdi32.dll #15 0x777005db in GDI32!EnumFontFamiliesExA () from C:\Windows\system32\gdi32.dll #16 0x777005a8 in GDI32!EnumFontFamiliesExA () from C:\Windows\system32\gdi32.dll #17 0x011689a0 in w32font_list_internal ( f=f@entry=0x1810310 , font_spec=font_spec@entry=21240061, opentype_only=opentype_only@entry=1) at ../../emacs/src/w32font.c:833 #18 0x01178347 in uniscribe_list (f=0x1810310 , font_spec=21240061) at ../../emacs/src/w32uniscribe.c:74 #19 0x011179ca in font_list_entities (f=0x1810310 , spec=25013381) at ../../emacs/src/font.c:2804 #20 0x011181e4 in font_find_for_lface ( f=f@entry=0x1810310 , attrs=attrs@entry=0x82eeb4, spec=spec@entry=25232517, c=c@entry=-1) at ../../emacs/src/font.c:3281 #21 0x01118df2 in font_load_for_lface ( f=f@entry=0x1810310 , attrs=attrs@entry=0x82eeb4, spec=spec@entry=25232517) at ../../emacs/src/font.c:3354 #22 0x01118eb9 in font_open_by_spec ( f=f@entry=0x1810310 , spec=25232517) at ../../emacs/src/font.c:3416 #23 0x01118ef6 in font_open_by_name ( f=f@entry=0x1810310 , name=14478433) at ../../emacs/src/font.c:3432 #24 0x01157ffc in x_default_font_parameter ( f=f@entry=0x1810310 , parms=parms@entry=22486246) at ../../emacs/src/w32fns.c:4404 #25 0x0115fc4c in Fx_create_frame (parameters=22486246) at ../../emacs/src/w32fns.c:4568 #26 0x011044b2 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x82f094) at ../../emacs/src/eval.c:2723 #27 0x01136cda in exec_byte_code (bytestr=, vector=18883733, maxdepth=16, args_template=21139074, nargs=nargs@entry=0, args=, args@entry=0x0) at ../../emacs/src/bytecode.c:920 #28 0x0110401b in funcall_lambda (fun=18883685, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x82f240) at ../../emacs/src/eval.c:2956 #29 0x01104335 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x82f23c) at ../../emacs/src/eval.c:2784 #30 0x01136cda in exec_byte_code (bytestr=, vector=19180645, maxdepth=64, args_template=args_template@entry=1024, nargs=nargs@entry=1, args=, args@entry=0x82f3e8) at ../../emacs/src/bytecode.c:920 #31 0x0110409e in funcall_lambda (fun=19180597, nargs=nargs@entry=1, arg_vector=arg_vector@entry=0x82f3e8) at ../../emacs/src/eval.c:2890 #32 0x01104335 in Ffuncall (nargs=nargs@entry=2, args=args@entry=0x82f3e4) at ../../emacs/src/eval.c:2784 #33 0x01136cda in exec_byte_code (bytestr=, vector=19178765, maxdepth=24, args_template=args_template@entry=0, nargs=nargs@entry=0, args=, args@entry=0x82f578) at ../../emacs/src/bytecode.c:920 #34 0x0110409e in funcall_lambda (fun=19178725, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x82f578) at ../../emacs/src/eval.c:2890 #35 0x01104335 in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x82f574) at ../../emacs/src/eval.c:2784 #36 0x01136cda in exec_byte_code (bytestr=, vector=19196101, maxdepth=68, args_template=args_template@entry=0, nargs=nargs@entry=0, args=, args@entry=0x82f73c) at ../../emacs/src/bytecode.c:920 #37 0x0110409e in funcall_lambda (fun=19196061, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x82f73c) at ../../emacs/src/eval.c:2890 #38 0x01104335 in Ffuncall (nargs=nargs@entry=1, args=args@entry=0x82f738) at ../../emacs/src/eval.c:2784 #39 0x01136cda in exec_byte_code (bytestr=, vector=19194541, maxdepth=48, args_template=args_template@entry=0, nargs=nargs@entry=0, args=, args@entry=0x82f870) at ../../emacs/src/bytecode.c:920 #40 0x0110409e in funcall_lambda (fun=fun@entry=19194501, nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x82f870) at ../../emacs/src/eval.c:2890 #41 0x01103595 in apply_lambda (fun=, args=, count=count@entry=3) at ../../emacs/src/eval.c:2831 #42 0x01103865 in eval_sub (form=form@entry=22884086) at ../../emacs/src/eval.c:2253 #43 0x01106be9 in Feval (form=22884086, lexical=21139074) at ../../emacs/src/eval.c:1993 #44 0x01099b84 in top_level_2 () at ../../emacs/src/keyboard.c:1206 #45 0x01102c39 in internal_condition_case ( bfun=bfun@entry=0x1099b6b , handlers=21192610, hfun=hfun@entry=0x109dffd ) at ../../emacs/src/eval.c:1344 #46 0x01099b62 in top_level_1 (ignore=21139074) at ../../emacs/src/keyboard.c:1214 #47 0x01102b5c in internal_catch (tag=21189938, func=func@entry=0x1099b03 , arg=21139074) at ../../emacs/src/eval.c:1105 #48 0x0109dcb6 in command_loop () at ../../emacs/src/keyboard.c:1175 #49 recursive_edit_1 () at ../../emacs/src/keyboard.c:786 #50 0x0109df4b in Frecursive_edit () at ../../emacs/src/keyboard.c:857 #51 0x011ba1b8 in main (argc=, argv=0x8e2c30) at ../../emacs/src/emacs.c:1623 From unknown Sun Jun 22 07:59:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18699: 25.0.50; Windows 7: Odd length text property list Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Oct 2014 05:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18699 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: oscarfv@telefonica.net (=?UTF-8?Q?=C3=93scar?= Fuentes) Cc: 18699@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 18699-submit@debbugs.gnu.org id=B18699.141317831712111 (code B ref 18699); Mon, 13 Oct 2014 05:32:02 +0000 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 05:31:57 +0000 Received: from localhost ([127.0.0.1]:42365 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdYEe-00039G-Q2 for submit@debbugs.gnu.org; Mon, 13 Oct 2014 01:31:57 -0400 Received: from mtaout25.012.net.il ([80.179.55.181]:37018) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdYEa-000393-M5 for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 01:31:55 -0400 Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NDD00K00AUJFT00@mtaout25.012.net.il> for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 08:27:06 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDD00E4VB552Y70@mtaout25.012.net.il>; Mon, 13 Oct 2014 08:27:06 +0300 (IDT) Date: Mon, 13 Oct 2014 08:31:44 +0300 From: Eli Zaretskii In-reply-to: <87a950lob5.fsf_-_@wanadoo.es> X-012-Sender: halo1@inter.net.il Message-id: <8338as8ri7.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: oscarfv@telefonica.net (Óscar Fuentes) > Date: Mon, 13 Oct 2014 04:02:22 +0200 > > Backtrace: > > #0 validate_plist (list=8577862) at ../../emacs/src/textprop.c:235 > #1 0x0114d240 in add_text_properties_1 (start=start@entry=4, > end=end@entry=48, properties=properties@entry=8577862, > object=object@entry=22450013, > set_type=set_type@entry=TEXT_PROPERTY_REPLACE) > at ../../emacs/src/textprop.c:1181 > #2 0x0114d607 in Fadd_text_properties (object=22450013, properties=8577862, > end=end@entry=48, start=4) at ../../emacs/src/textprop.c:1306 > #3 Fput_text_property (start=4, end=end@entry=48, property=21207346, > value=22318226, object=22450013) at ../../emacs/src/textprop.c:1324 > #4 0x01071e04 in produce_charset (coding=, pos=12, > charbuf=0x82e39c) at ../../emacs/src/coding.c:7285 > #5 produce_annotation (pos=12, coding=) > at ../../emacs/src/coding.c:7328 > #6 decode_coding (coding=coding@entry=0x82e5e0) > at ../../emacs/src/coding.c:7423 > #7 0x01076e6e in decode_coding_object (coding=, > coding@entry=0x82e5e0, src_object=, > src_object@entry=14478465, from=, from@entry=0, > from_byte=, from_byte@entry=0, to=, > to_byte=, dst_object=, > dst_object@entry=21139106) at ../../emacs/src/coding.c:8149 > #8 0x01078aea in code_convert_string (string=string@entry=14478465, > coding_system=, coding_system@entry=22318258, > dst_object=, encodep=encodep@entry=false, > nocopy=nocopy@entry=false, norecord=norecord@entry=true) > at ../../emacs/src/coding.c:9491 > #9 0x01078f09 in code_convert_string_norecord (string=14478465, > coding_system=coding_system@entry=22318258, encodep=encodep@entry=false) > at ../../emacs/src/coding.c:9511 > #10 0x01167840 in intern_font_name ( > string=string@entry=0x82eb2c "Courier New") > at ../../emacs/src/w32font.c:289 > #11 0x01167ca7 in w32_enumfont_pattern_entity (frame=, > requested_font=0x82ecd4, backend=21295146, font_type=4, > physical_font=0x82e928, logical_font=0x82eb10) > at ../../emacs/src/w32font.c:1085 > #12 add_font_entity_to_list (logical_font=0x82eb10, physical_font=0x82e928, > font_type=4, lParam=8580308) at ../../emacs/src/w32font.c:1500 > #13 0x777004b5 in SetPixelV () from C:\Windows\system32\gdi32.dll > #14 0x7770041e in SetPixelV () from C:\Windows\system32\gdi32.dll > #15 0x777005db in GDI32!EnumFontFamiliesExA () > from C:\Windows\system32\gdi32.dll > #16 0x777005a8 in GDI32!EnumFontFamiliesExA () > from C:\Windows\system32\gdi32.dll > #17 0x011689a0 in w32font_list_internal ( > f=f@entry=0x1810310 , > font_spec=font_spec@entry=21240061, opentype_only=opentype_only@entry=1) > at ../../emacs/src/w32font.c:833 Looks exactly like #18559, but that one was fixed. Which version of GCC did you use to build this binary? The function add_font_entity_to_list is decorated with a GCC attribute that should cause GCC to emit a few instructions in the function's prologue to ensure the stack is 8-byte aligned. Do you see that in the disassembly of that function? If not, can you show the preprocessed source of the first few line of that function, including its definition line? In any case, please continue using the current trunk and reporting results from it, not from the Oct 4 version. Thanks. From unknown Sun Jun 22 07:59:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18699: 25.0.50; Windows 7: Odd length text property list Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Oct 2014 06:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18699 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: oscarfv@telefonica.net Cc: 18699@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 18699-submit@debbugs.gnu.org id=B18699.141318085916289 (code B ref 18699); Mon, 13 Oct 2014 06:15:02 +0000 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 06:14:19 +0000 Received: from localhost ([127.0.0.1]:42372 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdYte-0004Ee-Ly for submit@debbugs.gnu.org; Mon, 13 Oct 2014 02:14:18 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:64059) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdYtb-0004ER-Tx for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 02:14:17 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NDD00800D6UKY00@a-mtaout20.012.net.il> for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 09:14:14 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDD008RSDBPEM20@a-mtaout20.012.net.il>; Mon, 13 Oct 2014 09:14:14 +0300 (IDT) Date: Mon, 13 Oct 2014 09:14:07 +0300 From: Eli Zaretskii In-reply-to: <8338as8ri7.fsf@gnu.org> X-012-Sender: halo1@inter.net.il Message-id: <83wq847az4.fsf@gnu.org> References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > Date: Mon, 13 Oct 2014 08:31:44 +0300 > From: Eli Zaretskii > Cc: 18699@debbugs.gnu.org > > The function add_font_entity_to_list is decorated with a GCC attribute > that should cause GCC to emit a few instructions in the function's > prologue to ensure the stack is 8-byte aligned. Do you see that in the > disassembly of that function? If not, can you show the preprocessed > source of the first few line of that function, including its > definition line? Here's what I see in the preprocessed source on my machine: static int __attribute__((__stdcall__)) __attribute__((force_align_arg_pointer)) add_font_entity_to_list (ENUMLOGFONTEX *logical_font, NEWTEXTMETRICEX *physical_font, DWORD font_type, LPARAM lParam) { struct font_callback_data *match_data = (struct font_callback_data *) lParam; Lisp_Object backend = match_data->opentype_only ? Quniscribe : Qgdi; Lisp_Object entity; The important part is the force_align_arg_pointer attribute. This is set up in w32term.h, like this: #ifdef __GNUC__ # if USE_STACK_LISP_OBJECTS && !defined _W64 && !defined __x86_64__ \ && __GNUC__ + (__GNUC_MINOR__ > 1) >= 5 # define ALIGN_STACK __attribute__((force_align_arg_pointer)) # else # define ALIGN_STACK # endif /* USE_STACK_LISP_OBJECTS */ #endif Is it possible that the MinGW64 compiler somehow trips here? E.g., is it possible that, even in a 32-bit build, it defines _W64 or __x86_64__? If so, what other preprocessor macros are available in MinGW64 to distinguish between a 32-bit and a 64-bit build? From unknown Sun Jun 22 07:59:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18699: 25.0.50; Windows 7: Odd length text property list Resent-From: oscarfv@telefonica.net (=?UTF-8?Q?=C3=93scar?= Fuentes) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Oct 2014 10:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18699 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 18699@debbugs.gnu.org Received: via spool by 18699-submit@debbugs.gnu.org id=B18699.141319606810738 (code B ref 18699); Mon, 13 Oct 2014 10:28:02 +0000 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 10:27:48 +0000 Received: from localhost ([127.0.0.1]:42440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdcqx-0002n8-Gq for submit@debbugs.gnu.org; Mon, 13 Oct 2014 06:27:47 -0400 Received: from relaycp03.dominioabsoluto.net ([217.116.26.84]:39904) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdcqu-0002my-5B for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 06:27:45 -0400 Received: from smtp.movistar.es (smtp08.acens.net [86.109.99.132]) by relaycp03.dominioabsoluto.net (Postfix) with ESMTP id DA4B06E4188; Mon, 13 Oct 2014 12:27:42 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B020B.543BA91E.03DE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-Spam: Unknown Received: from qcore (79.158.173.198) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 540881B401257AC0; Mon, 13 Oct 2014 10:27:42 +0000 From: oscarfv@telefonica.net (=?UTF-8?Q?=C3=93scar?= Fuentes) References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> Date: Mon, 13 Oct 2014 12:27:41 +0200 In-Reply-To: <83wq847az4.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 13 Oct 2014 09:14:07 +0300") Message-ID: <8761fol0wy.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Eli Zaretskii writes: > The important part is the force_align_arg_pointer attribute. > > This is set up in w32term.h, like this: > > #ifdef __GNUC__ > # if USE_STACK_LISP_OBJECTS && !defined _W64 && !defined __x86_64__ \ > && __GNUC__ + (__GNUC_MINOR__ > 1) >= 5 > # define ALIGN_STACK __attribute__((force_align_arg_pointer)) The problem is _W64, which is defined to _w64. This doesn't make much sense to me. I'll ask on the MinGW-w64 ml. Thanks. From unknown Sun Jun 22 07:59:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18699: 25.0.50; Windows 7: Odd length text property list Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Oct 2014 11:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18699 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: oscarfv@telefonica.net (=?UTF-8?Q?=C3=93scar?= Fuentes) Cc: 18699@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 18699-submit@debbugs.gnu.org id=B18699.141320025422881 (code B ref 18699); Mon, 13 Oct 2014 11:38:02 +0000 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 11:37:34 +0000 Received: from localhost ([127.0.0.1]:42502 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XddwT-0005wz-Vz for submit@debbugs.gnu.org; Mon, 13 Oct 2014 07:37:34 -0400 Received: from mtaout26.012.net.il ([80.179.55.182]:46780) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XddwS-0005wr-6R for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 07:37:33 -0400 Received: from conversion-daemon.mtaout26.012.net.il by mtaout26.012.net.il (HyperSendmail v2007.08) id <0NDD00200S0ULB00@mtaout26.012.net.il> for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 14:35:45 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout26.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDD00LJUS7LQ560@mtaout26.012.net.il>; Mon, 13 Oct 2014 14:35:45 +0300 (IDT) Date: Mon, 13 Oct 2014 14:37:24 +0300 From: Eli Zaretskii In-reply-to: <8761fol0wy.fsf@wanadoo.es> X-012-Sender: halo1@inter.net.il Message-id: <83ppdw6w0b.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> <8761fol0wy.fsf@wanadoo.es> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: oscarfv@telefonica.net (Óscar Fuentes) > Cc: 18699@debbugs.gnu.org > Date: Mon, 13 Oct 2014 12:27:41 +0200 > > > #ifdef __GNUC__ > > # if USE_STACK_LISP_OBJECTS && !defined _W64 && !defined __x86_64__ \ > > && __GNUC__ + (__GNUC_MINOR__ > 1) >= 5 > > # define ALIGN_STACK __attribute__((force_align_arg_pointer)) > > The problem is _W64, which is defined to _w64. This doesn't make much > sense to me. I'll ask on the MinGW-w64 ml. Thanks. So this _is_ the same as 18559. From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 13 07:41:54 2014 Received: (at control) by debbugs.gnu.org; 13 Oct 2014 11:41:55 +0000 Received: from localhost ([127.0.0.1]:42510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xde0g-000646-3Y for submit@debbugs.gnu.org; Mon, 13 Oct 2014 07:41:54 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:42984) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xde0c-00063t-Do for control@debbugs.gnu.org; Mon, 13 Oct 2014 07:41:51 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NDD00D00RZ4RU00@mtaout27.012.net.il> for control@debbugs.gnu.org; Mon, 13 Oct 2014 14:36:36 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDD00ASTS900D40@mtaout27.012.net.il> for control@debbugs.gnu.org; Mon, 13 Oct 2014 14:36:36 +0300 (IDT) Date: Mon, 13 Oct 2014 14:41:43 +0300 From: Eli Zaretskii Subject: Re: Processed (with 1 errors): Re: Processed: Re: bug#18699: 25.0.50; Windows 7: Odd length text property list In-reply-to: X-012-Sender: halo1@inter.net.il To: control@debbugs.gnu.org (GNU bug tracker automated control server) Message-id: <83mw906vt4.fsf@gnu.org> References: <83oatg6vyk.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) reopen 18559 merge 18699 18559 thanks From unknown Sun Jun 22 07:59:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18699: 25.0.50; Windows 7: Odd length text property list In-Reply-To: <87eguclr91.fsf@telefonica.net> Resent-From: oscarfv@telefonica.net (=?UTF-8?Q?=C3=93scar?= Fuentes) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Oct 2014 11:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18699 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 18699@debbugs.gnu.org Cc: Eli Zaretskii Received: via spool by 18699-submit@debbugs.gnu.org id=B18699.141320089128810 (code B ref 18699); Mon, 13 Oct 2014 11:49:02 +0000 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 11:48:11 +0000 Received: from localhost ([127.0.0.1]:42517 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xde6k-0007Ub-DR for submit@debbugs.gnu.org; Mon, 13 Oct 2014 07:48:10 -0400 Received: from smtp08.acens.net ([86.109.99.132]:17297 helo=smtp.movistar.es) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xde6g-0007UR-PZ for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 07:48:08 -0400 X-CTCH-RefID: str=0001.0A0B020D.543BBBF3.0301, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-Spam: Unknown Received: from qcore (79.158.173.198) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 540881B401260C93; Mon, 13 Oct 2014 11:48:03 +0000 From: oscarfv@telefonica.net (=?UTF-8?Q?=C3=93scar?= Fuentes) Date: Mon, 13 Oct 2014 13:46:22 +0200 Lines: 22 References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-From-Line: nobody Mon Oct 13 13:46:24 2014 Message-ID: <8761fojiml.fsf@telefonica.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) The MinGW-w64 guys say that _W64 is not the rigth way of checking that we are targeting Windows 64. _WIN64 is. http://sourceforge.net/p/mingw-w64/mailman/message/32925577/ AFAIU the fact that we are using _W64 for detecting MinGW-w64 (on both 32 and 64 bit variants) is also wrong. _W64 is a MS thing and not specific to MinGW-w64, as explained on the StackOverflow question linked from the above message. It just happens that MinGW does not define it. The right way to detect MinGW-w64 is to test for __MINGW64_VERSION_MAJOR *after* including some C runtime header or _mingw.h, because it is not a preprocessor predefined macro. It is explained here: http://sourceforge.net/p/mingw-w64/discussion/723798/thread/ea355c1f/#d4db I propose to fix the ALIGN_STACK issue by replacing _W64 with _WIN64 and later fix the places where _W64 is used for detecting MinGW-w64 with the right method. Eli, can you take care of the ALIGN_STACK fix? I'll send a patch for the rest of _W64 cases, if nobody beats me to it. From unknown Sun Jun 22 07:59:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18699: 25.0.50; Windows 7: Odd length text property list Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Oct 2014 12:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18699 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: oscarfv@telefonica.net (=?UTF-8?Q?=C3=93scar?= Fuentes) Cc: 18699@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 18699-submit@debbugs.gnu.org id=B18699.14132045682379 (code B ref 18699); Mon, 13 Oct 2014 12:50:02 +0000 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 12:49:28 +0000 Received: from localhost ([127.0.0.1]:42546 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdf43-0000cI-KL for submit@debbugs.gnu.org; Mon, 13 Oct 2014 08:49:28 -0400 Received: from mtaout27.012.net.il ([80.179.55.183]:38358) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdf3z-0000c7-VV for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 08:49:25 -0400 Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NDD00200V4NXS00@mtaout27.012.net.il> for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 15:44:09 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDD00LW6VDIQM60@mtaout27.012.net.il>; Mon, 13 Oct 2014 15:44:09 +0300 (IDT) Date: Mon, 13 Oct 2014 15:49:13 +0300 From: Eli Zaretskii In-reply-to: <8761fojiml.fsf@telefonica.net> X-012-Sender: halo1@inter.net.il Message-id: <83k3446som.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> <8761fojiml.fsf@telefonica.net> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: oscarfv@telefonica.net (Óscar Fuentes) > Cc: Eli Zaretskii > Date: Mon, 13 Oct 2014 13:46:22 +0200 > > The MinGW-w64 guys say that _W64 is not the rigth way of checking that > we are targeting Windows 64. _WIN64 is. I'm quite sure at some point someone told me the exact opposite of this, whcih is why you see what you see in nt/inc/. > The right way to detect MinGW-w64 is to test for __MINGW64_VERSION_MAJOR > *after* including some C runtime header or _mingw.h, because it is not a > preprocessor predefined macro. It is a PITA that the MinGW64 compiler doesn't define some clear-cut macro for that without the need to include headers. IME this is a terrible maintenance headache in the long run. Perhaps you could ask the MinGW64 developers to change their mind about that. What about __x86_64__, does it perhaps fit the bill already? > Eli, can you take care of the ALIGN_STACK fix? Done in trunk revision 118105. > I'll send a patch for the rest of _W64 cases, if nobody beats me to > it. TIA From unknown Sun Jun 22 07:59:12 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: oscarfv@telefonica.net (=?UTF-8?Q?=C3=93scar?= Fuentes) Subject: bug#18699: closed (Re: bug#18699: 25.0.50; Windows 7: Odd length text property list) Message-ID: References: <871tqcjcn6.fsf@wanadoo.es> <87eguclr91.fsf@telefonica.net> X-Gnu-PR-Message: they-closed 18699 X-Gnu-PR-Package: emacs Reply-To: 18699@debbugs.gnu.org Date: Mon, 13 Oct 2014 13:58:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1413208682-13923-1" This is a multi-part message in MIME format... ------------=_1413208682-13923-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #18699: 25.0.50; Windows 7: Odd length text property list which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 18699@debbugs.gnu.org. --=20 18699: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D18699 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1413208682-13923-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 18699-done) by debbugs.gnu.org; 13 Oct 2014 13:57:28 +0000 Received: from localhost ([127.0.0.1]:42797 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdg7q-0003bj-Rg for submit@debbugs.gnu.org; Mon, 13 Oct 2014 09:57:27 -0400 Received: from relaycp01.dominioabsoluto.net ([217.116.26.68]:50048) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdg7l-0003bV-JA for 18699-done@debbugs.gnu.org; Mon, 13 Oct 2014 09:57:24 -0400 Received: from smtp.movistar.es (smtp09.acens.net [86.109.99.133]) by relaycp01.dominioabsoluto.net (Postfix) with ESMTP id D4E595121; Mon, 13 Oct 2014 16:30:32 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0205.543BDA3F.016D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-Spam: Unknown Received: from qcore (79.158.173.198) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 54077A760155633E; Mon, 13 Oct 2014 13:57:19 +0000 From: oscarfv@telefonica.net (=?utf-8?Q?=C3=93scar?= Fuentes) To: Eli Zaretskii Subject: Re: bug#18699: 25.0.50; Windows 7: Odd length text property list References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> <8761fojiml.fsf@telefonica.net> <83k3446som.fsf@gnu.org> Date: Mon, 13 Oct 2014 15:57:17 +0200 In-Reply-To: <83k3446som.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 13 Oct 2014 15:49:13 +0300") Message-ID: <871tqcjcn6.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 18699-done Cc: 18699-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Eli Zaretskii writes: [snip] > It is a PITA that the MinGW64 compiler doesn't define some clear-cut > macro for that without the need to include headers. IME this is a > terrible maintenance headache in the long run. Agreed. > Perhaps you could ask the MinGW64 developers to change their mind > about that. I could try, but my understanding is that they are not interested on doing that, for multiple reasons. One of them is that, in theory, you could use the MinGW-w64 compiler with the MinGW headers and libraries. > What about __x86_64__, does it perhaps fit the bill already? __x86_64__ is about the processor. It is also defined by gcc 4.8.2 on my Kubuntu x86_64. Of course, being MinGW on x86_64 implies Windows 64. But I've seen quite a few patch submissions about ARM support on the MinGW-w64 ml, so an hypothetical Emacs compiled for Windows ARM 64bits by MinGW would fail the __x86_64__ test. If that Emacs comes to light, we probably would need to determine what's the right thing wrt ALIGN_STACK, though. So in this specific case __x86_64__ does not harm, but it is superfluous on the presence on _WIN64. >> Eli, can you take care of the ALIGN_STACK fix? > > Done in trunk revision 118105. Thanks! ------------=_1413208682-13923-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 13 Oct 2014 00:59:22 +0000 Received: from localhost ([127.0.0.1]:42278 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdTys-0003vx-01 for submit@debbugs.gnu.org; Sun, 12 Oct 2014 20:59:22 -0400 Received: from eggs.gnu.org ([208.118.235.92]:47241) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdTyn-0003vj-Up for submit@debbugs.gnu.org; Sun, 12 Oct 2014 20:59:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XdTyg-00079S-22 for submit@debbugs.gnu.org; Sun, 12 Oct 2014 20:59:17 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:54415) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdTyf-00079N-VP for submit@debbugs.gnu.org; Sun, 12 Oct 2014 20:59:09 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48827) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdTyZ-0001xn-Go for bug-gnu-emacs@gnu.org; Sun, 12 Oct 2014 20:59:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XdTyT-00074a-9A for bug-gnu-emacs@gnu.org; Sun, 12 Oct 2014 20:59:03 -0400 Received: from smtp10.acens.net ([86.109.99.134]:58571 helo=smtp.movistar.es) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XdTyS-00074P-U2 for bug-gnu-emacs@gnu.org; Sun, 12 Oct 2014 20:58:57 -0400 X-CTCH-RefID: str=0001.0A0B0208.543B23CC.00B2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-Spam: Unknown Received: from qcore (79.158.173.198) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 54074B0E012DB66A for bug-gnu-emacs@gnu.org; Mon, 13 Oct 2014 00:58:52 +0000 From: oscarfv@telefonica.net (=?utf-8?Q?=C3=93scar?= Fuentes) To: bug-gnu-emacs@gnu.org Subject: 25.0.50; Windows 7: Odd length text property list Date: Mon, 13 Oct 2014 02:58:50 +0200 Message-ID: <87eguclr91.fsf@telefonica.net> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.3 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -4.3 (----) Emacs -Q won't start on a Windows 7 32 bits laptop. It prints the mentioned message on the console. Same for a Windows 7 64 bits VM. However, the same binary has no issues on Windows XP 32 bits nor on Windows 8 64 bits. It was compiled on a Windows XP machine with MinGW-w64. The sources are the same used for this instance of Emacs on GNU Linux that I'm using for writing this report. There is bug#18559 on Sep 25 about the same problem but it was confirmed as fixed that same day. My sources are from Oct 4. Also tried an emacs.exe binary with current trunk. In GNU Emacs 25.0.50.2 (x86_64-unknown-linux-gnu, X toolkit) of 2014-10-04 on qcore Windowing system distributor `The X.Org Foundation', version 11.0.11501000 System Description: Ubuntu 14.04.1 LTS ------------=_1413208682-13923-1-- From unknown Sun Jun 22 07:59:12 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.503 (Entity 5.503) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Jarek Czekalski Subject: bug#18559: closed (Re: bug#18699: 25.0.50; Windows 7: Odd length text property list) Message-ID: References: <871tqcjcn6.fsf@wanadoo.es> <54244554.9070100@jarek.katowice.pl> X-Gnu-PR-Message: they-closed 18559 X-Gnu-PR-Package: emacs Reply-To: 18559@debbugs.gnu.org Date: Mon, 13 Oct 2014 13:58:03 +0000 Content-Type: multipart/mixed; boundary="----------=_1413208683-13923-3" This is a multi-part message in MIME format... ------------=_1413208683-13923-3 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #18699: 24.4.50; can't start emacs - Odd length text property list which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 18559@debbugs.gnu.org. --=20 18699: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D18699 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1413208683-13923-3 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 18699-done) by debbugs.gnu.org; 13 Oct 2014 13:57:28 +0000 Received: from localhost ([127.0.0.1]:42797 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdg7q-0003bj-Rg for submit@debbugs.gnu.org; Mon, 13 Oct 2014 09:57:27 -0400 Received: from relaycp01.dominioabsoluto.net ([217.116.26.68]:50048) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdg7l-0003bV-JA for 18699-done@debbugs.gnu.org; Mon, 13 Oct 2014 09:57:24 -0400 Received: from smtp.movistar.es (smtp09.acens.net [86.109.99.133]) by relaycp01.dominioabsoluto.net (Postfix) with ESMTP id D4E595121; Mon, 13 Oct 2014 16:30:32 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0205.543BDA3F.016D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-Spam: Unknown Received: from qcore (79.158.173.198) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 54077A760155633E; Mon, 13 Oct 2014 13:57:19 +0000 From: oscarfv@telefonica.net (=?utf-8?Q?=C3=93scar?= Fuentes) To: Eli Zaretskii Subject: Re: bug#18699: 25.0.50; Windows 7: Odd length text property list References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> <8761fojiml.fsf@telefonica.net> <83k3446som.fsf@gnu.org> Date: Mon, 13 Oct 2014 15:57:17 +0200 In-Reply-To: <83k3446som.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 13 Oct 2014 15:49:13 +0300") Message-ID: <871tqcjcn6.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 18699-done Cc: 18699-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Eli Zaretskii writes: [snip] > It is a PITA that the MinGW64 compiler doesn't define some clear-cut > macro for that without the need to include headers. IME this is a > terrible maintenance headache in the long run. Agreed. > Perhaps you could ask the MinGW64 developers to change their mind > about that. I could try, but my understanding is that they are not interested on doing that, for multiple reasons. One of them is that, in theory, you could use the MinGW-w64 compiler with the MinGW headers and libraries. > What about __x86_64__, does it perhaps fit the bill already? __x86_64__ is about the processor. It is also defined by gcc 4.8.2 on my Kubuntu x86_64. Of course, being MinGW on x86_64 implies Windows 64. But I've seen quite a few patch submissions about ARM support on the MinGW-w64 ml, so an hypothetical Emacs compiled for Windows ARM 64bits by MinGW would fail the __x86_64__ test. If that Emacs comes to light, we probably would need to determine what's the right thing wrt ALIGN_STACK, though. So in this specific case __x86_64__ does not harm, but it is superfluous on the presence on _WIN64. >> Eli, can you take care of the ALIGN_STACK fix? > > Done in trunk revision 118105. Thanks! ------------=_1413208683-13923-3 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 25 Sep 2014 16:40:48 +0000 Received: from localhost ([127.0.0.1]:52219 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XXC62-0003dq-Ry for submit@debbugs.gnu.org; Thu, 25 Sep 2014 12:40:47 -0400 Received: from eggs.gnu.org ([208.118.235.92]:35042) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XXC5w-0003dc-4u for submit@debbugs.gnu.org; Thu, 25 Sep 2014 12:40:41 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XXC5l-0001R2-LT for submit@debbugs.gnu.org; Thu, 25 Sep 2014 12:40:39 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=AC_HTML_NONSENSE_TAGS, BAYES_50 autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:42553) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXC5l-0001Pt-I2 for submit@debbugs.gnu.org; Thu, 25 Sep 2014 12:40:29 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36730) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXC5Y-0003G8-T1 for bug-gnu-emacs@gnu.org; Thu, 25 Sep 2014 12:40:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XXC5R-0001O2-1I for bug-gnu-emacs@gnu.org; Thu, 25 Sep 2014 12:40:16 -0400 Received: from s74.linuxpl.com ([46.4.67.7]:41113) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XXC5Q-0001CB-Ny for bug-gnu-emacs@gnu.org; Thu, 25 Sep 2014 12:40:08 -0400 Received: from cj.e-siemianowice.pl ([95.215.234.30] helo=[192.168.17.9]) by s74.linuxpl.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.83) (envelope-from ) id 1XXC5Q-0004Jm-Qo for bug-gnu-emacs@gnu.org; Thu, 25 Sep 2014 18:40:08 +0200 Message-ID: <54244554.9070100@jarek.katowice.pl> Date: Thu, 25 Sep 2014 18:39:48 +0200 From: Jarek Czekalski User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: bug-gnu-emacs@gnu.org Subject: 24.3.90; can't start emacs - Odd length text property list Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (barebone) [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.1 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.1 (---) I just built trunk r117948 on mingw. I can't start emacs, it reports: Odd length text property list I can't make a report from this version as it is not starting, even with -Q. I managed to run r117941. Attaching stack trace below. Jarek Breakpoint 4, validate_plist (list=8971294) at ../../emacs-checkout/src/textprop.c:235 235 error ("Odd length text property list"); (gdb) bt #0 validate_plist (list=8971294) at ../../emacs-checkout/src/textprop.c:235 #1 0x0114e2cf in add_text_properties_1 (start=4, end=48, properties=, object=22190749, set_type=TEXT_PROPERTY_REPLACE) at ../../emacs-checkout/src/textprop.c:1181 #2 0x0114e634 in Fput_text_property (start=4, end=48, property=20970810, value=22189522, object=22190749) at ../../emacs-checkout/src/textprop.c:1323 #3 0x01073540 in produce_charset (pos=12, charbuf=0x88e47c, coding=) at ../../emacs-checkout/src/coding.c:7276 #4 produce_annotation (pos=, coding=0x88e6e8) at ../../emacs-checkout/src/coding.c:7319 #5 decode_coding (coding=) at ../../emacs-checkout/src/coding.c:7414 #6 0x01077423 in decode_coding_object (coding=0x88e6e8, src_object=116670713, from=0, from_byte=0, to=11, to_byte=11, dst_object=20909466) at ../../emacs-checkout/src/coding.c:8140 #7 0x010791e4 in code_convert_string (string=116670713, coding_system=, dst_object=20909466, encodep=false, nocopy=false, norecord=true) at ../../emacs-checkout/src/coding.c:9482 #8 0x01079405 in code_convert_string_norecord (string=116670713, coding_system=22096450, encodep=false) at ../../emacs-checkout/src/coding.c:9502 #9 0x011680e3 in intern_font_name (string=) at ../../emacs-checkout/src/w32font.c:289 #10 0x01168542 in w32_enumfont_pattern_entity (backend=21044986, font_type=4, physical_font=0x88ea48, logical_font=0x88ec30, frame=, requested_font=) at ../../emacs-checkout/src/w32font.c:1085 #11 add_font_entity_to_list (logical_font=0x88ec30, physical_font=0x88ea48, font_type=4, lParam=8973812) at ../../emacs-checkout/src/w32font.c:1500 #12 0x768c247a in GDI32!D3DKMTGetDeviceState () from C:\Windows\syswow64\gdi32.dll #13 0x0088ec30 in ?? () #14 0x768c23e3 in GDI32!D3DKMTGetDeviceState () from C:\Windows\syswow64\gdi32.dll #15 0x00a946e0 in ?? () #16 0x768c259c in GDI32!D3DKMTGetDeviceState () from C:\Windows\syswow64\gdi32.dll #17 0xee011eb1 in ?? () #18 0x00a907a0 in ?? () #19 0x768c256d in GDI32!D3DKMTGetDeviceState () from C:\Windows\syswow64\gdi32.dll #20 0xee011eb1 in ?? () #21 0x0088ee10 in ?? () #22 0x01169226 in w32font_list_internal (f=0x16f4620, font_spec=20999229, opentype_only=1) at ../../emacs-checkout/src/w32font.c:833 #23 0x01178081 in uniscribe_list (f=0x16f4620, font_spec=20999229) at ../../emacs-checkout/src/w32uniscribe.c:74 #24 0x0111a07a in font_list_entities (f=0x16f4620, spec=24070029) at ../../emacs-checkout/src/font.c:2805 #25 0x0111a769 in font_find_for_lface (f=0x16f4620, attrs=0x88eff4, spec=24078277, c=-1) at ../../emacs-checkout/src/font.c:3282 #26 0x0111ab84 in font_load_for_lface (f=0x16f4620, attrs=0x88eff4, spec=24078277) at ../../emacs-checkout/src/font.c:3355 #27 0x0111ac53 in font_open_by_spec (f=0x16f4620, spec=24078277) at ../../emacs-checkout/src/font.c:3417 #28 0x0111ac8c in font_open_by_name (f=0x16f4620, name=116670681) at ../../emacs-checkout/src/font.c:3433 #29 0x011595f2 in x_default_font_parameter (f=0x16f4620, parms=22317782) at ../../emacs-checkout/src/w32fns.c:4382 #30 0x0115f963 in Fx_create_frame (parameters=22317782) at ../../emacs-checkout/src/w32fns.c:4546 #31 0x011063f7 in Ffuncall (nargs=2, args=0x88f1d4) at ../../emacs-checkout/src/eval.c:2723 #32 0x0113874b in exec_byte_code (bytestr=6, vector=2, maxdepth=16, args_template=20909442, nargs=8974804, args=0x2) at ../../emacs-checkout/src/bytecode.c:920 #33 0x01105e8a in funcall_lambda (fun=18882493, nargs=, arg_vector=0x88f348) at ../../emacs-checkout/src/eval.c:2956 #34 0x011061ff in Ffuncall (nargs=2, args=0x88f344) at ../../emacs-checkout/src/eval.c:2784 #35 0x0113874b in exec_byte_code (bytestr=6, vector=2, maxdepth=20, args_template=20909442, nargs=8975172, args=0x2) at ../../emacs-checkout/src/bytecode.c:920 #36 0x01105e8a in funcall_lambda (fun=19200949, nargs=, arg_vector=0x88f4b8) at ../../emacs-checkout/src/eval.c:2956 #37 0x011061ff in Ffuncall (nargs=2, args=0x88f4b4) at ../../emacs-checkout/src/eval.c:2784 #38 0x0113874b in exec_byte_code (bytestr=6, vector=2, maxdepth=24, args_template=20909442, nargs=8975540, args=0x2) at ../../emacs-checkout/src/bytecode.c:920 #39 0x01105e8a in funcall_lambda (fun=19198509, nargs=, arg_vector=0x88f628) at ../../emacs-checkout/src/eval.c:2956 #40 0x011061ff in Ffuncall (nargs=1, args=0x88f624) at ../../emacs-checkout/src/eval.c:2784 #41 0x0113874b in exec_byte_code (bytestr=6, vector=2, maxdepth=68, args_template=0, nargs=8975908, args=0x1) at ../../emacs-checkout/src/bytecode.c:920 #42 0x01105f75 in funcall_lambda (fun=18902357, nargs=0, arg_vector=0x88f7cc) at ../../emacs-checkout/src/eval.c:2890 #43 0x011061ff in Ffuncall (nargs=1, args=0x88f7c8) at ../../emacs-checkout/src/eval.c:2784 #44 0x0113874b in exec_byte_code (bytestr=6, vector=2, maxdepth=48, args_template=0, nargs=8976328, args=0x1) at ../../emacs-checkout/src/bytecode.c:920 #45 0x01105f75 in funcall_lambda (fun=18900621, nargs=0, arg_vector=0x88f8e0) at ../../emacs-checkout/src/eval.c:2890 #46 0x01105412 in apply_lambda (fun=18900621, args=, count=3) at ../../emacs-checkout/src/eval.c:2831 #47 0x0110565e in eval_sub (form=22106294) at ../../emacs-checkout/src/eval.c:2253 #48 0x01107904 in Feval (form=22106294, lexical=20909442) at ../../emacs-checkout/src/eval.c:1993 #49 0x0109e056 in top_level_2 () at ../../emacs-checkout/src/keyboard.c:1207 #50 0x01104b67 in internal_condition_case (bfun=0x109e03a , handlers=20959738, hfun=0x109f702 ) at ../../emacs-checkout/src/eval.c:1344 #51 0x0109e96e in top_level_1 (ignore=20909442) at ../../emacs-checkout/src/keyboard.c:1215 #52 0x01104aab in internal_catch (tag=20953578, func=0x109e910 , arg=20909442) at ../../emacs-checkout/src/eval.c:1105 #53 0x0109f383 in command_loop () at ../../emacs-checkout/src/keyboard.c:1176 #54 recursive_edit_1 () at ../../emacs-checkout/src/keyboard.c:787 #55 0x0109f644 in Frecursive_edit () at ../../emacs-checkout/src/keyboard.c:858 #56 0x0109ab40 in main (argc=, argv=0xc52ff8) at ../../emacs-checkout/src/emacs.c:1643 (gdb) In GNU Emacs 24.3.90.2 (i686-pc-mingw32) of 2014-05-08 on BONSOFTW7 Repository revision: 117082 rgm@gnu.org-20140508033420-vclxect0m43u0rnh Windowing system distributor `Microsoft Corp.', version 6.1.7601 Configured using: `configure --prefix=d:/program_files/emacs24-master' Important settings: value of $LANG: pl locale-coding-system: cp1250 Major mode: C Minor modes in effect: shell-dirtrack-mode: t global-hl-line-mode: t recentf-mode: t tooltip-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t size-indication-mode: t column-number-mode: t line-number-mode: t transient-mark-mode: t abbrev-mode: t Recent input: M-x r e p o r c a n ' t SPC s t a r t SPC e m a c s SPC - SPC o d d SPC l e n g t h SPC t e x t SPC p r o p e r t y SPC l i s t C-g C-x C-f c : \ t e m p \ s r c \ e m - c h s r c M-x g r e p o d d . l e n SPC * M-x r e p o r t - e m Recent messages: Loading c:/Users/Jarek/AppData/Roaming/.emacs.d/snippets/text-mode/.yas-compiled-snippets.el (source)...done [yas] Loading snippet files from c:/Users/Jarek/AppData/Roaming/.emacs.d/snippets/text-mode [yas] Loaded ~/.emacs.d/snippets [yas] Reloaded everything.... Loading hl-line...done Loading whitespace...done Loading grep...done For information about GNU Emacs and the GNU system, type C-h C-a. Quit Grep exited abnormally with code 2 Load-path shadows: None found. Features: (shadow sort mail-extr vc-bzr cc-langs cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs shell pcomplete dired emacsbug message rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums grep compile comint ansi-color ring whitespace hl-line cus-start cus-load xml-parse yasnippet derived easy-mmode edmacro kmacro help-mode folding-isearch folding cl-macs advice cl gv eww mm-url gnus gnus-ems nnheader mail-utils url url-proxy url-privacy url-expand url-methods url-history url-cookie url-domsuf url-util url-parse auth-source eieio byte-opt bytecomp byte-compile cconv eieio-core gnus-util mm-util help-fns mail-prsvr password-cache url-vars mailcap shr browse-url format-spec bookmark pp recentf tree-widget wid-edit cl-loaddefs cl-lib easymenu server time-date tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp w32-common-fns disp-table w32-win w32-vars tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process w32notify w32 multi-tty emacs) Memory information: ((conses 8 217908 14720) (symbols 24 28252 0) (miscs 20 131 289) (strings 16 40240 5876) (string-bytes 1 1255123) (vectors 8 19506) (vector-slots 4 504869 6396) (floats 8 199 265) (intervals 28 3022 3678) (buffers 508 17)) ------------=_1413208683-13923-3-- From unknown Sun Jun 22 07:59:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18699: 25.0.50; Windows 7: Odd length text property list Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Oct 2014 19:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18699 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: oscarfv@telefonica.net (=?UTF-8?Q?=C3=93scar?= Fuentes) Cc: 18699@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 18699-submit@debbugs.gnu.org id=B18699.141322725410390 (code B ref 18699); Mon, 13 Oct 2014 19:08:01 +0000 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 19:07:34 +0000 Received: from localhost ([127.0.0.1]:42865 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdkxx-0002hU-LP for submit@debbugs.gnu.org; Mon, 13 Oct 2014 15:07:34 -0400 Received: from mtaout29.012.net.il ([80.179.55.185]:53450) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdkxt-0002hJ-EX for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 15:07:31 -0400 Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0NDE00I00D0QRP00@mtaout29.012.net.il> for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 22:06:30 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDE00872D2U1VA0@mtaout29.012.net.il>; Mon, 13 Oct 2014 22:06:30 +0300 (IDT) Date: Mon, 13 Oct 2014 22:07:22 +0300 From: Eli Zaretskii In-reply-to: <871tqcjcn6.fsf@wanadoo.es> X-012-Sender: halo1@inter.net.il Message-id: <83iojn7pqt.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> <8761fojiml.fsf@telefonica.net> <83k3446som.fsf@gnu.org> <871tqcjcn6.fsf@wanadoo.es> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: oscarfv@telefonica.net (Óscar Fuentes) > Cc: 18699-done@debbugs.gnu.org > Date: Mon, 13 Oct 2014 15:57:17 +0200 > > > Perhaps you could ask the MinGW64 developers to change their mind > > about that. > > I could try, but my understanding is that they are not interested on > doing that, for multiple reasons. One of them is that, in theory, you > could use the MinGW-w64 compiler with the MinGW headers and libraries. That's a nice theory, but I don't think it will hold, since (AFAIU) the two compilers use different methods of throwing C++ exceptions between DLLs. > > What about __x86_64__, does it perhaps fit the bill already? > > __x86_64__ is about the processor. It is also defined by gcc 4.8.2 on my > Kubuntu x86_64. Of course, being MinGW on x86_64 implies Windows 64. But > I've seen quite a few patch submissions about ARM support on the > MinGW-w64 ml, so an hypothetical Emacs compiled for Windows ARM 64bits > by MinGW would fail the __x86_64__ test. If that Emacs comes to light, > we probably would need to determine what's the right thing wrt > ALIGN_STACK, though. > > So in this specific case __x86_64__ does not harm, but it is superfluous > on the presence on _WIN64. It is there for Cygwin's sake, but I thought it could also serve MinGW64. From unknown Sun Jun 22 07:59:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18699: 25.0.50; Windows 7: Odd length text property list Resent-From: Ken Brown Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Oct 2014 19:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18699 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , =?UTF-8?Q?=C3=93scar?= Fuentes Cc: 18699@debbugs.gnu.org Received: via spool by 18699-submit@debbugs.gnu.org id=B18699.141322769511070 (code B ref 18699); Mon, 13 Oct 2014 19:15:02 +0000 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 19:14:55 +0000 Received: from localhost ([127.0.0.1]:42869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdl54-0002sT-OV for submit@debbugs.gnu.org; Mon, 13 Oct 2014 15:14:55 -0400 Received: from limerock02.mail.cornell.edu ([128.84.13.242]:60226) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Xdl52-0002sL-CQ for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 15:14:53 -0400 X-CornellRouted: This message has been Routed already. Received: from authusersmtp.mail.cornell.edu (granite3.serverfarm.cornell.edu [10.16.197.8]) by limerock02.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id s9DJEpAV024626; Mon, 13 Oct 2014 15:14:51 -0400 Received: from [128.84.234.253] (dhcp253.math.cornell.edu [128.84.234.253]) (authenticated bits=0) by authusersmtp.mail.cornell.edu (8.14.4/8.12.10) with ESMTP id s9DJEos3026708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 13 Oct 2014 15:14:51 -0400 Message-ID: <543C24AD.7090101@cornell.edu> Date: Mon, 13 Oct 2014 15:14:53 -0400 From: Ken Brown User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> <8761fojiml.fsf@telefonica.net> <83k3446som.fsf@gnu.org> <871tqcjcn6.fsf@wanadoo.es> <83iojn7pqt.fsf@gnu.org> In-Reply-To: <83iojn7pqt.fsf@gnu.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) On 10/13/2014 3:07 PM, Eli Zaretskii wrote: >> From: oscarfv@telefonica.net (Óscar Fuentes) >> Cc: 18699-done@debbugs.gnu.org >> Date: Mon, 13 Oct 2014 15:57:17 +0200 >> >>> Perhaps you could ask the MinGW64 developers to change their mind >>> about that. >> >> I could try, but my understanding is that they are not interested on >> doing that, for multiple reasons. One of them is that, in theory, you >> could use the MinGW-w64 compiler with the MinGW headers and libraries. > > That's a nice theory, but I don't think it will hold, since (AFAIU) > the two compilers use different methods of throwing C++ exceptions > between DLLs. > >>> What about __x86_64__, does it perhaps fit the bill already? >> >> __x86_64__ is about the processor. It is also defined by gcc 4.8.2 on my >> Kubuntu x86_64. Of course, being MinGW on x86_64 implies Windows 64. But >> I've seen quite a few patch submissions about ARM support on the >> MinGW-w64 ml, so an hypothetical Emacs compiled for Windows ARM 64bits >> by MinGW would fail the __x86_64__ test. If that Emacs comes to light, >> we probably would need to determine what's the right thing wrt >> ALIGN_STACK, though. >> >> So in this specific case __x86_64__ does not harm, but it is superfluous >> on the presence on _WIN64. > > It is there for Cygwin's sake, Right. And it's *not* about the processor. gcc running under 32-bit Cygwin will not define __x86_64__, regardless of the processor. Ken From unknown Sun Jun 22 07:59:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18699: 25.0.50; Windows 7: Odd length text property list Resent-From: oscarfv@telefonica.net (=?UTF-8?Q?=C3=93scar?= Fuentes) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Oct 2014 19:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18699 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ken Brown Cc: Eli Zaretskii , 18699@debbugs.gnu.org Received: via spool by 18699-submit@debbugs.gnu.org id=B18699.141322918213412 (code B ref 18699); Mon, 13 Oct 2014 19:40:01 +0000 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 19:39:42 +0000 Received: from localhost ([127.0.0.1]:42876 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdlT3-0003UF-KM for submit@debbugs.gnu.org; Mon, 13 Oct 2014 15:39:42 -0400 Received: from relaycp01.dominioabsoluto.net ([217.116.26.68]:36582) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdlSz-0003U1-0k for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 15:39:39 -0400 Received: from smtp.movistar.es (smtp22.acens.net [86.109.99.146]) by relaycp01.dominioabsoluto.net (Postfix) with ESMTP id 8B10D44A8; Mon, 13 Oct 2014 22:12:49 +0200 (CEST) X-CTCH-RefID: str=0001.0A0B0207.543C2A76.0344, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-Spam: Unknown Received: from qcore (79.158.173.198) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 543BDF950002128F; Mon, 13 Oct 2014 19:39:34 +0000 From: oscarfv@telefonica.net (=?UTF-8?Q?=C3=93scar?= Fuentes) References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> <8761fojiml.fsf@telefonica.net> <83k3446som.fsf@gnu.org> <871tqcjcn6.fsf@wanadoo.es> <83iojn7pqt.fsf@gnu.org> <543C24AD.7090101@cornell.edu> Date: Mon, 13 Oct 2014 21:39:33 +0200 In-Reply-To: <543C24AD.7090101@cornell.edu> (Ken Brown's message of "Mon, 13 Oct 2014 15:14:53 -0400") Message-ID: <87wq83iwsq.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Ken Brown writes: > Right. And it's *not* about the processor. gcc running under 32-bit > Cygwin will not define __x86_64__, regardless of the processor. It is about the *target* processor of the compiler. Obviously if you target x86 then __x86_64__ is expected to be undefined, regardless of the *host* processor. OTOH if you are saying that Cygwin does not define __x86_64__ when you are cross-compiling to a x86_64 target on a x86 host, I'll consider that a bug. My understanding now is that the __x86_64__ test is there because Cygwin does not define _WIN64. Eli, both MinGW and MinGW-w64 compilers support sjlj and Dwarf exception methods on x86. Maybe MinGW only supports one method on its official binaries, but that's just a detail that can change at any moment. Plus the user can build his own toolchain. And since when we do care about C++ here? ;-) From unknown Sun Jun 22 07:59:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18699: 25.0.50; Windows 7: Odd length text property list Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Oct 2014 20:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18699 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: oscarfv@telefonica.net (=?UTF-8?Q?=C3=93scar?= Fuentes) Cc: 18699@debbugs.gnu.org, kbrown@cornell.edu Reply-To: Eli Zaretskii Received: via spool by 18699-submit@debbugs.gnu.org id=B18699.141323192818581 (code B ref 18699); Mon, 13 Oct 2014 20:26:02 +0000 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 20:25:28 +0000 Received: from localhost ([127.0.0.1]:42900 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdmBK-0004pc-T8 for submit@debbugs.gnu.org; Mon, 13 Oct 2014 16:25:27 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:47058) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdmBH-0004pR-Ho for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 16:25:25 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NDE00G00GFH2300@a-mtaout20.012.net.il> for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 23:25:21 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDE00FFXGQ9W030@a-mtaout20.012.net.il>; Mon, 13 Oct 2014 23:25:21 +0300 (IDT) Date: Mon, 13 Oct 2014 23:25:16 +0300 From: Eli Zaretskii In-reply-to: <87wq83iwsq.fsf@wanadoo.es> X-012-Sender: halo1@inter.net.il Message-id: <83fver7m4z.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> <8761fojiml.fsf@telefonica.net> <83k3446som.fsf@gnu.org> <871tqcjcn6.fsf@wanadoo.es> <83iojn7pqt.fsf@gnu.org> <543C24AD.7090101@cornell.edu> <87wq83iwsq.fsf@wanadoo.es> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: oscarfv@telefonica.net (Óscar Fuentes) > Cc: Eli Zaretskii , 18699@debbugs.gnu.org > Date: Mon, 13 Oct 2014 21:39:33 +0200 > > Ken Brown writes: > > > Right. And it's *not* about the processor. gcc running under 32-bit > > Cygwin will not define __x86_64__, regardless of the processor. > > It is about the *target* processor of the compiler. Obviously if you > target x86 then __x86_64__ is expected to be undefined, regardless of > the *host* processor. > > OTOH if you are saying that Cygwin does not define __x86_64__ when you > are cross-compiling to a x86_64 target on a x86 host, I'll consider that > a bug. > > My understanding now is that the __x86_64__ test is there because Cygwin > does not define _WIN64. A 64-bit build on Windows, whether a Cygwin build or a MinGW64 build, doesn't need the force_align_arg_pointer, since the 64-bit ABI requires the 8-byte alignment. The __x86_64__ is there to exclude the 64-bit Cygwin build. If it can also exclude the MinGW64 build, we don't need any MinGW64-specific symbols there. > Eli, both MinGW and MinGW-w64 compilers support sjlj and Dwarf exception > methods on x86. But what is the default one? That's what's important. > And since when we do care about C++ here? ;-) At least the DWARF2-based exceptions machinery comes into play in C programs as well, see the few Emacs crashes we had with libraries linked against the libgcc DLL. From unknown Sun Jun 22 07:59:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18699: 25.0.50; Windows 7: Odd length text property list Resent-From: oscarfv@telefonica.net (=?UTF-8?Q?=C3=93scar?= Fuentes) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Oct 2014 20:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18699 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 18699@debbugs.gnu.org, kbrown@cornell.edu Received: via spool by 18699-submit@debbugs.gnu.org id=B18699.141323255519835 (code B ref 18699); Mon, 13 Oct 2014 20:36:01 +0000 Received: (at 18699) by debbugs.gnu.org; 13 Oct 2014 20:35:55 +0000 Received: from localhost ([127.0.0.1]:42904 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdmLS-00059q-3p for submit@debbugs.gnu.org; Mon, 13 Oct 2014 16:35:54 -0400 Received: from smtp08.acens.net ([86.109.99.132]:19998 helo=smtp.movistar.es) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdmLN-00059c-JI for 18699@debbugs.gnu.org; Mon, 13 Oct 2014 16:35:52 -0400 X-CTCH-RefID: str=0001.0A0B0204.543C37A3.0134, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-Spam: Unknown Received: from qcore (79.158.173.198) by smtp.movistar.es (8.6.122.03) (authenticated as 981711563$telefonica.net) id 543BDCB40003273F; Mon, 13 Oct 2014 20:35:47 +0000 From: oscarfv@telefonica.net (=?UTF-8?Q?=C3=93scar?= Fuentes) References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> <8761fojiml.fsf@telefonica.net> <83k3446som.fsf@gnu.org> <871tqcjcn6.fsf@wanadoo.es> <83iojn7pqt.fsf@gnu.org> <543C24AD.7090101@cornell.edu> <87wq83iwsq.fsf@wanadoo.es> <83fver7m4z.fsf@gnu.org> Date: Mon, 13 Oct 2014 22:35:45 +0200 In-Reply-To: <83fver7m4z.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 13 Oct 2014 23:25:16 +0300") Message-ID: <87siiriu72.fsf@wanadoo.es> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: > A 64-bit build on Windows, whether a Cygwin build or a MinGW64 build, > doesn't need the force_align_arg_pointer, since the 64-bit ABI > requires the 8-byte alignment. The __x86_64__ is there to exclude the > 64-bit Cygwin build. If it can also exclude the MinGW64 build, we > don't need any MinGW64-specific symbols there. As mentioned on a previous message, __x86_64__ will exclude Windows 64 on x86* processors, but not on others (i.e. ARM). >> Eli, both MinGW and MinGW-w64 compilers support sjlj and Dwarf exception >> methods on x86. > > But what is the default one? That's what's important. MinGW-w64 has no default. Both sjlj and Dwarf have official binaries on x86 and sjlj and SEH on x86_64. MinGW only distributes Dwarf, IIRC, but that can change anytime. But we are off-topic now. From unknown Sun Jun 22 07:59:12 2025 X-Loop: help-debbugs@gnu.org Subject: bug#18699: 25.0.50; Windows 7: Odd length text property list Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 14 Oct 2014 06:10:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18699 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: oscarfv@telefonica.net (=?UTF-8?Q?=C3=93scar?= Fuentes) Cc: 18699@debbugs.gnu.org, kbrown@cornell.edu Reply-To: Eli Zaretskii Received: via spool by 18699-submit@debbugs.gnu.org id=B18699.141326698220215 (code B ref 18699); Tue, 14 Oct 2014 06:10:03 +0000 Received: (at 18699) by debbugs.gnu.org; 14 Oct 2014 06:09:42 +0000 Received: from localhost ([127.0.0.1]:43109 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdvIk-0005Fz-1J for submit@debbugs.gnu.org; Tue, 14 Oct 2014 02:09:42 -0400 Received: from mtaout20.012.net.il ([80.179.55.166]:61993) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XdvIg-0005Fo-LE for 18699@debbugs.gnu.org; Tue, 14 Oct 2014 02:09:40 -0400 Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NDF00K007OKTC00@a-mtaout20.012.net.il> for 18699@debbugs.gnu.org; Tue, 14 Oct 2014 09:09:35 +0300 (IDT) Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NDF00KZC7RZOJ30@a-mtaout20.012.net.il>; Tue, 14 Oct 2014 09:09:35 +0300 (IDT) Date: Tue, 14 Oct 2014 09:09:31 +0300 From: Eli Zaretskii In-reply-to: <87siiriu72.fsf@wanadoo.es> X-012-Sender: halo1@inter.net.il Message-id: <83bnpf6v38.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <87eguclr91.fsf@telefonica.net> <87a950lob5.fsf_-_@wanadoo.es> <8338as8ri7.fsf@gnu.org> <83wq847az4.fsf@gnu.org> <8761fojiml.fsf@telefonica.net> <83k3446som.fsf@gnu.org> <871tqcjcn6.fsf@wanadoo.es> <83iojn7pqt.fsf@gnu.org> <543C24AD.7090101@cornell.edu> <87wq83iwsq.fsf@wanadoo.es> <83fver7m4z.fsf@gnu.org> <87siiriu72.fsf@wanadoo.es> X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: oscarfv@telefonica.net (Óscar Fuentes) > Cc: kbrown@cornell.edu, 18699@debbugs.gnu.org > Date: Mon, 13 Oct 2014 22:35:45 +0200 > > Eli Zaretskii writes: > > > A 64-bit build on Windows, whether a Cygwin build or a MinGW64 build, > > doesn't need the force_align_arg_pointer, since the 64-bit ABI > > requires the 8-byte alignment. The __x86_64__ is there to exclude the > > 64-bit Cygwin build. If it can also exclude the MinGW64 build, we > > don't need any MinGW64-specific symbols there. > > As mentioned on a previous message, __x86_64__ will exclude Windows 64 > on x86* processors, but not on others (i.e. ARM). We could decide not to worry about that until we need to support a Windows build on any of those others. Like we do with Cygwin.