[Bug fortran/52347] New: -Wno-tabs -Wall -Wno-tabs still warns about tabs

[Bug fortran/52347] New: -Wno-tabs -Wall -Wno-tabs still warns about tabs

[burnus at gcc dot gnu.org]

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

             Bug #: 52347
           Summary: -Wno-tabs -Wall -Wno-tabs still warns about tabs
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org


With mosts flags, a flag which is implied by another flag can be overridden by
the specific flag. For instance -f(no-)protect-parens overriddes the settings
of -O0 (protected) or -Ofast (unprotected parentheses).

However, for tab warnings -Wno-tabs cannot be used to turn off the warning,
enabled by -Wall.

I wouldn't be surprised if that also holds for other warnings, enabled by -Wall
or -Wextra.

Found at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/9942915c9c41b151

[Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs

[manu at gcc dot gnu.org]

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

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

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

--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-02-23 08:37:08 UTC ---
(In reply to comment #0)
> However, for tab warnings -Wno-tabs cannot be used to turn off the warning,
> enabled by -Wall.
> 
> I wouldn't be surprised if that also holds for other warnings, enabled by -Wall
> or -Wextra.
> 
> Found at
> http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/9942915c9c41b151

Sure, it happens with many flags in fact, not only in Fortran, since -Wall
either does not check whether the flag was already initialized, or it sets the
value too early. Ideally, flags that enable other flags should be checked last,
and they should only touch flags that haven't been set already in the
command-line. But this is only done on a case-by-case basis by using -1 as
starting value (I did it mostly for -Wextra, -Wunused, and -Wimplicit). It
would be nice that the options handling code would take care of this, by
specifying the relations in *.opt files.

[Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs

[Simon.Richter at hogyros dot de]

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

Simon Richter <Simon.Richter at hogyros dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Simon.Richter at hogyros dot de

--- Comment #2 from Simon Richter <Simon.Richter at hogyros dot de> ---
In 4.8, this causes build failures for me:

$ g++ -g -Wall -W -Werror -Wno-unused -I. -o stage1/tree_bison_lex.o -c
tree_bison_lex.cpp
tree_bison_lex.cpp:1744:13: error: unused parameter 'yyscanner'
[-Werror=unused-parameter]

As can be guessed from the name, this is a file that is generated from flex,
which is why I've added -Wno-unused for this file specifically.

4.7 did not warn.

[Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs

[manu at gcc dot gnu.org]

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

--- Comment #3 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Simon Richter from comment #2)
> In 4.8, this causes build failures for me:
> 
> $ g++ -g -Wall -W -Werror -Wno-unused -I. -o stage1/tree_bison_lex.o -c
> tree_bison_lex.cpp
> tree_bison_lex.cpp:1744:13: error: unused parameter 'yyscanner'
> [-Werror=unused-parameter]

Could you attach a self-contained preprocessed testcase?
See http://gcc.gnu.org/bugs/
>From gcc-bugs-return-424380-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 14 21:41:19 2013
Return-Path: <gcc-bugs-return-424380-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5479 invoked by alias); 14 Jun 2013 21:41:19 -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 5459 invoked by uid 48); 14 Jun 2013 21:41:15 -0000
From: "gdjss2728 at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/57619] New: std::unordered_map and std::unordered_multimap::insert invoking std::pair move constructor
Date: Fri, 14 Jun 2013 21:41:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: gdjss2728 at gmail 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-57619-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-06/txt/msg00759.txt.bz2
Content-length: 1217

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

            Bug ID: 57619
           Summary: std::unordered_map and std::unordered_multimap::insert
                    invoking std::pair move constructor
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gdjss2728 at gmail dot com

The following code is invoking the std::pair move constructor:

int main ()
{
    std::unordered_map<std::string, std::string> mymap;
    std::unordered_multimap<std::string, std::string> mymultimap;
    std::pair<std::string, std::string> mypair{std::string("key"),
std::string("value")};
    mymultimap.insert(mypair); // std::pair move constructor invoked here
    mymap.insert(mypair); // strings already moved out!
}

This seems related to http://gcc.gnu.org/bugzilla/show_bug.cgi?idS657.

As far as I can tell, overload resolution is choosing `insert(_Pair&& __x)`
over `insert(const value_type& __x)`. Since this is an lvalue, the latter
should be chosen. This happens for std::unordered_map::insert and
std::unordered_multimap::insert.

[Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs

[Simon.Richter at hogyros dot de]

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

--- Comment #4 from Simon Richter <Simon.Richter at hogyros dot de> ---
Testcase is simple:

$ cat tt.cpp

void bar(int baz) { }

$ g++-4.7 -c -W -Wall -Werror -Wno-unused tt.cpp 

$ g++-4.8 -c -W -Wall -Werror -Wno-unused tt.cpp 
tt.cpp:1:6: error: unused parameter ‘baz’ [-Werror=unused-parameter]
 void bar(int baz) { }
      ^
cc1plus: all warnings being treated as errors
>From gcc-bugs-return-424389-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jun 14 23:19:34 2013
Return-Path: <gcc-bugs-return-424389-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25889 invoked by alias); 14 Jun 2013 23:19:34 -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 25861 invoked by uid 48); 14 Jun 2013 23:19:29 -0000
From: "ccoutant at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug rtl-optimization/57451] Incorrect debug ranges emitted for -freorder-blocks-and-partition -g
Date: Fri, 14 Jun 2013 23:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: rtl-optimization
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ccoutant at gcc dot gnu.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-57451-4-TmCZDYWLkd@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57451-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57451-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-06/txt/msg00768.txt.bz2
Content-length: 4046

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

--- Comment #4 from Cary Coutant <ccoutant at gcc dot gnu.org> ---
The problem is a lexical block in main() that appears to be getting split by
-freorder-blocks-and-partition, but when debug info is emitted during
rest_of_handle_final(), this particular lexical block still appears to be a
single block -- BLOCK_FRAGMENT_CHAIN is NULL, so the DWARF output code decides
that it can emit a DW_AT_low_pc/high_pc pair instead of a DW_AT_ranges. The
DW_AT_high_pc is now being output relative to DW_AT_low_pc, so we see an
assembly expression .LBE14 - .LBB14, which are labels attached to the block
start and block end, and should be in the same section.

Here's the block:

(gdb) p stmt
$1 = (tree) 0x7ffff5f4c4b0
(gdb) pt
warning: Expression is not an assignment (and might have no effect)
 <block 0x7ffff5f4c4b0 asm_written used
    vars <var_decl 0x7ffff608bc78 e
        type <reference_type 0x7ffff609b930 type <record_type 0x7ffff608e9d8
MyException>
            sizes-gimplified unsigned DI
            size <integer_cst 0x7ffff5f24dc0 constant 64>
            unit size <integer_cst 0x7ffff5f24de0 constant 8>
            align 64 symtab 0 alias set -1 canonical type 0x7ffff609b930>
        readonly tree_1 tree_3 unsigned decl_5 DI file pr49115.C line 21 col 25
size <integer_cst 0x7ffff5f24dc0 64> unit size <integer_cst 0x7ffff5f24de0 8>
        align 64 context <function_decl 0x7ffff6096f00 main>>
    supercontext <block 0x7ffff60c00f0 asm_written used
        vars <var_decl 0x7ffff608bb48 data type <record_type 0x7ffff608ec78
Data>
            used tree_1 tree_3 decl_5 SI file pr49115.C line 18 col 8
            size <integer_cst 0x7ffff5f42140 constant 32>
            unit size <integer_cst 0x7ffff5f42160 constant 4>
            align 128 context <function_decl 0x7ffff6096f00 main>
            (reg/v:SI 64 [ data ])>
        supercontext <block 0x7ffff5f4c550 asm_written used supercontext
<function_decl 0x7ffff6096f00 main>
            subblocks <block 0x7ffff5f4c500 asm_written used vars <var_decl
0x7ffff608bb48 data> supercontext <block 0x7ffff5f4c550> subblocks <block
0x7ffff5f4c4b0> chain <block 0x7ffff60c00f0>>>>>

(gdb) p stmt->block
$2 = {base = {code = BLOCK, side_effects_flag = 0, constant_flag = 0,
addressable_flag = 0,
    volatile_flag = 0, readonly_flag = 0, asm_written_flag = 1, nowarning_flag
= 0, visited = 0,
    used_flag = 1, nothrow_flag = 0, static_flag = 0, public_flag = 0,
private_flag = 0,
    protected_flag = 0, deprecated_flag = 0, default_def_flag = 0, u = {bits {lang_flag_0 = 0,
        lang_flag_1 = 0, lang_flag_2 = 0, lang_flag_3 = 0, lang_flag_4 = 0,
lang_flag_5 = 0,
        lang_flag_6 = 0, saturating_flag = 0, unsigned_flag = 0, packed_flag 0, user_align = 0,
        nameless_flag = 1, spare0 = 0, spare1 = 0, address_space = 0}, length 2048,
      version = 2048}}, chain = 0x0, abstract_flag = 0, block_num = 14, locus 0,
  vars = 0x7ffff608bc78, nonlocalized_vars = 0x0, subblocks = 0x0, supercontext
= 0x7ffff60c00f0,
  abstract_origin = 0x0, fragment_origin = 0x0, fragment_chain = 0x0}

Here's the fragment of assembly code between .LBB14 and .LBE14:

.LBB14:
        # pr49115.C:21
        .loc 1 21 0
        call    __cxa_begin_catch
.LVL7:
        call    __cxa_end_catch
.LVL8:
        .p2align 4,,5
# SUCC: 3 [100.0%]  count:1
        jmp     .L15
        .cfi_endproc
        .section        .text.unlikely
        .cfi_startproc
        .cfi_personality 0x3,__gxx_personality_v0
        .cfi_lsda 0x3,.LLSDAC4
# BLOCK 6 freq:5000 seq:4
# PRED: 4 [50.0%]  (CROSSING,CAN_FALLTHRU)
.L14:
        .cfi_def_cfa_offset 16
        .p2align 4,,8
.LEHB1:
# SUCC:
        call    _Unwind_Resume
.LEHE1:
.LVL9:
.LBE14:
.LBE15:
        .cfi_endproc

You can see that the block from .LBB14 to .LBE14 has been split across two
sections. In order for dwarf2out to generate the proper debug info,
BLOCK_FRAGMENT_CHAIN(stmt) needs to be non-NULL. I'm not sure why that's not
happening when the block is split.

[Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Simon Richter from comment #4)
> Testcase is simple:
> 
> $ cat tt.cpp
> 
> void bar(int baz) { }
> 
> $ g++-4.7 -c -W -Wall -Werror -Wno-unused tt.cpp 
> 
> $ g++-4.8 -c -W -Wall -Werror -Wno-unused tt.cpp 
> tt.cpp:1:6: error: unused parameter ‘baz’ [-Werror=unused-parameter]
>  void bar(int baz) { }
>       ^
> cc1plus: all warnings being treated as errors

There is a bug in the logic of the autogenerated code:

      if (!opts_set->x_warn_unused_parameter && (opts->x_warn_unused &&
opts->x_extra_warnings))
          handle_generated_option (opts, opts_set,
                                   OPT_Wunused_parameter, NULL, value,
                                   lang_mask, kind, loc, handlers, dc);

When processing -Wno-unused, opts->x_warn_unused is false, so we don't turn off
OPT_Wunused_parameter. I think the generated code should be:


      if (!opts_set->x_warn_unused_parameter && opts->x_extra_warnings)

for case OPT_Wunused and


      if (!opts_set->x_warn_unused_parameter && opts->x_warn_unused)

for the case OPT_Wextra. So optc-gen.awk needs adjusting. Let me see if I can
find time to do this in the coming weeks/months, but if anyone wants to
investigate how to fix it, please go ahead.

I think this is a different bug than the -Wno-tabs, since that is not handled
by the autogenerated code.
>From gcc-bugs-return-424399-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jun 15 09:36:25 2013
Return-Path: <gcc-bugs-return-424399-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19836 invoked by alias); 15 Jun 2013 09:36:25 -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 19792 invoked by uid 48); 15 Jun 2013 09:36:22 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57622] New: -W -Wall -Werror -Wno-unused gives Wunused-parameter warning
Date: Sat, 15 Jun 2013 09:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.8.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.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 keywords bug_severity priority component assigned_to reporter cc dependson
Message-ID: <bug-57622-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg00778.txt.bz2
Content-length: 1974

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

            Bug ID: 57622
           Summary: -W -Wall -Werror -Wno-unused gives Wunused-parameter
                    warning
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Keywords: diagnostic
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: manu at gcc dot gnu.org
                CC: burnus at gcc dot gnu.org, manu at gcc dot gnu.org,
                    Simon.Richter at hogyros dot de
        Depends on: 52347

+++ This bug was initially created as a clone of Bug #52347 +++

Testcase is simple:

$ cat tt.cpp

void bar(int baz) { }

$ g++-4.7 -c -W -Wall -Werror -Wno-unused tt.cpp 

$ g++-4.8 -c -W -Wall -Werror -Wno-unused tt.cpp 
tt.cpp:1:6: error: unused parameter ‘baz’ [-Werror=unused-parameter]
 void bar(int baz) { }
      ^
cc1plus: all warnings being treated as errors

There is a bug in the logic of the autogenerated code:

      if (!opts_set->x_warn_unused_parameter && (opts->x_warn_unused &&
opts->x_extra_warnings))
          handle_generated_option (opts, opts_set,
                                   OPT_Wunused_parameter, NULL, value,
                                   lang_mask, kind, loc, handlers, dc);

When processing -Wno-unused, opts->x_warn_unused is false, so we don't turn off
OPT_Wunused_parameter. I think the generated code should be:


      if (!opts_set->x_warn_unused_parameter && opts->x_extra_warnings)

for case OPT_Wunused and


      if (!opts_set->x_warn_unused_parameter && opts->x_warn_unused)

for the case OPT_Wextra. So optc-gen.awk needs adjusting. Let me see if I can
find time to do this in the coming weeks/months, but if anyone wants to
investigate how to fix it, please go ahead.

I think this is a different bug than the -Wno-tabs, since that is not handled
by the autogenerated code.
>From gcc-bugs-return-424400-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jun 15 09:36:47 2013
Return-Path: <gcc-bugs-return-424400-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20523 invoked by alias); 15 Jun 2013 09:36: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 20489 invoked by uid 48); 15 Jun 2013 09:36:44 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57622] -W -Wall -Werror -Wno-unused gives Wunused-parameter warning
Date: Sat, 15 Jun 2013 09:36: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.8.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
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 cc everconfirmed
Message-ID: <bug-57622-4-t68PFRdMVt@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57622-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57622-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg00779.txt.bz2
Content-length: 477

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-06-15
                 CC|burnus at gcc dot gnu.org          |
     Ever confirmed|0                           |1
>From gcc-bugs-return-424401-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jun 15 09:39:15 2013
Return-Path: <gcc-bugs-return-424401-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 22918 invoked by alias); 15 Jun 2013 09:39:15 -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 22883 invoked by uid 48); 15 Jun 2013 09:39:12 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs
Date: Sat, 15 Jun 2013 09:39: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.7.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.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: cc blocked
Message-ID: <bug-52347-4-i1geEaUCut@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52347-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52347-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg00780.txt.bz2
Content-length: 640

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

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

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

--- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
I created bug 52347 to track the autogenerated code issue. This bug should be
fixed if Fortran's -Wall is moved to the autogenerated method of handling group
options (see options.texi)
>From gcc-bugs-return-424402-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jun 15 09:54:04 2013
Return-Path: <gcc-bugs-return-424402-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26910 invoked by alias); 15 Jun 2013 09:54:04 -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 26858 invoked by uid 48); 15 Jun 2013 09:53:54 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57620] Phantom terminator confuses raw string literal parsing.
Date: Sat, 15 Jun 2013 09: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.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.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-57620-4-Ug94S2Mep4@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57620-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57620-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-06/txt/msg00781.txt.bz2
Content-length: 497

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
There seems to be more issues in the raw string literal lexing.  E.g.
const char *s = R"a??/(x)a??/";
should be I think handled the same as
const char *s = "x";
with -std=c++11 or -std=gnu++11 -trigraphs, but is not.  We only revert the
phase 1 and phase 2 transformations in between ( and ), but they should
actually be reverted everywhere between the " after R and the final ".

[Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Fixed for Fortran by the work done for and around PR44054.

(The C++ issue mentioned in comment 4 is also fixed in GCC 5 - but probably was
already fixed for GCC 4.7, 4.8 and/or 4.9.)