[Bug c/37041] -Wc++-compat refinements

[Bug c/37041] -Wc++-compat refinements

[egall at gwmail dot gwu.edu]

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

Eric Gallager <egall at gwmail dot gwu.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egall at gwmail dot gwu.edu

--- Comment #5 from Eric Gallager <egall at gwmail dot gwu.edu> ---
A few other refinements to -Wc++-compat that I would like to see:

1. Have it properly handle stuff like the following idiom commonly found in
header files:

#ifdef __cplusplus
extern "C" {
#endif

/* code that is C-only */

#ifdef __cplusplus
}
#endif /* __cplusplus */

I would expect -Wc++-compat to treat something like the above similarly to how
the following pragmas would work:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wc++-compat"

/* code that -Wc++-compat should ignore */

#pragma GCC diagnostic pop

While the version with pragmas is shorter, the `extern "C"` stuff is often
needed for separate reasons, and as such, it would be nice to avoid the need to
do both...

2. Make -Wc++-compat an "umbrella" warning flag like -Wall or -Wextra.
Currently -Wc++-compat warns about many different things, and sometimes I would
like to just focus on one of those things. I can think of at least the
following sub-flags that could be split off from it:
** "-Wc++-compat-pointer-conversion" for the ones like "warning: request for
implicit conversion from 'void *' to 'char *' not permitted in C++"
** "-Wc++-compat-keywords" for the ones like "warning: identifier 'class'
conflicts with C++ keyword"
** "-Wc++-compat-visibility" for the ones like "warning: enum constant defined
in struct or union is not visible in C++" (or likewise with "struct" or "union"
instead of "enum constant")

[Bug c/37041] -Wc++-compat refinements

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Eric Gallager from comment #5)
> #ifdef __cplusplus
> extern "C" {
> #endif
> 
> /* code that is C-only */

This is not what extern "C" means. The code still needs to be valid C++ and
this is why -Wc++-compat would be useful here. For example, this is not valid
C++ despite being valid C, and -Wc++-compat rightly warns you about it:

#ifdef __cplusplus
extern "C" {
#endif
/* code that is C-only */
int and(void);
#ifdef __cplusplus
}
#endif /* __cplusplus */


> 2. Make -Wc++-compat an "umbrella" warning flag like -Wall or -Wextra.

My guess is that if/when existing GCC developers have time to work on
-Wc++-compat, they will likely focus on fixing the missing warnings and
particularly invalid warnings, rather than figuring out how to refine
-Wc++-compat. But we always welcome new developers
(https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps).
>From gcc-bugs-return-471588-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Dec 22 19:46:34 2014
Return-Path: <gcc-bugs-return-471588-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7920 invoked by alias); 22 Dec 2014 19:46:33 -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 7405 invoked by uid 48); 22 Dec 2014 19:46:29 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/64372] [DR1560] Gratuitous lvalue-to-rvalue conversion in conditional-expression with throw-expression operand
Date: Mon, 22 Dec 2014 19:46: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.2
X-Bugzilla-Keywords: diagnostic, wrong-code
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: keywords bug_status bug_file_loc cf_reconfirmed_on short_desc everconfirmed
Message-ID: <bug-64372-4-6EBey2WTxR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64372-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64372-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: 2014-12/txt/msg02595.txt.bz2
Content-length: 1191

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |diagnostic, wrong-code
             Status|UNCONFIRMED                 |NEW
                URL|                            |http://www.open-std.org/jtc
                   |                            |1/sc22/wg21/docs/cwg_defect
                   |                            |s.html#1560
   Last reconfirmed|                            |2014-12-22
            Summary|Spurious warning with throw |[DR1560] Gratuitous
                   |in ternary operator         |lvalue-to-rvalue conversion
                   |returning const reference   |in conditional-expression
                   |                            |with throw-expression
                   |                            |operand
     Ever confirmed|0                           |1

--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Thanks Harald!

I updated the PR accordingly.
>From gcc-bugs-return-471589-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Dec 22 19:52:47 2014
Return-Path: <gcc-bugs-return-471589-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14045 invoked by alias); 22 Dec 2014 19:52: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 13894 invoked by uid 48); 22 Dec 2014 19:52:42 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/64372] [DR1560] Gratuitous lvalue-to-rvalue conversion in conditional-expression with throw-expression operand
Date: Mon, 22 Dec 2014 19:52: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.2
X-Bugzilla-Keywords: diagnostic, wrong-code
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:
Message-ID: <bug-64372-4-sJTSlEF7gy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64372-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64372-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: 2014-12/txt/msg02596.txt.bz2
Content-length: 393

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

--- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
BTW Harald, GCC needs more C++ FE developers, have you considered joining the
project? Even if you don't end up contributing much code, you can get a
gcc.gnu.org account for Bugzilla with the possibility of
updating/confirming/rejecting bug reports.
>From gcc-bugs-return-471590-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Dec 22 20:21:38 2014
Return-Path: <gcc-bugs-return-471590-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29959 invoked by alias); 22 Dec 2014 20:21:37 -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 29911 invoked by uid 48); 22 Dec 2014 20:21:31 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/64377] nios2 compile error in options-save.c
Date: Mon, 22 Dec 2014 20:21:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: build
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: keywords cf_gcctarget bug_status cf_reconfirmed_on everconfirmed
Message-ID: <bug-64377-4-HFOXVTgzGb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64377-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64377-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: 2014-12/txt/msg02597.txt.bz2
Content-length: 2062

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build
             Target|                            |nios2
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-12-22
     Ever confirmed|0                           |1

--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Joel Sherrill from comment #1)
> Looking at the generated options-save.c, the first line of this method is
> clearly incorrect in the cast on the RHS. It looks like a full declaration
> and not a type. If anyone familiar with the magic in these files looked at
> it, I am sure it is easy to fix.

Those types come from processing TargetSave in .opt files, which are
transformed into variable names and types in optc-save-gen.awk:

for (i = 0; i < n_target_save; i++) {
        var = target_save_decl[i];
        sub (" *=.*", "", var);
        name = var;
        type = var;
        sub("^.*[ *]", "", name)
        sub(" *" name "$", "", type)
        if (target_save_decl[i] ~ "^const char \\*+[_" alnum "]+$")
                var_target_str[n_target_str++] = name;
        else {
                var_target_val_type[n_target_val] = type;
                var_target_val[n_target_val++] = name;
        }
}

However, the above code does not seem to support array
declarations. Not only the resulting cast does not make any
sense, but something like ptr->saved_custom_code_status[256] does
not seem correct either.

My guess is that the TargetSave declarations in nios2.opt are not
valid (it is the only file that uses arrays for TargetSave), but I'm not sure
what is the correct way to do what those declarations are trying to do. A patch
to optc-save-gen.awk to give a sensible error would also be welcome.
>From gcc-bugs-return-471591-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Dec 22 20:50:49 2014
Return-Path: <gcc-bugs-return-471591-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12583 invoked by alias); 22 Dec 2014 20:50:48 -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 12519 invoked by uid 48); 22 Dec 2014 20:50:43 -0000
From: "unmobile at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/59410] tsan tests fail with address randomization disabled
Date: Mon, 22 Dec 2014 20:50:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: unmobile at gmail dot com
X-Bugzilla-Status: RESOLVED
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
Message-ID: <bug-59410-4-5XIGe4wN4S@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59410-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59410-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-12/txt/msg02598.txt.bz2
Content-length: 3607

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

Phil Miller <unmobile at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |unmobile at gmail dot com

--- Comment #38 from Phil Miller <unmobile at gmail dot com> ---
(In reply to Dmitry Vyukov from comment #34)
> I propose to close this as obsolete. Or does somebody see any actionable items here?
> Non-pie binaries are supported by tsan now. Non-aslr (0x55555) are not.

I have a definite real-world use case for ThreadSanitizer with ASLR disabled,
which I would really like to see supported. I'm happy to help in testing or
hacking, with pointers in the right direction.

Potentially horrifying details:
I work on a system for distributed-memory parallel programming called Charm++.
One of the features of our system is an ability to migrate user-level threads
across processes and hardware nodes. This lets us provide functionality like
load balancing, communication optimization, and fault tolerance with low
overhead and fine granularity.

To do this 'nicely', without our users having to write huge amounts of very
finicky serialization code, we implement a technique called 'isomalloc'. In
isomalloc, each thread is allocated in a chunk of virtual address space that is
unique across the entire distributed set of processes. Any memory allocations
by that thread are served from this chunk. When we want to migrate a thread, we
can just copy the allocated bits of that chunk, including its stack, from one
process to another, and all the pointers within will remain valid.

Isomalloc works best when we can assure it as large a range of common,
unoccupied virtual address space as possible. Thus, it's much happier when ASLR
is disabled.

Our runtime system supports a shared-memory multi-threading mode that allows
message passing by pointer within each process. Several libraries on top of the
RTS also exploit shared memory to reduce memory footprint and/or improve
performance. So, we and our users really benefit from being able to use
ThreadSanitizer to help debug our code. For instance, you can see our tracking
bug for issues in our code code that have been detected using tsan so far:
https://charm.cs.illinois.edu/redmine/issues/535

Tie that all together, and we really want to see tsan working with non-ASLR.

I've just tested the patch in https://bugzilla.kernel.org/show_bug.cgi?idf721
against Linux 3.19-rc1, and found that it doesn't (no longer?) solve this
issue.

I tried compiling my code as non-PIE to hack around this issue. GCC will accept
"-fsanitize=thread -fPIC -shared" instead of "-fsanitize=thread -fPIE -pie" to
compile and link successfully. However, any attempts to run the resulting
binary result in a segfault. Per earlier requests, here's /proc/.../maps for
that process:

555555554000-555555555000 r-xp 00000000 08:07 2072846
/home/phil/pie
555555754000-555555755000 rw-p 00000000 08:07 2072846
/home/phil/pie
7ffff7ffb000-7ffff7ffd000 r-xp 00000000 00:00 0                          [vdso]
7ffff7ffd000-7ffff7fff000 r--p 00000000 00:00 0                          [vvar]
7ffffffde000-7ffffffff000 rw-p 00000000 00:00 0
[stack]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
[vsyscall]

If there's some other way to build as non-PIE that will let tsan work with ASLR
disabled, I'm happy to get a workaround, as long as it's something I can
document for our users.

[Bug c/37041] -Wc++-compat refinements

[egall at gwmail dot gwu.edu]

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

--- Comment #7 from Eric Gallager <egall at gwmail dot gwu.edu> ---
(In reply to Manuel López-Ibáñez from comment #6)
> (In reply to Eric Gallager from comment #5)
> > #ifdef __cplusplus
> > extern "C" {
> > #endif
> > 
> > /* code that is C-only */
> 
> This is not what extern "C" means. The code still needs to be valid C++ and
> this is why -Wc++-compat would be useful here. For example, this is not
> valid C++ despite being valid C, and -Wc++-compat rightly warns you about it:
> 
> #ifdef __cplusplus
> extern "C" {
> #endif
> /* code that is C-only */
> int and(void);
> #ifdef __cplusplus
> }
> #endif /* __cplusplus */
> 

Oops, I made my example needlessly complicated. I should have just said:

#ifndef __cplusplus
/* code that is C-only */
int and(void);
#endif /* !__cplusplus */
>From gcc-bugs-return-479603-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 06 19:03:44 2015
Return-Path: <gcc-bugs-return-479603-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 14149 invoked by alias); 6 Mar 2015 19:03:44 -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 14069 invoked by uid 48); 6 Mar 2015 19:03:41 -0000
From: "hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/65334] [5 Regression] r221099 caused: FAIL: gfortran.fortran-torture/execute/in-pack.f90 execution, -O2 -ftree-vectorize -msse2
Date: Fri, 06 Mar 2015 19:03:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: hubicka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65334-4-OuQFsrum2e@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65334-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65334-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: 2015-03/txt/msg00747.txt.bz2
Content-length: 1295

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

--- Comment #2 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
We ICE at:
   0x080486d9 <+409>:   cmp    %eax,%ebx
   0x080486db <+411>:   jge    0x80486c8 <isub4_+392>
=> 0x080486dd <+413>:   movdqa 0x80cf41c,%xmm7
   0x080486e5 <+421>:   movl   $0x5,0x10(%edi)
   0x080486ec <+428>:   movups %xmm7,(%edi)
   0x080486ef <+431>:   mov    %esi,0x30(%esp)
   0x080486f3 <+435>:   add    $0x1c,%esp
   0x080486f6 <+438>:   pop    %ebx
   0x080486f7 <+439>:   pop    %esi
   0x080486f8 <+440>:   pop    %edi
   0x080486f9 <+441>:   pop    %ebp

so this is an alignment issue.
        movdqa  A.22.3410, %xmm7
        movl    $5, 16(%edi)
        movups  %xmm7, (%edi)

The var is defined as follows:
        .long   1
        .align 4
        .type   A.94.3694, @object
        .size   A.94.3694, 20
A.94.3694:
        .long   1
        .long   2
        .long   3
        .long   4
        .long   5
        .set    A.22.3410,A.94.3694

so it is not actually aligned.  Without ICF we get:
        .align 16
        .type   A.22.3410, @object
        .size   A.22.3410, 20
A.22.3410:
        .long   1
        .long   2
        .long   3
        .long   4
        .long   5

So this is an increase_alignment bug - it does not consider aliases.

[Bug c/37041] -Wc++-compat refinements

[manu at gcc dot gnu dot org]

------- Comment #4 from manu at gcc dot gnu dot org  2010-07-03 20:10 -------
We should collect individual Wc++-compat issues here.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |40564


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

[Bug c/37041] -Wc++-compat refinements

[ian at airs dot com]

------- Comment #3 from ian at airs dot com  2009-06-12 21:07 -------
-Wc++-compat now warns about alternative representations for operators and
punctuators such as "and".  The other issues have not yet been addressed.


-- 

ian at airs dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ian at airs dot com


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

[Bug c/37041] -Wc++-compat refinements

[joseph at codesourcery dot com]

------- Comment #2 from joseph at codesourcery dot com  2008-08-07 12:04 -------
Subject: Re:  -Wc++-compat refinements

On Thu, 7 Aug 2008, manu at gcc dot gnu dot org wrote:

> To clarify how to implement this, I have some questions:
> 
> (In reply to comment #0)
> > -Wc++-compat should allow bool, wchar_t, char16_t and char32_t as typedefs
> > defined in system headers, while warning if they are used other than as types
> > or the typedefs are defined other than in system headers.
> 
> This will require:
> 
> * a check in CPP when defining new macros. It should probably allow also to be
> used as macro name if defined in system header (#define bool _Bool).

I see no need for macro checks for these type names; the check should be 
for when they reach the C parser as identifiers, just like the checks for 
other C++ keywords both with the restriction on context.  Because they are 
keywords in C++, C++ programs could also define them as macros.

> > -Wc++-compat should warn for asm and inline when used in a C mode where they
> > are identifiers not keywords, but not in a mode when they are keywords and
> > not for the __ variants in any case.
> 
> I think that not checking the __ variants is given. I don't understand what you
> mean by "not in a mode when they are keywords". My understanding is that we
> should warn always that they are used as names (type names, identifiers, macro
> names, macro parameters) and never when they are keywords (independently of the
> C mode).

With -std=c89 -Wc++-compat, both are identifiers and both should be warned 
for when they reach the C parser as identifiers.  No warnings for 
preprocessor uses are needed.

With -std=gnu89 -Wc++-compat, both are keywords and neither should be 
warned for.

With -std=c99 -Wc++-compat, inline is a keyword and should not be warned 
for, but asm is an identifier and should be warned for.

> > -Wc++-compat should warn for uses of the alternative representations for
> > operators and punctuators such as "and", including uses as macro names (except
> > when defined in system headers, because of iso646.h) and macro parameter names.
> 
> Hence:
> 
> * a check in CPP when defining new macros.
> 
> * various checks in c-parser.c or c-decl.c to check for names. Any use here is
> wrong. (CPP would have already replaced 'and' if it is a macro).

That seems right.  If they reach the parser they can probably be handled 
just like the existing -Wc++-compat warnings (put in the keyword table for 
warning, but never actually handled as keywords), but additional 
preprocessor checks are needed as well.  (The relevant preprocessor cases 
give errors in C++.)


-- 


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

[Bug c/37041] -Wc++-compat refinements

[manu at gcc dot gnu dot org]

------- Comment #1 from manu at gcc dot gnu dot org  2008-08-07 11:54 -------
Confirmed as enhancement.

To clarify how to implement this, I have some questions:

(In reply to comment #0)
> -Wc++-compat should allow bool, wchar_t, char16_t and char32_t as typedefs
> defined in system headers, while warning if they are used other than as types
> or the typedefs are defined other than in system headers.

This will require:

* a check in CPP when defining new macros. It should probably allow also to be
used as macro name if defined in system header (#define bool _Bool).

* various checks in c-parser.c or c-decl.c to check for
   a) typedefs outside system headers.
   b) Names except for types.

> -Wc++-compat should warn for asm and inline when used in a C mode where they
> are identifiers not keywords, but not in a mode when they are keywords and
> not for the __ variants in any case.

I think that not checking the __ variants is given. I don't understand what you
mean by "not in a mode when they are keywords". My understanding is that we
should warn always that they are used as names (type names, identifiers, macro
names, macro parameters) and never when they are keywords (independently of the
C mode).

> -Wc++-compat should warn for uses of the alternative representations for
> operators and punctuators such as "and", including uses as macro names (except
> when defined in system headers, because of iso646.h) and macro parameter names.

Hence:

* a check in CPP when defining new macros.

* various checks in c-parser.c or c-decl.c to check for names. Any use here is
wrong. (CPP would have already replaced 'and' if it is a macro).


Am I missing something?

Cheers,

Manuel.


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org
           Severity|normal                      |enhancement
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-08-07 11:54:54
               date|                            |


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