[Bug c/102422] New: Missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102422 Bug ID: 102422 Summary: Missing -Warray-bounds Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: marco.morandini at polimi dot it Target Milestone: --- Created attachment 51489 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51489=edit Code triggering the bug The attached code raises a warning with gcc 4.5.3 when compiling with "-O2 -Wall", but misses it starting from from gcc 4.6.4 down to gcc 11.2.1. We think it should raise the warning, but we are not language lawyers
[Bug c++/84358] New: error message (missing call to class contructor): misleading source code location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84358
Bug ID: 84358
Summary: error message (missing call to class contructor):
misleading source code location
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marco.morandini at polimi dot it
Target Milestone: ---
Consider the following (wrong) code:
//
class A {
public:
A(int i) {};
A& operator=(const A&) = delete;
A(const A&) = delete;
};
class B {
private:
A a;
const int b;
public:
B() : b(1) {};
};
//
The error message is
marco@pao:~> g++ pippo.C
pippo.C: In constructor ‘B::B()’:
pippo.C:13:11: error: no matching function for call to ‘A::A()’
B() : b(1) {};
^
pippo.C:3:2: note: candidate: A::A(int)
A(int i) {};
^
pippo.C:3:2: note: candidate expects 1 argument, 0 provided
I think that the indication of b(1) as the location of the error, together with
the above message ("no matching function for call to ‘A::A()’": which call?
there is not such call at the offending line!) is misleading. For a complex
code with many members stored inside B it's not obvious that the compiler is
trying to insert a call to A's constructor.
[Bug c++/84356] error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84356 marco.morandini at polimi dot it changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from marco.morandini at polimi dot it --- Apologize, I was still entering the fields.
[Bug c++/84356] New: error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84356 Bug ID: 84356 Summary: error message Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marco.morandini at polimi dot it Target Milestone: ---
[Bug c++/63680] New: ice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63680
Bug ID: 63680
Summary: ice
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marco.morandini at polimi dot it
Created attachment 33845
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33845action=edit
reduced testcase
g++ version:
marco@pao:~/Mbdyn/mbdyn.cvs g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/marco/local/gcc-4.9.1/lib/gcc/x86_64-unknown-linux-gnu/4.9.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/marco/local/gcc-4.9.1
--enable-checking=release --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --enable-linux-futex --enable-lto
--with-arch=native --enable-threads=posix --with-ppl --with-cloog
--enable-languages=c,c++,fortran,lto
Thread model: posix
gcc version 4.9.1 (GCC)
--
ice message:
marco@pao:~/TTT/GccTestcaseReduction g++ -c RulesDirective.ii
RulesDirective.ii: In function ‘void processLabels()’:
RulesDirective.ii:7:6: internal compiler error: Segmentation fault
void processLabels() {
^
0x9aca5f crash_signal
../../gcc/toplev.c:337
0x8583ea get_class_context
../../gcc/ipa-devirt.c:997
0x8593fd contains_type_p
../../gcc/ipa-devirt.c:1012
0x8593fd get_polymorphic_call_info(tree_node*, tree_node*, tree_node**, long*,
ipa_polymorphic_call_context*)
../../gcc/ipa-devirt.c:1227
0x73669f cgraph_create_indirect_edge(cgraph_node*, gimple_statement_base*, int,
long, int)
../../gcc/cgraph.c:976
0x737cd3 build_cgraph_edges
../../gcc/cgraphbuild.c:343
0x737cd3 execute
../../gcc/cgraphbuild.c:409
[Bug libstdc++/63449] New: documentation of vector space overhead management
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63449 Bug ID: 63449 Summary: documentation of vector space overhead management Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: marco.morandini at polimi dot it This is a documentation bug, but I didn't find a documentation component. Anyway: I fear that https://gcc.gnu.org/onlinedocs/gcc-4.9.1/libstdc++/manual/manual/containers.html#sequences.vector.management is outdated. At the very least, the links to the two alpha releases are broken.
[Bug libstdc++/57226] The installation of pretty printers is not documented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57226 --- Comment #2 from marco.morandini at polimi dot it --- On 05/09/2013 02:48 PM, redi at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57226 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- You install GCC and the printers get installed alongside them, and when gdb loads libstdc++.so.6.0.16 it automatically loads libstdc++.so.6.0.16-gdb.py ... what more do you need to know? What needs to be documented? First, mentioning that the pretty printers existst, and are installed with gcc, and not with gdb. Second, what to do if someone installs gcc in a non-standard location that is not known by gdb. I agree that by reading the gdb info one can come up with these commands in his .gdbinit, add-auto-load-safe-path /home/marco/local/gcc-4.8.0/share/gcc-4.8.0/python python import sys sys.path.insert(0, '/home/marco/local/gcc-4.8.0/share/gcc-4.8.0/python') from libstdcxx.v6.printers import register_libstdcxx_printers register_libstdcxx_printers (None) end but reporting them in gcc's manual would help.
[Bug libstdc++/57226] The installation of pretty printers is not documented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57226 --- Comment #3 from marco.morandini at polimi dot it --- On 05/09/2013 02:48 PM, redi at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57226 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- You install GCC and the printers get installed alongside them, and when gdb loads libstdc++.so.6.0.16 it automatically loads libstdc++.so.6.0.16-gdb.py ... what more do you need to know? What needs to be documented? First, mentioning that the pretty printers do exist and that they are installed with gcc, not with gdb. Second, what to do if someone installs gcc in a non-standard location that is not known by gdb. I agree that by reading the gdb info one can come up with these commands in his .gdbinit, - add-auto-load-safe-path GCC_INSTALL_PREFIX/share/gcc-4.8.0/python python import sys sys.path.insert(0, 'GCC_INSTALL_PREFIX/share/gcc-4.8.0/python') from libstdcxx.v6.printers import register_libstdcxx_printers register_libstdcxx_printers (None) end but reporting them in gcc's manual would help.
