[Bug c++/60517] New: warning/error for taking address of member of a temporary object

[Bug c++/60517] New: warning/error for taking address of member of a temporary object

[manu at gcc dot gnu.org]

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

            Bug ID: 60517
           Summary: warning/error for taking address of member of a
                    temporary object
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: manu at gcc dot gnu.org

class B {
public:
    double x[2];
};
class A {
    B b;
public:
    B getB(void) { return b; }
};

double foo(A a) {
    double * x = &(a.getB().x[0]);
    return x[0];
}

In the code above, x is not pointing to anything useful. I am not sure how hard
would be to diagnose this, but it would be nice if it was possible. It would
have saved me a few hours of bug-hunting today.

[Bug c++/60517] warning/error for taking address of member of a temporary object

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
I see in the dump:

  # .MEM_4 = VDEF <.MEM_8>
  D.2272 ={v} {CLOBBER};
  # VUSE <.MEM_4>
  _5 = MEM[(doubleD.39 *)&D.2272];

which looks like something we could warn about in the middle-end.

[Bug c++/60517] warning/error for taking address of member of a temporary object

[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: 2662 bytes --]

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

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #1)
> I see in the dump:
> 
>   # .MEM_4 = VDEF <.MEM_8>
>   D.2272 ={v} {CLOBBER};
>   # VUSE <.MEM_4>
>   _5 = MEM[(doubleD.39 *)&D.2272];
> 
> which looks like something we could warn about in the middle-end.

Could you elaborate? My middle-end foo is not as good as it used to be.
>From gcc-bugs-return-446252-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 14 04:55:53 2014
Return-Path: <gcc-bugs-return-446252-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24554 invoked by alias); 14 Mar 2014 04:55:52 -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 24486 invoked by uid 48); 14 Mar 2014 04:55:41 -0000
From: "jvdelisle at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/58324] Bogus END-of-line error with list-directed I/O of file without trailing sequential record marker
Date: Fri, 14 Mar 2014 04:55: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.7.3
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jvdelisle at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jvdelisle at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-58324-4-JEUWkNzepi@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58324-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58324-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-03/txt/msg01121.txt.bz2
Content-length: 351

http://gcc.gnu.org/bugzilla/show_bug.cgi?idX324

--- Comment #4 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Created attachment 32346
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id2346&actioníit
A proposed patch

The attached patch regression tests OK on x86-64-linux-gnu.  Fixes the original
test case and the reduced test case.

[Bug c++/60517] warning/error for taking address of member of a temporary object

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #2)
> (In reply to Marc Glisse from comment #1)
> > I see in the dump:
> > 
> >   # .MEM_4 = VDEF <.MEM_8>
> >   D.2272 ={v} {CLOBBER};
> >   # VUSE <.MEM_4>
> >   _5 = MEM[(doubleD.39 *)&D.2272];
> > 
> > which looks like something we could warn about in the middle-end.
> 
> Could you elaborate? My middle-end foo is not as good as it used to be.

_5 = MEM[(doubleD.39 *)&D.2272];
says we are reading something inside variable D.2272. And right in the previous
instruction:
D.2272 ={v} {CLOBBER};
we clobbered the content of that variable, so what we are reading is nonsense.
These clobbers are specifically added to indicate when variables die (like your
temporary).
And we don't need to rely on the clobber being exactly the previous
instruction. The state of the memory (VUSE) when we execute the last
instruction was defined (VDEF) by the clobber instruction, typically
walk_aliased_vdefs would help you find the last instructions that touched
something related to the variable (get_ref_base_and_extent to get the variable
maybe?), the visitor would always stop, recording if the instruction was a
clobber, and you would check if all branches (or one branch for a -Wmaybe- type
of warning?) stopped on a clobber. Some passes may record enough information to
make the walk unnecessary, but I am not sure. And you may want to record
objects you have already warned about, to avoid flooding if a dead variable is
used a lot.

Now that I am describing it, there may already be code that does the same thing
for use-after-free or other cases?

Anyway, a hard part would be deciding in which pass to warn. And turning this
vague description (assuming it makes at least a bit of sense) into something
that actually works. And finding a right compromise between false positives and
false negatives. The usual...
>From gcc-bugs-return-446257-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 14 07:23:55 2014
Return-Path: <gcc-bugs-return-446257-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18283 invoked by alias); 14 Mar 2014 07:23:55 -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 18247 invoked by uid 48); 14 Mar 2014 07:23:51 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/60492] Using the L#param in a macro fails
Date: Fri, 14 Mar 2014 07:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub 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: cc
Message-ID: <bug-60492-4-72VdLvgjfF@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60492-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60492-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-03/txt/msg01126.txt.bz2
Content-length: 684

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`492

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
E.g. in ISO C99, 6.10.3.2, you can read that #s is replaced by a single
preprocessing token, but the mere fect that L immediately precedes it doesn't
make it a part of the same preprocessing token.  For wide character literals,
the L needs to be part of the same preprocessing token as the "string" after
it.

[Bug c++/60517] warning/error for taking address of member of a temporary object

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #3)
> (In reply to Manuel López-Ibáñez from comment #2)
> > (In reply to Marc Glisse from comment #1)
> > > I see in the dump:
> > > 
> > >   # .MEM_4 = VDEF <.MEM_8>
> > >   D.2272 ={v} {CLOBBER};
> > >   # VUSE <.MEM_4>
> > >   _5 = MEM[(doubleD.39 *)&D.2272];
> > > 
> > > which looks like something we could warn about in the middle-end.
> > 
> > Could you elaborate? My middle-end foo is not as good as it used to be.
> 
> _5 = MEM[(doubleD.39 *)&D.2272];
> says we are reading something inside variable D.2272. And right in the
> previous instruction:
> D.2272 ={v} {CLOBBER};
> we clobbered the content of that variable, so what we are reading is
> nonsense. These clobbers are specifically added to indicate when variables
> die (like your temporary).

Where is the clobber added? The closer to the FE that we warn, the better
diagnostic we can generate. I'm not very concerned about maybe-branches, since 
I expect most bugs to appear in temporaries created in the middle of
expressions (such as a.getB().getA().x), where no branching occurs.
>From gcc-bugs-return-446279-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 14 10:45:13 2014
Return-Path: <gcc-bugs-return-446279-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 28092 invoked by alias); 14 Mar 2014 10:45:13 -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 28046 invoked by uid 48); 14 Mar 2014 10:45:10 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/60523] Warning flag for octal literals
Date: Fri, 14 Mar 2014 10:45: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: enhancement
X-Bugzilla-Who: mpolacek 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: cc
Message-ID: <bug-60523-4-w7hyzYyDri@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60523-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60523-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-03/txt/msg01148.txt.bz2
Content-length: 536

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`523

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

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

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I agree with Andrew - if we are ever to implement -Woctal, making it a part of
-Wextra doesn't sound sensible.  Especially with -Werror it'd be a pain.

[Bug c++/60517] warning/error for taking address of member of a temporary object

[glisse at gcc dot gnu.org]

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

--- Comment #5 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #4)
> Where is the clobber added?

front-end, I expect (sorry, I'm trying to get something to work on windows and
don't have my usual sources at hand).

> The closer to the FE that we warn, the better
> diagnostic we can generate.

Then do it in the front-end and ignore my message ;-)

> I'm not very concerned about maybe-branches, since 
> I expect most bugs to appear in temporaries created in the middle of
> expressions (such as a.getB().getA().x), where no branching occurs.

An exemple I have in mind is (pseudo):
ref id(ref x){return x;}
ref fun(){return id(temporary);}
where the function call hides that we are returning a reference to a temporary
(id could return a reference to a global object, for all fun knows) and we know
more after inlining (I need id inlined into fun, and either fun inlined into
something that uses its returned ref (so my previous technique works) or I
would need a different (middle-end) warning that detects return &local_var,
which seems even easier except that it would give a lot of duplicates with
front-end warnings).
>From gcc-bugs-return-446286-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 14 12:24:40 2014
Return-Path: <gcc-bugs-return-446286-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 32588 invoked by alias); 14 Mar 2014 12:24:39 -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 32568 invoked by uid 48); 14 Mar 2014 12:24:36 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/60484] [4.7/4.8/4.9 Regression] -fdump-rtl-expand and attribute optimize gives incorrect dump file path
Date: Fri, 14 Mar 2014 12:24: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.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek 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: bug_status cf_reconfirmed_on cc short_desc everconfirmed
Message-ID: <bug-60484-4-qB4Mvb1oaS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60484-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60484-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-03/txt/msg01155.txt.bz2
Content-length: 868

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`484

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-03-14
                 CC|                            |mpolacek at gcc dot gnu.org
            Summary|-fdump-rtl-expand and       |[4.7/4.8/4.9 Regression]
                   |attribute optimize gives    |-fdump-rtl-expand and
                   |incorrect dump file path    |attribute optimize gives
                   |                            |incorrect dump file path
     Ever confirmed|0                           |1

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Confirmed.  GCC 4.4 works.

[Bug c++/60517] warning/error for taking address of member of a temporary object

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #5)
> I would need a different (middle-end) warning that
> detects return &local_var,

To confirm this, I looked at the last dangling reference I debugged, recompiled
it with -O3 -fkeep-inline-functions, and a grep for "return &" in the
.optimized dump showed:
  return &one;
  return &one;
  return &D.495451.c_;
(where "one" is a global variable, but D.495451 is a local variable)
so even this trivial version of the warning would be useful.

[Bug c++/60517] warning/error for taking address of member of a temporary object

[manu at gcc dot gnu.org]

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

--- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Marc Glisse from comment #6)
> (In reply to Marc Glisse from comment #5)
> > I would need a different (middle-end) warning that
> > detects return &local_var,
> 
> To confirm this, I looked at the last dangling reference I debugged,
> recompiled it with -O3 -fkeep-inline-functions, and a grep for "return &" in
> the .optimized dump showed:
>   return &one;
>   return &one;
>   return &D.495451.c_;
> (where "one" is a global variable, but D.495451 is a local variable)
> so even this trivial version of the warning would be useful.

To avoid duplicates, the front-end could just return something else, like NULL,
when it detects this case (I guess the behavior is undefined and we can do
whatever we want, no?).
>From gcc-bugs-return-446309-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 14 16:59:23 2014
Return-Path: <gcc-bugs-return-446309-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25017 invoked by alias); 14 Mar 2014 16:59: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 24969 invoked by uid 48); 14 Mar 2014 16:59:20 -0000
From: "sje at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/60528] New: MIPS GCC puts out complex constant incorrectly when in big-endian mode
Date: Fri, 14 Mar 2014 16:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: sje 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc cf_gcctarget
Message-ID: <bug-60528-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-03/txt/msg01178.txt.bz2
Content-length: 1510

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`528

            Bug ID: 60528
           Summary: MIPS GCC puts out complex constant incorrectly when in
                    big-endian mode
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sje at gcc dot gnu.org
                CC: rsandifo at gcc dot gnu.org
            Target: mips-*-*

The included test program prints out:

x = 0.634964 1.298458
x = inf inf

on MIPS instead of:

x = 0.634964 1.298458
x = 0.182506 1.163916

To reproduce the problem you need to compile the program with no optimization
(-O0) and in big-endian mode.  Little endian mode seems fine.  When I compare
the assembly language output to an earlier 4.8.1 GCC, the latest GCC output
contains the following code to store the complex constant passed in to csinh:

$LC0:
    .word    1071927711
    .word    3624173458
    .word    1073006203
    .word    1962331215

Earlier GCC compilers that worked contained:

$LC0:
    .word    1071927711
    .word    -670793838
    .word    1073006203
    .word    1962331215


Test case:

#include <stdio.h>
#include <complex.h>
#include <math.h>

int main()
{
    double complex x;
    x = 0.63496391478473613 + 1.2984575814159773I;
    printf("x = %f %f\n", creal(x), cimag(x));
    x = csinh(x);
    printf("x = %f %f\n", creal(x), cimag(x));
    return 0;
}

[Bug c++/60517] warning/error for taking address of member of a temporary object

[glisse at gcc dot gnu.org]

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

--- Comment #8 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #7)
> To avoid duplicates, the front-end could just return something else, like
> NULL, when it detects this case (I guess the behavior is undefined and we
> can do whatever we want, no?).

I guess... Then we might as well introduce a call to __builtin_unreachable
right before the return, at the same time as we replace the return value.
>From gcc-bugs-return-446313-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 14 17:32:47 2014
Return-Path: <gcc-bugs-return-446313-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21898 invoked by alias); 14 Mar 2014 17:32:47 -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 21863 invoked by uid 55); 14 Mar 2014 17:32:44 -0000
From: "joseph at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/60523] Warning flag for octal literals
Date: Fri, 14 Mar 2014 17:32: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: enhancement
X-Bugzilla-Who: joseph at codesourcery 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:
Message-ID: <bug-60523-4-AzHLsp5JWS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60523-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60523-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-03/txt/msg01182.txt.bz2
Content-length: 544

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`523

--- Comment #6 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
Octal literals are also used in macro definitions from system headers, so
care would be needed that a warning doesn't apply to those.

Such a warning should of course not apply to 0 (and maybe more generally
should not apply to any octal constant consisting of some number of
leading 0s followed by at most one nonzero digit, as those have the same
value whether interpreted as octal or as decimal).

[Bug c++/60517] warning/error for taking address of member of a temporary object

[glisse at gcc dot gnu.org]

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

Marc Glisse <glisse at gcc dot gnu.org> changed:

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

--- Comment #9 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #7)
> To avoid duplicates, the front-end could just return something else, like
> NULL, when it detects this case (I guess the behavior is undefined and we
> can do whatever we want, no?).

Actually, for a function that returns a reference, we may also want to warn if
we detect that it is returning NULL. And a function returning a pointer could
be marked returns_nonnull. In both cases we would be introducing a new warning,
more confusing than a duplicate. But there are probably small variations on
this idea that would work.
>From gcc-bugs-return-446318-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 14 18:04:43 2014
Return-Path: <gcc-bugs-return-446318-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 32714 invoked by alias); 14 Mar 2014 18:04:43 -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 32657 invoked by uid 48); 14 Mar 2014 18:04:39 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/60484] [4.7/4.8/4.9 Regression] -fdump-rtl-expand and attribute optimize gives incorrect dump file path
Date: Fri, 14 Mar 2014 18:04:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: mpolacek at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-60484-4-avWERhbjlU@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60484-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60484-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-03/txt/msg01187.txt.bz2
Content-length: 427

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`484

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

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

--- Comment #7 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Fixed.

[Bug c++/60517] warning/error for taking address of member of a temporary object

[glisse at gcc dot gnu.org]

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

--- Comment #10 from Marc Glisse <glisse at gcc dot gnu.org> ---
Created attachment 32549
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32549&action=edit
first try

With -O -fdisable-tree-esra (see PR 60770), it warns on the testcase. Twice
because the DSE pass is run twice.

The commented out code was supposed to remove the clobber, but it crashes in
unlink_stmt_vdef (probably because I am exiting FOR_EACH_IMM_USE_STMT too
violently) so I removed it for now.

[Bug c++/60517] warning/error for taking address of member of a temporary object

[glisse at gcc dot gnu.org]

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

Marc Glisse <glisse at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #32549|0                           |1
        is obsolete|                            |

--- Comment #11 from Marc Glisse <glisse at gcc dot gnu.org> ---
Created attachment 32551
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32551&action=edit
first try

With clobber removal now.

It isn't so great, the statements before the clobber have already been removed
as dead code, so by removing the clobber we produce an uninitialized read for
which we get a warning later.

[Bug c++/60517] warning/error for taking address of member of a temporary object

[glisse at gcc dot gnu.org]

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

--- Comment #13 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #12)
> Why do you want to remove the clobber? 

I am in the DSE pass, so removing the clobber as a dead store is the easiest
thing to do ;-)

Ok, it might not be such a good idea.

> I understood your idea to avoid duplicated warnings was to add
> __builtin_unreachable and replace the value.

adding __builtin_unreachable seems doable. I am not sure what to replace the
value with though, as the variable could have any type.

Note that I also posted:
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html
(hmm, OPT_Wreturn_local_addr is a C/C++ FE flag, I should move it or pick a
different one)
where I do replace the pointer by zero as you suggested. I am not adding
__builtin_unreachable, because if nothing uses the return value, I am not sure
it would be right to break the code.

> Could be possible to have a special var/value that is marked as artificial
> such that the warning code never warns for statements containing this
> variable? We already have DECL_ARTIFICIAL in the FE but I am not sure
> whether that survives to the middle-end.

There is probably some unused bit somewhere...
>From gcc-bugs-return-448396-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Apr 06 10:38:59 2014
Return-Path: <gcc-bugs-return-448396-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18081 invoked by alias); 6 Apr 2014 10:38:58 -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 18034 invoked by uid 55); 6 Apr 2014 10:38:54 -0000
From: "dominiq at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/54083] FAIL: gcc.dg/torture/pr53922.c on *-apple-darwin*
Date: Sun, 06 Apr 2014 10:38: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.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq 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: <bug-54083-4-QRiv0wohFR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-54083-4@http.gcc.gnu.org/bugzilla/>
References: <bug-54083-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-04/txt/msg00416.txt.bz2
Content-length: 792

http://gcc.gnu.org/bugzilla/show_bug.cgi?idT083

--- Comment #24 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Sun Apr  6 10:38:16 2014
New Revision: 209161

URL: http://gcc.gnu.org/viewcvs?rev 9161&root=gcc&view=rev
Log:
2014-04-06  Dominique d'Humieres  <dominiq@lps.ens.fr>
        Iain Sandoe <iain@codesourcery.com>

    PR target/54083
    * gcc.dg/attr-weakref-1.c: Allow the test on darwin with
    the additional options -Wl,-undefined,dynamic_lookup and
    -Wl,-flat_namespace
    * gcc.dg/torture/pr53922.c: Additional option
    -Wl,-flat_namespace for darwin[89].


Modified:
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/attr-weakref-1.c
    branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr53922.c

[Bug c++/60517] warning/error for taking address of member of a temporary object

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lisp2d at lisp2d dot net

--- Comment #14 from Paolo Carlini <paolo.carlini at oracle dot com> ---
*** Bug 61528 has been marked as a duplicate of this bug. ***

[Bug c++/60517] warning/error for taking address of member of a temporary object

[glisse at gcc dot gnu.org]

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

--- Comment #15 from Marc Glisse <glisse at gcc dot gnu.org> ---
Author: glisse
Date: Thu Jul 31 09:33:58 2014
New Revision: 213323

URL: https://gcc.gnu.org/viewcvs?rev=213323&root=gcc&view=rev
Log:
2014-07-31  Marc Glisse  <marc.glisse@inria.fr>

    PR c++/60517
gcc/c/
    * c-typeck.c (c_finish_return): Return 0 instead of the address of
    a local variable.
gcc/cp/
    * typeck.c (maybe_warn_about_returning_address_of_local): Return
    whether it is returning the address of a local variable.
    (check_return_expr): Return 0 instead of the address of a local
    variable.
gcc/c-family/
    * c.opt (-Wreturn-local-addr): Move to common.opt.
gcc/
    * common.opt (-Wreturn-local-addr): Moved from c.opt.
    * gimple-ssa-isolate-paths.c: Include diagnostic-core.h and intl.h.
    (isolate_path): New argument to avoid inserting a trap.
    (find_implicit_erroneous_behaviour): Handle returning the address
    of a local variable.
    (find_explicit_erroneous_behaviour): Likewise.
gcc/testsuite/
    * c-c++-common/addrtmp.c: New file.
    * c-c++-common/uninit-G.c: Adapt.

Added:
    trunk/gcc/testsuite/c-c++-common/addrtmp.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c.opt
    trunk/gcc/c/ChangeLog
    trunk/gcc/c/c-typeck.c
    trunk/gcc/common.opt
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/typeck.c
    trunk/gcc/gimple-ssa-isolate-paths.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/c-c++-common/uninit-G.c

[Bug c++/60517] warning/error for taking address of member of a temporary object

[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: 3767 bytes --]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-08-22
     Ever confirmed|0                           |1

--- Comment #16 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Note that we still do not warn for my original testcase.
>From gcc-bugs-return-459044-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 22 13:20:37 2014
Return-Path: <gcc-bugs-return-459044-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7197 invoked by alias); 22 Aug 2014 13:20:36 -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 7182 invoked by uid 48); 22 Aug 2014 13:20:33 -0000
From: "demoonlit at panathenaia dot halfmoon.jp" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ada/62230] New: Legal program rejected, RM 4.3.2(3, 5/3), ancestor_part can not be expression against error message by compiler itself
Date: Fri, 22 Aug 2014 13:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ada
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: demoonlit at panathenaia dot halfmoon.jp
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: <bug-62230-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-08/txt/msg01541.txt.bz2
Content-length: 1324

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

            Bug ID: 62230
           Summary: Legal program rejected, RM 4.3.2(3, 5/3),
                    ancestor_part can not be expression against error
                    message by compiler itself
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ada
          Assignee: unassigned at gcc dot gnu.org
          Reporter: demoonlit at panathenaia dot halfmoon.jp

Created attachment 33380
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3380&actioníit
minimal bug triggering source code

GNAT rejects any expressions implying aggregate for ancestor_part.

For example: (Please see the attachment file, also)
   type T1 is limited new Ada.Finalization.Limited_Controlled with null record;
   type T2 is new T1 with null record;
   X : T2 := (T1 with null record); -- OK
   Z : T2 := (T1'(Ada.Finalization.Limited_Controlled with null record) with
null record); -- ERROR

GNAT outputs:
    main.adb:23:09: limited ancestor part must be aggregate or function call

It seems for me that aggregate expression is allowed into ancestor_part
according to the error message outputted by GNAT itself. But, it is not.

And, RM 4.3.2(3, 5/3) allows it explicitly.

[Bug c++/60517] warning/error for taking address of member of a temporary object

[glisse at gcc dot gnu.org]

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

--- Comment #17 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #16)
> Note that we still do not warn for my original testcase.

I didn't close the PR ;-)

There are patches around that may need more work, see these discussions (I
picked a random message for the link):
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00376.html
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00422.html

(apparently the patches do manage to warn on your original testcase, at least I
said so in one of the emails)
>From gcc-bugs-return-459046-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Aug 22 13:28:32 2014
Return-Path: <gcc-bugs-return-459046-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13720 invoked by alias); 22 Aug 2014 13:28:31 -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 13334 invoked by uid 48); 22 Aug 2014 13:28:26 -0000
From: "steven at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/62049] Negative count_rate when calling system_clock
Date: Fri, 22 Aug 2014 13:28: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: steven at gcc dot gnu.org
X-Bugzilla-Status: WAITING
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 cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-62049-4-mskI8laV99@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62049-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62049-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-08/txt/msg01543.txt.bz2
Content-length: 1167

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

Steven Bosscher <steven at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2014-08-22
                 CC|                            |steven at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Steven Bosscher <steven at gcc dot gnu.org> ---
(In reply to Paul Martin from comment #0)

Looks like a bug, yes. The intrinsic subroutine appears to be resolved
to _gfortran_system_clock_8.  That should be _gfortran_system_clock_4
if your "crate" variable is integer(kind=4).

Can you please compile the following and report back the output here?

----- 8< ----- (t.f90)
PROGRAM clock
   IMPLICIT NONE
   INTEGER(kind=4) :: crate4
   INTEGER(kind=8) :: crate8
   CALL system_clock (count_rate = crate4)
   WRITE(*,*) crate4
   CALL system_clock (count_rate = crate8)
   WRITE(*,*) crate8
END PROGRAM clock
----- 8< -----

$ gfortran -Wall t.f90 -fdump-parse-tree

[Bug c++/60517] warning/error for taking address of member of a temporary object

[glisse at gcc dot gnu.org]

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

--- Comment #18 from Marc Glisse <glisse at gcc dot gnu.org> ---
The .uninit dump for the original testcase now looks like:

double foo(A) (struct A a)
{
  double SR.1;

  <bb 2>:
  return SR.1_2(D);

}

which the uninit pass would warn about, except that SR.1 is marked
TREE_NO_WARNING (possibly since the temporary created by the front-end). If
someone wants to look into that...