[Bug c++/63454] New: [5 Regression] internal compiler error: canonical types differ for identical types

[Bug c++/63454] New: [5 Regression] internal compiler error: canonical types differ for identical types

[ai.azuma at gmail dot com]

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

            Bug ID: 63454
           Summary: [5 Regression] internal compiler error: canonical
                    types differ for identical types
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ai.azuma at gmail dot com

Created attachment 33645
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33645&action=edit
Output of -v option and preprocessed file

The following valid code causes an ICE with GCC 5.0.0 20140928.

//=======================================================
template<typename T>
struct A
{
  typedef T type;
};

template<typename T>
struct B
{};

template<typename T>
B<typename A<T const>::type>
f(T const &)
{}

template<typename CharT>
struct X
{
  typedef CharT char_type;

  void memfun()
  {
    char_type const c[1] = { static_cast<char_type>(0) };
    f(c);
  }
};

template<typename CharT>
struct Y
{
  typedef CharT char_type;

  void memfun()
  {
    char_type const c[1] = { static_cast<char_type>(0) };
    f(c);
  }
};

template struct X<char>;
template struct Y<char>;
//=======================================================

Note that the above code compiles successfully with 4.9.2 20140924 and 4.8.4
20140925. The reproducer originally comes from a Boost.Log 1.56.0 source file.

[Bug c++/63454] [5 Regression] internal compiler error: canonical types differ for identical types

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler@googlemail.
                   |                            |com

--- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
I don't see any ICE for gcc 5.0.0 20141004 (experimental). Could you retry that
one?
>From gcc-bugs-return-463295-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Oct 05 10:07:30 2014
Return-Path: <gcc-bugs-return-463295-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8668 invoked by alias); 5 Oct 2014 10:07:29 -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 8649 invoked by uid 48); 5 Oct 2014 10:07:26 -0000
From: "toon at moene dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libfortran/63460] New: Some namelists cannot be read from stdin (unit 5): Fortran runtime error: End of file
Date: Sun, 05 Oct 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: libfortran
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: toon at moene dot 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-63460-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-10/txt/msg00316.txt.bz2
Content-length: 985

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

            Bug ID: 63460
           Summary: Some namelists cannot be read from stdin (unit 5):
                    Fortran runtime error: End of file
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: toon at moene dot org

The following Fortran program, when compiled with gfortran 4.9.1 or trunk
(5.0), cannot read a valid namelist file from stdin (unit 5).

Reading it from another unit (or as an internal file) proceeds fine.

Fortran program:

      character*10 file /'noot.hdf'/
      character*5  aap(10) /10*""/
      integer      par(10) /10*3/
      namelist /namlis/ file, aap, par
      read (5, namlis)
      write(6, namlis)
      end

Namelist file (which is redirected to stdin):

&NAMLIS
file='aap.hdf', aap(5)='noot', par(5)=6
/

[Bug c++/63454] [5 Regression] internal compiler error: canonical types differ for identical types

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-10-06
   Target Milestone|---                         |5.0
     Ever confirmed|0                           |1

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed with some old cc1plus and trunk.

[Bug c++/63454] [5 Regression] internal compiler error: canonical types differ for identical types

[ai.azuma at gmail dot com]

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

--- Comment #3 from Ai Azuma <ai.azuma at gmail dot com> ---
(In reply to Daniel Krügler from comment #1)
> I don't see any ICE for gcc 5.0.0 20141004 (experimental). Could you retry
> that one?

I am still seeing the ICE with 5.0.0 20141005 (experimental).
>From gcc-bugs-return-463418-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Oct 07 05:16:46 2014
Return-Path: <gcc-bugs-return-463418-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1964 invoked by alias); 7 Oct 2014 05:16: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 1934 invoked by uid 55); 7 Oct 2014 05:16:41 -0000
From: "tejohnson at google dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/63432] [5 Regression] profiledbootstrap failure with bootstrap-lto
Date: Tue, 07 Oct 2014 05:16:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tejohnson at google 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-63432-4-UofnKpa0Bp@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63432-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63432-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-10/txt/msg00439.txt.bz2
Content-length: 5715

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

--- Comment #17 from Teresa Johnson <tejohnson at google dot com> ---
I'm going to finish testing my patch, which passes regular
x86_64-unknown-linux-gnu bootstrap + regression tests. I am still
trying to get the lto profiledbootstrap to work. I found some
workarounds for the undefined reference issue on Honza's blog, and I
am trying to get that working. Then I will send to gcc-patches for
review.

In the meantime, H.J. do you want to try the patch? It is below.

Thanks,
Teresa

2014-10-06  Teresa Johnson  <tejohnson@google.com>

        * tree-ssa-threadupdate.c (estimated_freqs_path): New function.
        (ssa_fix_duplicate_block_edges): Invoke it.
        (mark_threaded_blocks): Make two passes to avoid ordering dependences.

Index: tree-ssa-threadupdate.c
==================================================================--- tree-ssa-threadupdate.c     (revision 215830)
+++ tree-ssa-threadupdate.c     (working copy)
@@ -959,6 +959,43 @@ update_joiner_offpath_counts (edge epath, basic_bl
 }


+/* Check if the paths through RD all have estimated frequencies but zero
+   profile counts.  This is more accurate than checking the entry block
+   for a zero profile count, since profile insanities sometimes creep in.  */
+
+static bool
+estimated_freqs_path (struct redirection_data *rd)
+{
+  edge e = rd->incoming_edges->e;
+  vec<jump_thread_edge *> *path = THREAD_PATH (e);
+  edge ein;
+  edge_iterator ei;
+  bool non_zero_freq = false;
+  FOR_EACH_EDGE (ein, ei, e->dest->preds)
+    {
+      if (ein->count)
+        return false;
+      non_zero_freq |= ein->src->frequency != 0;
+    }
+
+  for (unsigned int i = 1; i < path->length (); i++)
+    {
+      edge epath = (*path)[i]->e;
+      if (epath->src->count)
+        return false;
+      non_zero_freq |= epath->src->frequency != 0;
+      edge esucc;
+      FOR_EACH_EDGE (esucc, ei, epath->src->succs)
+        {
+          if (esucc->count)
+            return false;
+          non_zero_freq |= esucc->src->frequency != 0;
+        }
+    }
+  return non_zero_freq;
+}
+
+
 /* Invoked for routines that have guessed frequencies and no profile
    counts to record the block and edge frequencies for paths through RD
    in the profile count fields of those blocks and edges.  This is because
@@ -1058,9 +1095,11 @@ ssa_fix_duplicate_block_edges (struct redirection_
      data we first take a snapshot of the existing block and edge frequencies
      by copying them into the empty profile count fields.  These counts are
      then used to do the incremental updates, and cleared at the end of this
-     routine.  */
+     routine.  If the function is marked as having a profile, we still check
+     to see if the paths through RD are using estimated frequencies because
+     the routine had zero profile counts.  */
   bool do_freqs_to_counts = (profile_status_for_fn (cfun) != PROFILE_READ
-                             || !ENTRY_BLOCK_PTR_FOR_FN (cfun)->count);
+                             || estimated_freqs_path (rd));
   if (do_freqs_to_counts)
     freqs_to_counts_path (rd);

@@ -2077,35 +2116,48 @@ mark_threaded_blocks (bitmap threaded_blocks)

   /* Now iterate again, converting cases where we want to thread
      through a joiner block, but only if no other edge on the path
-     already has a jump thread attached to it.  */
+     already has a jump thread attached to it.  We do this in two passes,
+     to avoid situations where the order in the paths vec can hide overlapping
+     threads (the path is recorded on the incoming edge, so we would miss
+     cases where the second path starts at a downstream edge on the same
+     path).  First record all joiner paths, deleting any in the unexpected
+     case where there is already a path for that incoming edge.  */
   for (i = 0; i < paths.length (); i++)
     {
       vec<jump_thread_edge *> *path = paths[i];

       if ((*path)[1]->type == EDGE_COPY_SRC_JOINER_BLOCK)
+        {
+         /* Attach the path to the starting edge if none is yet recorded.  */
+          if ((*path)[0]->e->aux == NULL)
+            (*path)[0]->e->aux = path;
+         else if (dump_file && (dump_flags & TDF_DETAILS))
+           dump_jump_thread_path (dump_file, *path, false);
+        }
+    }
+  /* Second, look for paths that have any other jump thread attached to
+     them, and either finish converting them or cancel them.  */
+  for (i = 0; i < paths.length (); i++)
+    {
+      vec<jump_thread_edge *> *path = paths[i];
+      edge e = (*path)[0]->e;
+
+      if ((*path)[1]->type == EDGE_COPY_SRC_JOINER_BLOCK && e->aux == path)
        {
          unsigned int j;
-
-         for (j = 0; j < path->length (); j++)
+         for (j = 1; j < path->length (); j++)
            if ((*path)[j]->e->aux != NULL)
              break;

          /* If we iterated through the entire path without exiting the loop,
-            then we are good to go, attach the path to the starting edge.  */
+            then we are good to go, record it.  */
          if (j == path->length ())
-           {
-             edge e = (*path)[0]->e;
-             e->aux = path;
-             bitmap_set_bit (tmp, e->dest->index);
-           }
+           bitmap_set_bit (tmp, e->dest->index);
          else if (dump_file && (dump_flags & TDF_DETAILS))
-           {
-             dump_jump_thread_path (dump_file, *path, false);
-           }
+           dump_jump_thread_path (dump_file, *path, false);
        }
     }

-
   /* If optimizing for size, only thread through block if we don't have
      to duplicate it or it's an otherwise empty redirection block.  */
   if (optimize_function_for_size_p (cfun))

[Bug c++/63454] [5 Regression] internal compiler error: canonical types differ for identical types

[jason at gcc dot gnu.org]

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

Jason Merrill <jason at gcc dot gnu.org> changed:

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

--- Comment #4 from Jason Merrill <jason at gcc dot gnu.org> ---
Fixed by patch for bug 63485.

*** This bug has been marked as a duplicate of bug 63485 ***