[Bug c++/82310] New: Odd regression in g++-6.4.0 with a variable named major
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82310
Bug ID: 82310
Summary: Odd regression in g++-6.4.0 with a variable named
major
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dflogeras2 at gmail dot com
Target Milestone: ---
After upgrading to gcc-6.4.0, one of my regression tests fails to compile. I
boiled it down to the following simple code which fails to compile, claiming
that "major" was not declared in this scope. If I change that variable name to
something else (maj), it works.
#include
#include
int main() {
const uint32_t minor( 0 );
{
uint32_t file_minor = 0;
if( minor!= file_minor ) throw std::runtime_error( "version error" );
}
}
[Bug c++/82310] Odd regression in g++-6.4.0 with a variable named major
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82310 --- Comment #2 from Dave Flogeras --- Sorry for the noise, it seems to be a glibc bug. Looks like it was fixed in 2.25 (too recent for my affected system). In case anyone else hits it and finds this bug, see below: https://sourceware.org/bugzilla/show_bug.cgi?id=19239
[Bug c++/67309] New: Error compiling with -std=c++11 and -fsingle-precision-constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67309
Bug ID: 67309
Summary: Error compiling with -std=c++11 and
-fsingle-precision-constant
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dflogeras2 at gmail dot com
Target Milestone: ---
The ARM people recommend using -fsingle-precision-constant for targeting their
microcontrollers, such as the Cortex M4. I am experimenting with using parts
of modern C++ on my uC projects.
If I compile the following (not just with arm cross compilers, even my native
linux compiler):
#include
int main() {}
with:
gcc test.cpp -fsingle-precision-constant -std=c++11 -c
It fails, since c++11 templating will not promote float types, and there is an
ambiguous 6.0 floating point constant in the bowels of the STL, which ends up
with a call to std::max( float, double ) which is illegal.
Not sure what the proper fix is, and I'm also not sure why this used to compile
for me (same flags, gcc-4.7.3), but no longer does.
[Bug libstdc++/67309] Error compiling with -std=c++11 and -fsingle-precision-constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67309 --- Comment #3 from Dave Flogeras --- That is what is weird to me, it definitely used to compile for me with GCC 4.7.3 and 4.8.3 (with the same build system flags). Is there anything that is conditional when compiling GCC that maybe the Gentoo crossdev folks have changed over time, which could mask this behaviour? I don't imagine they were patching those headers. However, when I rebuild my cross GCC 4.7.3 with crossdev, it now fails, as you've noted. I am happy to test patchsets, and or even come up with them if you think this is something worth delegating. I have no experience in GCC's tree, but I can follow orders :)
[Bug libstdc++/67309] Error compiling with -std=c++11 and -fsingle-precision-constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67309 --- Comment #5 from Dave Flogeras --- Definitely, this project is my testbed for playing with new C++ features on a STM32F4 micro. I also checked the ChibiOS (the RTOS I use) and it has always had -fsingle-precision-constant defined (well for all versions I have used in the past year). Certainly mysterious, maybe Gentoo was patching it.. I mean it has to be deterministic after all.
[Bug libstdc++/67309] Error compiling with -std=c++11 and -fsingle-precision-constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67309 --- Comment #6 from Dave Flogeras --- Created attachment 36237 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36237&action=edit Patch for random.tcc This patch made the test case presented compile cleanly for myself. It is from GCC-4.8.4's tree because that is what I had kicking around.
[Bug c++/30019] New: g++ did not issue a warning when it (IMO) could have
Hi, I mixed up the following code to reset a ostringstream ostringstream oss; oss << "Stuff"; oss.str() = ""; // Should have been oss.str( "" ); The third line is creating a temporary variable and assigning it the new "" value, then it disappears. Couldn't g++ have warned me of an unused temp? I know I have seen it do things like that before. Thanks -- Summary: g++ did not issue a warning when it (IMO) could have Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dflogeras2 at gmail dot com GCC host triplet: Gentoo Linux GCC target triplet: Target: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30019
[Bug c/106068] New: Infinite loop generated with -mcpu=cortex-m7 and -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106068 Bug ID: 106068 Summary: Infinite loop generated with -mcpu=cortex-m7 and -O2 Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dflogeras2 at gmail dot com Target Milestone: --- Created attachment 53197 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53197&action=edit Preprocessed src to reproduce bug We hit this suspected bug compiling an older firmware after recently upgrading to a more recent version of GCC. It can be triggered by 11.3.0, while the old 5.4.x version did not produce the infinite loop. The code snippet is from a quite old version of LWIP (stripped down to the minimal). It appears to not be exiting the loop on the second condition (n<2). The exact command I used to generate the .i is as follows: arm-none-eabi-gcc -mcpu=cortex-m7 src/core/dhcp.c -c -save-temps -g -O2 GCC that it definitely fails on is as follows: arm-none-eabi-gcc -v Using built-in specs. COLLECT_GCC=arm-none-eabi-gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-none-eabi/11.3.0/lto-wrapper Target: arm-none-eabi Configured with: /var/tmp/notmpfs/portage/cross-arm-none-eabi/gcc-11.3.0/work/gcc-11.3.0/configure --host=x86_64-pc-linux-gnu --target=arm-none-eabi --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/arm-none-eabi/gcc-bin/11.3.0 --includedir=/usr/lib/gcc/arm-none-eabi/11.3.0/include --datadir=/usr/share/gcc-data/arm-none-eabi/11.3.0 --mandir=/usr/share/gcc-data/arm-none-eabi/11.3.0/man --infodir=/usr/share/gcc-data/arm-none-eabi/11.3.0/info --with-gxx-include-dir=/usr/lib/gcc/arm-none-eabi/11.3.0/include/g++-v11 --with-python-dir=/share/gcc-data/arm-none-eabi/11.3.0/python --enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 11.3.0 p4' --disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch --enable-poison-system-directories --disable-libstdcxx-time --with-sysroot=/usr/arm-none-eabi --disable-bootstrap --with-newlib --enable-multilib --disable-fixed-point --disable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --without-zstd --enable-lto --without-isl --disable-libsanitizer --disable-default-pie --enable-default-ssp --with-multilib-list=rmprofile Thread model: single Supported LTO compression algorithms: zlib gcc version 11.3.0 (Gentoo 11.3.0 p4)
[Bug target/106068] Infinite loop generated with -mcpu=cortex-m7 and -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106068
--- Comment #2 from Dave Flogeras ---
(In reply to Andrew Pinski from comment #1)
> You access an out of bounds for the array dhcp_rx_options_given in the while
> statement:
>
> while((dhcp_rx_options_given[8 + n] != 0) && (n < 2)) {
>
>
> Swap around the two expressions so you check to make sure n is less than 2
> before doing the array access. that is:
>
> while((n < 2) && (dhcp_rx_options_given[8 + n] != 0)) {
For that code, agreed, and that was indeed both our and upstreams workaround.
We were just wondering if it was a legitimate compiler bug given that it
generated an infinite loop in asm. Or does it just fall under "undefined"
