[Bug c/61534] New: Wlogical-op should not warn when either operand comes from macro expansion

[Bug c/61534] New: Wlogical-op should not warn when either operand comes from macro expansion

[manu at gcc dot gnu.org]

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

            Bug ID: 61534
           Summary: Wlogical-op should not warn when either operand comes
                    from macro expansion
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: manu at gcc dot gnu.org

#define DEFINED (x != 0)

int foo(int x)
{
  if (!DEFINED && x != 0) return 0;
  return 1;
}

manuel@gcc10:~$ ~/test1/210581/build/gcc/cc1 -Wlogical-op test.c
 foo
test.c: In function ‘foo’:
test.c:5:16: warning: logical ‘and’ of mutually exclusive tests is always false
[-Wlogical-op]
   if (!DEFINED && x != 0) return 0;
                ^

Clang does not warn. This was the reason -Wlogical-op was moved out of -Wextra
(PR40172).
>From gcc-bugs-return-454370-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 17 10:33:59 2014
Return-Path: <gcc-bugs-return-454370-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25269 invoked by alias); 17 Jun 2014 10:33: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 25226 invoked by uid 48); 17 Jun 2014 10:33:55 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/60759] improve -Wlogical-op
Date: Tue, 17 Jun 2014 10:33: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.6.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
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: bug_status cf_reconfirmed_on short_desc everconfirmed
Message-ID: <bug-60759-4-dOycqSgqww@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60759-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60759-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-06/txt/msg01452.txt.bz2
Content-length: 1403

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-06-17
            Summary|-Wlogical-op should perhaps |improve -Wlogical-op
                   |warn about two-way implicit |
                   |conversions                 |
     Ever confirmed|0                           |1

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
GCC's -Wlogical-op warns for this:

pr60759.c:6:12: warning: logical ‘or’ applied to non-boolean constant
[-Wlogical-op]
   return y || 3;
            ^

However, GCC does not warn when both operands are constants or neither is a
constant. I think it is clear that it should warn for the former case. The
conditions at which it should warn are the same (it warns even if the result is
used in a boolean context).

The latter case is more controversial. Moreover, in this case the context is
significant:

int a = foo(1) || foo(2);  // warn
bool a = foo(1) || foo(2);  // do NOT warn

Someone would need to check how much code will be wrongly warned and how to
minimize the amount of false positives.
>From gcc-bugs-return-454371-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 17 10:34:05 2014
Return-Path: <gcc-bugs-return-454371-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25908 invoked by alias); 17 Jun 2014 10:34:05 -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 25547 invoked by uid 48); 17 Jun 2014 10:34:01 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/53131] -Wlogical-op: ready for prime time in -Wall ?
Date: Tue, 17 Jun 2014 10:34: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.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: minor
X-Bugzilla-Who: manu 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-53131-4-DKPVR8kU9e@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-53131-4@http.gcc.gnu.org/bugzilla/>
References: <bug-53131-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-06/txt/msg01453.txt.bz2
Content-length: 582

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

--- Comment #8 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #7)
> In fact, the main show-stopper for adding -Wlogical-op to -Wextra (or -Wall)
> is PR40172, which was the reason it was moved out of -Wextra in the first
> place. 

Since PR40172 was closed without fixing the real problem, I opened PR61534. As
far as I am aware, this is the only issue preventing -Wlogical-op to be moved
back to -Wextra. As always, patches welcome.
>From gcc-bugs-return-454372-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 17 10:55:05 2014
Return-Path: <gcc-bugs-return-454372-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9948 invoked by alias); 17 Jun 2014 10:55:04 -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 9448 invoked by uid 48); 17 Jun 2014 10:54:32 -0000
From: "Ulrich.Windl at rz dot uni-regensburg.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61531] Optimizer completely removes some bitset code
Date: Tue, 17 Jun 2014 10: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: 4.3.4
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: Ulrich.Windl at rz dot uni-regensburg.de
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:
Message-ID: <bug-61531-4-4i23ewHEU2@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61531-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61531-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-06/txt/msg01454.txt.bz2
Content-length: 511

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

--- Comment #6 from Ulrich Windl <Ulrich.Windl at rz dot uni-regensburg.de> ---
(In reply to Richard Biener from comment #5)
> > rpm -q gcc43-c++
> gcc43-c++-4.3.4_20091019-0.22.17
> > rpm -q --changelog gcc43-c++ | head
> * Thu Nov 10 2011 rguenther@suse.com
> - Fix altivec comparison builtins.  [bnc#729378]

Could be SUSE-specific: Although I have all updates for the product installed,
my version is older (Fri Jan 09 2009, as indicated in comment #1).

[Bug c/61534] Wlogical-op should not warn when either operand comes from macro expansion

[mpolacek at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-06-25
                 CC|                            |mpolacek at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
This should be easy with track macro expansion on, we'd just have

--- a/gcc/input.h
+++ b/gcc/input.h
@@ -60,6 +60,8 @@ extern location_t input_location;

 #define in_system_header_at(LOC) \
   ((linemap_location_in_system_header_p (line_table, LOC)))
+#define from_macro_expansion_at(LOC) \
+  ((linemap_location_from_macro_expansion_p (line_table, LOC)))

 void dump_line_table_statistics (void);

and then we could use from_macro_expansion_at and don't warn if it's true.  But
the problem is with -ftrack-macro-expansion=0, since from_macro_expansion_at
wouldn't work :(.

[Bug c/61534] Wlogical-op should not warn when either operand comes from macro expansion

[manu at gcc dot gnu.org]

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

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #1)
> and then we could use from_macro_expansion_at and don't warn if it's true. 
> But the problem is with -ftrack-macro-expansion=0, since
> from_macro_expansion_at wouldn't work :(.

I think warning in that case (returning false in the macro) is fair. One cannot
expect to turn off features and get the same quality. Is
ftrack-macro-expansion=0 used when bootstrapping gcc?
>From gcc-bugs-return-454938-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 25 18:16:47 2014
Return-Path: <gcc-bugs-return-454938-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14119 invoked by alias); 25 Jun 2014 18:16:46 -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 14072 invoked by uid 48); 25 Jun 2014 18:16:41 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/61601] C++11 regex resource exhaustion
Date: Wed, 25 Jun 2014 18:16: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: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi 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: cc
Message-ID: <bug-61601-4-iQu1jo253O@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61601-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61601-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-06/txt/msg02020.txt.bz2
Content-length: 452

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

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

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Tim, how hard would it be to hardcode limits somewhere for these cases?

[Bug c/61534] Wlogical-op should not warn when either operand comes from macro expansion

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I don't think so, -ftrack-macro-expansion=2 is on by default and I don't see
-ftrack-macro-expansion=0 anywhere in the log of bootstrap.  So maybe my
approach would be viable after all (and I could fix PR61081 the same way then).

[Bug c/61534] Wlogical-op should not warn when either operand comes from macro expansion

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

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
         Depends on|                            |43486

--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
If we take gcc/testsuite/gcc.dg/pr40172-3.c (which is XFAIL)

extern int xxx;
#define XXX xxx
int test (void)
{
  if (!XXX && xxx)
    return 4;
  else
    return 0;
}


The big hurdle is that !XXX becomes XXX == 0, but it has the location of "!",
which is not virtual. If we look at the argument of the expression, then XXX is
actually a var_decl, whose location corresponds to the declaration and not the
use, and it is not virtual either. This is PR43486.
>From gcc-bugs-return-465557-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Nov 02 08:01:50 2014
Return-Path: <gcc-bugs-return-465557-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19375 invoked by alias); 2 Nov 2014 08:01: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 19349 invoked by uid 48); 2 Nov 2014 08:01:44 -0000
From: "chengniansun at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/63710] New: Incorrect column number for -Wconversion
Date: Sun, 02 Nov 2014 08:01: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: chengniansun at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-63710-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-11/txt/msg00029.txt.bz2
Content-length: 2138

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

            Bug ID: 63710
           Summary: Incorrect column number for -Wconversion
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: chengniansun at gmail dot com

The column information can be improved by pinpointing the exact location where
the conversion happens. Taking the following code as an example, in the
expression "unsigned long r1 = ul + l", the variable "l" of type char is
promoted to "unsigned long", so IMHO the warning should point at this variable
instead of the operator '+'. 

============================================
=========       Test Case     ==============
============================================
$: cat s.c
unsigned long f1(unsigned long ul, char l) {
  unsigned long r1 = ul + l;
  unsigned long r2 = l + ul;
  return r1 + r2;
}
$: 
$: gcc-trunk -c -Wconversion s.c
s.c: In function ‘f1’:
s.c:2:25: warning: conversion to ‘long unsigned int’ from ‘char’ may change the
sign of the result [-Wsign-conversion]
   unsigned long r1 = ul + l;
                         ^
s.c:3:24: warning: conversion to ‘long unsigned int’ from ‘char’ may change the
sign of the result [-Wsign-conversion]
   unsigned long r2 = l + ul;
                        ^
$: 
$: clang-trunk -c -Wconversion s.c
s.c:2:27: warning: implicit conversion changes signedness: 'char' to
      'unsigned long' [-Wsign-conversion]
  unsigned long r1 = ul + l;
                        ~ ^
s.c:3:22: warning: implicit conversion changes signedness: 'char' to
      'unsigned long' [-Wsign-conversion]
  unsigned long r2 = l + ul;
                     ^ ~
2 warnings generated.
>From gcc-bugs-return-465558-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Nov 02 08:37:58 2014
Return-Path: <gcc-bugs-return-465558-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31672 invoked by alias); 2 Nov 2014 08:37:57 -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 31658 invoked by uid 48); 2 Nov 2014 08:37:54 -0000
From: "dushistov at mail dot ru" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/63711] New: can not compile llvm in debug mode
Date: Sun, 02 Nov 2014 08:37:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dushistov at mail dot ru
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-63711-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-11/txt/msg00030.txt.bz2
Content-length: 1061

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

            Bug ID: 63711
           Summary: can not compile llvm in debug mode
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dushistov at mail dot ru

Created attachment 33864
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3864&actioníit
failed test

In attachment source code extracted from llvm/lib/Analysis/LazyValueInfo.cpp
and from couple of headers.

It compiles find with
g++ -Wall -std=c++11 test.cpp

but failed with
g++ -Wall -std=c++11 -D_GLIBCXX_DEBUG test.cpp

It print
/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.1/include/g++-v4/debug/functions.h:220:61:
error: invalid initialization of non-const reference of type 'BasicBlock*&'
from an rvalue of type 'SuccIterator<TerminatorInst*, BasicBlock>::reference
{aka BasicBlock*}'
       return __foreign_iterator_aux4(__it, std::__addressof(*__other));

[Bug c/61534] Wlogical-op should not warn when either operand comes from macro expansion

[mpolacek at gcc dot gnu.org]

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

--- Comment #7 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Author: mpolacek
Date: Fri Apr 24 11:49:52 2015
New Revision: 222406

URL: https://gcc.gnu.org/viewcvs?rev=222406&root=gcc&view=rev
Log:
    PR c/61534
    * input.h (from_macro_expansion_at): Define.

    * c-common.c (warn_logical_operator): Bail if either operand comes
    from a macro expansion.

    * c-c++-common/pr61534-1.c: New test.

Added:
    trunk/gcc/testsuite/c-c++-common/pr61534-1.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/c-family/ChangeLog
    trunk/gcc/c-family/c-common.c
    trunk/gcc/input.h
    trunk/gcc/testsuite/ChangeLog

[Bug c/61534] Wlogical-op should not warn when either operand comes from macro expansion

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61534
Bug 61534 depends on bug 43486, which changed state.

Bug 43486 Summary: Preserve variable-use locations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486

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