[Bug c++/65186] internal compiler error: in tsubst, at cp/pt.c:11738

["ppalka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #10 from Patrick Palka <ppalka at gcc dot gnu.org> ---
When I said that this PR is not a dup of c++/30044 I sadly failed to look at
#c1 and instead only looked at #c3.  The test case in #c1 does appear to
effectively be a dup of c++/30044, and with the fix for that PR now in trunk
this test case no longer ICEs, but now it fails with a compile error:

65186.cc:10:3: error: ‘C<x, x, x>’ is not a valid type for a template non-type
parameter
   C<x, x, x>>
   ^

This seems to be a bogus error because after instantiation C<x, x, x> will
resolve to int which is a valid type for the template parameter.  The fix for
this is simple.

The test cases in #c3 and in #c8 however exposes an entirely different bug than
the test case in #c1 (even though the ICE is the same).  I wonder what the
standard procedure here is.  Should this PR be split into two?
>From gcc-bugs-return-492056-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jul 11 22:59:29 2015
Return-Path: <gcc-bugs-return-492056-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 129951 invoked by alias); 11 Jul 2015 22:59:28 -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 129933 invoked by uid 48); 11 Jul 2015 22:59:25 -0000
From: "bin.x.fan at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/66842] New: libatomic uses multiple locks for locked atomics
Date: Sat, 11 Jul 2015 22:59: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: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bin.x.fan at oracle 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-66842-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-07/txt/msg00946.txt.bz2
Content-length: 2644

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

            Bug ID: 66842
           Summary: libatomic uses multiple locks for locked atomics
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bin.x.fan at oracle dot com
  Target Milestone: ---

Hi GCC folks,

I'm opening this bug to report an issue that may or may not be a real bug. I
notice that GCC libatomic uses multiple locks for a locked atomic object whose
size is greater than 64 bytes. The granularity seems to be 64 because for every
64 bytes added to the size, one more lock is added.

It seems that this is to protect overlapping locked atomic object. If locked
atomic objects never overlap, then a more efficient way to do locked atomic
operations would be each object being protected by just one lock that is hashed
from its address.

Accessing a member of an atomic struct object is undefined behavior in C11
standard. So, does GCC support it as an extension or using multiple locks is
unnecessary therefore it’s a performance bug?

Here is my code to illustrate the issue. I interpose pthread_mutex_lock to
count how many times it is called. My GCC version is 4.9.2, and its target is
x86_64-unknown-linux-gnu. The libatomic.so I use comes with the GCC 4.9.2
installation.

-bash-4.2$ cat libmythread.c
#define _GNU_SOURCE
#include <pthread.h>
#include <dlfcn.h>
#include <stdio.h>
#include <assert.h>

static int counter = 0;

int pthread_mutex_lock (pthread_mutex_t *mutex)
{
    static int (*real_pthread_mutex_lock)(pthread_mutex_t *) = NULL;
    if (real_pthread_mutex_lock == NULL) {
        real_pthread_mutex_lock = dlsym (RTLD_NEXT, "pthread_mutex_lock");
    }
    assert (real_pthread_mutex_lock);
    counter++;
    return real_pthread_mutex_lock (mutex);
}

void display_nlocks ()
{
    printf ("pthread_mutex_lock is called %d times\n", counter);
    return;
}
-bash-4.2$ cat c11_locked_atomics.c
#include <stdatomic.h>

#ifndef SIZE
#define SIZE 1024
#endif

typedef struct {
    char a[SIZE];
} lock_obj_t;

extern void display_nlocks ();

int main()
{
    lock_obj_t v2 = {0};
    _Atomic lock_obj_t v1 = ATOMIC_VAR_INIT(v2);
    v2 = atomic_load (&v1);
    display_nlocks ();
    return 0;
}

-bash-4.2$ gcc -shared -ldl -fPIC libmythread.c -o libmythread.so
-bash-4.2$ gcc -latomic c11_locked_atomics.c -DSIZE=2048 -L./ -Wl,-rpath=./
-lmythread
-bash-4.2$ LD_PRELOAD=./libmythread.so a.out
pthread_mutex_lock is called 32 times
>From gcc-bugs-return-492057-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jul 12 02:29:58 2015
Return-Path: <gcc-bugs-return-492057-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 119856 invoked by alias); 12 Jul 2015 02:29:54 -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 117760 invoked by uid 48); 12 Jul 2015 02:29:45 -0000
From: "fvvnaqnd at grr dot la" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66843] New: g++ outputting nonsense errors, won't compile operational program
Date: Sun, 12 Jul 2015 02:29: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.1.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fvvnaqnd at grr dot la
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-66843-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-07/txt/msg00947.txt.bz2
Content-length: 1432

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

            Bug ID: 66843
           Summary: g++ outputting nonsense errors, won't compile
                    operational program
           Product: gcc
           Version: 5.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: fvvnaqnd at grr dot la
  Target Milestone: ---

I'm trying to compile this valid c++ code, as follows:

int main(int argc, char** argv) {
    dildo
    #define char int
    int *ptr = 0;
    return EXIT_SUCCESS;
}
=
while(1)
break;
/* https://www.gnu.org/licenses/gpl-3.0.en.html */
int i = 1 / 0;
goto dildo;

However, when trying to compile this with g++, the compiler spits out nonsense,
unintelligible errors:

shit.cpp: In function ‘int main(int, char**)’:
shit.cpp:2:5: error: ‘dildo’ was not declared in this scope
     dildo
     ^
shit.cpp:5:12: error: ‘EXIT_SUCCESS’ was not declared in this scope
     return EXIT_SUCCESS;
            ^
shit.cpp: At global scope:
shit.cpp:7:1: error: expected unqualified-id before ‘=’ token
 =
 ^
shit.cpp:11:11: warning: division by zero [-Wdiv-by-zero]
 int i = 1 / 0;
           ^
shit.cpp:12:1: error: expected unqualified-id before ‘goto’
 goto dildo;
 ^

Please Respond
>From gcc-bugs-return-492058-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jul 12 04:51:16 2015
Return-Path: <gcc-bugs-return-492058-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 35368 invoked by alias); 12 Jul 2015 04:51:14 -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 35345 invoked by uid 48); 12 Jul 2015 04:51:07 -0000
From: "Casey at Carter dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66844] New: [c++-concepts] Requires-expression parameter with void type
Date: Sun, 12 Jul 2015 04:51: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: normal
X-Bugzilla-Who: Casey at Carter dot net
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-66844-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-07/txt/msg00948.txt.bz2
Content-length: 768

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

            Bug ID: 66844
           Summary: [c++-concepts] Requires-expression parameter with void
                    type
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: Casey at Carter dot net
  Target Milestone: ---

This ill-formed program compiles successfully:

template <class T, class U>
concept bool Same = __is_same_as(T, U);

template <class T>
concept bool C   requires (T t) {
    requires Same<decltype(t),void>;
  };

template <C>
constexpr bool is_c() { return true; }

static_assert(is_c<void>(), "");

int main() {}