[Bug ada/68179] Missing error on Default_Value and Default_Component_Value aspects specified for derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68179 --- Comment #4 from Troy --- You are correct that RM 3.5. 56.3/3 says the same for Default_Value, that it shall only be applied to full_type_declaration. So obviously full_type_declaration here must include derived types, or the whole feature would be useless.
[Bug ada/68179] Missing error on Default_Value and Default_Component_Value aspects specified for derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68179 --- Comment #3 from Troy --- RM 3.6. 22.2/3 says that Default_Component_Value should only be specified for a full_type_declaration. I.e. not for derived types. Is this not correct?
[Bug ada/68179] New: No warning when specifying a Default_Component_Value on derived type, resulting in unexpected behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68179 Bug ID: 68179 Summary: No warning when specifying a Default_Component_Value on derived type, resulting in unexpected behavior Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: gcc at gyw dot com Target Milestone: --- Created attachment 36634 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36634=edit Sample code to demonstrate dangerous behavior The 'Default_Component_Value' aspect is not allowed on derived types, yet there is no warning from the compiler when it is used. The aspect is just silently ignored. As it stands, one can declare a type derived from String or another array type, and specify a 'Default_Component_Value' for it. However, the default value isn't applied to the components, and there is no warning. It is inconsistent that one can specify a 'Default_Value' on a derived type, but not a 'Default_Component_Value' on a derived array type. I found a mention that allowing default values for components could be risky because of potentially different sizes for the components. It isn't clear to me how this could occur, but the rule is there. I find that silently ignoring the 'Default_Component_Value' aspect is potentially dangerous, as the program's behavior thus differs from what is the intent of the programmer. Subsequent code review is also bound to miss an error of this nature.
[Bug ada/68179] No warning when specifying a Default_Component_Value on derived type, resulting in unexpected behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68179 --- Comment #1 from Troy --- Command line to build sample code: gnatmake -gnat12 -gnatE -gnatf -gnatn -gnato -gnatX -gnatwa -gnatVa ada2012bug2
[Bug ada/68171] Default value in record for component with predicate causes bug box
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68171 --- Comment #1 from Troy --- As an aside, the test is based on an example in the Ada 2012 Rationale. The original uses Static_Predicate, but fails to compile with gnat 4.9.2. That is why I used Dynamic_Predicate instead.
[Bug ada/68171] New: Default value in record for component type with predicate causes bug box
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68171 Bug ID: 68171 Summary: Default value in record for component type with predicate causes bug box Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: gcc at gyw dot com Target Milestone: --- Created attachment 36629 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36629=edit Test file to reproduce bug When a record includes a component with a default value and that component's type is a subtype with a dynamic predicate, a bug box appears. Assertion_Policy(Check) must be set to reproduce the bug box. The code is in the attachment. gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --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-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.2 (Debian 4.9.2-10) - gnatmake -gnat12 -gnatE -gnatf -gnatn -gnato -gnatX -gnatwa -gnatVa ada2012bug1 gcc-4.9 -c -gnat12 -gnatE -gnatf -gnatn -gnato -gnatX -gnatwa -gnatVa ada2012bug1.adb +===GNAT BUG DETECTED==+ | 4.9.2 (x86_64-linux-gnu) GCC error: | | in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:348 | | Error detected at ada2012bug1.adb:18:52 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.9 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+
[Bug c++/54606] reference assignment failing/points at previous object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54606 --- Comment #3 from Troy gcc at gyw dot com 2012-09-25 09:13:34 UTC --- I think more to the point, and a better mnemonic, is to say that there are no references in C++. What is called a reference in C++ is really just a rename/alias for the variable. To reiterate my point, if assignment to a reference is equivalent to assigning to the original variable, then we are talking a rename operation similar to a C macro, not the creation of a new reference object. Sadly, I found out that I had fallen into the same trap before as well, just forgot about it. So clearly there is need for a mnemonic. Maybe not for people who only use C++, but for the rest of us who have to use multiple languages, including variants of C++ such as C++/CLI, the word reference in the C++ context really stinks. It is one of the Norman doors (UX term) of C++, as it keeps making people push the wrong side of the door time and again.
[Bug libstdc++/54606] New: reference assignment failing/points at previous object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54606 Bug #: 54606 Summary: reference assignment failing/points at previous object Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: g...@gyw.com Created attachment 28203 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=28203 Sample code When one assigns a reference to a variable, the value doesn't point at the new object. It keeps referring to the previous object. A a = X; a.a(); // calls X::a() a = Y; a.a(); // Still calls X::a(), not Y::a(). Corresponding code using pointers works. References and pointers should handle dynamic dispatch the same way. Tried g++ 4.4, 4.5 and 4.6 on Ubuntu and Debian.
