[Bug driver/59512] New: Incomplete output files when compiler is killed

[robert-gcc at debian dot org]

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

Bug ID: 59512
   Summary: Incomplete output files when compiler is killed
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: robert-gcc at debian dot org

Hi

When cc1plus program is killed for example by OOM then the output file (given
by the `-o' option) can be incomplete, which will than result in linker error.
This is especially visible when the `-pipe' option is used. 

I can see that clang always first create some temporary file, and then renames
it into the final one:
 strace -efile -f  clang++ a.cpp -pipe -c -o a.o
  [pid 28990] stat64("a.o", {st_mode=S_IFREG|0644, st_size=716, ...}) = 0
  [pid 28990] access("a.o", W_OK) = 0
  [pid 28990] open("/dev/urandom", O_RDONLY) = 3
  [pid 28990] open("a.o-8cc52ce9", O_RDWR|O_CREAT|O_EXCL, 0666) = 3
// skipped some output
  [pid 28990] rename("a.o-8cc52ce9", "a.o") = 0

It would be nice if g++ could implement the same behaviour.

I tried to simulate it in makefiles by using something like `g++ -o $@.tmp &&
mv $@.tmp $@', and it worked pretty well, unless coverage flags
(`-fprofile-arcs -ftest-coverage') were also given, in which case the generated
gcno/gcda files refered to the `.o.tmp' files, which generally broke the
coverage calculations. For that reason I think that it would be best if g++
could handle this `write to temp && rename temp' approach internally.

[Bug c++/70145] New: g++-5 and g++-6: invalid code generated for -fno-elide-constructors and constexpr array

[robert-gcc at debian dot org]

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

Bug ID: 70145
   Summary: g++-5 and g++-6: invalid code generated for
-fno-elide-constructors and  constexpr array
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: robert-gcc at debian dot org
  Target Milestone: ---

Created attachment 37900
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37900&action=edit
Simplified test case

The attached simplified code gives different results when compiled with
-fno-elide-constructors with g++-6:

The expected behaviour:
/tmp/tst> g++-6 -Wall -Wextra --std=c++1y   ./test.cpp -o test

/tmp/tst> ./test; echo $?
1

The incorrect output with -fno-elide-constructors:
/tmp/tst> g++-6 -Wall -Wextra --std=c++1y -fno-elide-constructors  ./test.cpp
-o test

/tmp/tst> ./test; echo $?
0

The same issue exists in g++-5. The issue is not reproducible in g++-4.9.

Versions:
* g++-6:
Using built-in specs.
COLLECT_GCC=g++-6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i586-linux-gnu/6/lto-wrapper
Target: i586-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6-20160228-1'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-i386/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-i386
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-i386
--with-arch-directory=i386 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-targets=all --enable-multiarch --with-arch-32=i586
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-checking=release --build=i586-linux-gnu --host=i586-linux-gnu
--target=i586-linux-gnu
Thread model: posix
gcc version 6.0.0 20160228 (experimental) [trunk revision 233789] (Debian
6-20160228-1) 
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-shared-libgcc' '-mtune=generic'
'-march=i586'
 /usr/lib/gcc/i586-linux-gnu/6/cc1plus -quiet -v -imultiarch i386-linux-gnu
-D_GNU_SOURCE ./test.cpp -quiet -dumpbase test.cpp -mtune=generic -march=i586
-auxbase test -std=c++11 -version -o /tmp/user/1000/ccOuyw8T.s
GNU C++11 (Debian 6-20160228-1) version 6.0.0 20160228 (experimental) [trunk
revision 233789] (i586-linux-gnu)
compiled by GNU C version 6.0.0 20160228 (experimental) [trunk revision
233789], GMP version 6.1.0, MPFR version 3.1.4-rc1, MPC version 1.0.3, isl
version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "/usr/include/i386-linux-gnu/c++/6"
ignoring nonexistent directory "/usr/local/include/i386-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/i586-linux-gnu/6/../../../../i586-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/6
 /usr/include/i386-linux-gnu/c++/6
 /usr/include/c++/6/backward
 /usr/lib/gcc/i586-linux-gnu/6/include
 /usr/local/include
 /usr/lib/gcc/i586-linux-gnu/6/include-fixed
 /usr/include/i386-linux-gnu
 /usr/include
End of search list.
GNU C++11 (Debian 6-20160228-1) version 6.0.0 20160228 (experimental) [trunk
revision 233789] (i586-linux-gnu)
compiled by GNU C version 6.0.0 20160228 (experimental) [trunk revision
233789], GMP version 6.1.0, MPFR version 3.1.4-rc1, MPC version 1.0.3, isl
version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 36ae62cc8c2555d6cda1e59f88303dae
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-shared-libgcc' '-mtune=generic'
'-march=i586'
 as -v --32 -o /tmp/user/1000/ccJITulw.o /tmp/user/1000/ccOuyw8T.s
GNU assembler version 2.26 (i686-linux-gnu) using BFD version (GNU Binutils for
Debian) 2.26
COMPILER_PATH=/usr/lib/gcc/i586-linux-gnu/6/:/usr/lib/gcc/i586-linux-gnu/6/:/usr/lib/gcc/i586-linux-gnu/:/usr/lib/gcc/i586-linux-gnu/6/:/usr/lib/gcc/i586-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i586-linux-gnu/6/:/usr/lib/gcc/i586-linux-gnu/6/../../../i386-linux-gnu/:/usr/lib/gcc/i586-linux-gnu/6/../../../../lib/:/lib/i386-linux-gnu/:/lib/../lib/:/usr/lib/i386-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/i586-linux-gnu/6/../../../:/lib/:/usr/lib/
COLLE

[Bug driver/19541] need another option to support what -I- did just besides -iquote

[robert-gcc at debian dot org]

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

Robert Luberda  changed:

   What|Removed |Added

 CC||robert-gcc at debian dot org

--- Comment #26 from Robert Luberda  ---
After 11 years since the first report I can confirm the bug is still present in
gcc-6:

 -the compiler still claims that -I- is deprecated,

 -it also still lies that -iquote can be used instead, 

 - and it still does not provide any other option to get rid of the current
file's directory from the search path...

[Bug c++/99353] New: warn_unused attribute does not seem to work for static variables

[robert-gcc at debian dot org via Gcc-bugs]

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

Bug ID: 99353
   Summary: warn_unused attribute does not seem to work for static
variables
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: robert-gcc at debian dot org
  Target Milestone: ---

According to
https://gcc.gnu.org/onlinedocs/gcc-10.1.0/gcc/C_002b_002b-Attributes.html#C_002b_002b-Attributes,
the 'warn_unused' attribute  'informs the compiler that variables of this type
should be warned about if they appear to be unused, just like variables of
fundamental types'. 

However this does not seem to work in case of static variables - please see the
program pasted below, that does not use any of declared variables, but "g++
-Wall  -Wextra -O2 -std=c++17" diagnoses mostly local unused variables, as
marked in the comments in the program. 

See https://wandbox.org/permlink/fztgVWxYX8iJ5uYS for a demo. I've tried a few
different versions of g++ there, including the latest one, but with the same
result.

--- Program contents:  ---

struct  __attribute__ ((warn_unused)) A 
{
};

struct  __attribute__ ((warn_unused)) B 
{
  B() {};
};

struct  __attribute__ ((warn_unused)) C 
{
  ~C() {};
};


static int i1 = 0;//  warning: 'i1' defined but not used 
static const int i2 = 0;  // NO WARNING 

static A a1; // warning: 'a1' defined but not used 
static const A a2;   // NO WARNING 

static B b1; // NO WARNING  
static const B b2;   // NO WARNING 

static C c1; // NO WARNING 
static const C c2;   // NO WARNING 


int main()
{

A a3; // warning: unused variable 'a3' 
const A a4;   // warning: unused variable 'a4'
B b3; // warning: unused variable 'b3
const B b4;   // warning: unused variable 'b4'
C c3; // warning: unused variable 'c3'
const C c4;   // warning: unused variable 'c4'

static A a5;   // warning: unused variable 'a5',  warning: 'a5' defined
but not used
static const A a6; // warning: unused variable 'a6'
static B b5;   // warning: unused variable 'b5'
static const B b6; // warning: unused variable 'b6'
static C c5;   // NO WARNING 
static const C c6; // NO WARNING 


return 0;
}