X-Recipient:	archive-cygwin AT delorie DOT com
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.1 sourceware.org 9BFA93858438
Authentication-Results:	sourceware.org; dmarc=none (p=none dis=none)
	header.from=SystematicSw.ab.ca
Authentication-Results:	sourceware.org;
	spf=none smtp.mailfrom=systematicsw.ab.ca
X-Authority-Analysis:	v=2.4 cv=R8NgpfdX c=1 sm=1 tr=0 ts=617996f9
	a=T+ovY1NZ+FAi/xYICV7Bgg==:117 a=T+ovY1NZ+FAi/xYICV7Bgg==:17
	a=IkcTkHD0fZMA:10 a=uYT-Tk0qkVT609LjNaIA:9 a=QEXdDO2ut3YA:10
From:	Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
To:	cygwin AT cygwin DOT com
References:	<248361fa-f16d-cebb-eefe-be78e09f4c10 AT towo DOT net>
Organization:	Systematic Software
Subject:	Re: gcc 11 weird bug
Message-ID:	<aa5d7632-8561-ed8e-b735-851fd3fc8489@SystematicSw.ab.ca>
Date:	Wed, 27 Oct 2021 12:14:16 -0600
User-Agent:	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
	Thunderbird/78.14.0
MIME-Version:	1.0
In-Reply-To:	<248361fa-f16d-cebb-eefe-be78e09f4c10@towo.net>
X-CMAE-Envelope:	MS4xfKDkW66EzjWbg6ObZwcafiPNIhXlMFVz8/nCp8GhSnS8PObFaj8r0ifdElKo10rfvV3DBNRYY9oeXQ79lUR7ydL56GgsIet1x9AzhDOBUSN6eYS0AF6w
	BoieTQgjGLHGWgErcLtaa+eL/cc4dcrV81yalRpB4FMPUgL+KSrJ9iBzhdRisEbc8JNXkv0Y4P9oHuyNDXNj4r7PqdJgzSK7vh8=
X-Spam-Status:	No, score=-1166.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
	KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL,
	RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,
	SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.4
X-Spam-Checker-Version:	SpamAssassin 3.4.4 (2020-01-24) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Reply-To:	cygwin AT cygwin DOT com
Errors-To:	cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 19RIH1e7008809

On 2021-10-27 03:19, Thomas Wolff wrote:
> I noticed that mintty did not compile anymore after upgrade to gcc 11, 
> but only on cygwin 32-bit.
> I tried to minimize the test case as much as possible without having the 
> bug vanish, to the attached standalone file.
> Compile this with
> cc -O2 -Wall -Werror m0.c
> and it gives a false positive warning about possible uninitialized data 
> usage.
> While data flow analysis is not perfect, it is weird that this used to 
> happen on 32 bit but not on 64 bit.
> Meanwhile, after updating some other packages (not sure which), but 
> still the same gcc version, the report on the test case also happens on 
> 64 bit, while the original, unstripped file, as part of mintty, still 
> works without error on 64 bit, which is even weirder.
> I have not yet had the opportunity to test this on Linux, sorry, so I'm 
> reporting it here.

Your initialization loops all have i = 0; i < count; which may leave 
types[0] uninitialized.

You should also add -Wextra to your compiles to get these warnings:

$ gcc -g -O2 -Wall -Wextra -c m0.c
m0.c: In function ‘do_bidi’:
m0.c:40:14: warning: unused parameter ‘autodir’ [-Wunused-parameter]
     40 | do_bidi(bool autodir, int paragraphLevel, bool explicitRTL, 
bool box_mirror,
        |              ^
m0.c:40:66: warning: unused parameter ‘box_mirror’ [-Wunused-parameter]
     40 | do_bidi(bool autodir, int paragraphLevel, bool explicitRTL, 
bool box_mirror,
        |                                                                  ^
m0.c:41:21: warning: unused parameter ‘line’ [-Wunused-parameter]
     41 |         bidi_char * line, int count)
        |         ~~~~~~~~~~~~^~~~
m0.c:256:12: warning: ‘*types[0]’ may be used uninitialized 
[-Wmaybe-uninitialized]
    256 |   if (types[0] == NSM /*&& !skip[0]*/)
        |       ~~~~~^~~

with source:

    if (types[0] == NSM /*&& !skip[0]*/)
      types[0] = (paragraphLevel & 1) ? R : L;  // sor

you need to add below:

    int isolateLevel = 0;
    int resLevel = -1;

the following:

    if (!count) {
      return resLevel;
    }

as that seems to be missing, then perhaps after:

   (void)levels;

   types[0] = NSM;

or something appropriate to quiet the warning.

You may also want to look at the control flow through your switch to see 
whether some additional else branches and assignments would ensure the 
values are always set.

You may also want to consider whether adding the following options to 
your gcc command lines would work with your builds:

-fanalyzer -fsanitize-recover=all -fstack-check -fstack-protector-all

as they could give you more warnings about possible issues.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -