[Bug c++/38928] New: infinite loop on error message in C++ only

[Bug c++/38928] New: infinite loop on error message in C++ only

[etienne_lorrain at yahoo dot fr]

etienne@pc300:~$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.3.2 (Debian 4.3.2-1)
etienne@pc300:~$ cat tmp.c
struct id_struct
{
    unsigned char is_ip_addrs[4];
};

struct addr_struct
{
    unsigned short    family;
    unsigned short   port;
    struct   id_struct id;
    char     *name;
};

int main (int argc, char **argv)
{
        struct addr_struct tmp_addr_struct = {
                family: 1,
                port: 666,
                id: 0,
                name: (char []){"psig TCP"}
                };
        return 2;
}
etienne@pc300:~$ gcc tmp.c
etienne@pc300:~$ g++ tmp.c 2> log
^C
etienne@pc300:~$ head log
tmp.c: In function 'int main(int, char**)':
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
tmp.c:21: error: 'id_struct' has no non-static data member named 'id'
etienne@pc300:~$


-- 
           Summary: infinite loop on error message in C++ only
           Product: gcc
           Version: 4.3.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: etienne_lorrain at yahoo dot fr
 GCC build triplet: i486-linux-gnu
  GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu


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

[Bug c++/38928] infinite loop on error message in C++ only

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2009-01-22 01:41 -------
3.3 ICEd on the testcase.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |4.0.0 4.3.0 4.4.0


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

[Bug c++/38928] infinite loop on error message in C++ only

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2009-01-22 01:41 -------
Confirmed.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
  GCC build triplet|i486-linux-gnu              |
   GCC host triplet|i486-linux-gnu              |
 GCC target triplet|i486-linux-gnu              |
           Keywords|                            |diagnostic
   Last reconfirmed|0000-00-00 00:00:00         |2009-01-22 01:41:08
               date|                            |


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

[Bug c++/38928] infinite loop on error message in C++ only

[paolo dot carlini at oracle dot com]

------- Comment #3 from paolo dot carlini at oracle dot com  2009-01-30 01:43 -------
On it.


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |paolo dot carlini at oracle
                   |dot org                     |dot com
             Status|NEW                         |ASSIGNED


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

[Bug c++/38928] infinite loop on error message in C++ only

[paolo dot carlini at oracle dot com]

------- Comment #4 from paolo dot carlini at oracle dot com  2009-01-30 10:18 -------
The diagnostic issue is trivial, just add a check for error_mark_node on the
return value of reshape_init_r, consistently with other calls.

However, I'm still analyzing whether we really want to reject. As data points,
ICC doesn't, even in strict mode; on the other hand Comeau rejects the
identifier "family" already...

Mark, do you have a quick opinion? Thanks in advance...


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at codesourcery dot com


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

[Bug c++/38928] infinite loop on error message in C++ only

[bangerth at gmail dot com]

------- Comment #5 from bangerth at gmail dot com  2009-01-30 15:00 -------
(In reply to comment #4)

> However, I'm still analyzing whether we really want to reject. As data points,
> ICC doesn't, even in strict mode; on the other hand Comeau rejects the
> identifier "family" already...

Does it reject the code because this form of member initializer (where you
name individual members) is really a C99 thing, not C++98?

W.


-- 


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

[Bug c++/38928] infinite loop on error message in C++ only

[mmitchel at gcc dot gnu dot org]

------- Comment #6 from mmitchel at gcc dot gnu dot org  2009-02-02 06:41 -------
Yes, designated initializers are of course a GNU extension to C++.  I'm
surprised that icc accepts them in its strict mode.

In GNU C++, it makes sense for us to accept the same extensions that are
accepted in GNU C.  So, if GCC accepts this, I think G++ should too.  (I don't
know what the initialization of "id_struct" with "0" means, though; does it
only initialize the first element of id_struct::is_ip_addrs?)  However, the GCC
and G++ code that processes initializers is, I think, mostly if not totally
distinct.  So, it's likely that some significant work would need to be done to
handle this case.

-- Mark


-- 


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

[Bug c++/38928] infinite loop on error message in C++ only

[paolo dot carlini at oracle dot com]

------- Comment #7 from paolo dot carlini at oracle dot com  2009-02-02 10:19 -------
Ok Mark, agreed, thanks. For the moment, I'm not going to work on this one and
I'm unassigning myself in order not to prevent anyone else quicker than me...


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu
                   |dot com                     |dot org
             Status|ASSIGNED                    |NEW


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

[Bug c++/38928] infinite loop on error message in C++ only

[paolo.carlini at oracle dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|gcc-bugs at gcc dot gnu.org |
      Known to fail|                            |

--- Comment #8 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-11-07 16:25:00 UTC ---
The infinite loop is gone in 4.5.x and current branches.