[Bug c/61854] New: Warning single-line comment for -std=c89?

[Bug c/61854] New: Warning single-line comment for -std=c89?

[chengniansun at gmail dot com]

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

            Bug ID: 61854
           Summary: Warning single-line comment for -std=c89?
           Product: gcc
           Version: 4.10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: chengniansun at gmail dot com

Currently there is no warning on single-line comments for -std=c89. For
example, when I am compiling the following code extracted from SPEC, GCC emits
several errors and Clang emits a warning saying that the single-line comment is
not supported in the c89 language. IMHO, it is worth considering to emit such a
warning, as it is the root cause of the errors, making it easier to understand
the errors. 

$: cat t.c
#include <stdio.h>

void
_E_pr_info_header(char const *f, long ln, char const *msg)                      
{                                                                               
  //SPEC lots of informationals are printed for validation; use stdout          
  //     intead of stderr so as to prefer buffered io                           

      /* make different format so as not to be parsed by emacs compile */       
      (void) fprintf(stdout, "%s: %s(%ld): ", msg, f, ln);                      
}                                                                               

$: gcc-trunk -c -pedantic -Wall -Wextra -std=c89 t.c
t.c: In function ‘_E_pr_info_header’:
t.c:6:3: error: expected expression before ‘/’ token
   //SPEC lots of informationals are printed for validation; use stdout         
   ^
t.c:6:61: error: unknown type name ‘use’
   //SPEC lots of informationals are printed for validation; use stdout         
                                                             ^
t.c:7:3: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘/’
token
   //     intead of stderr so as to prefer buffered io                          
   ^
t.c:6:61: warning: ISO C90 forbids mixed declarations and code [-Wpedantic]
   //SPEC lots of informationals are printed for validation; use stdout         
                                                             ^
t.c:4:31: warning: unused parameter ‘f’ [-Wunused-parameter]
 _E_pr_info_header(char const *f, long ln, char const *msg)                     
                               ^
t.c:4:39: warning: unused parameter ‘ln’ [-Wunused-parameter]
 _E_pr_info_header(char const *f, long ln, char const *msg)                     
                                       ^
t.c:4:55: warning: unused parameter ‘msg’ [-Wunused-parameter]
 _E_pr_info_header(char const *f, long ln, char const *msg)                     
                                                       ^


$: clang-trunk -c -pedantic -Wcomment -std=c89 t.c
t.c:6:3: warning: // comments are not allowed in this language [-Wcomment]
  //SPEC lots of informationals are printed for validation; use stdout          
  ^
1 warning generated.
>From gcc-bugs-return-456784-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jul 20 01:50:57 2014
Return-Path: <gcc-bugs-return-456784-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8491 invoked by alias); 20 Jul 2014 01:50:55 -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 1892 invoked by uid 48); 20 Jul 2014 01:50:18 -0000
From: "kumba at gentoo dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61538] g++ compiled binary, linked to glibc libpthread, hangs on SGI MIPS R1x000 systems on Linux
Date: Sun, 20 Jul 2014 01:50: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.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: kumba at gentoo 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:
Message-ID: <bug-61538-4-2cw9AHXSuN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61538-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61538-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-07/txt/msg01375.txt.bz2
Content-length: 3313

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

--- Comment #16 from Joshua Kinard <kumba at gentoo dot org> ---
(In reply to Andrew Pinski from comment #15)
> (In reply to Joshua Kinard from comment #14)
> > (In reply to Andrew Pinski from comment #13)
> > > What is the kernel version?  There has been some recent (this year) fixes
> > > inside the kernel for futex.
> > >
> > > Though I admit I have seen this just recently when debugging a program where
> > > I did next over a pthread_mutex_unlock call.
> >
> > Was under 3.14.x.  I already tried going back to 3.14.0, due to the recent
> > futex security flaws covered in CVE-2014-3153.  Now on 3.15.5 on the Octane,
> > and my test binaries still hang, so I've pretty much ruled out it being the
> > kernel.
> >
> > I've been doing a git bisect of gcc the last few days, and I've pinned the
> > problem commit down to somewhere between Jun 12 2012 and June 26 2012.
> > anything prior to the 26th works so far, anything after doesn't.  My current
> > bisect build is going to test June 19 2012 next.  Averages about ~7.5hrs for
> > gcc and 3.5hrs for glibc to build, so I can cram in roughly, 2 tests a day.
>
> I would try the daily date update right before
> 30c3c4427521f96fb58b6e1debb86da4f113f06f commit and then bispect from there
> because there are a few changes between the daily date update which could
> have caused this issue.

So I spent the last week bisecting as far as I can, but right around 20120620,
I keep running into the same build failure about ~3hrs into the build:

In file included from ../.././gcc/config/mips/mips.c:31:0:
../.././gcc/config/mips/mips.c: In function 'void mips_process_sync_loop(rtx,
rtx_def**)':
../.././gcc/rtl.h:632:48: error: invalid conversion from 'long long int' to
'memmodel' [-fpermissive]
 #define XCWINT(RTX, N, C)     ((RTX)->u.hwint[N])

In 'all-stage2-gcc'.  That's right around the commit you're referencing, so I
went ahead and reversed these four commits:

1. 39a8c5eaded1e5771a941c56a49ca0a5e9c5eca0  * config/mips/mips.c
(mips_emit_pre_atomic_barrier_p,)
2. 974f0a74e2116143b88d8cea8e1dd5a9c18ef96c  * config/mips/constraints.md (ZR):
New constraint.
3. 0f8e46b16a53c02d7255dcd6b6e9b5bc7f8ec953  * config/mips/mips.c
(mips_process_sync_loop): Emit cmp result only if
4. 30c3c4427521f96fb58b6e1debb86da4f113f06f  * emit-rtl.c
(need_atomic_barrier_p): New function.

And am going to rebuild again and see if it either compiles or not.  If it does
compile, I'll rebuild glibc and see if the 'sln' binary works.  If so, then we
have the bad commits.  I think all four of them go together, so I don't know if
I can undo only one at a time.  Thoughts?  If I can save a day or two of
compiling, that'd be great.  Though, if these four are the problem, I still
have to find a way to undo them from at least 4.8.3 to verify the c++-side of
things w/ my original -lpthreads testcase.  But I don't know how deeply
ingrained these commits are now after ~2 years.

I am guessing the changes don't impact newer MIPS processors, but I am still
not sure why it's affecting only the R1x000-family.  I've looked over the
errata sheets I have, but nothing sticks out as a possible cause.  I doubt
these four commits can just be reversed entirely.  The actual problem has to be
found and worked around.

[Bug c/61854] Warning single-line comment for -std=c89?

[harald at gigawatt dot nl]

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

Harald van Dijk <harald at gigawatt dot nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |harald at gigawatt dot nl

--- Comment #2 from Harald van Dijk <harald at gigawatt dot nl> ---
(In reply to Manuel López-Ibáñez from comment #1)
> Perhaps GCC should accept // without comment unless -Wpedantic. The current
> error is nonsensical.

The point of the -std=c89 option is that if a program is valid C89, GCC will
accept it in that mode. Extensions that don't conflict with the standard are
enabled without any diagnostic unless -pedantic is also passed. Extensions that
do conflict with the standard are disabled. // comments are an extension that
conflicts with the standard, so should not be enabled. A C89+extensions mode
already exists, that's what -std=gnu89 (the default mode) does. Example
program:

int main() {
  return 1 //**/ 2
    ;
}

C89 requires this to return zero, and gcc -std=c89 does correctly make this
return zero. gcc -std=gnu89 makes this return 1. (More realistically, enabling
// comments could cause GCC to reject valid code as having syntax errors where
there are none.)

The request in this bug report does make sense to me: if GCC detects a syntax
error in c89 mode, and the syntax error is caused by an unexpected / token that
immediately follows another / token, it would make sense to treat that as a
special case. Handling it only when there is an error will not cause valid code
to be rejected.
>From gcc-bugs-return-456816-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jul 20 19:53:05 2014
Return-Path: <gcc-bugs-return-456816-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29817 invoked by alias); 20 Jul 2014 19:53:03 -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 29376 invoked by uid 48); 20 Jul 2014 19:52:52 -0000
From: "jvdelisle at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/61632] Memory corruption on error when writing formatted data
Date: Sun, 20 Jul 2014 19:53:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jvdelisle at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jvdelisle at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-61632-4-zj0XYY11tM@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61632-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61632-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-07/txt/msg01407.txt.bz2
Content-length: 851

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

--- Comment #23 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #22)

>
> (1) my understanding of
>
>   offset = (j > 60) ? j - 40 : 0;
>
>   j -= offset;
>   width = dtp->format_len - offset;
>
> is to set j to 40 and to decrease width by j-40 if j>60.
>
> This part is now removed, should not we limit offset to something?
>
Yes, I would like to first commit the patch and then work on this additional
part.  Ideally, if we have a long format string and the error occurs beyond a
typical line length of 80 we should 'slide' the view of the format string and
the carat along so the user can see where and in what context. Very doable, now
that we have the other problem taken care of.

Your other question I am still thinking about. ;)

[Bug c/61854] Warning single-line comment for -std=c89?

[mpolacek at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |mpolacek at gcc dot gnu.org
           Assignee|unassigned at gcc dot gnu.org      |mpolacek at gcc dot gnu.org
   Target Milestone|---                         |5.0

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I have a potential fix.

[Bug c/61854] Warning single-line comment for -std=c89?

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Author: mpolacek
Date: Wed Sep 17 21:49:46 2014
New Revision: 215339

URL: https://gcc.gnu.org/viewcvs?rev=215339&root=gcc&view=rev
Log:
    PR c/61854
libcpp/
    * init.c (struct lang_flags): Remove cplusplus_comments.
    (cpp_set_lang): Likewise.
    (post_options): Likewise.
    * lex.c (_cpp_lex_direct): Disallow C++ style comments in C90/C94.
testsuite/
    * gcc.dg/cpp/pr61854-1.c: New test.
    * gcc.dg/cpp/pr61854-2.c: New test.
    * gcc.dg/cpp/pr61854-3.c: New test.
    * gcc.dg/cpp/pr61854-3.h: New test.
    * gcc.dg/cpp/pr61854-4.c: New test.
    * gcc.dg/cpp/pr61854-5.c: New test.
    * gcc.dg/cpp/pr61854-6.c: New test.
    * gcc.dg/cpp/pr61854-7.c: New test.
    * gcc.dg/cpp/pr61854-c90.c: New test.
    * gcc.dg/cpp/pr61854-c94.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/cpp/pr61854-1.c
    trunk/gcc/testsuite/gcc.dg/cpp/pr61854-2.c
    trunk/gcc/testsuite/gcc.dg/cpp/pr61854-3.c
    trunk/gcc/testsuite/gcc.dg/cpp/pr61854-3.h
    trunk/gcc/testsuite/gcc.dg/cpp/pr61854-4.c
    trunk/gcc/testsuite/gcc.dg/cpp/pr61854-5.c
    trunk/gcc/testsuite/gcc.dg/cpp/pr61854-6.c
    trunk/gcc/testsuite/gcc.dg/cpp/pr61854-7.c
    trunk/gcc/testsuite/gcc.dg/cpp/pr61854-c90.c
    trunk/gcc/testsuite/gcc.dg/cpp/pr61854-c94.c
Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/libcpp/ChangeLog
    trunk/libcpp/init.c
    trunk/libcpp/lex.c

[Bug c/61854] Warning single-line comment for -std=c89?

[mpolacek at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Should be fixed now.