[Bug target/71607] [ARM] ice due to forbidden enabled attribute dependency on instruction operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71607 --- Comment #1 from Mickael Guene --- Created attachment 38739 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38739=edit ice backtrace
[Bug target/71607] New: [ARM] ice due to forbidden enabled attribute dependency on instruction operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71607 Bug ID: 71607 Summary: [ARM] ice due to forbidden enabled attribute dependency on instruction operands Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: mickael.guene at st dot com Target Milestone: --- Created attachment 38738 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38738=edit reduce test case that ice There is a rule in the 'gcc internals' document that states that 'enabled' attribute must not depend on the current insn operands. But unfortunately such a dependency exists due to 'use_literal_pool' attribute dependency on operands[1] and 'use_literal_pool' usage in 'enabled' attribute definition (see arm.md). This leads to ice on check_bool_attrs() assertion in recog.c that exactly checks that 'enabled', 'preferred_for_size' or 'preferred_for_speed' are static properties of the subtarget (as stated in gcc internals document and in check_bool_attrs() comment). Find attached a test case that triggers this ice. >> arm-none-eabi-gcc -c simple.c -mslow-flash-data -O0 -mfloat-abi=hard >> -march=armv7-m -mthumb -mfpu=vfpv3 will trigger an ice whereas >> arm-none-eabi-gcc -c simple.c -mno-slow-flash-data -O0 -mfloat-abi=hard >> -march=armv7-m -mthumb -mfpu=vfpv3 will not. Mickael
[Bug libstdc++/68197] negative index to ios_base::iword lead to unpredictable result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68197 --- Comment #2 from Mickael Guene --- Anyway it's a bad usage since index must come from xalloc. I was unable to find what the specifications say in case of using a negative index (or invalid index), do you have some inputs in this case ?
[Bug libstdc++/68197] New: negative index to ios_base::iword lead to unpredictable result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68197 Bug ID: 68197 Summary: negative index to ios_base::iword lead to unpredictable result Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: mickael.guene at st dot com Target Milestone: --- Created attachment 36639 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36639=edit segfault on my machine Attach test program will crash since iword(-100) return invalid memory address. In that case it should return a valid long& intialized to 0. Inline iword and pword should check negative value.
[Bug c++/53109] New: e.E::~E() should compile without error in c++ 2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53109 Bug #: 53109 Summary: e.E::~E() should compile without error in c++ 2011 Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: mickael.gu...@st.com Created attachment 27232 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27232 foo.cpp When compiling attach foo.cpp with following command line: g++ -std=c++0x foo.cpp -c gcc return following error : foo.cpp:7:7: error: request for member 'E::~E' in 'e', which is of non-class type 'E' According to c++ 2011 standard 3.4.3p6 this is a valid construction. Note also that 3.4.3p5 doesn't apply to this construction since a pseudo-destructor-name, according to 3p4 is not a name. Mickael
[Bug c++/52599] New: illegal constexpr constructor declaration make g++ assert instead of returning an error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52599 Bug #: 52599 Summary: illegal constexpr constructor declaration make g++ assert instead of returning an error Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: mickael.gu...@st.com Created attachment 26902 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26902 This test make g++ to assert when compiling attach file with 'g++ -std=c++0x test.cpp' compiler assert in build_constexpr_constructor_member_initializers function from cp/semantics.c. g++ should instead return an error since construct is illegal.
