[Bug c++/64332] New: gcc/g++ handles system_header differently

[Bug c++/64332] New: gcc/g++ handles system_header differently

[a3at.mail at gmail dot com]

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

            Bug ID: 64332
           Summary: gcc/g++ handles system_header differently
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: a3at.mail at gmail dot com

Created attachment 34292
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34292&action=edit
warning-constructor-attribute-ignored.tgz

Digging through one or compilation errors, after doing this:
#define __constructor __attribute__((constructor))

I turned out that gcc/g++ have different behaviours for system_header pragma.

Here is a simple example (also archived in attach):
$ head *.[ch]
==> c.h <==
#define __constructor __attribute__((constructor))

==> c-impl.h <==
#pragma GCC system_header

typedef void (*__cb_type)(void *);
int foo(__cb_type __constructor);

==> main.c <==
#include "c.h"
#include "c-impl.h"

$ gcc -c main.c
$ gcc -Wall -Wextra -Wpedantic -Wattributes -c main.c
$ g++ -c main.c
In file included from main.c:1:0:
c.h:1:50: warning: ‘constructor’ attribute ignored [-Wattributes]
 #define __constructor __attribute__((constructor))
$ clang++-3.5 -c main.c
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated
$ clang-3.5 -c main.c

$ g++ --version
g++ (Debian 4.9.1-16) 4.9.1
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Is this desired behavior?
>From gcc-bugs-return-470892-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Dec 16 16:10:22 2014
Return-Path: <gcc-bugs-return-470892-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24444 invoked by alias); 16 Dec 2014 16:10:21 -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 24412 invoked by uid 48); 16 Dec 2014 16:10:17 -0000
From: "izamyatin at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/64286] Redundant extend removal ignores vector element type
Date: Tue, 16 Dec 2014 16:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: major
X-Bugzilla-Who: izamyatin 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:
Message-ID: <bug-64286-4-kVBHNkipqE@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64286-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64286-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-12/txt/msg01899.txt.bz2
Content-length: 732

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

--- Comment #1 from Igor Zamyatin <izamyatin at gmail dot com> ---
Perhaps something like below to restrict ree for such cases?

diff --git a/gcc/ree.c b/gcc/ree.c
index 3376901..92370ea 100644
--- a/gcc/ree.c
+++ b/gcc/ree.c
@@ -1004,6 +1004,11 @@ add_removable_extension (const_rtx expr, rtx_insn *insn,
       struct df_link *defs, *def;
       ext_cand *cand;

+      if (!SCALAR_INT_MODE_P (GET_MODE (dest))
+      && (GET_MODE_UNIT_PRECISION (mode) !+          GET_MODE_UNIT_PRECISION (GET_MODE (XEXP (src, 0)))))
+    return;
+
       /* First, make sure we can get all the reaching definitions.  */
       defs = get_defs (insn, XEXP (src, 0), NULL);
       if (!defs)

[Bug c++/64332] gcc/g++ handles system_header differently

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I don't think it is system header which is being handled differently, rather I
think it is warning for attribute is being handled differently.

[Bug c++/64332] gcc/g++ handles system_header differently

[a3at.mail at gmail dot com]

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

--- Comment #3 from Azat <a3at.mail at gmail dot com> ---
On Tue, Dec 16, 2014 at 07:50:48PM +0300, Azat Khuzhin wrote:
> > --- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
> > I don't think it is system header which is being handled differently, rather I
> > think it is warning for attribute is being handled differently.
> 
> Maybe... I didn't check this.

I've checked this and you are right:
$ head main.c c-impl.h  # the same is in attach
==> main.c <==
#include "c-impl.h"

==> c-impl.h <==
#pragma GCC system_header

static inline int foo(int foo)
{
}

$ gcc -Wall -Wextra -Wpedantic -Wattributes -c main.c
$ g++ -Wall -Wextra -Wpedantic -Wattributes -c main.c

Now drop system_header:
$ head main.c c-impl.h 
==> main.c <==
#include "c-impl.h"

==> c-impl.h <==
static inline int foo(int foo)
{
}

$ gcc -Wall -Wextra -Wpedantic -Wattributes -c main.c
In file included from main.c:1:0:
c-impl.h: In function ‘foo’:
c-impl.h:3:1: warning: no return statement in function returning non-void
[-Wreturn-type]
 }
 ^
c-impl.h:1:27: warning: unused parameter ‘foo’ [-Wunused-parameter]
 static inline int foo(int foo)
                           ^
$ g++ -Wall -Wextra -Wpedantic -Wattributes -c main.c
In file included from main.c:1:0:
c-impl.h: In function ‘int foo(int)’:
c-impl.h:3:1: warning: no return statement in function returning non-void
[-Wreturn-type]
 }
 ^
c-impl.h: At global scope:
c-impl.h:1:27: warning: unused parameter ‘foo’ [-Wunused-parameter]
 static inline int foo(int foo)
                           ^
>From gcc-bugs-return-470904-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Dec 16 17:16:46 2014
Return-Path: <gcc-bugs-return-470904-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8323 invoked by alias); 16 Dec 2014 17: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 8301 invoked by uid 48); 16 Dec 2014 17:16:41 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/64332] wrong location for Wattributes warning
Date: Tue, 16 Dec 2014 17:16: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.9.1
X-Bugzilla-Keywords: diagnostic
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: keywords bug_status cf_reconfirmed_on cc component short_desc everconfirmed
Message-ID: <bug-64332-4-dK009hqTr9@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64332-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64332-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-12/txt/msg01911.txt.bz2
Content-length: 2084

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-12-16
                 CC|                            |manu at gcc dot gnu.org
          Component|c++                         |c
            Summary|gcc/g++ handles             |wrong location for
                   |system_header differently   |Wattributes warning
     Ever confirmed|0                           |1

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
The difference that you see is because of macro expansion and bad location info
in the C FE. This testcase makes it clear:

$ cat test.c
#define __constructor __attribute__((constructor))
typedef void (*__cb_type)(void *);
int foo(__cb_type __constructor);

$ cc1 -Wattributes test.c
test.c:3:1: warning: ‘constructor’ attribute ignored [-Wattributes]
 int foo(__cb_type __constructor);
 ^
$ cc1plus -Wattributes test.c
test.c:1:50: warning: ‘constructor’ attribute ignored [-Wattributes]
 #define __constructor __attribute__((constructor))
                                                  ^
test.c:3:19: note: in expansion of macro ‘__constructor’
 int foo(__cb_type __constructor);
                   ^

The C FE does not point to __constructor (3:1 vs 3:19), thus it doesn't realize
this comes from a macro expansion, thus (in your testcase) the system_header is
applied. The C++ FE sees that the attribute actually appears in 1:50 and not
3:19, thus in your testcase the pragma system_header does not apply.

Whether the correct behavior is that the system_header applies to the
definition or to the expansion location, I am not sure. However, the bad
location of the C FE is clearly a bug.
>From gcc-bugs-return-470905-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Dec 16 17:20:45 2014
Return-Path: <gcc-bugs-return-470905-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12389 invoked by alias); 16 Dec 2014 17:20: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 12194 invoked by uid 55); 16 Dec 2014 17:20:38 -0000
From: "a3at.mail at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/64332] wrong location for Wattributes warning
Date: Tue, 16 Dec 2014 17:20: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.9.1
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: a3at.mail 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:
Message-ID: <bug-64332-4-JxwvY5nMnB@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64332-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64332-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-12/txt/msg01912.txt.bz2
Content-length: 783

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

--- Comment #5 from Azat <a3at.mail at gmail dot com> ---
On Tue, Dec 16, 2014 at 05:16:41PM +0000, manu at gcc dot gnu.org wrote:
> The C FE does not point to __constructor (3:1 vs 3:19), thus it doesn't realize
> this comes from a macro expansion, thus (in your testcase) the system_header is
> applied. The C++ FE sees that the attribute actually appears in 1:50 and not
> 3:19, thus in your testcase the pragma system_header does not apply.

Hm.. good to know, thanks for pointing me out!

> Whether the correct behavior is that the system_header applies to the
> definition or to the expansion location, I am not sure. However, the bad
> location of the C FE is clearly a bug.

Maybe gcc will behave like clang in this case?

[Bug c/64332] wrong location for Wattributes warning

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Azat from comment #5)
> > Whether the correct behavior is that the system_header applies to the
> > definition or to the expansion location, I am not sure. However, the bad
> > location of the C FE is clearly a bug.
> 
> Maybe gcc will behave like clang in this case?

How does Clang behave? For example, what happens when you don't use
system_header in your testcase? and when you use it, but also add
-Wsystem-headers? What happens if the system_header #pragma is moved to c.h?
Trying to guess a correct behavior from a single testcase is quite hard. Clang
may "work" in this case, but may "fail" in another case..

My intuition is that whether the warning is printed or not depends on the way
the macro unwinder works. We have an open bug about that already PR55252, but
no one has tried to change it yet.
>From gcc-bugs-return-470912-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Dec 16 17:43:41 2014
Return-Path: <gcc-bugs-return-470912-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26732 invoked by alias); 16 Dec 2014 17:43:41 -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 26675 invoked by uid 48); 16 Dec 2014 17:43:36 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/63851] [5 Regression] ipa-icf miscompiles gfortran.dg/assumed_rank_(8|9|10).f90 at -O2 and above
Date: Tue, 16 Dec 2014 17:43:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: marxin at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63851-4-EUSJyGMNps@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63851-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63851-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-12/txt/msg01919.txt.bz2
Content-length: 369

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

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Yes, IPA ICF should respect 'restrict' attribute.
> May I ask you to rerun test suite with applied:

My machine is busy regtesting 4.8.4, but a quick test shows that your patch
indeed fixes this PR. More testing tonight. Thanks for the fix.

[Bug c/64332] wrong location for Wattributes warning

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2014-12-16 00:00:00         |2022-1-10

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Simpler repro for the bad location still present on trunk:

void f (int __attribute__ ((invalid)) i);

f.c:1:1: warning: ‘invalid’ attribute directive ignored [-Wattributes]
    1 | void f (int __attribute__ ((invalid)) i);
      | ^~~~