From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from loongson.cn (mail.loongson.cn [114.242.206.163]) by sourceware.org (Postfix) with ESMTP id 90AFB3890435 for ; Mon, 10 Jan 2022 03:23:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 90AFB3890435 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=loongson.cn Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=loongson.cn Received: from [192.168.68.105] (unknown [111.18.94.40]) by mail.loongson.cn (Coremail) with SMTP id AQAAf9Dx+MmmptthuxABAA--.2489S3; Mon, 10 Jan 2022 11:23:20 +0800 (CST) Message-ID: <29468082-9c93-b644-199f-784c992ec369@loongson.cn> Date: Mon, 10 Jan 2022 11:23:18 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH 1/2] gdb: testsuite: fix failed testcases in gdb.base/charset.exp Content-Language: en-US To: Simon Marchi , gdb-patches@sourceware.org References: <20211225040320.8467-1-yangtiezhu@loongson.cn> <20211225040320.8467-2-yangtiezhu@loongson.cn> From: Tiezhu Yang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID: AQAAf9Dx+MmmptthuxABAA--.2489S3 X-Coremail-Antispam: 1UD129KBjvJXoW7Zr48ZrWrtFy8uF47ArWkZwb_yoW8Ar15pF WSva18t3ZYqF4xJrW0yw1Y9r92kF4xXryUJaykAa4DGa48CryUX39akF4rGasrAF1fJ3Wa v3y3u398Wan5JaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvIb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJr0_GcWl84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI 64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8Jw Am72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0VAS07AlzVAYIcxG8wCY 02Avz4vE14v_Gr4l42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxV Aqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1Y 6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6x kF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv 67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf 9x07bwdb8UUUUU= X-CM-SenderInfo: p1dqw3xlh2x3gn0dqz5rrqw2lrqou0/ X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_SHORT, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2022 03:23:38 -0000 On 1/10/22 10:42, Simon Marchi wrote: > > > On 2021-12-24 23:03, Tiezhu Yang wrote: >> In gdb/testsuite/gdb.base/charset.c, the last argument is greater than 127 >> when call fill_run() in EBCDIC-US and IBM1047, but the type of string[] is >> char, this will change the value due to sign extension. >> >> For example, ebcdic_us_string[7] will be -63 instead of the original 193 in >> EBCDIC-US. >> >> Make the type of string[] as unsigned char to fix the following six failed >> testcases: >> >> $ grep FAIL gdb/testsuite/gdb.sum >> FAIL: gdb.base/charset.exp: check value of parsed character literal in EBCDIC-US >> FAIL: gdb.base/charset.exp: check value of parsed string literal in EBCDIC-US >> FAIL: gdb.base/charset.exp: check value of escape that doesn't exist in EBCDIC-US >> FAIL: gdb.base/charset.exp: check value of parsed character literal in IBM1047 >> FAIL: gdb.base/charset.exp: check value of parsed string literal in IBM1047 >> FAIL: gdb.base/charset.exp: check value of escape that doesn't exist in IBM1047 > > Out of curiosity, on which configuration do you see these failures? I test this on LoongArch which is a new RISC architecture. > Asking because I don't see them on x86-64 Linux. > > Is it related to the fact that some architectures have "char" signed by > default and others unsigned by default? Yes. Each kind of machine has a default for what char should be. It is either like unsigned char by default or like signed char by default. Ideally, a portable program should always use signed char or unsigned char when it depends on the signedness of an object. https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html Thanks, Tiezhu > > Simon