[Bug c++/93630] Multi-dimensional array initialization converts empty raw strings to NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93630 --- Comment #4 from Rodrigo Rivas --- Reproduced with 9.1 and 9.2 here: https://godbolt.org/z/ZeEsuc Trunk seems immune, though. Maybe it is already fixed there?
[Bug c++/93630] Multi-dimensional array initialization converts empty raw strings to NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93630 --- Comment #3 from Rodrigo Rivas --- (In reply to Jakub Jelinek from comment #1) > Can't reproduce, neither with 9.x, nor trunk, nor various revisions in > between, different optimization levels etc. I get '' in all places where it > should be. > What exact g++ version are you using, what exact target, what exact g++ > options? I'm using an up-to-date x64 ArchLinux: * `g++ --version` reports 9.2.0 (packaged as gcc-9.2.0-4) [1] * `ld --version` reports 2.33.1 (packaged as binutils-2.33.1-2) I'm using just `g++ test.cpp`, that will be the x86_64-unknown-linux-gnu target. I tried also with different optimizations: -O0 -O1, -O2, -O3, -Os, -Ofast... all the same results. I've also tried with `-m32`, no changes. I happen to have installed mingw-w64-gcc version 9.1.0, and running the EXE with Wine, and it also reproduces the issue. Doing what Andrew Pinski suggests, adding `-no-pie` changes nothing either. To discard a weird binutils, I've run the compiler with `g++ -O0 --no-pie test.cpp -S` and it gives: .file "test.cpp" .text .section.rodata .LC0: .string "AA" .LC1: .string "AB" .LC2: .string "BA" .LC3: .string "" .LC4: .string "XX" .align 32 .type _ZL5group, @object .size _ZL5group, 72 _ZL5group: .quad .LC0 .quad .LC1 .zero 8 .quad .LC2 .zero 16 .quad .LC3 .quad .LC3 .quad .LC4 ... Even in the assembly, you can see how the NULL pointers creep into the array. Adding the option `-x c` to the above command to force C produces instead: .file "test.cpp" .text .globl group .section.rodata .LC0: .string "AA" .LC1: .string "AB" .LC2: .string "" .LC3: .string "BA" .LC4: .string "XX" .align 32 .type group, @object .size group, 72 group: .quad .LC0 .quad .LC1 .quad .LC2 .quad .LC3 .quad .LC2 .quad .LC2 .quad .LC2 .quad .LC2 .quad .LC4 ... 1: Details at: https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/gcc It looks like there are no distro-specific C++ patches, only a few for D.
[Bug c++/93630] New: Multi-dimensional array initialization converts empty raw strings to NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93630
Bug ID: 93630
Summary: Multi-dimensional array initialization converts empty
raw strings to NULL
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rodrigorivascosta at gmail dot com
Target Milestone: ---
Hello!
Consider the following C++ code:
```
#include
struct Data
{
const char *text;
};
const struct Data group[3][3] =
{
{
{"AA"},
{"AB"},
{""},
},
{
{"BA"},
{""},
{""},
},
{
{""},
{""},
{"XX"},
},
};
int main()
{
for (int i = 0; i < 3; ++i)
for (int j = 0; j < 3; ++j)
{
printf("'%s'\n", group[i][j].text);
}
return 0;
}
```
I'd expect to print the strings as they are in the code. Instead it prints:
'AA'
'AB'
'(null)'
'BA'
'(null)'
'(null)'
''
''
'XX'
That is, the trailing empty strings of each subarray are compiled as if they
were NULL.
Compiling it as C instead does print the expected output, as does with clang++-
[Bug lto/46376] New: LTO, MinGW and virtual base classes don't work together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46376 Summary: LTO, MinGW and virtual base classes don't work together Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassig...@gcc.gnu.org ReportedBy: rodrigorivasco...@gmail.com
[Bug lto/46376] LTO, MinGW and virtual base classes don't work together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46376
--- Comment #1 from Rodrigo Rivas rodrigorivascosta at gmail dot com
2010-11-08 17:07:11 UTC ---
Sorry for the previous empty body... my dog ate my keyboard ;-)
Anyway, the following code fails when compiled with MinGW:
$ i686-mingw32msvc-g++ -v
Using built-in specs.
COLLECT_GCC=i686-mingw32msvc-g++
COLLECT_LTO_WRAPPER=/home/rodrigo/local/mingw/libexec/gcc/i686-mingw32msvc/4.6.0/lto-wrapper
Target: i686-mingw32msvc
Configured with: ../configure --prefix=/home/rodrigo/local/mingw
--target=i686-mingw32msvc --build=i686-linux --with-sysroot=/home/rodrigo/local
--enable-lto --enable-languages=c,c++,lto --enable-multilib=no
--with-system-zlib=yes --enable-threads --disable-nls --with-arch-32=i686
--disable-sjlj-exceptions
Thread model: win32
gcc version 4.6.0 20101108 (experimental) (GCC)
*** File: test.h
#ifndef TEST_H_INCLUDED
#define TEST_H_INCLUDED
struct VBase
{
virtual ~VBase()
{
}
};
struct MyClass : virtual public VBase
{
};
#endif /* TEST_H_INCLUDED */
*** File: test.cpp
#include test.h
int main()
{
MyClass x;
return 0;
}
*** File: foo.cpp
#include test.h
int main()
{
MyClass x;
return 0;
}
*** File: bar.cpp
#include test.h
int bar()
{
MyClass x;
return 0;
}
$ i686-mingw32msvc-g++ -flto *.cpp
test.h:11:8: error: '_ZTv0_n12_N7MyClassD1Ev' has already been defined
test.h:11:8: note: previously defined here
test.h:11:8: error: '_ZTv0_n12_N7MyClassD0Ev' has already been defined
test.h:11:8: note: previously defined here
lto-wrapper: i686-mingw32msvc-g++ returned 1 exit status
collect2: lto-wrapper returned 1 exit status
However, with a native build of the exactly same GCC revision it compiles and
links correctly.
This *may* be a duplicate of Bug 45343.
Regards.
Rodrigo
[Bug c++/46056] [C++0x] range-based for loop does not destruct iterators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46056
--- Comment #6 from Rodrigo Rivas rodrigorivascosta at gmail dot com
2010-10-20 08:56:30 UTC ---
Ok, thank you for the report...
It looks like the range-for temporary completely ignore destructors.
Also, if the range is a temporary it gets destructed quite early, instead of
being kept alive because of the implicit reference.
for (auto x : temp() )
//the temporary is destroyed here
{
//...
} //instead of here
It shouldn't be too difficult to patch, though, so I'll try and have a patch in
a while...
[Bug c++/46056] [C++0x] range-based for loop does not destruct iterators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46056 --- Comment #7 from Rodrigo Rivas rodrigorivascosta at gmail dot com 2010-10-20 10:06:39 UTC --- I've just sent a patch to gcc-patches: http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01699.html In the testcase I added a lot of other destructor checks, just to be sure.
[Bug c++/43824] C++0x feature inline namespace enabled under -std=c++98; no warnings
--- Comment #5 from rodrigorivascosta at gmail dot com 2010-07-26 09:59 --- Created an attachment (id=21313) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21313action=view) Patch to add pedantic warning to inline namespaces in C++98 I think that this tiny patch should do the trick. Regards. -- Rodrigo. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43824
[Bug c++/43223] New: c++0x: Cannot init a R-value reference with L-value
The following function fails to compile with C++0x:
int main()
{
int i = 3;
int x = i;
}
$ g++ -std=gnu++0x test.cpp -o test
test.cpp:4:15: error: invalid initialization of reference of type 'int' from
expression of type 'int'
--
Summary: c++0x: Cannot init a R-value reference with L-value
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rodrigorivascosta at gmail dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43223
[Bug c++/42370] [C++0x][lambda] in a void function: Warning: control reaches end of non-void function
--- Comment #3 from rodrigorivascosta at gmail dot com 2009-12-16 17:05
---
If the lambda line is changed from:
[] { return 0; };
into any of the following:
[=] { return 0; };
[] { return 0; };
int foo = 0;
[foo] { return 0; };
The warnings disappear.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42370
[Bug c++/42370] New: in a void function: Warning: control reaches end of non-void function
Test with a SVN build: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/rodrigo/local/gcc/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/home/rodrigo/local/gcc --with-gmp=/home/rodrigo/local/gcc --with-mpfr=/home/rodrigo/local/gcc --with-mpc=/home/rodrigo/local/gcc --enable-lto --enable-languages=c,c++,lto Thread model: posix gcc version 4.5.0 20091212 (experimental) (GCC) The attached code emits a non-sensical warning (both functions return void!). If the lambda is deleted it works as expected. $ g++ -c -std=gnu++0x -o test.o -Wall -save-temps test.cpp test.cpp: In function 'int end()': test.cpp:8:1: warning: no return statement in function returning non-void test.cpp: In function 'int start()': test.cpp:3:1: warning: control reaches end of non-void function -- Summary: in a void function: Warning: control reaches end of non-void function Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rodrigorivascosta at gmail dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42370
[Bug c++/42370] in a void function: Warning: control reaches end of non-void function
--- Comment #1 from rodrigorivascosta at gmail dot com 2009-12-14 20:19 --- Created an attachment (id=19294) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19294action=view) Simplest test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42370
[Bug c++/42370] in a void function: Warning: control reaches end of non-void function
--- Comment #2 from rodrigorivascosta at gmail dot com 2009-12-14 20:21 --- Created an attachment (id=19295) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19295action=view) Simplest test case Sorry, wrong MIME in the atch 19294 -- rodrigorivascosta at gmail dot com changed: What|Removed |Added Attachment #19294|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42370
