[Bug c/16351] NULL dereference warnings

[Bug c/16351] NULL dereference warnings

[Paulo.Matos at csr dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

Paulo J. Matos <Paulo.Matos at csr dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Paulo.Matos at csr dot com

--- Comment #10 from Paulo J. Matos <Paulo.Matos at csr dot com> 2012-07-02 14:36:40 UTC ---
I wonder if this is ever going to be fixed and if not, if there's any point in
being open.

[Bug c/16351] NULL dereference warnings

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu.org

--- Comment #11 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-07-02 14:54:22 UTC ---
(In reply to comment #10)
> I wonder if this is ever going to be fixed and if not, if there's any point in
> being open.

Like most things in GCC, it will get fixed when someone motivated enough
decides to spent the time and effort required to get it fixed.

A bug being open means that GCC maintainers are not in principle against the
feature, but it doesn't mean that they are ever going to work on it. There are
much older bugs than this one that are still open and some of them even get
fixed from time to time.

[Bug c/16351] NULL dereference warnings

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #12 from Jeffrey A. Law <law at redhat dot com> ---
gimple-ssa-isolate-paths.c has the necessary logic to catch a lot of this kind
of stuff now.  From what I can tell, it would catch everything properly in the
attached testcase.

[Bug c/16351] NULL dereference warnings

[hannes at stressinduktion dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

hannes <hannes at stressinduktion dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hannes at stressinduktion dot org

--- Comment #14 from hannes <hannes at stressinduktion dot org> ---
(In reply to Jeffrey A. Law from comment #13)
> Just adding a quick warning_at at the points where we optimize erroneous
> uses of NULL I get:

Very nice to see progress on this! Do you think this could be in-cooperated in
a future version of gcc?

[Bug c/16351] NULL dereference warnings

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #15 from Jeffrey A. Law <law at redhat dot com> ---
I expect it will be in GCC 4.9.  It's a wrap-up item for
-fisolate-erroneous-paths.

[Bug c/16351] NULL dereference warnings

[law at redhat dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #16 from Jeffrey A. Law <law at redhat dot com> ---
Created attachment 31928
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31928&action=edit
Work-In-Progress patch

[Bug c/16351] NULL dereference warnings

[mpolacek at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dcb314 at hotmail dot com

--- Comment #17 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
*** Bug 50606 has been marked as a duplicate of this bug. ***

[Bug c/16351] NULL dereference warnings

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #18 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #16)
> Created attachment 31928 [details]
> Work-In-Progress patch

Jeff, what happened with this?
>From gcc-bugs-return-463856-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Oct 12 12:54:46 2014
Return-Path: <gcc-bugs-return-463856-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5548 invoked by alias); 12 Oct 2014 12:54:45 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 5506 invoked by uid 48); 12 Oct 2014 12:54:41 -0000
From: "karo13de at googlemail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/63513] New: Error to build gcc loaded from svn
Date: Sun, 12 Oct 2014 12:54: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: blocker
X-Bugzilla-Who: karo13de at googlemail 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
Message-ID: <bug-63513-4@http.gcc.gnu.org/bugzilla/>
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-10/txt/msg00877.txt.bz2
Content-length: 2061

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63513

            Bug ID: 63513
           Summary: Error to build gcc loaded from svn
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: karo13de at googlemail dot com

Build error of gcc svn on MacOSX 10.9:

No options given for configure and make

...
/Users/xxx/sw/gccdir/./gcc/xgcc -B/Users/karo/sw/gccdir/./gcc/
-B/usr/local/x86_64-apple-darwin13.4.0/bin/
-B/usr/local/x86_64-apple-darwin13.4.0/lib/ -isystem
/usr/local/x86_64-apple-darwin13.4.0/include -isystem
/usr/local/x86_64-apple-darwin13.4.0/sys-include    -g -O2 -m32 -O2  -g -O2
-DIN_GCC    -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -pipe -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc
-fno-stack-protector   -pipe -fno-common -I. -I. -I../../.././gcc
-I../../.././../gcc/libgcc -I../../.././../gcc/libgcc/.
-I../../.././../gcc/libgcc/../gcc -I../../.././../gcc/libgcc/../include 
-DHAVE_CC_TLS -DUSE_EMUTLS -o _mulxc3.o -MT _mulxc3.o -MD -MP -MF _mulxc3.dep
-DL_mulxc3 -c ../../.././../gcc/libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS
../../.././../gcc/libgcc/libgcc2.c: In Funktion »__mulxc3«:
../../.././../gcc/libgcc/libgcc2.c:1955:6: interner Compiler-Fehler: Illegal
instruction: 4
    a = COPYSIGN (isinf (a) ? 1 : 0, a);
      ^
libbacktrace could not find executable to open
Bitte senden Sie einen vollständigen Fehlerbericht auf Englisch ein;
bearbeiten Sie die Quellen zunächst mit einem Präprozessor, wenn es
dienlich ist.
Siehe <http://gcc.gnu.org/bugs.html> für nähere Anweisungen.
make[5]: *** [_mulxc3.o] Error 1
make[4]: *** [multi-do] Error 1
make[3]: *** [all-multi] Error 2
make[2]: *** [all-stage1-target-libgcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2
gccdir $
>From gcc-bugs-return-463857-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Oct 12 13:09:54 2014
Return-Path: <gcc-bugs-return-463857-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13358 invoked by alias); 12 Oct 2014 13:09:54 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 13339 invoked by uid 48); 12 Oct 2014 13:09:51 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/25689] missed diagnostic about assignment used as truth value.
Date: Sun, 12 Oct 2014 13:09: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: 4.1.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: minor
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: cf_reconfirmed_on
Message-ID: <bug-25689-4-mMSMhm6T6s@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-25689-4@http.gcc.gnu.org/bugzilla/>
References: <bug-25689-4@http.gcc.gnu.org/bugzilla/>
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-10/txt/msg00878.txt.bz2
Content-length: 1121

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25689

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2006-01-06 12:32:23         |2014-10-12

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
A simpler testcase:

struct Var {
  operator int() const;
  Var& operator = (int);
};

void foo(Var var)
{
  if (var = 0) {}  // we should warn
  if (var.operator=(0)) {} // we should NOT warn
}

Clang prints:

pr25689.C:8:11: warning: using the result of an assignment as a condition
without parentheses [-Wparentheses]
  if (var = 0) {}  // if (var.operator=(0))
      ~~~~^~~
pr25689.C:8:11: note: place parentheses around the assignment to silence this
warning
  if (var = 0) {}  // if (var.operator=(0))
          ^
      (      )
pr25689.C:8:11: note: use '==' to turn this assignment into an equality
comparison
  if (var = 0) {}  // if (var.operator=(0))
          ^
          ==
>From gcc-bugs-return-463858-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Oct 12 13:18:49 2014
Return-Path: <gcc-bugs-return-463858-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15980 invoked by alias); 12 Oct 2014 13:18:49 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 15950 invoked by uid 48); 12 Oct 2014 13:18:45 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/37866] "passing argument from incompatible pointer type" warning cannot be passed to -WerrorDate: Sun, 12 Oct 2014 13:18: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: 4.3.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
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_status resolution
Message-ID: <bug-37866-4-HIezVGixt3@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-37866-4@http.gcc.gnu.org/bugzilla/>
References: <bug-37866-4@http.gcc.gnu.org/bugzilla/>
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-10/txt/msg00879.txt.bz2
Content-length: 906

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37866

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #9 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
https://gcc.gnu.org/gcc-5/changes.html

It is possible to disable warnings about conversions between pointers that have
incompatible types via a new warning option -Wno-incompatible-pointer-types;
warnings about implicit incompatible integer to pointer and pointer to integer
conversions via a new warning option -Wno-int-conversion; and warnings about
qualifiers on pointers being discarded via a new warning option
-Wno-discarded-qualifiers.
>From gcc-bugs-return-463859-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Oct 12 13:34:25 2014
Return-Path: <gcc-bugs-return-463859-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 23076 invoked by alias); 12 Oct 2014 13:34:25 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 23048 invoked by uid 48); 12 Oct 2014 13:34:22 -0000
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63260] [SH] fabs, fneg do not need fp-mode setting and do not use fpscr
Date: Sun, 12 Oct 2014 13:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: olegendo at gcc dot gnu.org
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:
Message-ID: <bug-63260-4-9dlDGQt98r@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63260-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63260-4@http.gcc.gnu.org/bugzilla/>
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-10/txt/msg00880.txt.bz2
Content-length: 374

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc260

--- Comment #1 from Oleg Endo <olegendo at gcc dot gnu.org> ---
The following functions should not show any mode changes:

float test_0 (float x)
{
  return -x;
}

double test_1 (double x)
{
  return -x;
}

float test_2 (float x)
{
  return __builtin_fabs (x);
}

double test_3 (double x)
{
  return __builtin_abs (x);
}

[Bug c/16351] NULL dereference warnings

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #19 from Jeffrey A. Law <law at redhat dot com> ---
Nobody ever reviewed the changes :(

[Bug c/16351] NULL dereference warnings

[manu at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 12081 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #20 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #19)
> Nobody ever reviewed the changes :(

If precisely you cannot get someone to review your patches, the lack of
manpower in GCC is becoming truly desperate, including the middle-end.

In any case, you are a middle-end maintainer. Give a period for last minute
comments and commit it? If something breaks, you can always revert it. This is
not some major architectural work, it seems quite independent piece.
>From gcc-bugs-return-463979-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Oct 13 20:48:17 2014
Return-Path: <gcc-bugs-return-463979-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4003 invoked by alias); 13 Oct 2014 20:48:17 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 3895 invoked by uid 48); 13 Oct 2014 20:48:09 -0000
From: "daniel.kruegler at googlemail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63526] O1 O2 O3 optimization and inline template constructor - uninitialized member
Date: Mon, 13 Oct 2014 20:48: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: daniel.kruegler at googlemail 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: cc
Message-ID: <bug-63526-4-7wfeP1DNpZ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63526-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63526-4@http.gcc.gnu.org/bugzilla/>
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-10/txt/msg01000.txt.bz2
Content-length: 2601

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63526

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler@googlemail.
                   |                            |com

--- Comment #3 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
(In reply to Dávid Éles from comment #2)
> I uses the default mechanism to initialization of members. 
> As far as I know the C++ standard says (8.5/5):
> To default-initialize an object of type T means:
> * If T is a non-POD class type (clause 9), the default constructor for T is
> called (and the initialization is ill-formed if T has no accessible default
> constructor).

[Based on your quotes and your compiler settings you seem to quote the C++98/03
standard. This is where my response is referred to as well]

In your example an object of type Foo<double> is default-initialized. Class
Foo<double> is a non-POD class type, and therefore exactly this bullet is
entered. The result is what the wording says: the default constructor for T
(that is Foo<double> in this example is called. The semantics of calling the
default-constructor of a class that has no member-initializer provided (such as
in this case) is specified in [class.base.init] p5:

"If a given nonstatic data member or base class is not named by a
mem-initializer-id (including the case where there is no mem-initializer-list
because the constructor has no ctor-initializer), then
— If the entity is a nonstatic data member of (possibly cv-qualified) class
type (or array thereof) or a base class, and the entity class is a non-POD
class [..]
— Otherwise, the entity is not initialized. [..]

The first bullet here does not apply, because the member is of type double and
thus does not match a class type. The second bullet therefore unconditionally
applied and says that the member is not initialized at all.

> * If T is an array type, each element is default-initialized.

This bullet does not apply

> * Otherwise, the object is zero-initialized.

This bullet does not apply.

> In case of c++ it should be zero initialized if it is the member of a
> class/struct.

No, you are incorrectly interpreting the Standard.

> As far as I know I have to force to not doing zero initialization something
> like that Foo* f = new Foo;

That has essentially the same initialization semantics as your example code.
>From gcc-bugs-return-463980-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Oct 13 20:48:24 2014
Return-Path: <gcc-bugs-return-463980-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4663 invoked by alias); 13 Oct 2014 20:48:24 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 4015 invoked by uid 48); 13 Oct 2014 20:48:17 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug driver/61106] [4.8/4.9] impliedness of -Wunused-parameter depends on -W option ordering
Date: Mon, 13 Oct 2014 20:48:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: driver
X-Bugzilla-Version: 4.8.3
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
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: 4.8.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61106-4-X3vdSHvKP1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61106-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61106-4@http.gcc.gnu.org/bugzilla/>
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-10/txt/msg01001.txt.bz2
Content-length: 340

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61106

--- Comment #22 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to lucier from comment #21)
> so I think it also affects -Wunused-result.

You can always retest the patches in the 4.8 and 4.9 branches and resubmit. And
ping until someone reviews it.
>From gcc-bugs-return-463981-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Oct 13 20:55:48 2014
Return-Path: <gcc-bugs-return-463981-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 11425 invoked by alias); 13 Oct 2014 20:55:48 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 11399 invoked by uid 48); 13 Oct 2014 20:55:44 -0000
From: "daniel.kruegler at googlemail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/63528] A variadic variable template cannot use the ::value of a variadic trait
Date: Mon, 13 Oct 2014 20:55: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: 5.0
X-Bugzilla-Keywords: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: daniel.kruegler at googlemail 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: cc
Message-ID: <bug-63528-4-vXb2OW7KA8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63528-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63528-4@http.gcc.gnu.org/bugzilla/>
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-10/txt/msg01002.txt.bz2
Content-length: 779

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63528

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler@googlemail.
                   |                            |com

--- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
Reduced example free of library stuff:

//------------------------
template<class...>
struct X
{
  constexpr static bool value = true;  
};

static_assert(X<int>::value, "");

template <class... Args>
constexpr bool X_v = X<Args...>::value;

static_assert(X_v<int>, "");
//------------------------
>From gcc-bugs-return-463982-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Oct 13 20:58:15 2014
Return-Path: <gcc-bugs-return-463982-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15121 invoked by alias); 13 Oct 2014 20:58:15 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 14368 invoked by uid 48); 13 Oct 2014 20:58:08 -0000
From: "russelldub at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/40958] module files too large
Date: Mon, 13 Oct 2014 20:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: russelldub at gmail dot com
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: attachments.created
Message-ID: <bug-40958-4-QKsLqxD2w6@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-40958-4@http.gcc.gnu.org/bugzilla/>
References: <bug-40958-4@http.gcc.gnu.org/bugzilla/>
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-10/txt/msg01003.txt.bz2
Content-length: 536

https://gcc.gnu.org/bugzilla/show_bug.cgi?id@958

--- Comment #18 from russelldub at gmail dot com ---
Created attachment 33703
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3703&actioníit
Proposed patch to fix module equivalence duplicates

Here is a proposed fix for the problem related to equivalence statements in
nested/recursive use (see also PR 60780).  I've run 'make check-fortran' on
rev. 216017 with and without this patch had a FAIL on
gfortran.dg/typebound_operator_3.f03 (as discussed in PR 63404) both ways.

[Bug c/16351] NULL dereference warnings

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #22 from Marc Glisse <glisse at gcc dot gnu.org> ---
There were some comments by Florian:
https://gcc.gnu.org/ml/gcc-patches/2014-02/msg00149.html

I don't think the patch was ever pinged during stage 1, worth another try...

[Bug c/16351] NULL dereference warnings

[tim.ruehsen at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

Tim Ruehsen <tim.ruehsen at gmx dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tim.ruehsen at gmx dot de

--- Comment #23 from Tim Ruehsen <tim.ruehsen at gmx dot de> ---
*PLEASE* put this on higher priority.

In 25 years of C development I saw thousands of crashes due to NULL pointer
dereferences. Many of them could have been avoided by simply printing a
warning.

You really save lifes ! And millions of working hours searching for obvious
bugs.

The requested warning is an absolutely must-have (enabled by default).
Seeing this bug open since 2004 is... well ... I have no words.

(Don't get me wrong: I make a deep kneefall for gcc and it's developers)

[Bug c/16351] NULL dereference warnings

[pmatos at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

pmatos at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pmatos at gcc dot gnu.org

--- Comment #25 from pmatos at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #24)
> I can give you many examples of old "must-have" bugs that are "easy" to fix,
> but simply there is no one with enough time and motivation to get them done.

It would be interesting to have that list. Or just those on the top of your
head. I might not necessarily look at them now but I know I will have some time
in the near future to work on a few of these, so it would be interesting to
have this list so I can look at them.

Thanks.
>From gcc-bugs-return-485520-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 05 13:48:28 2015
Return-Path: <gcc-bugs-return-485520-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 45101 invoked by alias); 5 May 2015 13:48:25 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 33384 invoked by uid 48); 5 May 2015 13:48:10 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/66011] [6 Regression] call to '__open_missing_mode' declared with attribute error
Date: Tue, 05 May 2015 13:48:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: redi at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on assigned_to target_milestone everconfirmed
Message-ID: <bug-66011-4-Hr2Kk0jxDo@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66011-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66011-4@http.gcc.gnu.org/bugzilla/>
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: 2015-05/txt/msg00360.txt.bz2
Content-length: 701

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf011

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2015-05-05
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
   Target Milestone|---                         |6.0
     Ever confirmed|0                           |1

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I'll fix this ASAP. In the meanwhile, you can configure with
--disable-libstdcxx-filesystem-ts

[Bug c/16351] NULL dereference warnings

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #26 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to pmatos from comment #25)
> (In reply to Manuel López-Ibáñez from comment #24)
> > I can give you many examples of old "must-have" bugs that are "easy" to fix,
> > but simply there is no one with enough time and motivation to get them done.
> 
> It would be interesting to have that list. Or just those on the top of your
> head. I might not necessarily look at them now but I know I will have some
> time in the near future to work on a few of these, so it would be
> interesting to have this list so I can look at them.

A good place to start is
https://gcc.gnu.org/bugzilla/buglist.cgi?keywords=easyhack&list_id=116934&order=bug_id&query_format=advanced

In particular, PR19808 should be fairly easy and there is some work already
done. It is also a prerequisite for PR2972. 

PR7652 has an initial patch.
PR23087 is very straightforward. 
PR17896 has a patch already.
PR99 is the oldest bug in my list and it is still a mystery. It needs proper
debugging to understand what goes wrong.

Of course, there are also quite a few very old bugs where the fix is not so
straight-forward but the impact would be very high: PR19430 (do the warning in
the FE?) and PR18501 (the most common Wuninitialized bug).
>From gcc-bugs-return-485522-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 05 14:17:21 2015
Return-Path: <gcc-bugs-return-485522-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 80544 invoked by alias); 5 May 2015 14:17:20 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 80355 invoked by uid 48); 5 May 2015 14:17:16 -0000
From: "pmatos at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/16351] NULL dereference warnings
Date: Tue, 05 May 2015 14:17: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: 4.0.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: pmatos at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: law at redhat dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-16351-4-zgTta3066N@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-16351-4@http.gcc.gnu.org/bugzilla/>
References: <bug-16351-4@http.gcc.gnu.org/bugzilla/>
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: 2015-05/txt/msg00362.txt.bz2
Content-length: 370

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #27 from pmatos at gcc dot gnu.org ---
(In reply to Manuel López-Ibáñez from comment #26)
> A good place to start is
> https://gcc.gnu.org/bugzilla/buglist.
> cgi?keywords=easyhack&list_id=116934&order=bug_id&query_format=advanced
> 

Thanks for the input. I will take a look.
>From gcc-bugs-return-485523-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 05 14:23:10 2015
Return-Path: <gcc-bugs-return-485523-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 90869 invoked by alias); 5 May 2015 14:23:10 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 90831 invoked by uid 55); 5 May 2015 14:23:06 -0000
From: "bergner at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/64579] __TM_end __builtin_tend failed to return transactional state
Date: Tue, 05 May 2015 14:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bergner at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: bergner at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64579-4-Cco2GezSHS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64579-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64579-4@http.gcc.gnu.org/bugzilla/>
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: 2015-05/txt/msg00363.txt.bz2
Content-length: 3547

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd579

--- Comment #3 from Peter Bergner <bergner at gcc dot gnu.org> ---
Author: bergner
Date: Tue May  5 14:22:33 2015
New Revision: 222807

URL: https://gcc.gnu.org/viewcvs?rev"2807&root=gcc&view=rev
Log:
gcc/

        Backport from mainline.
        2015-04-27  Peter Bergner  <bergner@vnet.ibm.com>

        PR target/64579
        * config/rs6000/htm.md: Remove all define_expands.
        (UNSPECV_HTM_TABORTDC, UNSPECV_HTM_TABORTDCI, UNSPECV_HTM_TABORTWC,
        UNSPECV_HTM_TABORTWCI): Remove.
        (UNSPECV_HTM_TABORTXC, UNSPECV_HTM_TABORTXCI, UNSPECV_HTM_TTEST): New.
        (tabort_internal, tbegin_internal, tcheck_internal, tend_internal,
        trechkpt_internal, treclaim_internal, tsr_internal): Rename from
this...
        (tabort, tbegin, tcheck, tend, trechkpt, treclaim, tsr): ...to this.
        (tabortdc_internal, tabortdci_internal, tabortwc_internal,
        tabortwci_internal): Remove define_insns.
        (tabort<wd>c, tabort<wd>ci): New define_insns.
        (tabort): Use gpc_reg_operand.
        (tcheck): Remove operand.
        (htm_mfspr_<mode>, htm_mtspr_<mode>): Use GPR mode macro.
        * config/rs6000/htmxlintrin.h (__TM_end): Use _HTM_TRANSACTIONAL as
        expected value.
        * config/rs6000/rs6000-builtin.def (BU_HTM_SPR0): Remove.
        (BU_HTM_SPR1): Rename to BU_HTM_V1.  Remove use of RS6000_BTC_SPR.
        (tabort, tabortdc, tabortdci, tabortwc, tabortwci, tbegin,
        tcheck, tend, tendall, trechkpt, treclaim, tresume, tsuspend,
        tsr, ttest): Pass in the RS6000_BTC_CR attribute.
        (get_tfhar, set_tfhar, get_tfiar, set_tfiar, get_texasr, set_texasr,
        get_texasru, set_texasru): Pass in the RS6000_BTC_SPR attribute.
        (tcheck): Remove builtin argument.
        * config/rs6000/rs6000.c (rs6000_htm_spr_icode): Use TARGET_POWERPC64
        not TARGET_64BIT.
        (htm_expand_builtin): Fix usage of expandedp.  Disallow usage of the
        tabortdc and tabortdci builtins when not in 64-bit mode.
        Modify code to handle the loss of the HTM define_expands.
        Emit code to copy the CR register to TARGET.
        (htm_init_builtins): Modify code to handle the loss of the HTM
        define_expands.
        * config/rs6000/rs6000.h (RS6000_BTC_32BIT): Delete.
        (RS6000_BTC_64BIT): Likewise.
        (RS6000_BTC_CR): New macro.
        * doc/extend.texi: Update documentation for htm builtins.

gcc/testsuite/

        Backport from mainline.
        2015-04-27  Peter Bergner  <bergner@vnet.ibm.com>

        PR target/64579
        * gcc.target/powerpc/htm-1.c: New test.
        * gcc.target/powerpc/htm-builtin-1.c (__builtin_tabortdc): Only test
        on 64-bit compiles.
        (__builtin_tabortdci): Likewise.
        (__builtin_tcheck): Remove operand.
        * lib/target-supports.exp (check_htm_hw_available): New function.

Added:
    branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/htm-1.c
Modified:
    branches/gcc-5-branch/gcc/ChangeLog
    branches/gcc-5-branch/gcc/config/rs6000/htm.md
    branches/gcc-5-branch/gcc/config/rs6000/htmxlintrin.h
    branches/gcc-5-branch/gcc/config/rs6000/rs6000-builtin.def
    branches/gcc-5-branch/gcc/config/rs6000/rs6000.c
    branches/gcc-5-branch/gcc/config/rs6000/rs6000.h
    branches/gcc-5-branch/gcc/doc/extend.texi
    branches/gcc-5-branch/gcc/testsuite/ChangeLog
    branches/gcc-5-branch/gcc/testsuite/gcc.target/powerpc/htm-builtin-1.c
    branches/gcc-5-branch/gcc/testsuite/lib/target-supports.exp

[Bug c/16351] NULL dereference warnings

[tim.ruehsen at gmx dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #28 from Tim Ruehsen <tim.ruehsen at gmx dot de> ---
I far as I can read, not a patch is missing. A review + commit is missing.
How can you ask for more developers (=patches) when the work is ignored ?
Don't get me wrong, I just try to understand how this should work.

[Bug c/16351] NULL dereference warnings

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #29 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Tim Ruehsen from comment #28)
> I far as I can read, not a patch is missing. A review + commit is missing.
> How can you ask for more developers (=patches) when the work is ignored ?
> Don't get me wrong, I just try to understand how this should work.

I'm actually not asking for more patches. As you can see, many of those PRs
already have patches. People send patches all the time. Sometimes very large
ones, and many times they never get committed, because they do not ping them,
or they do not address the reviewers' comments, or simply they get bored and
move to something else. 

What we need is people that are "patient and motivated" to get their code
committed to the upstream repository.

Unfortunately, getting reviews is hard because there are few developers and
they are busy, and new developers often fail to insist because they feel their
work is being ignored or they do not have time to follow-up and do the changes
asked by the reviewers. It is a vicious circle that I do not know how to solve.

As a volunteer, I know a patch of mine may take weeks/months to get reviewed. I
simply keep pinging (see https://gcc.gnu.org/wiki/Community for tips on how to
do this effectively). If I have free time, I work on something else; if not,
well, then it doesn't matter that it did not get reviewed yet. I am not in a
hurry. I don't have a deadline or a boss to present results. It is better that
it gets fixed in a year or two than never. 

For example, it took many years to get something as simple as coloured output
for diagnostics, but it finally happened. This was not because the core GCC
devs had a meeting and said "Oh, Clang is kicking our ass with their colors,
let's make this a priority". No, it took one volunteer insisting during many
months, revisions of patches and compromises. It did not actually take a lot of
coding time in total, but it was a process spread across many months.
>From gcc-bugs-return-485534-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 05 15:33:27 2015
Return-Path: <gcc-bugs-return-485534-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30854 invoked by alias); 5 May 2015 15:33:27 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 30798 invoked by uid 48); 5 May 2015 15:33:23 -0000
From: "thiago at kde dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic
Date: Tue, 05 May 2015 15:33:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.1.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: thiago at kde dot org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.2
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65886-4-FemLKtiM06@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65886-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65886-4@http.gcc.gnu.org/bugzilla/>
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: 2015-05/txt/msg00374.txt.bz2
Content-length: 1368

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide886

--- Comment #27 from Thiago Macieira <thiago at kde dot org> ---
(In reply to Jakub Jelinek from comment #26)
> Plus, if KDE uses so small binaries, why don't just compile them with -fPIC
> then?
> You can then link them as normal executables or PIEs, depending on what you
> prefer, and still it supposedly wouldn't use copy relocations, as all
> references to externals would be through .got.

Can you guarantee that the linker won't generate copy relocs for -fPIC?

Anyway, I know I am generalising from a sample of 1, but in my experience as a
desktop developer, the mass of library code is much bigger and more complex
than the application code. This is probably not true in large single-instance
applications -- for example, mysqld's text segment is of comparable size to the
total size of the libraries it uses.

Still, if this were solved properly, relocations that resolved back into the
executable itself would still be bound locally, even position-dependently if
that's how the binary were built. I am asking that it stop doing copy
relocations, which only applies to symbols the linker *did* detect came from
elsewhere.

I've also said I'll gladly tag each of those symbols with an __attribute__ so
that GCC also knows it comes from elsewhere and generate the proper indirect
load sequence via the GOT.

[Bug c/16351] NULL dereference warnings

[jg at jguk dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

Jon Grant <jg at jguk dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jg at jguk dot org

--- Comment #30 from Jon Grant <jg at jguk dot org> ---
Hello
I offer a bounty on getting this change incorporated into GCC.
150 USD. Email me at for a confirmation.

This is the kind of feature I would love to see in GCC :-)
Jon

[Bug c/16351] NULL dereference warnings

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #31 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Author: manu
Date: Wed Aug  5 17:36:29 2015
New Revision: 226640

URL: https://gcc.gnu.org/viewcvs?rev=226640&root=gcc&view=rev
Log:
gcc/ChangeLog:

2015-08-05  Manuel López-Ibáñez  <manu@gcc.gnu.org>
            Jeff Law  <law@redhat.com>

        PR c/16351
        * doc/invoke.texi (Wnull-dereference): New.
        * tree-vrp.c (infer_value_range): Update call to infer_nonnull_range.
        * gimple-ssa-isolate-paths.c (find_implicit_erroneous_behaviour):
        Warn for potential NULL dereferences.
        (find_explicit_erroneous_behaviour): Warn for NULL dereferences.
        * ubsan.c (instrument_nonnull_arg): Call
        infer_nonnull_range_by_attribute.
        (instrument_nonnull_return): Likewise.
        * common.opt (Wnull-dereference); New.
        * gimple.c (infer_nonnull_range): Remove bool arguments.
        (infer_nonnull_range_by_dereference): New.
        (infer_nonnull_range_by_attribute): New.
        * gimple.h: Update declarations.

gcc/testsuite/ChangeLog:

2015-08-05  Manuel López-Ibáñez  <manu@gcc.gnu.org>
            Jeff Law  <law@redhat.com>

        PR c/16351
        * gcc.dg/tree-ssa/isolate-2.c: Close comment.
        * gcc.dg/tree-ssa/isolate-4.c: Likewise.
        * gcc.dg/tree-ssa/wnull-dereference.c: New test.
        * gcc.dg/tree-ssa/isolate-1.c: Test warnings with -Wnull-dereference.
        * gcc.dg/tree-ssa/isolate-3.c: Likewise.
        * gcc.dg/tree-ssa/isolate-5.c: Likewise.



Added:
    trunk/gcc/testsuite/gcc.dg/tree-ssa/wnull-dereference.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/common.opt
    trunk/gcc/doc/invoke.texi
    trunk/gcc/gimple-ssa-isolate-paths.c
    trunk/gcc/gimple.c
    trunk/gcc/gimple.h
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.dg/tree-ssa/isolate-1.c
    trunk/gcc/testsuite/gcc.dg/tree-ssa/isolate-2.c
    trunk/gcc/testsuite/gcc.dg/tree-ssa/isolate-3.c
    trunk/gcc/testsuite/gcc.dg/tree-ssa/isolate-4.c
    trunk/gcc/testsuite/gcc.dg/tree-ssa/isolate-5.c
    trunk/gcc/tree-vrp.c
    trunk/gcc/ubsan.c
>From gcc-bugs-return-494202-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Aug 05 17:39:33 2015
Return-Path: <gcc-bugs-return-494202-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 126093 invoked by alias); 5 Aug 2015 17:39:32 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 126059 invoked by uid 48); 5 Aug 2015 17:39:29 -0000
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66619] Internal compiler error: variable template deduced by template argument deduction
Date: Wed, 05 Aug 2015 17:39: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: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jason at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jason at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc assigned_to everconfirmed
Message-ID: <bug-66619-4-aRxRbkCjc7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66619-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66619-4@http.gcc.gnu.org/bugzilla/>
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: 2015-08/txt/msg00344.txt.bz2
Content-length: 631

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf619

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2015-08-05
                 CC|                            |jason at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |jason at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Jason Merrill <jason at gcc dot gnu.org> ---
This

[Bug c/16351] NULL dereference warnings

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #32 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
The NULL dereference warnings originally requested should be working in GCC 6
(unless we find some issue and the patch gets reverted). However, the original
patch by Jeff also used the nonnull attribute to give even more warnings, thus
I'm leaving this open for now.
>From gcc-bugs-return-494206-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Aug 05 17:49:22 2015
Return-Path: <gcc-bugs-return-494206-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14847 invoked by alias); 5 Aug 2015 17:49:22 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 14818 invoked by uid 48); 5 Aug 2015 17:49:18 -0000
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/67041] [C++14] Variable template initialized by call to lambda does not compile
Date: Wed, 05 Aug 2015 17:49: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: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jason at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jason at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc assigned_to
Message-ID: <bug-67041-4-at8Q2ctcmZ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67041-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67041-4@http.gcc.gnu.org/bugzilla/>
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: 2015-08/txt/msg00348.txt.bz2
Content-length: 449

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg041

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |jason at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |jason at gcc dot gnu.org

[Bug c/16351] NULL dereference warnings

[manu at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 4061 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #34 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to David Binderman from comment #33)
> I found that using -g -O2 -Wall didn't enable this warning.
> Some of the documentation says it does.

Ops, you are right. I used the wrong EnabledBy() instead of LangEnabledBy(). I
see now that are other options suffering from the same problem. I'll produce a
patch.
>From gcc-bugs-return-494344-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 07 10:32:00 2015
Return-Path: <gcc-bugs-return-494344-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5823 invoked by alias); 7 Aug 2015 10:32:00 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 5799 invoked by uid 48); 7 Aug 2015 10:31:55 -0000
From: "afomin.mailbox at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/67145] New: [6 Regression] Innefective plus-minus simplification
Date: Fri, 07 Aug 2015 10:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: afomin.mailbox at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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 cc target_milestone cf_gcctarget attachments.created
Message-ID: <bug-67145-4@http.gcc.gnu.org/bugzilla/>
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: 2015-08/txt/msg00486.txt.bz2
Content-length: 1693

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg145

            Bug ID: 67145
           Summary: [6 Regression] Innefective plus-minus simplification
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: afomin.mailbox at gmail dot com
                CC: izamyatin at gmail dot com
  Target Milestone: ---
            Target: i686

Created attachment 36145
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id6145&actioníit
Reproducer

For the loop in the attached test compiled with -O3 -m32 -fPIE -pie after
r224768 we generate 20 insns because of additional copies (first seen at fwprop
pass)
mov    (%esp),%edi
mov    (%edi),%edx
mov    0x4(%esp),%edi
add    %esi,%edx
movzbl (%edx,%ebx,1),%edx
mov    %dl,(%ecx,%eax,1)
mov    (%edi),%edx
mov    0x8(%esp),%edi
add    %ebp,%edx
add    (%edi),%edx
mov    0xc(%esp),%edi
movzbl (%edx),%edx
mov    %dl,0x1(%ecx,%eax,1)
mov    %esi,%edx
add    (%edi),%edx
movzbl (%edx,%ebx,1),%edx
mov    %dl,0x2(%ecx,%eax,1)
add    $0x3,%eax
cmp    $0xfffffffd,%eax
jne    50 <foo+0x50>

while for r224767 we generate just 18 insns
mov    0x0(%ebp),%edx
mov    0x4(%esp),%esi
add    %ecx,%edx
movzbl (%edx),%edx
mov    %dl,(%ebx,%eax,1)
mov    %ecx,%edx
add    (%esi),%edx
add    (%edi),%edx
mov    (%esp),%esi
movzbl (%edx),%edx
mov    %dl,0x1(%ebx,%eax,1)
mov    (%esi),%edx
add    %ecx,%edx
movzbl (%edx),%edx
mov    %dl,0x2(%ebx,%eax,1)
add    $0x3,%eax
cmp    $0xfffffffd,%eax
jne    48 <foo+0x48>

Probably this simplification should be tuned for array indices.

[Bug c/16351] NULL dereference warnings

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #35 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #34)
> (In reply to David Binderman from comment #33)
> > I found that using -g -O2 -Wall didn't enable this warning.
> > Some of the documentation says it does.

Enabling this option with -Wall or -Wextra triggers errors in gcc bootstrap:

/home/manuel/test1/226719M/build/./prev-gcc/xg++
-B/home/manuel/test1/226719M/build/./prev-gcc/
-B/home/manuel/test1/./226719M/install/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/home/manuel/test1/226719M/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/home/manuel/test1/226719M/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/manuel/test1/226719M/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu

-I/home/manuel/test1/226719M/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
 -I/home/manuel/test1/src/libstdc++-v3/libsupc++
-L/home/manuel/test1/226719M/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/manuel/test1/226719M/build/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
 -I/home/manuel/test1/src/libcpp -I. -I/home/manuel/test1/src/libcpp/../include
-I/home/manuel/test1/src/libcpp/include  -g -O2 -gtoggle -W -Wall
-Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -pedantic
-Wno-long-long -Werror -fno-exceptions -fno-rtti
-I/home/manuel/test1/src/libcpp -I. -I/home/manuel/test1/src/libcpp/../include
-I/home/manuel/test1/src/libcpp/include   -c -o line-map.o -MT line-map.o -MMD
-MP -MF .deps/line-map.Tpo /home/manuel/test1/src/libcpp/line-map.c
-fdump-tree-isolate-paths-all-lineno
In file included from /home/manuel/test1/src/libcpp/line-map.c:24:0:
/home/manuel/test1/src/libcpp/include/line-map.h: In function ‘const line_map*
linemap_add(line_maps*, lc_reason, unsigned int, const char*, linenum_type)’:
/home/manuel/test1/src/libcpp/include/line-map.h:927:60: error: potential null
pointer dereference [-Werror=null-dereference]
    : LINEMAPS_ORDINARY_MAP_AT (set, ord_map->included_from));
                                                            ^
/home/manuel/test1/src/libcpp/line-map.c: In function ‘source_location
linemap_line_start(line_maps*, linenum_type, unsigned int)’:
/home/manuel/test1/src/libcpp/line-map.c:591:18: error: potential null pointer
dereference [-Werror=null-dereference]
     (linemap_add (set, LC_RENAME,
                  ^
cc1plus: error: potential null pointer dereference [-Werror=null-dereference]
/home/manuel/test1/src/libcpp/line-map.c:595:37: error: potential null pointer
dereference [-Werror=null-dereference]
       map->column_bits = column_bits;
                                     ^
cc1plus: all warnings being treated as errors


The reason is code like:

     map = linemap_check_ordinary
                (const_cast <line_map *>
                  (linemap_add (set, LC_RENAME,
                                ORDINARY_MAP_IN_SYSTEM_HEADER_P (map),
                                ORDINARY_MAP_FILE_NAME (map),
                                to_line)));
     map->column_bits = column_bits;

where linemap_check_ordinary is inlined as:

inline line_map_ordinary *
linemap_check_ordinary (struct line_map *map)
{
  linemap_assert (!map || map->reason != LC_ENTER_MACRO);
  return (line_map_ordinary *)map;
}

which means that there is a path through which a null pointer could be
potentially dereferenced. However, this actually cannot happen because
linemap_add will not return NULL in this case.

I fear this case might be quite common and lead to many false positives that
are then quite hard to understand due to the poor location info in the
middle-end.
>From gcc-bugs-return-494361-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 07 18:14:27 2015
Return-Path: <gcc-bugs-return-494361-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 76308 invoked by alias); 7 Aug 2015 18:14:27 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 76237 invoked by uid 48); 7 Aug 2015 18:14:24 -0000
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/16351] NULL dereference warnings
Date: Fri, 07 Aug 2015 18:14: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: 4.0.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: law at redhat dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: law at redhat dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-16351-4-1RdgPAdQVg@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-16351-4@http.gcc.gnu.org/bugzilla/>
References: <bug-16351-4@http.gcc.gnu.org/bugzilla/>
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: 2015-08/txt/msg00503.txt.bz2
Content-length: 610

https://gcc.gnu.org/bugzilla/show_bug.cgi?id\x16351

--- Comment #36 from Jeffrey A. Law <law at redhat dot com> ---
But those are *precisely* the ones that need deep investigation.  That
investigation may find a real bug, it may find a relatively simple missed
optimization, complex missed optimizations or poor APIs.

It's no different maybe uninitialized warnings.

Note that in this case, the compiler should be determining that MAP can't be
NULL and thus linemap_check_ordinary can't return NULL and propagating that
information.  So if we're still getting a warning, then something is wrong
somewhere.

[Bug c/16351] NULL dereference warnings

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #37 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #36)
> It's no different maybe uninitialized warnings.  

Well, one can silence uninitialized warnings by simply initializing the
variable. I don't see how this code can be refactored to silence the warning
(and the way I understood the warning is by looking at the GCC dumps, which
people will not do).

> Note that in this case, the compiler should be determining that MAP can't be
> NULL and thus linemap_check_ordinary can't return NULL and propagating that
> information.  So if we're still getting a warning, then something is wrong
> somewhere.

But how it can do such a thing if the definition of linemap_add were not
available?

(In this case it is, but GCC's IPA is not smart enough to figure it that it
cannot return NULL. The code injected by -f-isolate-paths survives until the
end).

In any case, I don't see how to keep this in -Wall or -Wextra if it breaks GCC
bootstrap. And options that are not enabled by either of those are rarely used
and tend to bit-rot or receive little attention.

Hum, perhaps, we do really need some kind of -Weverything that includes not
every warning, but those that are potentially useful but too noisy to not break
GCC bootstrap.
>From gcc-bugs-return-494363-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 07 18:43:27 2015
Return-Path: <gcc-bugs-return-494363-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12324 invoked by alias); 7 Aug 2015 18:43:27 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 12262 invoked by uid 48); 7 Aug 2015 18:43:23 -0000
From: "mikael at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/57839] Reallocate on assignment does not work properly
Date: Fri, 07 Aug 2015 18:43:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mikael at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
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_status cc resolution
Message-ID: <bug-57839-4-ZxZDWHgb9Z@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57839-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57839-4@http.gcc.gnu.org/bugzilla/>
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: 2015-08/txt/msg00505.txt.bz2
Content-length: 599

https://gcc.gnu.org/bugzilla/show_bug.cgi?idW839

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
                 CC|                            |mikael at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #4 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #3)
> This PR seems to be fixed for 4.9.0.

Indeed, closing.

[Bug c/16351] NULL dereference warnings

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #38 from David Binderman <dcb314 at hotmail dot com> ---
(In reply to Manuel López-Ibáñez from comment #35)
> I fear this case might be quite common and lead to many false positives that
> are then quite hard to understand due to the poor location info in the
> middle-end.

I tried out the new warning flag by compiling the current Linux kernel
and see something similar.

No definately NULL pointers found, which is good news, but also
about 60 messages about potentially NULL pointers.

I checked a few of the 60 and couldn't see anything wrong.
I didn't bother checking the rest.

Suggest don't bother emitting warnings about potentially NULL pointers
and keep the new code about definately NULL pointers.

It could even be the case that the "potential NULL" code gets
put into some backwater flag away from -Wall, and, after a suitable period
of more testing, the "definately NULL" code gets to go into
prime time of -Wall. 

Meanwhile, I'll be ignoring the warnings about potentially NULL.
>From gcc-bugs-return-494365-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 07 19:32:23 2015
Return-Path: <gcc-bugs-return-494365-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 89541 invoked by alias); 7 Aug 2015 19:32:23 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 89489 invoked by uid 48); 7 Aug 2015 19:32:19 -0000
From: "mikael at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/55603] [F03] Memory leak with scalar allocatable function result
Date: Fri, 07 Aug 2015 19:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mikael at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
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: cc
Message-ID: <bug-55603-4-XieoPN3UCr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55603-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55603-4@http.gcc.gnu.org/bugzilla/>
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: 2015-08/txt/msg00507.txt.bz2
Content-length: 422

https://gcc.gnu.org/bugzilla/show_bug.cgi?idU603

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #9 from Mikael Morin <mikael at gcc dot gnu.org> ---
It seems to work with current trunk.  FIXED?

[Bug c/16351] NULL dereference warnings

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #39 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to David Binderman from comment #38)
> It could even be the case that the "potential NULL" code gets
> put into some backwater flag away from -Wall, and, after a suitable period
> of more testing, the "definately NULL" code gets to go into
> prime time of -Wall. 

We could split the flag into -Wnull-dereference and -Wmaybe-null-dereference.
>From gcc-bugs-return-494367-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 07 20:15:20 2015
Return-Path: <gcc-bugs-return-494367-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 69208 invoked by alias); 7 Aug 2015 20:15:20 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 69183 invoked by uid 48); 7 Aug 2015 20:15:16 -0000
From: "eric.niebler at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/67148] New: [concepts] Failed concept check when indirecting through a constrained trait
Date: Fri, 07 Aug 2015 20:15: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: c++-concepts
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: eric.niebler at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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 target_milestone
Message-ID: <bug-67148-4@http.gcc.gnu.org/bugzilla/>
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: 2015-08/txt/msg00509.txt.bz2
Content-length: 3989

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg148

            Bug ID: 67148
           Summary: [concepts] Failed concept check when indirecting
                    through a constrained trait
           Product: gcc
           Version: c++-concepts
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eric.niebler at gmail dot com
  Target Milestone: ---

I've reduced this as much as I can. Test case below. The two static asserts are
testing the same thing, AFAICT. One tests the Function concept directly, the
other tests it indirectly through a __function trait that has been constrained
with Function. The former succeeds while the latter fails. Somewhat mysterious.

namespace std
{
  typedef unsigned int size_t;
  typedef int ptrdiff_t;
  typedef decltype(nullptr) nullptr_t;
  template<typename _Tp, _Tp... _Idx>
    struct integer_sequence
    {
      typedef _Tp value_type;
      static constexpr size_t size() { return sizeof...(_Idx); }
    };

  template <class T, T Value>
  struct integral_constant {
    using type = integral_constant;
    using value_type = T;
    constexpr operator T() const { return Value; }
    constexpr T operator()() const { return Value; }
    static constexpr T value {Value};
  };
  template <class T, T Value>
  constexpr T integral_constant<T, Value>::value;
  using true_type = integral_constant<bool, true>;
  using false_type = integral_constant<bool, false>;

  template <class T, class U>
  struct is_same : false_type {};
  template <class T>
  struct is_same<T,T> : true_type {};
}

namespace meta
{
    inline namespace v1
    {
        template <typename T>
        using _t = typename T::type;
        template <bool... Bools>
        using and_c = std::is_same<std::integer_sequence<bool, Bools...>,
                                   std::integer_sequence<bool, (Bools ||
true)...>>;
    }
}

namespace stl2 { inline namespace v1 {
using std::declval;
namespace detail {
template <class...>
struct all_same : std::true_type {};
template <class T, class...Rest>
struct all_same<T, Rest...> :
  meta::and_c<__is_same_as(T, Rest)...> {};
}
template <class...Ts>
concept bool Same() {
  return detail::all_same<Ts...>::value;
}
template <class F, class...Args>
using ResultType = decltype(declval<F>()(declval<Args>()...));
template <class>
struct value_type {};
template <class T>
struct value_type<T*> {
  using type = T;
};
template <class T>
using ValueType   typename value_type<T>::type;

template <class F, class...Args>
concept bool Function() {
  return requires (F& f, Args&&...args) {
    f((Args&&)args...);
    requires Same<decltype(f((Args&&)args...)), ResultType<F, Args...> >();
  };
}

template <class, class...> struct __function : std::false_type {};
Function{F, ...Args} struct __function<F, Args...> : std::true_type {};

template <class F, class I1, class I2>
concept bool IndirectCallable() {
  return Function<F, ValueType<I1>, ValueType<I2>>();
}

template <class F, class I1, class I2>
concept bool IndirectCallable2() {
  return __function<F, ValueType<I1>, ValueType<I2>>::value;
}

namespace ext { namespace models {
template <class, class, class>
constexpr bool indirect_callable() { return false; }
IndirectCallable{F, I1, I2}
constexpr bool indirect_callable() { return true; }

template <class, class, class>
constexpr bool indirect_callable2() { return false; }
IndirectCallable2{F, I1, I2}
constexpr bool indirect_callable2() { return true; }
}}
}}

namespace models = stl2::ext::models;

template <class T = void>
struct plus {
  T operator()(T, T) const;
};

static_assert((models::indirect_callable<::plus<int>, int*, int*>()), "Concept
check failed: " "models::indirect_callable<::plus<int>, int*, int*>()");
static_assert((models::indirect_callable2<::plus<int>, int*, int*>()), "Concept
check failed: " "models::indirect_callable2<::plus<int>, int*, int*>()");

[Bug c/16351] NULL dereference warnings

[jg at jguk dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #40 from Jon Grant <jg at jguk dot org> ---
(In reply to Manuel López-Ibáñez from comment #35)
<snip>
> which means that there is a path through which a null pointer could be
> potentially dereferenced. However, this actually cannot happen because
> linemap_add will not return NULL in this case.
> 
> I fear this case might be quite common and lead to many false positives that
> are then quite hard to understand due to the poor location info in the
> middle-end.

I am sure this is very common.. we use static analysis, and there will be many
potentially dereferences.. the thing is, the implementation of linemap_add may
be changed.. so those calling linemap_add should always check result is
non-NULL before using right? (then the calling code can handle gracefully)
>From gcc-bugs-return-494409-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Aug 08 13:58:49 2015
Return-Path: <gcc-bugs-return-494409-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 126055 invoked by alias); 8 Aug 2015 13:58:49 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 126024 invoked by uid 48); 8 Aug 2015 13:58:45 -0000
From: "dilyan.palauzov at aegee dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/67156] New: config/bootstrap-debug.mk: STAGE2_CFLAGS += -gtoggle
Date: Sat, 08 Aug 2015 13:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dilyan.palauzov at aegee dot org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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 target_milestone
Message-ID: <bug-67156-4@http.gcc.gnu.org/bugzilla/>
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: 2015-08/txt/msg00551.txt.bz2
Content-length: 1254

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg156

            Bug ID: 67156
           Summary: config/bootstrap-debug.mk: STAGE2_CFLAGS += -gtoggle
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dilyan.palauzov at aegee dot org
  Target Milestone: ---

config/bootstrap-debug.mk contains:
  STAGE2_CFLAGS += -gtoggle
and in turn stage2 is compiled with -gtoggle, while stage3 is compile without
-gtoggle. This can be seen by comparing stage{2,3}-gcc/Makefile .  After
finishing stage3, the build process compares the binaries from stage2 and
stage3, which differ, because they were compiled with/out -gtoggle.

Removing  -gtoggle from config/bootstrap-debug.mk:STAGE2_CFLAGS enables to
finish the compilation without errors (during the final comparison)

I compile gcc with

/git/gcc/configure --enable-host-shared --enable-threads=posix
--with-arch=haswell --enable-__cxa_atexit --enable-languages=c,c++,lto,jit
--enable-targets=all --enable-nls --with-linker-hash-style=gnu
--with-system-zlib --disable-multilib

and the gcc-git repository is at the newest state.

[Bug c/16351] NULL dereference warnings

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #41 from Jeffrey A. Law <law at redhat dot com> ---
Actually I think we want the concept of never returns NULL, both as an
attribute and as a property the compiler can discover by analysis.  Given that
property on the return value, it can be propagated into call sites.

[Bug c/16351] NULL dereference warnings

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #43 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Tim Ruehsen from comment #42)
> (In reply to Jeffrey A. Law from comment #41)
> > Actually I think we want the concept of never returns NULL, both as an
> > attribute and as a property the compiler can discover by analysis.  Given
> > that property on the return value, it can be propagated into call sites.
> 
> ++ That sounds like very useful feature.

We have returns_nonnull already.
>From gcc-bugs-return-494424-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Aug 08 17:50:09 2015
Return-Path: <gcc-bugs-return-494424-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 81088 invoked by alias); 8 Aug 2015 17:50:08 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 81057 invoked by uid 48); 8 Aug 2015 17:50:05 -0000
From: "fxcoudert at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libfortran/67140] undefined reference to _gfortran_mvbits_i16
Date: Sat, 08 Aug 2015 17:50:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libfortran
X-Bugzilla-Version: 4.8.4
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fxcoudert at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: kargl at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-67140-4-ZmDb9yZSBj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67140-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67140-4@http.gcc.gnu.org/bugzilla/>
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: 2015-08/txt/msg00566.txt.bz2
Content-length: 881

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg140

Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu.org

--- Comment #3 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
(In reply to kargl from comment #2)
> Patched built and tested with OP's code.
> Regression test passed.

Patch approved for trunk, with the following testcase (just double-check that
it passes!):

! { dg-do run }
!
! Check that MVBITS is available for the largest integer kind (PR 67140)
!
program test
  use iso_fortran_env
  integer, parameter :: k = integer_kinds(size(integer_kinds))

  integer(kind=k) :: i = 6
  call mvbits(7_k,2,2,i,0)
  if (i /= 5) call abort
end

[Bug c/16351] NULL dereference warnings

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #44 from Jeffrey A. Law <law at redhat dot com> ---
Duh, I should have remembered that we had returns_nonnull because I wrote a
dataflow pass to find any NULLs that flow to such statements :-)

The pieces that are missing are tagging functions with that attribute when we
can prove they never return NULL.  We'll be relying a lot of IPA to present
functions in the right order, but it'd be a good improvement.

[Bug c/16351] NULL dereference warnings

[manu at gcc dot gnu dot org]

------- Comment #9 from manu at gcc dot gnu dot org  2007-03-13 16:22 -------
*** Bug 30368 has been marked as a duplicate of this bug. ***


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lidaobing at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

[Bug other/16351] New: NULL dereference warnings

[phython at gcc dot gnu dot org]

It'd be really nice if gcc warned about NULL pointer dereferences.
e.g.
 if (foo == NULL && foo->bar)

See the attached test case for more examples.

-- 
           Summary: NULL dereference warnings
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: other
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: phython at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

[Bug c/16351] NULL dereference warnings

[bangerth at dealii dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|other                       |c


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

[Bug c/16351] NULL dereference warnings

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-07-03 20:16 -------
Confirmed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|                            |diagnostic
   Last reconfirmed|0000-00-00 00:00:00         |2004-07-03 20:16:54
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

[Bug c/16351] NULL dereference warnings

[phython at gcc dot gnu dot org]

------- Additional Comments From phython at gcc dot gnu dot org  2004-07-07 06:19 -------
better patch:
http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00423.html

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

[Bug c/16351] NULL dereference warnings

[phython at gcc dot gnu dot org]

------- Additional Comments From phython at gcc dot gnu dot org  2004-10-01 02:16 -------
 dnovillo reviewed this over irc and said it should be done in fold_stmt.  So
far, implementing this in fold_stmt has caused false positives.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|patch                       |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

[Bug c/16351] NULL dereference warnings

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-12-06 14:19 -------
*** Bug 18854 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |walles at mailblocks dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

[Bug c/16351] NULL dereference warnings

[walles at mailblocks dot com]

------- Additional Comments From walles at mailblocks dot com  2004-12-07 12:04 -------
Bug 18854 deals with *potential* NULL pointer dereferences, while this one
mentions only *confirmed* NULL pointer dereferences, i.e:

1 #include <stdlib.h>
2 int main(int argc, char *argv[]) {
3   volatile char *monkey = (char*)malloc(1234);
4   monkey[0] = '\0';
5   return 0;
6 }

Since malloc() on line 3 can *potentially* return NULL, I'd like a warning on
line 4. 

Phython, would you say potential NULL dereferences are within the scope of this
bug, or should bug 18854 be re-opened for those cases?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

[Bug c/16351] NULL dereference warnings

[phython at gcc dot gnu dot org]

------- Additional Comments From phython at gcc dot gnu dot org  2004-12-07 16:08 -------
 I'd probably leave them as the same bug for now.  Neither are being fixed for
4.0 so I don't think it's a problem having one bug.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351