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 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: 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> Content-Language: en-CA 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 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: cygwin AT cygwin DOT com Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" Content-Transfer-Encoding: 8bit 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