[Bug plugins/65227] New: Plugin headers are unusable when included after inttypes.h

[Bug plugins/65227] New: Plugin headers are unusable when included after inttypes.h

[Bert.Wesarg at googlemail dot com]

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

            Bug ID: 65227
           Summary: Plugin headers are unusable when included after
                    inttypes.h
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: plugins
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Bert.Wesarg at googlemail dot com

GCC 5 20150215 Snapshot.

When the gcc-plugin.h header is included after the inttypes.h header, than the
compilation breaks. Used compiler:

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/wesarg/opt/gcc-5-20150215/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/wesarg/opt/gcc-5-20150215
--enable-languages=c,c++,fortran --disable-nls --enable-checking=yes
--disable-werror
Thread model: posix
gcc version 5.0.0 20150215 (experimental) (GCC) 

Compiling the attached file, which includes inttypes.h before gcc-plugin.h
results in this error:

$ g++ -save-temps -c -I$(g++ -print-file-name=plugin/include)
no-inttypes-pri-macros.cc 
In file included from
/home/wesarg/opt/gcc-5-20150215/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/plugin/include/double-int.h:23:0,
                 from
/home/wesarg/opt/gcc-5-20150215/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/plugin/include/gcc-plugin.h:52,
                 from no-inttypes-pri-macros.cc:2:
/home/wesarg/opt/gcc-5-20150215/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/plugin/include/wide-int.h:
In member function 'void generic_wide_int<T>::dump() const':
/home/wesarg/opt/gcc-5-20150215/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/plugin/include/wide-int.h:877:26:
error: expected ')' before 'PRIx64'
     fprintf (stderr, HOST_WIDE_INT_PRINT_HEX ",", val[len - 1 - i]);
                          ^
In file included from
/home/wesarg/opt/gcc-5-20150215/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/plugin/include/double-int.h:23:0,
                 from
/home/wesarg/opt/gcc-5-20150215/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/plugin/include/gcc-plugin.h:52,
                 from no-inttypes-pri-macros.cc:2:
/home/wesarg/opt/gcc-5-20150215/lib/gcc/x86_64-unknown-linux-gnu/5.0.0/plugin/include/wide-int.h:878:24:
error: expected ')' before 'PRIx64'
   fprintf (stderr, HOST_WIDE_INT_PRINT_HEX "], precision = %d\n",
                        ^
The reason seems to be, that system.h defines __STDC_FORMAT_MACROS, than
conditionally includes inttypes.h, and later hwint.h relys that this
conditional include has resulted in the definition of the PRI macros. But that
is not the case as the the include <inttypes.h> in system.h is not the first
inclusion of this header.

[Bug plugins/65227] Plugin headers are unusable when included after inttypes.h

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
You should always include gcc-plugin.h first when compiling plugins.

[Bug plugins/65227] Plugin headers are unusable when included after inttypes.h

[Bert.Wesarg at googlemail dot com]

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

--- Comment #2 from Bert Wesarg <Bert.Wesarg at googlemail dot com> ---
(In reply to Andrew Pinski from comment #1)
> You should always include gcc-plugin.h first when compiling plugins.

But the documentation in gcc/doc/plugins.texi only reads:

The header @file{gcc-plugin.h} must be the first gcc header to be included.

Thus it does it not required that gcc-plugin.h is the first header at all to be
included. And this doesn't changed between GCC 4.9.2 and the GCC 5 snapshot.

[Bug plugins/65227] Plugin headers are unusable when included after inttypes.h

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |documentation
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-02-27
     Ever confirmed|0                           |1

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Doumentation bug then.  gcc-plugin.h should be the _only_ GCC header to
include.

Confirmed as documentation bug.

[Bug plugins/65227] Plugin headers are unusable when included after inttypes.h

[Bert.Wesarg at googlemail dot com]

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

--- Comment #4 from Bert Wesarg <Bert.Wesarg at googlemail dot com> ---
(In reply to Richard Biener from comment #3)
> Doumentation bug then.  gcc-plugin.h should be the _only_ GCC header to
> include.
> 

So inttypes.h is considered a GCC header than? And even if GCC mandates that
gcc-plugin.h should be the first header to include in a compilation unit, how
should this work in a autoconf projects which uses AC_CONFIG_HEADER, because
they also mandate that this header should be the first header to include (from
http://www.gnu.org/software/autoconf/manual/autoconf.html#Configuration-Headers):

The package should ‘#include’ the configuration header file before any other
header files, to prevent inconsistencies in declarations (for example, if it
redefines const).
>From gcc-bugs-return-478692-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Feb 27 09:18:57 2015
Return-Path: <gcc-bugs-return-478692-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 122710 invoked by alias); 27 Feb 2015 09:18:56 -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 122649 invoked by uid 48); 27 Feb 2015 09:18:53 -0000
From: "vogt at linux dot vnet.ibm.com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug go/64999] s390x libgo test failure in TestMemoryProfiler
Date: Fri, 27 Feb 2015 10:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: go
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vogt at linux dot vnet.ibm.com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ian at airs dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-64999-4-4sJ90eGWaL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64999-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64999-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-02/txt/msg03024.txt.bz2
Content-length: 510

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

--- Comment #35 from Dominik Vogt <vogt at linux dot vnet.ibm.com> ---
I'd like to bring back to attention the fact that the code that deducts six
from the pc (s390x) in pprof.go is broken regardless of what patches are made
to the runtime code.  Determining the size of the call instruction is by no
means trivial.  Other platforms certainly have similar problems with the "pc -4".  It would be good to solve this at the same time as the "pc--" problem.