[Bug c++/29834] g++ thinks it is a declaration when it cannot be

[Bug c++/29834] g++ thinks it is a declaration when it cannot be

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ace.of.zerosync at gmail
                   |                            |dot com

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-10-11 21:54:39 UTC ---
*** Bug 54905 has been marked as a duplicate of this bug. ***

[Bug c++/29834] g++ thinks it is a declaration when it cannot be

[ace.of.zerosync at gmail dot com]

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

--- Comment #6 from M.S. Babaei <ace.of.zerosync at gmail dot com> ---
Hi,

I'm wondering if this bug is ever going to be fixed?

Unfortunately I don't know C and do not understand how inner parts of GCC
works. But, it's mid 2013 and the bug first appeared on late 2006, with another
duplicate in 2012. Which is also a blocker for another bug.

It really bothers me, because I use GCC, Clang and VC++ at the same time. And I
should put GCC specific #ifdefs and disable part of my code's functionality on
GCC due to this bug. Both Clang and VC++ do not have this bug.

Regards,
M.S. Babaei

[Bug c++/29834] g++ thinks it is a declaration when it cannot be

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
You can use list-initialization to workaround it:

  Doh{x}, ++x;

[Bug c++/29834] g++ thinks it is a declaration when it cannot be

[ace.of.zerosync at gmail dot com]

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

--- Comment #8 from M.S. Babaei <ace.of.zerosync at gmail dot com> ---
(In reply to Jonathan Wakely from comment #7)
> You can use list-initialization to workaround it:
> 
>   Doh{x}, ++x;

Thanks for the reply. Yeah, it did the trick for GCC 4.4+. And, I've never
thought of that.

But this is a bug, and I see no reason why it hasn't been fixed anyway.
However, your solution works fine with only C++11 enabled projects. Although,
this is not a problem for me, because it has been virtually three years that my
default mode for any new project is C++11. But, it might still be a problem for
others.

Thanks again, you saved me a lot of headaches.

[Bug c++/29834] g++ thinks it is a declaration when it cannot be

[james.kanze at gmail dot com]

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

--- Comment #9 from James Kanze <james.kanze at gmail dot com> ---
Re using the init list syntax: it won't work if you have to be compatible with
other compilers (like Sun CC).  Using something like (Doh (x)), ++x seems to be
the most portable work-around.

[Bug c++/29834] g++ thinks it is a declaration when it cannot be

[manu at gcc dot gnu.org]

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

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

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

--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to M.S. Babaei from comment #8)
> But this is a bug, and I see no reason why it hasn't been fixed anyway.

I see plenty of reasons: It is a obscure bug, there are easy work-arounds,
there are very few G++ developers (maybe 4-5 sporadic and two full-time? I am
not even sure they are actually full-time...), and there are literally
thousands of other bugs requiring attention. Any help would be welcome.

> Unfortunately I don't know C and do not understand how inner parts of GCC works.

G++ is written in C++. The C++ FE is mostly isolated from other parts of the
compiler and the parser is almost solely contained in gcc/cp/parser.c. If you
know enough C++, you should be able to follow what it does. I am not saying it
is pretty or easy, but it is doable. If you can use a debugger, you could
figure out why g++ is getting confused here and what it should do instead.
>From gcc-bugs-return-425597-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 02 17:23:18 2013
Return-Path: <gcc-bugs-return-425597-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8066 invoked by alias); 2 Jul 2013 17:23:17 -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 8010 invoked by uid 48); 2 Jul 2013 17:23:08 -0000
From: "mtodorov3_69 at yahoo dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug driver/57784] New: GCC inadvertedly truncates source text
Date: Tue, 02 Jul 2013 17:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: driver
X-Bugzilla-Version: 4.7.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: mtodorov3_69 at yahoo 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-57784-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: 2013-07/txt/msg00104.txt.bz2
Content-length: 969

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW784

            Bug ID: 57784
           Summary: GCC inadvertedly truncates source text
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: driver
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mtodorov3_69 at yahoo dot com

The example goes as follows:

The line:

# gcc -o mypatch mypatch.cc -lstdc++

is mistyped as:

# gcc -o mypatch.cc -lstdc++

GCC complains about no main() and truncates the C++ source to zero length!

Correct would be to complain about wrong number of arguments before doing any
action on mypatch.cc.
Would it hurt to check suffix of the file referenced by "-o" option, if it is
common that object file is overwritten? Few executables' names end with ".cc"
or ".c".

Fortunatelly, the source was recovered with minimal loss of changes from backup
location :-)

Greetz,
mt

[Bug c++/29834] g++ thinks it is a declaration when it cannot be

[ace.of.zerosync at gmail dot com]

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

--- Comment #11 from M.S. Babaei <ace.of.zerosync at gmail dot com> ---
(In reply to James Kanze from comment #9)
> Re using the init list syntax: it won't work if you have to be compatible
> with other compilers (like Sun CC).  Using something like (Doh (x)), ++x
> seems to be the most portable work-around.

Of course I've already put some #ifdefs for GCC with init lists and rest of the
compilers using the old good code.

[Bug c++/29834] g++ thinks it is a declaration when it cannot be

[ace.of.zerosync at gmail dot com]

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

--- Comment #12 from M.S. Babaei <ace.of.zerosync at gmail dot com> ---
(In reply to Manuel López-Ibáñez from comment #10)
> (In reply to M.S. Babaei from comment #8)
> > But this is a bug, and I see no reason why it hasn't been fixed anyway.
> 
> I see plenty of reasons: It is a obscure bug, there are easy work-arounds,
> there are very few G++ developers (maybe 4-5 sporadic and two full-time? I
> am not even sure they are actually full-time...), and there are literally
> thousands of other bugs requiring attention. Any help would be welcome.
> 
> > Unfortunately I don't know C and do not understand how inner parts of GCC works.
> 
> G++ is written in C++. The C++ FE is mostly isolated from other parts of the
> compiler and the parser is almost solely contained in gcc/cp/parser.c. If
> you know enough C++, you should be able to follow what it does. I am not
> saying it is pretty or easy, but it is doable. If you can use a debugger,
> you could figure out why g++ is getting confused here and what it should do
> instead.

Thanks for the answer, I'll give it a shot.
>From gcc-bugs-return-425626-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jul 02 21:54:48 2013
Return-Path: <gcc-bugs-return-425626-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21213 invoked by alias); 2 Jul 2013 21:54:47 -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 21176 invoked by uid 48); 2 Jul 2013 21:54:43 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57746] Invalid specializations of member objects are accepted, unlike member functions
Date: Tue, 02 Jul 2013 21: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.7.2
X-Bugzilla-Keywords: accepts-invalid
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle 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: bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-57746-4-Zhh8iRyH1b@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57746-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57746-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: 2013-07/txt/msg00133.txt.bz2
Content-length: 406

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW746

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-07-02
     Ever confirmed|0                           |1

[Bug c++/29834] g++ thinks it is a declaration when it cannot be

[ace.of.zerosync at gmail dot com]

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

--- Comment #13 from M.S. Babaei <ace.of.zerosync at gmail dot com> ---
(In reply to James Kanze from comment #9)
> Re using the init list syntax: it won't work if you have to be compatible
> with other compilers (like Sun CC).  Using something like (Doh (x)), ++x
> seems to be the most portable work-around.

Sorry, I didn't get your answer at first sight. Actually your elegant
workaround is the most portable way. And, works on all compilers, too. Even
pre-C++11 era compilers.

Thanks.

[Bug c++/29834] g++ thinks it is a declaration when it cannot be

[pinskia at gcc dot gnu.org]

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

--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 113812 has been marked as a duplicate of this bug. ***

[Bug c++/29834] g++ thinks it is a declaration when it cannot be

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

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

--- Comment #15 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
A nice short test from Bug 113812:

void f(int x)
{
    int(x), 0;
}

I recently fixed similar problems (with auto(x)), so I suppose I ought to take
a look.

[Bug c++/29834] New: g++ thinks it is a declaration when it cannot be

[james dot kanze at gmail dot com]

More cases where g++ apparently doesn't take
enough context into account when deciding that
something can be (and thus is) a declaration.

Compiled the following (legal) program using "g++ -c"
---------------------------------------
struct Doh
{
    Doh( int ) {}
} ;

int x = 0 ;

int
f()
{
    Doh( x ), ++ x ;
    return Doh( x ), x ;
}
---------------------------------------
Got following errors:
---------------------------------------
parseError.cc: In function 'int f()':
parseError.cc:11: error: no matching function for call to 'Doh::Doh()'
parseError.cc:3: note: candidates are: Doh::Doh(int)
parseError.cc:2: note:                 Doh::Doh(const Doh&)
parseError.cc:11: error: expected unqualified-id before '++' token
parseError.cc:12: error: cannot convert 'Doh' to 'int' in return
---------------------------------------
Apparently, g++ is interpreting Doh( x ) as a declaration,
although in neither case is a declaration legal.  (++x is not a
legal declarator, so the first line cannot be a declaration, and
of course, a declaration cannot start with the keyword return.)

(Note that in the actual code, Doh was boost::mutex::scoped_lock.
And I fear that using boost::mutex::scoped_lock like this is becoming
a widespread idiom.)


-- 
           Summary: g++ thinks it is a declaration when it cannot be
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: james dot kanze at gmail dot com
 GCC build triplet: sparc-sun-solaris2.8
  GCC host triplet: sparc-sun-solaris2.8
GCC target triplet: sparc-sun-solaris2.8


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

[Bug c++/29834] g++ thinks it is a declaration when it cannot be

[rguenth at gcc dot gnu dot org]

------- Comment #1 from rguenth at gcc dot gnu dot org  2006-11-14 21:33 -------
I you use

 ( Doh ( x ) ), ++ x;

it works.  (EDG accepts the code unmodified)


-- 


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

[Bug c++/29834] g++ thinks it is a declaration when it cannot be

[bangerth at dealii dot org]

------- Comment #2 from bangerth at dealii dot org  2006-11-15 01:59 -------
Confirmed.


> (Note that in the actual code, Doh was boost::mutex::scoped_lock.
> And I fear that using boost::mutex::scoped_lock like this is becoming
> a widespread idiom.)

Ugh, this isn't an easy to read idiom...

W.


-- 

bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bangerth at dealii dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-11-15 01:59:29
               date|                            |


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

[Bug c++/29834] g++ thinks it is a declaration when it cannot be

[james dot kanze at gmail dot com]

------- Comment #3 from james dot kanze at gmail dot com  2006-11-15 10:05 -------
Subject: Re:  g++ thinks it is a declaration when it cannot be

On 14 Nov 2006 21:33:34 -0000, rguenth at gcc dot gnu dot org
<gcc-bugzilla@gcc.gnu.org> wrote:

> I you use

>  ( Doh ( x ) ), ++ x;

> it works.

I know.  I don't consider it a critical error, but it is legal
code, so formally, at least, the compiler should accept it.

> (EDG accepts the code unmodified)

So does Sun CC and VC++.

If I remember correctly, in the past, g++ has had problems with
opting too soon for the declaration, before having seen enough
of the context to know that it couldn't be.  I suspect that this
is just a case of the correction having missed a couple of
cases.


-- 


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

[Bug c++/29834] g++ thinks it is a declaration when it cannot be

[james dot kanze at gmail dot com]

------- Comment #4 from james dot kanze at gmail dot com  2006-11-15 10:10 -------
Subject: Re:  g++ thinks it is a declaration when it cannot be

On 15 Nov 2006 01:59:33 -0000, bangerth at dealii dot org
<gcc-bugzilla@gcc.gnu.org> wrote:

> > (Note that in the actual code, Doh was
> > boost::mutex::scoped_lock.  And I fear that using
> > boost::mutex::scoped_lock like this is becoming a widespread
> > idiom.)

> Ugh, this isn't an easy to read idiom...

Not sure I like it myself.  It has two advantages: you don't
have to invent a name for a variable that you are never going to
use, and you don't have to add braces to limit the scope of the
lock.  Very meager advantages, IMHO: it doesn't bother me to
just throw in any short name (e.g. 'l') in such cases, and if
the function is large enough to require the extra braces, it's
probably too large and complicated anyway.

But I'm not the only programmer in the world, and some people
seem to actually like it.  And... I'll use it too, in quick
hacks in throw-away code.


-- 


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