[Bug preprocessor/58770] New: GCC very slow compiling with #pragma once

[Bug preprocessor/58770] New: GCC very slow compiling with #pragma once

[yellow at rg3 dot name]

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

            Bug ID: 58770
           Summary: GCC very slow compiling with #pragma once
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: yellow at rg3 dot name

Created attachment 31026
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31026&action=edit
Benchmark files

Putting #pragma once in a header file, with or without additional classic
include guards, makes GCC very slow.

I've created a small benchmark that I'm attaching, with the following files:

* common.h: a common file to be included 10,000 times, protected with guards or
the pragma. In the tarball there are three versions to be tested.

* header0000.h to header9999.h: header files that include common.h

* all.h: header file that includes all header????.h files.

* main.c: main program, includes common.h and all.h

Building that program with gcc -o main main.c takes 1.5 seconds with #pragma
once, while merely using include guards takes only 70 milliseconds.

[Bug preprocessor/58770] GCC very slow compiling with #pragma once

[olafurw at gmail dot com]

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

Ólafur Waage <olafurw at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |olafurw at gmail dot com

--- Comment #1 from Ólafur Waage <olafurw at gmail dot com> ---
Created attachment 33017
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33017&action=edit
Log of running the attached tests

I have added an attachment of me running the test on GCC 4.8.2, I can run on a
newer version if needed, it was just what I had at the time.
>From gcc-bugs-return-455151-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 27 15:47:22 2014
Return-Path: <gcc-bugs-return-455151-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 4966 invoked by alias); 27 Jun 2014 15:47: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 4934 invoked by uid 48); 27 Jun 2014 15:47:18 -0000
From: "mshawcroft at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/61633] AArch64 SISD ASHR instruction split clobbers input register.
Date: Fri, 27 Jun 2014 15:47: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.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mshawcroft at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: mshawcroft at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cf_gcctarget bug_status cf_reconfirmed_on assigned_to everconfirmed
Message-ID: <bug-61633-4-Yu9pV68H15@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61633-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61633-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/msg02233.txt.bz2
Content-length: 542

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

mshawcroft at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |aarch64*-*-*
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2014-06-27
           Assignee|unassigned at gcc dot gnu.org      |mshawcroft at gcc dot gnu.org
     Ever confirmed|0                           |1

[Bug preprocessor/58770] GCC very slow compiling with #pragma once

[manu at gcc dot gnu.org]

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

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

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

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
The GCC preprocessor is very optimized for include guards. Perhaps the same
optimizations are not applied for "#pragma once". Someone will need to
investigate where the two code paths differ and what could be the reason for
the slow-down.

Unfortunately, there are very few developers working on the preprocessor and
very few users of "#pragma once", so this will likely have very low priority
unless one of those users takes the lead to fix it.
>From gcc-bugs-return-455158-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 27 16:20:31 2014
Return-Path: <gcc-bugs-return-455158-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25473 invoked by alias); 27 Jun 2014 16:20: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 25410 invoked by uid 48); 27 Jun 2014 16:20:28 -0000
From: "law at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/61607] DOM missed jump threading and destroyed loops
Date: Fri, 27 Jun 2014 16:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.10.0
X-Bugzilla-Keywords: missed-optimization, wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: law at redhat 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-61607-4-vnbYUtC6c0@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61607-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61607-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/msg02240.txt.bz2
Content-length: 518

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

--- Comment #8 from Jeffrey A. Law <law at redhat dot com> ---
FWIW, I vaguely recall experimenting with following the SSA_NAME_VALUE chains
in the past and having problems with cycles.  IIRC we can get cycles from
things like recording equivalences created by equality tests.

We could put a (small) upper limit on the number of SSA_NAME_VALUEs we walk.
I'd expect the vast majority of the time we'd be walking just one node.  I
guess that's worth investigating.

[Bug preprocessor/58770] GCC very slow compiling with #pragma once

[tromey at gcc dot gnu.org]

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

Tom Tromey <tromey at gcc dot gnu.org> changed:

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

--- Comment #3 from Tom Tromey <tromey at gcc dot gnu.org> ---
I think the difference is the code in libcpp/files.c:should_stack_file
that starts:

  /* Now we've read the file's contents, we can stack it if there
     are no once-only files.  */
  if (!pfile->seen_once_only)
    return true;

Any use of "#pragma once" sets this flag.
This then leads to a loop over all headers, so n^2 behavior.

I think the rationale for this code is that the #pragma must
prevent a second inclusion, even if done by a different file
name; whereas #ifdef exclusion doesn't suffer from this issue.

One possible fix might be to use a hash table rather than a
linked list for finding potential duplicates.

[Bug preprocessor/58770] GCC very slow compiling with #pragma once

[manu at gcc dot gnu.org]

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

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Tom Tromey from comment #3)
> I think the rationale for this code is that the #pragma must
> prevent a second inclusion, even if done by a different file
> name; whereas #ifdef exclusion doesn't suffer from this issue.

Sorry, I don't understand this. The #ifdef include-guards do prevent a second
inclusion, even if done by a different file name, no?
>From gcc-bugs-return-455749-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 07 09:59:43 2014
Return-Path: <gcc-bugs-return-455749-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6015 invoked by alias); 7 Jul 2014 09:59:42 -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 5941 invoked by uid 48); 7 Jul 2014 09:59:37 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/59850] Support sparse-style pointer address spaces (type attributes)
Date: Mon, 07 Jul 2014 09:59: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: 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-59850-4-eBxLCSoacC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59850-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59850-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-07/txt/msg00340.txt.bz2
Content-length: 1216

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

--- Comment #29 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Tom Tromey from comment #26)
> > 2. __force itself presents a problem as its semantics isn't well defined and
> > only sparse knows how to model it. in gcc it cannot be an attribute as
> > attributes apply to the outermost variable/etc, e.g., you can't use them on
> > a pointee in a pointer context.
> 
> Could you elaborate on this?
> I think I looked at all the sparse test cases here and I don't recall
> encountering any real issues (for address space I had to have a hack to
> deal with function return types, but this didn't seem to affect force).
> If you have extra tests not in sparse, that would be super.

If _Pragma can appear in the same places as __force, I think that would be a
superior approach. The trivial approach of using _Pragma("GCC diagnostic
ignore") does not seem to work in the middle of expressions, but that may be a
defect of the current implementation (PR60875 and PR52116).

Otherwise, a (type-generic?) __builtin_force_cast() perhaps would be even
better.

It seems strange and convoluted to use an attribute for this.
>From gcc-bugs-return-455750-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 07 10:07:07 2014
Return-Path: <gcc-bugs-return-455750-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19195 invoked by alias); 7 Jul 2014 10:07:07 -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 19119 invoked by uid 48); 7 Jul 2014 10:07:04 -0000
From: "vincenzo.innocente at cern dot ch" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/61731] New: Feature request: "generic" builtin for "conversion operator" among vectors
Date: Mon, 07 Jul 2014 10:07: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: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: vincenzo.innocente at cern dot ch
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-61731-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-07/txt/msg00341.txt.bz2
Content-length: 855

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

            Bug ID: 61731
           Summary: Feature request: "generic" builtin for "conversion
                    operator" among vectors
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vincenzo.innocente at cern dot ch

gcc is lacking a mechanism to convert (C-style cast) efficiently
"extended-vectors" among different types.
clang has recently introduce a "__builtin_convertvector"
(see few lines below
http://clang.llvm.org/docs/LanguageExtensions.html#langext-builtin-shufflevector)

I would like to ask if it is possible to implement the same feature in gcc.
An agreed syntax with "clang" would be welcome.

[Bug preprocessor/58770] GCC very slow compiling with #pragma once

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #4)
> Sorry, I don't understand this. The #ifdef include-guards do prevent a
> second inclusion, even if done by a different file name, no?

No, including the file via a different filename (e.g. via a symlink) will
re-open the file and preprocess it again. The include guards mean you don't get
re-definition of the file contents, but the file still gets included twice. You
can confirm that with strace.

With #pragma once the file is not even re-opened, so the compiler needs to do
extra checking.
>From gcc-bugs-return-455755-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 07 10:54:17 2014
Return-Path: <gcc-bugs-return-455755-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12588 invoked by alias); 7 Jul 2014 10:54:16 -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 12517 invoked by uid 48); 7 Jul 2014 10:54:09 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61732] Derivation from final class incorrectly allowed
Date: Mon, 07 Jul 2014 10:54: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:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi 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: bug_status resolution
Message-ID: <bug-61732-4-d9LGtPBnn8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61732-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61732-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-07/txt/msg00346.txt.bz2
Content-length: 504

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

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

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

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
The program is only ill-formed if you instantiate derived<X>, and you don't do
that.

[Bug preprocessor/58770] GCC very slow compiling with #pragma once

[sjames at gcc dot gnu.org]

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

--- Comment #8 from Sam James <sjames at gcc dot gnu.org> ---
(See the thread at
https://inbox.sourceware.org/gcc-patches/6027e3bb-99f9-573b-ff5e-ea1a48882df0@acm.org/.)