* [Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs
2012-02-23 8:37 [Bug fortran/52347] New: -Wno-tabs -Wall -Wno-tabs still warns about tabs burnus at gcc dot gnu.org
@ 2012-02-23 8:42 ` manu at gcc dot gnu.org
2013-06-14 19:43 ` Simon.Richter at hogyros dot de
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: manu at gcc dot gnu.org @ 2012-02-23 8:42 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs
2012-02-23 8:37 [Bug fortran/52347] New: -Wno-tabs -Wall -Wno-tabs still warns about tabs burnus at gcc dot gnu.org
2012-02-23 8:42 ` [Bug fortran/52347] " manu at gcc dot gnu.org
@ 2013-06-14 19:43 ` Simon.Richter at hogyros dot de
2013-06-14 21:27 ` manu at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: Simon.Richter at hogyros dot de @ 2013-06-14 19:43 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs
2012-02-23 8:37 [Bug fortran/52347] New: -Wno-tabs -Wall -Wno-tabs still warns about tabs burnus at gcc dot gnu.org
2012-02-23 8:42 ` [Bug fortran/52347] " manu at gcc dot gnu.org
2013-06-14 19:43 ` Simon.Richter at hogyros dot de
@ 2013-06-14 21:27 ` manu at gcc dot gnu.org
2013-06-14 23:15 ` Simon.Richter at hogyros dot de
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: manu at gcc dot gnu.org @ 2013-06-14 21:27 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs
2012-02-23 8:37 [Bug fortran/52347] New: -Wno-tabs -Wall -Wno-tabs still warns about tabs burnus at gcc dot gnu.org
` (2 preceding siblings ...)
2013-06-14 21:27 ` manu at gcc dot gnu.org
@ 2013-06-14 23:15 ` Simon.Richter at hogyros dot de
2013-06-15 9:36 ` manu at gcc dot gnu.org
2014-12-11 17:41 ` burnus at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: Simon.Richter at hogyros dot de @ 2013-06-14 23:15 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs
2012-02-23 8:37 [Bug fortran/52347] New: -Wno-tabs -Wall -Wno-tabs still warns about tabs burnus at gcc dot gnu.org
` (3 preceding siblings ...)
2013-06-14 23:15 ` Simon.Richter at hogyros dot de
@ 2013-06-15 9:36 ` manu at gcc dot gnu.org
2014-12-11 17:41 ` burnus at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: manu at gcc dot gnu.org @ 2013-06-15 9:36 UTC (permalink / raw)
To: gcc-bugs
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 ".
^ permalink raw reply [flat|nested] 7+ messages in thread* [Bug fortran/52347] -Wno-tabs -Wall -Wno-tabs still warns about tabs
2012-02-23 8:37 [Bug fortran/52347] New: -Wno-tabs -Wall -Wno-tabs still warns about tabs burnus at gcc dot gnu.org
` (4 preceding siblings ...)
2013-06-15 9:36 ` manu at gcc dot gnu.org
@ 2014-12-11 17:41 ` burnus at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: burnus at gcc dot gnu.org @ 2014-12-11 17:41 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 7+ messages in thread