[Bug c/60256] New: No -Wuninitialized warning for strcpy

[Bug c/60256] New: No -Wuninitialized warning for strcpy

[chengniansun at gmail dot com]

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

            Bug ID: 60256
           Summary: No -Wuninitialized warning for strcpy
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: chengniansun at gmail dot com

The pointer "s" is uninitialized, but used in the later call to strcpy.

$: cat s.c
#include<string.h>
void f(void) {
  char* s;
  strcpy(s, s);
}
$: gcc-trunk -Wuninitialized s.c -c
$: clang-trunk -Wuninitialized s.c -c
s.c:4:10: warning: variable 's' is uninitialized when used here
      [-Wuninitialized]
  strcpy(s, s);
         ^
s.c:3:10: note: initialize the variable 's' to silence this warning
  char* s;
         ^
          = NULL
1 warning generated.
$: gcc-trunk --version
gcc-trunk (GCC) 4.9.0 20140217 (experimental)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug c/60256] No -Wuninitialized warning for strcpy

[chengniansun at gmail dot com]

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

--- Comment #1 from Chengnian Sun <chengniansun at gmail dot com> ---
If the call is to a user-defined function, then gcc warns. I cannot see why
"strcpy" is special. 

$: cat s.c
extern void p(const char*);
void f(void) {
  char* s;
  p(s);
}
$: gcc-trunk -Wuninitialized s.c -c
s.c: In function ‘f’:
s.c:4:3: warning: ‘s’ is used uninitialized in this function [-Wuninitialized]
   p(s);
   ^
>From gcc-bugs-return-443999-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Feb 18 01:22:35 2014
Return-Path: <gcc-bugs-return-443999-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25130 invoked by alias); 18 Feb 2014 01:22:35 -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 25103 invoked by uid 48); 18 Feb 2014 01:22:31 -0000
From: "pinskia at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/60256] No -Wuninitialized warning for strcpy
Date: Tue, 18 Feb 2014 01:22: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: pinskia 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-60256-4-7inXv66RhS@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60256-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60256-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-02/txt/msg01756.txt.bz2
Content-length: 186

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`256

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Well that is because strcpy(s,s) is optimized away as it is a nop.

[Bug c/60256] No -Wuninitialized warning for strcpy

[mpolacek at gcc dot gnu.org]

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

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

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

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
I think this minor issue will go away if we introduce delayed folding.

[Bug c/60256] No -Wuninitialized warning for strcpy

[manu at gcc dot gnu.org]

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

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

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

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #3)
> I think this minor issue will go away if we introduce delayed folding.

Is this really folded in the FE?
>From gcc-bugs-return-449156-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 16 11:30:13 2014
Return-Path: <gcc-bugs-return-449156-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 676 invoked by alias); 16 Apr 2014 11:30:13 -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 574 invoked by uid 48); 16 Apr 2014 11:30:05 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/60852] [4.8/4.9/4.10 Regression] boost::has_complement of enum class does not compile
Date: Wed, 16 Apr 2014 11:30: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: paolo.carlini at oracle dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: paolo.carlini at oracle dot com
X-Bugzilla-Target-Milestone: 4.8.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc assigned_to
Message-ID: <bug-60852-4-Ov8U0oqXQ8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60852-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60852-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-04/txt/msg01176.txt.bz2
Content-length: 684

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`852

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|paolo.carlini at oracle dot com,   |
                   |paolo at gcc dot gnu.org           |
           Assignee|unassigned at gcc dot gnu.org      |paolo.carlini at oracle dot com

--- Comment #10 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Humm, I notice only now that the issue only affects enum classes not plain
enums. Thus must be easy to fix.

[Bug c/60256] No -Wuninitialized warning for strcpy

[manu at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 5503 bytes --]

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

--- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #5)
> We call c_fully_fold on strcpy (s, s);, and because this CALL_EXPR is
> tcc_vl_exp, we call fold () on it.  fold () then via fold_call_expr -> ... 
> calls fold_builtin_strcpy and that hits
>   /* If SRC and DEST are the same (and not volatile), return DEST.  */
>   if (operand_equal_p (src, dest, 0))
>     return fold_convert_loc (loc, TREE_TYPE (TREE_TYPE (fndecl)), dest);
> 
> But on second thought, delayed folding won't help, as uninit passes are run
> quite late and at that point strcpy(s, s); will be already gone.

That is what I was afraid. On the other hand, this is such a particular
testcase that I think it is better to focus on other more critical diagnostic
issues.
>From gcc-bugs-return-449193-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 16 19:52:07 2014
Return-Path: <gcc-bugs-return-449193-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 6898 invoked by alias); 16 Apr 2014 19:52:07 -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 6868 invoked by uid 48); 16 Apr 2014 19:52:04 -0000
From: "kjell.hedstrom at logrhythm dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/60867] New: std::atomic<std::unique_ptr<T>> should fail to compile since unique_ptr is not trivial to copy
Date: Wed, 16 Apr 2014 19:52: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: 4.8.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: kjell.hedstrom at logrhythm 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 attachments.created
Message-ID: <bug-60867-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-04/txt/msg01213.txt.bz2
Content-length: 2731

http://gcc.gnu.org/bugzilla/show_bug.cgi?id`867

            Bug ID: 60867
           Summary: std::atomic<std::unique_ptr<T>> should fail to compile
                    since unique_ptr is not trivial to copy
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: kjell.hedstrom at logrhythm dot com

Created attachment 32621
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id2621&actioníit
main.ii compiled with:  g++ -v -save-temps  -std=c++11  -O2 -Wall -Wextra
-pthread  main.cpp

std::atomic<T> is OK for T's that are not trivial to copy.  Example
std::atomic<std::unique_ptr<T>> should fail to g++ compile but is succeeds.

Example:
std::atomic<std::unique_ptr<int>> a;

Expected output is a compilation error. Maybe something similar to what you
would get from clang 3.4   Ref:
http://coliru.stacked-crooked.com/view?idë48cd3c29b3be15


See attachment main.cpp with code example. It can be build with no problems
g++ -std=c++11  -O2 -Wall -Wextra -pedantic -pthread -pedantic-errors  main.cpp

the main.ii File was created with:
g++ -v -save-temps  -std=c++11  -O2 -Wall -Wextra -pthread  main.cpp


gcc -v gives:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/probe/libexec/gcc/x86_64-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../gcc-4.8.2/configure -build=x86_64-linux-gnu
--prefix=/usr/local/probe --enable-cxx-flags='-L/usr/local/probe/lib
-L/usr/local/probe/lib64 -Wl,-rpath -Wl,/usr/local/probe/lib64 -Wl,-rpath
-Wl,/usr/local/probe/lib ' --enable-c-flags='-L/usr/local/probe/lib
-L/usr/local/probe/lib64 -Wl,-rpath -Wl,/usr/local/probe/lib64 -Wl,-rpath
-Wl,/usr/local/probe/lib ' --enable-shared --enable-threads=posix
--enable-libstdcxx-time=rt --enable-checking=release --with-multilib-list=m64
--with-mpc=/usr/local/probe --enable-gather-detailed-mem-stats
--enable-vtable-verify --with-mpc=/usr/local/probe/ --enable-languages=c,c++
Thread model: posix
gcc version 4.8.2 (GCC)


// Only one attachment could be added so the main.cpp is pasted in
// --- main.cpp ---
#include <iostream>
#include <atomic>
#include <memory>
#include <string>


int main() {
  std::atomic<std::unique_ptr<int>> a;  // this line should fail to compile.


   a.store(std::unique_ptr<int>(new int{5}));
   for (size_t index = 0; index < 100; ++index){
      a.load();
   }

   //typedef std::unique_ptr<int> IntPtr;
   // Hint: using gcc's internal 'has_trivial_copy' shows that it is NOT
   // trivial to copy
   //std::cout << "Is copyable " << __has_trivial_copy(IntPtr)
   return 0;
}