[Bug fortran/67250] New: gfortran does not faithfully preprocess the way cpp does

[Bug fortran/67250] New: gfortran does not faithfully preprocess the way cpp does

[jeff.science at gmail dot com]

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

            Bug ID: 67250
           Summary: gfortran does not faithfully preprocess the way cpp
                    does
           Product: gcc
           Version: 5.2.0
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jeff.science at gmail dot com
  Target Milestone: ---

Created attachment 36195
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36195&action=edit
source file

I do not understand why "gfortran -I. -E source.F" does not give the same
result as "cpp-5 -I. -E source.F".  It appears that gfortran does not properly
preprocessor "#", "##" and "\".

This breaks NWChem and there is no obvious workaround.

> cat header.fh 
! comment
      integer foo
      external foo
#define DECL(a) \
      integer err_##a; \
      integer l_##a,k_##a;
#define ALLO(a,s) \
      err_##a=foo(s,#a,l_##a,k_##a); \
      if (.not.err_##a) call bar("PUSH"#a,#s);

> cat source.F 
C
C OLD SCHOOL COMMENTS
C
      subroutine xyz(stuff)
      implicit none
#include "header.fh"
      integer stuff
      DECL(handle)
      ALLO(handle,100)
      print*,stuff
      return
      end


> gfortran -I. -E source.F 
# 1 "source.F"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "source.F"
C
C OLD SCHOOL COMMENTS
C
      subroutine xyz(stuff)
      implicit none

# 1 "header.fh" 1
! comment
      integer foo
      external foo
# 7 "source.F" 2
      integer stuff
      integer err_##handle;       integer l_##handle,k_##handle;
      err_##handle=foo(100,#handle,l_##handle,k_##handle);       if
(.not.err_##handle) call bar("PUSH"#handle,#100);
      print*,stuff
      return
      end

> cpp-5 -I. -E source.F 
# 1 "source.F"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "source.F"
C
C OLD SCHOOL COMMENTS
C
      subroutine xyz(stuff)
      implicit none
# 1 "header.fh" 1
! comment
      integer foo
      external foo
# 7 "source.F" 2
      integer stuff
      integer err_handle; integer l_handle,k_handle;
      err_handle=foo(100,"handle",l_handle,k_handle); if (.not.err_handle) call
bar("PUSH""handle","100");
      print*,stuff
      return
      end

> gfortran-5 -v
Using built-in specs.
COLLECT_GCC=gfortran-5
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/5.2.0/libexec/gcc/x86_64-apple-darwin14.4.0/5.2.0/lto-wrapper
Target: x86_64-apple-darwin14.4.0
Configured with: ../configure --build=x86_64-apple-darwin14.4.0
--prefix=/usr/local/Cellar/gcc/5.2.0
--libdir=/usr/local/Cellar/gcc/5.2.0/lib/gcc/5
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-5
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-libstdcxx-time=yes --enable-stage1-checking
--enable-checking=release --enable-lto --with-build-config=bootstrap-debug
--disable-werror --with-pkgversion='Homebrew gcc 5.2.0 --without-multilib'
--with-bugurl=https://github.com/Homebrew/homebrew/issues --enable-plugin
--disable-nls --disable-multilib
Thread model: posix
gcc version 5.2.0 (Homebrew gcc 5.2.0 --without-multilib)

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
See the option -traditional-cpp.

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

[manu at gcc dot gnu.org]

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

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
*** Bug 67251 has been marked as a duplicate of this bug. ***
>From gcc-bugs-return-495002-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Aug 17 16:43:23 2015
Return-Path: <gcc-bugs-return-495002-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 48897 invoked by alias); 17 Aug 2015 16:43: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 48547 invoked by uid 48); 17 Aug 2015 16:43:10 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/67251] gfortran does not faithfully preprocess the way cpp does
Date: Mon, 17 Aug 2015 16: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: 5.2.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: blocker
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: DUPLICATE
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-67251-4-Z4icijdCbp@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67251-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67251-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-08/txt/msg01144.txt.bz2
Content-length: 601

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |manu at gcc dot gnu.org
         Resolution|---                         |DUPLICATE

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Dup

*** This bug has been marked as a duplicate of bug 67250 ***
>From gcc-bugs-return-495003-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Aug 17 17:07:39 2015
Return-Path: <gcc-bugs-return-495003-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 105151 invoked by alias); 17 Aug 2015 17:07: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 105108 invoked by uid 48); 17 Aug 2015 17:07:35 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/67216] false is still a null pointer constant
Date: Mon, 17 Aug 2015 17:07: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: rejects-valid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: paolo.carlini at oracle dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: keywords bug_status assigned_to
Message-ID: <bug-67216-4-4SZViE8tlj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67216-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67216-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/msg01145.txt.bz2
Content-length: 531

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|accepts-invalid             |rejects-valid
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |paolo.carlini at oracle dot com

--- Comment #2 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Mine.

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jeff Hammond from comment #3)
> Unfortunately, this does not change anything.
> 

I saying gfortran defaults to that and you can use that option to cpp to get
the same behavior. 





> > gfortran-5 -traditional-cpp -I. -E source.F 
> # 1 "source.F"
> # 1 "<built-in>"
> # 1 "<command-line>"
> # 1 "source.F"
> C
> C OLD SCHOOL COMMENTS
> C
>       subroutine xyz(stuff)
>       implicit none
> 
> # 1 "header.fh" 1
> ! comment
>       integer foo
>       external foo
> # 7 "source.F" 2
>       integer stuff
>       integer err_##handle;       integer l_##handle,k_##handle;
>       err_##handle=foo(100,#handle,l_##handle,k_##handle);       if
> (.not.err_##handle) call bar("PUSH"#handle,#100);
>       print*,stuff
>       return
>       end

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |kargl at gcc dot gnu.org
         Resolution|---                         |INVALID
           Severity|blocker                     |normal

--- Comment #5 from kargl at gcc dot gnu.org ---
See the documenation where it explicitly states:

   Many Fortran compilers including GNU Fortran allow passing
   the source code through a C preprocessor (CPP; sometimes
   also called the Fortran preprocessor, FPP) to allow for
   conditional compilation.  In the case of GNU Fortran, this
   is the GNU C Preprocessor in the traditional mode.

% ~/work/5/bin/cpp -I. -E -traditional-cpp u2.F

gives the same result as gfortran -I. -E u2.F.


Obvious workaround

cpp -I. -E file.F > file.f90
gfortran -c file.f90

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

[jeff.science at gmail dot com]

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

--- Comment #7 from Jeff Hammond <jeff.science at gmail dot com> ---
And your "obvious workaround" is in fact not one because it changes the
behavior of gfortran for Fortran source code and breaks the build in another
way.  And even if it did solve the problem, why not make it automatic with a
flag to gfortran?  

The Intel Fortran compiler behaves as desired by default.

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jeff Hammond from comment #7)
> And your "obvious workaround" is in fact not one because it changes the
> behavior of gfortran for Fortran source code and breaks the build in another
> way.  And even if it did solve the problem, why not make it automatic with a
> flag to gfortran?  
> 

The only way is to use the workaround sorry.  You could try -no-traditional-cpp
.  But as you said it will break the build in a different way and that is
because the fortran code is not C code.  

> The Intel Fortran compiler behaves as desired by default.

So.  Using the C preprocessor is out side of the scope of the fortran standard
so different compilers will act differently.

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

[jeff.science at gmail dot com]

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

--- Comment #9 from Jeff Hammond <jeff.science at gmail dot com> ---
First, you will not accept the fusion of cpp+gfortran behavior as a feature
request?  Is there a reason other than you do not want to do it because you are
already busy?

Second, true, but that doesn't stop gcc from supporting inline assembly outside
of ISO C11, or stop gfortran from being compatible with vendor implementations
of https://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html, or of supporting
any number of other non-standard features.

In short, "it's not in the standard, therefore it's fine to break user
experience" seems pretty weak here.  It's fine if you tell me that you do not
care about my needs and will not implement it, but please don't use ISO as the
excuse.

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Jeff Hammond from comment #9)
> First, you will not accept the fusion of cpp+gfortran behavior as a feature
> request?  Is there a reason other than you do not want to do it because you
> are already busy?

Because you are mixing two different things together.  Patches are welcome
really.

> 
> Second, true, but that doesn't stop gcc from supporting inline assembly
> outside of ISO C11, or stop gfortran from being compatible with vendor
> implementations of
> https://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html, or of supporting
> any number of other non-standard features.
> 
> In short, "it's not in the standard, therefore it's fine to break user
> experience" seems pretty weak here.  It's fine if you tell me that you do
> not care about my needs and will not implement it, but please don't use ISO
> as the excuse.

No that is not what I am saying.  What I am saying is since it is non-standard
different compilers will decide to support it differently.  In this case
gfortran is following what was done for g77.  So changing it will break user
experience for folks who have used g77.

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #11 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Tue, Aug 18, 2015 at 06:03:00AM +0000, jeff.science at gmail dot com wrote:
> 
> In short, "it's not in the standard, therefore it's fine to break user
> experience" seems pretty weak here.  It's fine if you tell me that you do not
> care about my needs and will not implement it, but please don't use ISO as the
> excuse.
> 

Well, no.  It's not standard, so a compiler implementation
is free define its own behavior.  The gfortran manual
has documented its behavior for a very long time.  Have
you read the gfortran manual?

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

[jeff.science at gmail dot com]

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

--- Comment #13 from Jeff Hammond <jeff.science at gmail dot com> ---
This is all fair.  I try very hard to fix my own bugs and submit patches, but
in this case I am wholly unqualified.  I don't know the first thing about
implementing a production compiler, or any compiler for that matter.

I believe that some of my Intel colleagues contribute to GCC already.  If I can
figure out who they are, perhaps I can convince them to help here, since
replicating the behavior of the Intel Fortran compiler has value for us.

And yes, I did read a fraction of the gfortran manual (which google decided was
relevant to my issue) in hopes of trying to solve this on my own.  I confess to
not having read the entire gfortran manual.

[Bug fortran/67250] gfortran does not faithfully preprocess the way cpp does

[manu at gcc dot gnu.org]

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

--- Comment #14 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Jeff Hammond from comment #13)
> This is all fair.  I try very hard to fix my own bugs and submit patches,
> but in this case I am wholly unqualified.  I don't know the first thing
> about implementing a production compiler, or any compiler for that matter.

To work on GCC, you mostly need to know C/C++, how to use GDB and be able to
setup the bootstrap and regression test environment. Most tasks are not hard or
require any special knowledge, just tedious (run the testsuite, follow-up on
patches, trace code through the debugger and figure out why it is not working
as it should). In fact, GCC is not lacking patches, there are many unapplied
patches in bugzilla and the mailing lists. It lacks people motivated enough to
do all the red-tape work necessary to get a patch applied to the repository.
>From gcc-bugs-return-495180-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Aug 19 13:13:37 2015
Return-Path: <gcc-bugs-return-495180-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 104082 invoked by alias); 19 Aug 2015 13:13:37 -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 103958 invoked by uid 48); 19 Aug 2015 13:13:24 -0000
From: "vittorio.romeo at outlook dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/67273] New: Incorrect -Wshadow warning with generic lambdas
Date: Wed, 19 Aug 2015 13:13: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: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: vittorio.romeo at outlook 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-67273-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/msg01322.txt.bz2
Content-length: 1225

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

            Bug ID: 67273
           Summary: Incorrect -Wshadow warning with generic lambdas
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vittorio.romeo at outlook dot com
  Target Milestone: ---

The `-Wshadow` flag fires an incorrect warning using generic lambdas with
`auto` type deduction.

Minimal example:
http://melpon.org/wandbox/permlink/ynGNXTYN8rY40BgY

---

Code (copy-pasted from example):

// `auto i` -> incorrect warning
auto autol0()
{
    return [](auto i){ std::cout << i; };
}

auto autol1()
{
    return [](auto i){ autol0()(i); };
}

// `int i` -> no warnings
auto intl0()
{
    return [](int i){ std::cout << i; };
}

auto intl1()
{
    return [](int i){ intl0()(i); };
}

---

Warning (copy-pasted from example):

prog.cc:5:21: warning: declaration of 'int i' shadows a parameter [-Wshadow]
     return [](auto i){ std::cout << i; };
                     ^
prog.cc:10:20: note: shadowed declaration is here
     return [](auto i){ autol0()(i); };
                    ^