From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10716 invoked by alias); 27 Sep 2014 20:29:54 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 10677 invoked by uid 48); 27 Sep 2014 20:29:51 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/19808] miss a warning about uninitialized members in constructor Date: Sat, 27 Sep 2014 20:29:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 3.4.4 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: manu at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cf_reconfirmed_on cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-09/txt/msg02561.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D19808 Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez changed: What |Removed |Added ---------------------------------------------------------------------------- Last reconfirmed|2005-05-09 00:52:15 |2014-9-27 CC| |mpolacek at gcc dot gnu.or= g, | |paolo.carlini at oracle do= t com --- Comment #21 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- I just got hit by this bug. This can obviously be warned in the FE as clang does: test.cc:4:11: warning: field 'j' is uninitialized when used here [-Wuninitialized] S() : i(j), j(1) {}=20 ^ simply by marking the members somehow as initialized or not, and when using them realizing that they are still uninitialized. Marek, Paolo, Jason? Any idea how to do this? >>From gcc-bugs-return-462728-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Sep 27 20:40:12 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 14120 invoked by alias); 27 Sep 2014 20:40:11 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 14063 invoked by uid 48); 27 Sep 2014 20:40:08 -0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/2972] -Wuninitialized could warn about uninitialized member variable usage in constructors Date: Sat, 27 Sep 2014 20:40:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 3.4.0 X-Bugzilla-Keywords: diagnostic X-Bugzilla-Severity: enhancement X-Bugzilla-Who: manu at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-09/txt/msg02562.txt.bz2 Content-length: 1135 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D2972 --- Comment #20 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez --- (In reply to Jonathan Wakely from comment #14) > Created attachment 20817 [details] > better -Wmeminit patch >=20 > This version ignores empty classes and checks for a nontrivial default ct= or > instead of layout_pod_type. >=20 > This patch doesn't enable the warning unless explicity requested. I reali= se > that this warning is about enforcing style ("members should be initialised > in the mem-initializer-list not in the ctor body") but that's ok because > it's my preferred style, I just don't want the compiler to enforce other > people's preferred style ;) Perhaps a better alternative is to warn only if the uninitialized member is used in a mem-initializer. Then, when building the constructor call, mark t= he uninitialized members somehow as uninitialized for the middle-end, and let = the middle-end handle the cases in the body of the constructor. The first part would already fix PR19808. The second part will fix this bug with fewer fal= se positives than the proposed patch. >>From gcc-bugs-return-462729-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Sep 27 20:52:48 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 17873 invoked by alias); 27 Sep 2014 20:52:48 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 17851 invoked by uid 48); 27 Sep 2014 20:52:44 -0000 From: "Bruce at Daihls dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/63394] New: Segmentation Fault with -O3 flag on ARM v61 Processor Date: Sat, 27 Sep 2014 20:52:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 4.8.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: Bruce at Daihls dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-09/txt/msg02563.txt.bz2 Content-length: 1126 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D63394 Bug ID: 63394 Summary: Segmentation Fault with -O3 flag on ARM v61 Processor Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: Bruce at Daihls dot com Created attachment 33589 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D33589&action=3Dedit Preprocessed file layer3.c, from lame gcc: 4.8.2 20131212 (Red Hat 4.8.2-8) system: Raspberry Pi, ARMv6-compatible processor rev 7 (v6l) gcc build options: unknown cmd line: gcc -I. -I.. -I../include -I. -I../libmp3lame -I.. -O3 -c layer3= .c output: layer3.c: In function =CE=93=C3=87=C3=BFhip_init_tables_layer3=CE=93=C3=87= =C3=96: layer3.c:1871:1: internal compiler error: Segmentation fault } ^ This occurs when building lame-3.99.3.tar.gz. The shortened command line th= at will cause the segmentation fault is above, with the output from the compil= er. When the -O3 flag is removed, it compiles without error. >>From gcc-bugs-return-462730-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Sep 27 20:56:26 2014 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 19916 invoked by alias); 27 Sep 2014 20:56:26 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 19897 invoked by uid 48); 27 Sep 2014 20:56:22 -0000 From: "bernardwidynski at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug other/63395] New: Cygwin vs Cygwin64 Floating Point Discrepancy Date: Sat, 27 Sep 2014 20:56:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: other X-Bugzilla-Version: 4.8.3 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: bernardwidynski at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-09/txt/msg02564.txt.bz2 Content-length: 2383 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63395 Bug ID: 63395 Summary: Cygwin vs Cygwin64 Floating Point Discrepancy Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: bernardwidynski at gmail dot com Created attachment 33590 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33590&action=edit C source program that prints the floating point output I transitioned from Cygwin to Cygwin64 and noticed that one of my programs produces differing floating point output. I realize that floating point round off can produce differing outputs on different computer platforms, but Cygwin and Cygwin64 are each running on the same computer and the same floating point hardware is used. I noticed that with identical input values, the output values are different. I printed the floating point number in hexadecimal format and the outputs do not match. See the attached flterr.c program. This program computes the square of a floating-point number. The value of x before and after the square is printed. There are two iterations. On the first iteration Cygwin and Cygwin64 produce the same output: 0x3ff441395eb3a15d. But on the second iteration, differing outputs are printed: For Cygwin, the output is 0x400b56a2041cc08e. For Cygwin64, the output is 0x400b56a2041cc08d. See the attached files flterr.out and flterr64.out. Is there some explanation for this? This seems to be an error. I am running Cygwin and Cygwin64 on the same computer. The information from the system display shows the following: HP Pavilion dv5 Notebook PC Windows 7 Home Premium ServicePack 1 AMD Turion(tm) II P540 Dual-Core Processor 2.40 GHz 4.00 GB (3.74 GB usable) 64-bit Operating System The files gcc-v.out and gcc-v64.out show the gcc output when executing the make command. I've also attached cygcheck.out and cygcheck64.out for each installation. I thought perhaps that this may be a hardware error and I tried this same program on another computer which has the the following processor: AMD Phenom(tm) II N620 Dual-Core Processor 2.80 GHz The same error occurred. Apparently Cygwin and Cygwin64 are handling floating point differently and do not produce identical outputs.