[Bug c++/20682] lost parser

[Bug c++/20682] lost parser

[reichelt at gcc dot gnu dot org]

------- Comment #11 from reichelt at gcc dot gnu dot org  2007-04-09 18:16 -------
This is really a non-bug.

The following code snippet illustrates this:

============================
#define VAR1(i,j) i##j
#define VAR2(i,j) VAR1(i,j)
#define VAR(i) VAR2(i,__LINE__)
#line 385
int VAR(i) = 0;
============================

The code snippet compiles fine on my i686-pc-linux-gnu machine.
If I add an empty line before the last line, I get the following error:

bug.cc:386: error: expected unqualified-id before numeric constant

A look at the preprocessed versions reveals the mystery.
First the "good" example:

============================
# 1 "bug.cc"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "bug.cc"
# 385 "bug.cc"
int i385 = 0;
============================

The preprocessor magic constructs a variable consisting of the letter "i"
and the line number. That's also the case with the "bad" example.
But, "i386" is the name of another (compiler defined) macro which is
then substituted by its value "1":

============================
# 1 "bug.cc"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "bug.cc"
# 385 "bug.cc"

int 1 = 0;
============================

I don't know how boost generates the variable names in your example,
but it looks like it uses a similar mechanism to turn line numbers
into variable names. The significant difference between yor "good" and
"bad" example is the following line which works fine with line number 388,
but not with 386:

- typedef typeof(to(0, models.size())) i_t388; i_t388& i388 = to(0,
models.size()); for(typename i_t388::iterator i = i388.begin(); i !=
i388.end(); ++i) {
+ typedef typeof(to(0, models.size())) i_t386; i_t386& 1 = to(0,
models.size()); for(typename i_t386::iterator i = 1 .begin(); i != 1 .end();
++i) {

So closing as funny/interesting, but still invalid.


-- 

reichelt at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |reichelt at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug c++/20682] lost parser

[igodard at pacbell dot net]

------- Comment #12 from igodard at pacbell dot net  2007-04-10 02:45 -------
Funny indeed - that's a scream :-)


-- 


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

[Bug c++/20682] lost parser

[pinskia at gcc dot gnu dot org]

------- Comment #13 from pinskia at gcc dot gnu dot org  2007-04-10 03:40 -------
You can use -pedantic to get rid of the automatically defining of i386 or use
-Ui386.


-- 


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

[Bug c++/20682] New: lost parser

[igodard at pacbell dot net]

The attachments are a pair of compiler output/source code runs. The "good" ones
compile OK; the "bad" ones report errors. The difference? One blank line of
whitespace. And the reported errors are in a function about ten functions below
where the whitespace change is. Use diff to see where - it's in the second
function named "equate(".

I've seen a lot of bugs in gcc, but I don't think I've ever seen one that
depended on whitespace :-)

Ivan

-- 
           Summary: lost parser
           Product: gcc
           Version: 3.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: igodard at pacbell dot net
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug c++/20682] lost parser

[igodard at pacbell dot net]

------- Additional Comments From igodard at pacbell dot net  2005-03-29 11:37 -------
Created an attachment (id=8483)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8483&action=view)
compiler output (-v) - bad


-- 


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

[Bug c++/20682] lost parser

[igodard at pacbell dot net]

------- Additional Comments From igodard at pacbell dot net  2005-03-29 11:37 -------
Created an attachment (id=8484)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8484&action=view)
compiler output (-v) - good


-- 


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

[Bug c++/20682] lost parser

[igodard at pacbell dot net]

------- Additional Comments From igodard at pacbell dot net  2005-03-29 11:38 -------
Created an attachment (id=8485)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8485&action=view)
source code (-save-temps, compressed) - bad


-- 


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

[Bug c++/20682] lost parser

[igodard at pacbell dot net]

------- Additional Comments From igodard at pacbell dot net  2005-03-29 11:38 -------
Created an attachment (id=8486)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8486&action=view)
source code (-save-temps, compressed) - good


-- 


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

[Bug c++/20682] lost parser

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #8484|application/octet-stream    |text/plain
          mime type|                            |


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

[Bug c++/20682] lost parser

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #8483|application/octet-stream    |text/plain
          mime type|                            |


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

[Bug c++/20682] lost parser

[pinskia at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2852 bytes --]


------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 15:59 -------
One thing, this is definitely invalid code:
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: 
âboost::detail::dynamic_bitset_base<long unsigned int, std::allocator<long 
unsigned int> >::<anonymous enum>â is/uses anonymous type
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error:   
trying to instantiate âtemplate<class T> template<class Arg> T operator+(T, Arg)
â
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: 
âboost::detail::dynamic_bitset_base<long unsigned int, std::allocator<long 
unsigned int> >::<anonymous enum>â is/uses anonymous type
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error:   
trying to instantiate âtemplate<class T> template<class Arg> T operator+(T, Arg)
â
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: 
âboost::detail::dynamic_bitset_base<long unsigned int, std::allocator<long 
unsigned int> >::<anonymous enum>â is/uses anonymous type
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error:   
trying to instantiate âtemplate<class T> template<class Arg> T operator+(T, Arg)
â
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: 
âboost::detail::dynamic_bitset_base<long unsigned int, std::allocator<long 
unsigned int> >::<anonymous enum>â is/uses anonymous type
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error:   
trying to instantiate âtemplate<class T> template<class Arg> T operator+(T, Arg)
â
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: 
âboost::detail::dynamic_bitset_base<long unsigned int, std::allocator<long 
unsigned int> >::<anonymous enum>â is/uses anonymous type
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error:   
trying to instantiate âtemplate<class T> template<class Arg> T operator+(T, Arg)
â
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: 
âboost::detail::dynamic_bitset_base<long unsigned int, std::allocator<long 
unsigned int> >::<anonymous enum>â is/uses anonymous type
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error:   
trying to instantiate âtemplate<class T> template<class Arg> T operator+(T, Arg)
â
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error: 
âboost::detail::dynamic_bitset_base<long unsigned int, std::allocator<long 
unsigned int> >::<anonymous enum>â is/uses anonymous type
/home/ivan/ootbc/boost/include/boost/detail/dynamic_bitset.hpp:91: error:   
trying to instantiate âtemplate<class T> template<class Arg> T operator+(T, Arg)
â

Well the reduced testcase might not be though.

-- 


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

[Bug c++/20682] lost parser

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 16:01 -------
The code around the problem:
     typedef typeof(to(0, models.size())) i_t386;
      i_t386& a;

-- 


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

[Bug c++/20682] lost parser

[igodard at pacbell dot net]

------- Additional Comments From igodard at pacbell dot net  2005-03-29 21:03 -------
Re comment #5: I don't get the messages reported by Andrew, and I really rather
doubt that those messages (form a different compiler version than I'm using) are
legit. They are flagging stuff inside a stock "boost" library, and I have some
confidence that boost stuff is OK. Looks to me that whatever the bug is it
causes the compiler to start complaining at a random point in the source - with
my 3.4.0 the complaint is in my own code, with Andrew's it's in a boost library,
but both complaints are bogus.

Just a suspicion.



-- 


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

[Bug c++/20682] lost parser

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 21:11 -------
(In reply to comment #7)
> Re comment #5: I don't get the messages reported by Andrew, and I really rather
> doubt that those messages (form a different compiler version than I'm using) are
> legit. They are flagging stuff inside a stock "boost" library, and I have some
> confidence that boost stuff is OK. Looks to me that whatever the bug is it
> causes the compiler to start complaining at a random point in the source - with
> my 3.4.0 the complaint is in my own code, with Andrew's it's in a boost library,
> but both complaints are bogus.

The error messages are correct as far as I know.  I am using the mainline (as of a couple of days ago).
The error in Boost I think are fixed in a newer version of Boost.
I will try to reduce this later tonight, it just will take me a while because I have to remove all the invalid 
code.

-- 


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

[Bug c++/20682] lost parser

[igodard at pacbell dot net]

------- Additional Comments From igodard at pacbell dot net  2005-03-29 21:19 -------
Andrew - can you confirm getting the same problem I do if you run it in 3,4,0?


-- 


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

[Bug c++/20682] lost parser

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-03-29 21:25 -------
(In reply to comment #9)
> Andrew - can you confirm getting the same problem I do if you run it in 3,4,0?

yes which is why I pointed out in comment #6 the code around where the problem is.

-- 


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