[Bug c++/81787] [5/6/7/8 Regression] `#pragma GCC diagnostic warning "-fpermissive"` no longer works since gcc 4.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81787 Piotr Henryk Dabrowski changed: What|Removed |Added CC||phd at phd dot re --- Comment #8 from Piotr Henryk Dabrowski --- Can we then have a new "#pragma GCC" for changing such options like -fpermissive? Or -Werror which I would like to toggle conditionally for a portion of code? In general: can we have pragma(s) for every gcc command-line switch? Would that be possible? We already have diagnostic for warnings, optimize for optimization options.
[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030 --- Comment #17 from Thomas Koenig --- (In reply to David Edelsohn from comment #16) > libgfortran unix.c:raw_write() will access the WRITE system call with up to > 2GB of data, which the testcase is using for the native format. > > Should libgfortran I/O buffer at least use sysconf(_SC_PAGESIZE) instead of > hard coding 8192? Depends. I would try not to blow away too much cache for such an operation. So far, this problem appears to be limited to POWER, and more specifically to file systems which are typically used in HPC. Could you (generic you, people who have access to such systems) show us some benchmarks which show performance as a function of block write size?
[Bug tree-optimization/91033] New: [10 Regression] ICE in vect_analyze_loop, at tree-vect-loop.c:2416
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91033
Bug ID: 91033
Summary: [10 Regression] ICE in vect_analyze_loop, at
tree-vect-loop.c:2416
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-checking, ice-on-valid-code, openmp
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
gcc-10.0.0-alpha20190623 snapshot (r272608) ICEs when compiling the following
testcase extracted from gcc/testsuite/gcc.dg/ipa/pr90555.c w/ -O1 (-O2, -O3,
-Ofast) -march=knl -fopenmp-simd -ftree-parallelize-loops=2:
#define N 1024
int a[N];
void
test_simdlen1 (void)
{
int i;
#pragma omp simd simdlen (4)
for (i = 0; i < N; ++i)
a[i] = a[i] + 1;
}
% x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20190623 -march=knl -O1
-fopenmp-simd -ftree-parallelize-loops=2 -c pyxioyv3.c
during GIMPLE pass: vect
In function 'test_simdlen1._loopfn.0':
cc1: internal compiler error: in vect_analyze_loop, at tree-vect-loop.c:2416
0x6fcb1a vect_analyze_loop(loop*, _loop_vec_info*, vec_info_shared*)
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190623/work/gcc-10-20190623/gcc/tree-vect-loop.c:2416
0xfbb725 try_vectorize_loop_1
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190623/work/gcc-10-20190623/gcc/tree-vectorizer.c:886
0xfbc3cf vectorize_loops()
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190623/work/gcc-10-20190623/gcc/tree-vectorizer.c:1114
[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030 --- Comment #18 from David Edelsohn --- For GPFS, the striping unit is 16M. The 8K buffer size chosen by GFortran is a huge performance sink. We have confirmed this with testing. The recommendation from GPFS is that one should query the filesystem with fstat() and write in chunks of the block size. Instead of arbitrarily choosing a uniform buffer size of 8K, GFortran would achieve better I/O performance in general by dynamically querying the filesystem characteristics and choosing a buffer size tuned to the filesystem. Presumably one must find some balance of memory consumption if the application opens a huge number of files. Or maybe some environment variable to override the buffer size. IBM XL FORTRAN achieves better performance, even for EXT4, by adapting I/O to the filesystem block size.
[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030 --- Comment #19 from David Edelsohn --- IBM XLF provides an XLFRTEOPTS environment variable, which includes control over buffer size. The documentation makes it clear that XLF uses the block size of the device by default: buffer_size=size Specifies the size of I/O buffers in bytes instead of using the block size of devices. size must be either -1 or an integer value that is greater than or equal to 4096. The default, -1, uses the block size of the device where the file resides. Using this option can reduce the amount of memory used for I/O buffers when an application runs out of memory because the block size of devices is very large and the application opens many files at the same time. Note the following when using this runtime option: Preconnected units remain unaffected by this option. Their buffer size is the same as the block size of the device where they reside except when the block size is larger than 64KB, in which case the buffer size is set to 64KB. This runtime option does not apply to files on a tape device or logical volume. Specifying the buffer size with the SETRTEOPTS procedure overrides any value previously set by the XLFRTEOPTS environment variable or SETRTEOPTS procedure. The resetting of this option does not affect units that have already been opened. https://www.ibm.com/support/knowledgecenter/SSAT4T_16.1.1/com.ibm.xlf1611.lelinux.doc/compiler_ref/rteopts.html
[Bug bootstrap/91034] New: In tree build of gmp fails on Raspberry Pi4 (ARM Cortex A72) with `mls r1,r4,r8,r11' not supported in ARM mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034 Bug ID: 91034 Summary: In tree build of gmp fails on Raspberry Pi4 (ARM Cortex A72) with `mls r1,r4,r8,r11' not supported in ARM mode Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: andrewm.roberts at sky dot com Target Milestone: --- When building gcc 9.1.0 (or 8.3.0) on Raspberry Pi 4 (ARM Cortex A72 in 32 bit mode) in tree build of gmp 6.1.2 (or 6.1.0) fails to build with: tmp-divrem_1.s:129: Error: selected processor does not support `mls r1,r4,r8,r11' in ARM mode gmp 6.1.2 builds fine outside of gcc, thus its not a straight binutils issue, but something to do with how gcc is configuring/building gmp. The same configurations and version builds gcc-9.1.0/8.3.0 fine on Raspberry Pi Zero and Pi 3b etc. /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS: 108.00 Features: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part: 0xd08 CPU revision: 3 uname -a Linux raspberrypi 4.19.50-v7l+ #895 SMP Thu Jun 20 16:03:42 BST 2019 armv7l GNU/Linux OS: Raspbian GNU/Linux 10 (buster) gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/8/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Raspbian 8.3.0-6+rpi1' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --disable-werror --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 8.3.0 (Raspbian 8.3.0-6+rpi1) gcc -march=native -Q --help=target The following options are target specific: -mabi=aapcs-linux -mabort-on-noreturn [disabled] -mandroid [disabled] -mapcs[disabled] -mapcs-frame [disabled] -mapcs-reentrant [disabled] -mapcs-stack-check[disabled] -march= armv8-a+crc+simd -marm [enabled] -masm-syntax-unified [disabled] -mbe32[enabled] -mbe8 [disabled] -mbig-endian [disabled] -mbionic [disabled] -mbranch-cost=-1 -mcallee-super-interworking [disabled] -mcaller-super-interworking [disabled] -mcmse[disabled] -mcpu= -mfix-cortex-m3-ldrd [disabled] -mflip-thumb [disabled] -mfloat-abi= hard -mfp16-format=none -mfpu=vfp -mglibc [enabled] -mhard-float -mlittle-endian [enabled] -mlong-calls [disabled] -mmusl[disabled] -mneon-for-64bits [disabled] -mpic-data-is-text-relative [enabled] -mpic-register= -mpoke-function-name [disabled] -mprint-tune-info [disabled] -mpure-code [disabled] -mrestrict-it [disabled] -msched-prolog[enabled] -msingle-pic-base [disabled] -mslow-flash-data [disabled] -msoft-float -mstructure-size-boundary=8 -mthumb [disabled] -mthumb-interwork [disabled] -mtls-dialect=gnu -mtp= cp15 -mtpcs-frame [disabled] -mtpcs-leaf-frame [disabled] -mtune= -muclibc [disabled] -munaligned-access
[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91030
--- Comment #20 from Thomas Koenig ---
(In reply to David Edelsohn from comment #18)
> For GPFS, the striping unit is 16M. The 8K buffer size chosen by GFortran
> is a huge performance sink. We have confirmed this with testing.
Could you share some benchmarks on this? I'd really like if the
gfortran maintainers could form their own judgment on this, based
on numbers.
Here's a benchmark program:
#include
#include
#include
#include
#include
#include
#include
#include
double walltime (void)
{
struct timeval TV;
double elapsed;
gettimeofday(&TV, NULL);
elapsed = (double) TV.tv_sec + 1.0e-6*((double) TV.tv_usec);
return elapsed;
}
#define NAME "out.dat"
#define N 25000
int main()
{
int fd;
double *p, *w;
long i, size, blocksize, left, to_write;
int bits;
double t1, t2;
struct statvfs buf;
printf ("Test using %e doubles\n", N * 1.0);
statvfs (".", &buf);
printf ("Block size of file system: %ld\n", buf.f_bsize);
p = malloc(N * sizeof (*p));
for (i=0; i 0)
{
if (left >= blocksize)
to_write = blocksize;
else
to_write = left;
write (fd, w, blocksize * sizeof (double));
w += to_write;
left -= to_write;
}
close (fd);
t2 = walltime ();
printf ("%.2f MiB/s\n", N / (t2-t1) / 1048576);
}
free (p);
unlink (NAME);
return 0;
}
And here is some output on my home system (ext4):
Test using 2.50e+08 doubles
Block size of file system: 4096
bs = 1024, 175.81 MiB/s
bs = 2048, 244.40 MiB/s
bs = 4096, 247.27 MiB/s
bs = 8192, 227.46 MiB/s
bs = 16384, 195.55 MiB/s
bs = 32768, 223.14 MiB/s
bs = 65536, 168.95 MiB/s
bs = 131072, 240.70 MiB/s
bs = 262144, 260.39 MiB/s
bs = 524288, 265.38 MiB/s
bs =1048576, 261.67 MiB/s
bs =2097152, 259.94 MiB/s
bs =4194304, 258.71 MiB/s
bs =8388608, 262.19 MiB/s
bs = 16777216, 260.19 MiB/s
bs = 33554432, 263.37 MiB/s
bs = 67108864, 264.47 MiB/s
And here is something on gcc135 (POWER9), also ext4:
Test using 2.50e+08 doubles
Block size of file system: 4096
bs = 1024, 206.76 MiB/s
bs = 2048, 293.66 MiB/s
bs = 4096, 347.13 MiB/s
bs = 8192, 298.23 MiB/s
bs = 16384, 397.51 MiB/s
bs = 32768, 401.86 MiB/s
bs = 65536, 431.83 MiB/s
bs = 131072, 475.88 MiB/s
bs = 262144, 470.09 MiB/s
bs = 524288, 478.84 MiB/s
bs =1048576, 485.68 MiB/s
bs =2097152, 485.33 MiB/s
bs =4194304, 483.96 MiB/s
bs =8388608, 482.88 MiB/s
bs = 16777216, 485.04 MiB/s
bs = 33554432, 483.92 MiB/s
bs = 67108864, 485.55 MiB/s
So, write thoughput sort of seems to level out at ~ 131072 block size,
2**17.
For Fortran, this is only really relevant for unformatted files.
[Bug bootstrap/91034] In tree build of gmp fails on Raspberry Pi4 (ARM Cortex A72) with `mls r1,r4,r8,r11' not supported in ARM mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034 --- Comment #1 from Andrew Roberts --- Configure line used for building gcc 9.1.0: ../gcc-9.1.0/configure --prefix=/usr/local/gcc-9.1.0--program-suffix= --disa ble-werror --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style =gnu --enable-plugin--enable-gnu-indirect-function --enable-lto --with-isl --enable-languages=c,c++,fortran,lto --disable-libgcj --enable-clocale=gnu --d isable-libstdcxx-pch--enable-install-libiberty --disable-multilib --disabl e-libssp --enable-default-pie --enable-default-ssp --host=arm-linux-gnueabi hf --build=arm-linux-gnueabihf --with-arch=armv6 --with-float=hard --with-fpu=vf p --disable-bootstrap the -with-arch=armv6 is the same as the host compiler. I would normally build on ArchLinux ARM (but that's not available for Pi4 yet). One difference is Raspbian configures its gcc using: --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf --with-arch=armv6 Basically one gcc configuration for all raspberry pi's. whereas ArchLinux ARM uses: --host=armv7l-unknown-linux-gnueabihf --build=armv7l-unknown-linux-gnueabihf --with-arch=armv7-a (RPI 3b 32bit) --host=armv6l-unknown-linux-gnueabihf --build=armv6l-unknown-linux-gnueabihf --with-arch=armv6 (RPI Zero) I normally copy the triplet/arch from the host compiler when building. If I use the ArchLinx ARM triplet: armv7l-unknown-linux-gnueabihf and "--with-arch=armv7-a" it still fails in the same way, so its not the --with-arch or triplet which is breaking things. Alternate (arch linux arm style) config which also fails: ../gcc-9.1.0/configure --prefix=/usr/local/gcc-9.1.0--program-suffix= --disa ble-werror --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style =gnu --enable-plugin--enable-gnu-indirect-function --enable-lto --with-isl --enable-languages=c,c++,fortran,lto --disable-libgcj --enable-clocale=gnu --d isable-libstdcxx-pch--enable-install-libiberty --disable-multilib --disabl e-libssp --enable-default-pie --enable-default-ssp --host=armv7l-unknown-li nux-gnueabihf --build=armv7l-unknown-linux-gnueabihf --with-arch=armv7-a --with- float=hard --with-fpu=vfp --disable-bootstrap
[Bug go/91035] New: [10 Regression] gotools fails to build on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035 Bug ID: 91035 Summary: [10 Regression] gotools fails to build on s390x-linux-gnu Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: doko at debian dot org CC: cmang at google dot com Target Milestone: --- seen with trunk r272790, using a binutils build from trunK: /<>/build/./gcc/gccgo -B/<>/build/./gcc/ -B/usr/lib/gcc-snapshot/s390x-linux-gnu/bin/ -B/usr/lib/gcc-sna pshot/s390x-linux-gnu/lib/ -isystem /usr/lib/gcc-snapshot/s390x-linux-gnu/include -isystem /usr/lib/gcc-snapshot/s390x-linux-gnu/s ys-include -g -O2 -I ../s390x-linux-gnu/libgo -static-libstdc++ -static-libgcc -Wl,-z,relro -L ../s390x-linux-gnu/libgo -L ../s3 90x-linux-gnu/libgo/.libs -o buildid ../../src/gotools/../libgo/go/cmd/buildid/buildid.go ../../src/gotools/../libgo/go/cmd/buildi d/doc.go ../s390x-linux-gnu/libgo/libgotool.a /usr/bin/s390x-linux-gnu-ld: ../s390x-linux-gnu/libgo/.libs/libgo.so: undefined reference to `.L37' collect2: error: ld returned 1 exit status make[4]: *** [Makefile:827: vet] Error 1 make[4]: *** Waiting for unfinished jobs /usr/bin/s390x-linux-gnu-ld: ../s390x-linux-gnu/libgo/.libs/libgo.so: undefined reference to `.L37' collect2: error: ld returned 1 exit status make[4]: *** [Makefile:829: buildid] Error 1 /usr/bin/s390x-linux-gnu-ld: ../s390x-linux-gnu/libgo/.libs/libgo.so: undefined reference to `.L37' collect2: error: ld returned 1 exit status make[4]: *** [Makefile:821: go] Error 1 /usr/bin/s390x-linux-gnu-ld: ../s390x-linux-gnu/libgo/.libs/libgo.so: undefined reference to `.L37' collect2: error: ld returned 1 exit status make[4]: *** [Makefile:823: gofmt] Error 1 make[4]: Leaving directory '/<>/build/gotools' make[3]: *** [Makefile:14968: all-gotools] Error 2 make[3]: Leaving directory '/<>/build' make[2]: *** [Makefile:25314: bootstrap] Error 2 make[2]: Leaving directory '/<>/build' T Sat, 29 Jun 2019 10:04:47 +
[Bug c/91036] New: GCC option -mno-dspr2 blocks the use of dsp r1 instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91036
Bug ID: 91036
Summary: GCC option -mno-dspr2 blocks the use of dsp r1
instructions
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: petrcvekcz at gmail dot com
Target Milestone: ---
Setup:
GCC 8.3.0 crosscompiler from aarch64 debian sid to mipsel 24kec with DSP ASE
Simple testing code:
#ifdef __mips_dsp
#warning "+++ DSP r1"
#endif
#ifdef __mips_dspr2
#warning "+++ DSP r2"
#endif
#if (__mips_dsp_rev == 1)
#warning "+++ DSP revision is: 1"
#elif (__mips_dsp_rev == 2)
#warning "+++ DSP revision is: 2"
#endif
int main(void) {
asm volatile ("lwx $5,$5($20)\n");
return 0;
}
Tests:
1) No options (compiler built for arch/tune=24kec and -mdsp):
# mipsel-unknown-linux-gnu-gcc ./no_dspr2_bug.c
./no_dspr2_bug.c:2:6: warning: #warning "+++ DSP r1" [-Wcpp]
#warning "+++ DSP r1"
^~~
./no_dspr2_bug.c:10:6: warning: #warning "+++ DSP revision is: 1" [-Wcpp]
#warning "+++ DSP revision is: 1"
^~~
2) With -mdsp option, still OK
# mipsel-unknown-linux-gnu-gcc ./no_dspr2_bug.c -mdsp
./no_dspr2_bug.c:2:6: warning: #warning "+++ DSP r1" [-Wcpp]
#warning "+++ DSP r1"
^~~
./no_dspr2_bug.c:10:6: warning: #warning "+++ DSP revision is: 1" [-Wcpp]
#warning "+++ DSP revision is: 1"
^~~
3) With -mdspr2 option, works OK, lwx _seems_ to be from DSPr1
# mipsel-unknown-linux-gnu-gcc ./no_dspr2_bug.c -mdspr2
./no_dspr2_bug.c:2:6: warning: #warning "+++ DSP r1" [-Wcpp]
#warning "+++ DSP r1"
^~~
./no_dspr2_bug.c:6:6: warning: #warning "+++ DSP r2" [-Wcpp]
#warning "+++ DSP r2"
^~~
./no_dspr2_bug.c:12:6: warning: #warning "+++ DSP revision is: 2" [-Wcpp]
#warning "+++ DSP revision is: 2"
^~~
4) With -mno-dspr2 option, fails as no dsp was defined at all, but still the
DSP macros are available
# mipsel-unknown-linux-gnu-gcc ./no_dspr2_bug.c -mno-dspr2
./no_dspr2_bug.c:2:6: warning: #warning "+++ DSP r1" [-Wcpp]
#warning "+++ DSP r1"
^~~
./no_dspr2_bug.c:10:6: warning: #warning "+++ DSP revision is: 1" [-Wcpp]
#warning "+++ DSP revision is: 1"
^~~
/tmp/cceDi2vp.s: Assembler messages:
/tmp/cceDi2vp.s:24: Error: opcode not supported on this processor: mips32r2
(mips32r2) `lwx $5,$5($20)'
5) Options -mno-dspr2 and -mdsp, IMO useful for situations, when you want only
instructions from rev1 subset and not from rev2, fails too:
# mipsel-unknown-linux-gnu-gcc ./no_dspr2_bug.c -mno-dspr2 -mdsp
./no_dspr2_bug.c:2:6: warning: #warning "+++ DSP r1" [-Wcpp]
#warning "+++ DSP r1"
^~~
./no_dspr2_bug.c:10:6: warning: #warning "+++ DSP revision is: 1" [-Wcpp]
#warning "+++ DSP revision is: 1"
^~~
/tmp/ccNYI1Y8.s: Assembler messages:
/tmp/ccNYI1Y8.s:24: Error: opcode not supported on this processor: mips32r2
(mips32r2) `lwx $5,$5($20)'
6) Behavior for -mdspr2 and -mno-dsp (I don't know what it should do, maybe it
should use only new instructions which was added with revision 2?):
# mipsel-unknown-linux-gnu-gcc ./no_dspr2_bug.c -mno-dsp -mdspr2
./no_dspr2_bug.c:2:6: warning: #warning "+++ DSP r1" [-Wcpp]
#warning "+++ DSP r1"
^~~
./no_dspr2_bug.c:6:6: warning: #warning "+++ DSP r2" [-Wcpp]
#warning "+++ DSP r2"
^~~
./no_dspr2_bug.c:12:6: warning: #warning "+++ DSP revision is: 2" [-Wcpp]
#warning "+++ DSP revision is: 2"
^~~
[Bug c++/91032] [9/10 Regression] ICE in ocp_convert, at cp/cvt.c:766
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91032 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Marek Polacek --- Started with r260272; most likely a dup. *** This bug has been marked as a duplicate of bug 90393 ***
[Bug c++/90393] [9/10 Regression] ICE in return statement with a conditional operator, one of the second and third arguments is throw, and the other is a const variable of a class with a nontrivial co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90393 Marek Polacek changed: What|Removed |Added CC||doko at debian dot org --- Comment #6 from Marek Polacek --- *** Bug 91032 has been marked as a duplicate of this bug. ***
[Bug plugins/90924] lto-plugin/lto-plugin.c heap memory corruption due to insufficient sanitization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90924 --- Comment #2 from Ren Kimura --- Created attachment 46534 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46534&action=edit Proof of Concept ELF binary for nm command (Purified)
[Bug plugins/90924] lto-plugin/lto-plugin.c heap memory corruption due to insufficient sanitization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90924
--- Comment #3 from Ren Kimura ---
Hi. Sorry for late. I've just attached more simple one.
PoC file for this bug can be created easily, just generating ELF file and edit
e_shstrndx in ELF header file to 0.
Attached one is built from simple Hello World program.
#include
int main() {
printf("Hello World\n");
};
gcc -o memcorrupt_nm-2.30_gcc-9.1.0_gold_simple hello_world.c
Edit e_shtrndx (offset 0x3E) to 0.
Thanks
Ren
(In reply to Martin Liška from comment #1)
> (In reply to Ren Kimura from comment #0)
> > Created attachment 46501 [details]
> > Proof of Concept ELF binary for nm command
>
> Hello.
>
> Is the file created with a fuzzer? I can confirm the crash, but the ELF
> container
> looks broken to me:
>
> $ readelf -S memcorrupt_nm-2.30_gcc-9.1.0_gold
> readelf: Warning: possibly corrupt ELF file header - it has a non-zero
> section header offset, but no section headers
> readelf: Error: Too many program headers - 0xdeff - the file is not that big
>
> Can you provide steps how to create such a file?
>
> Thanks
>
> >
> > On several major linux distributions like ubuntu, debian... binutils uses
> > ELF parser from gold linker plugin,
> > /usr/lib/gcc/x86_64-linux-gnu/9/liblto_plugin.so instead of libbfd.
> > I found a memory corruption bug (Heap OOB read) of gold ELF parser linked
> > from latest nm command(2.30).
> > If input binary file has a zero value string section offset (i.e e_shstrndx
> > == 0.), gold ELF parser try to find string section by
> > simple_object_find_sections() without enough sanitization.
> >
> > https://github.com/gcc-mirror/gcc/blob/
> > 6c552ff765c1b02d3ec9094f92c1ce58f8cda14b/lto-plugin/lto-plugin.c#L1059
> >
> > As a result if e_shstrndx is equal to 0, "(eor->shstrndx - 1)" at this line
> > cause integer overflow (a result becomes negative value (unsigned int)-1 )
> > https://github.com/gcc-mirror/gcc/blob/
> > 6c552ff765c1b02d3ec9094f92c1ce58f8cda14b/libiberty/simple-object-elf.c#L600
> >
> > and try to do out of bound access against heap memory, cause memory
> > corruption.
> >
> > On Ubuntu 18.10 with GCC 9.1.0.
> >
> > PoC file is attached to this email.
> > Execute PoC:
> > nm ./memcorrupt_nm-2.30_gcc-9.1.0_gold
> > Segmentation fault (core dumped)
> >
> > CrashDump:
> > nm --plugin ./gcc-9.1.0/build/lto-plugin/.libs/liblto_plugin.so.0.0.0
> > ./memcorrupt_nm-2.30_gcc-9.1.0_gold
> > Core was generated by `nm --plugin
> > ./gcc-9.1.0/build/lto-plugin/.libs/liblto_plugin.so.0.0.0 ./researc'.
> >
> > Program terminated with signal SIGSEGV, Segmentation fault.
> >
> > #0 simple_object_fetch_little_64 (buf=0x5678b4bc3640 > memory at address 0x5678b4bc3640>)
> > at ../../libiberty/simple-object-common.h:262
> >
> > 262 return (((ulong_type) buf[7] << 56)
> >
> > (gdb) bt
> >
> > #0 simple_object_fetch_little_64 (buf=0x5678b4bc3640 > memory at address 0x5678b4bc3640>)
> > at ../../libiberty/simple-object-common.h:262
> >
> > #1 0x7feb2c5b7268 in simple_object_elf_find_sections
> > (sobj=0x5638b4bc3630, pfn=0x7feb2c5b0930 ,
> > data=0x7ffd5884ca00, err=0x7ffd5884c9f4) at
> > ../../libiberty/simple-object-elf.c:601
> > #2 0x7feb2c5b0dd5 in claim_file_handler (file=0x7ffd5884cac0,
> > claimed=0x7ffd5884cabc)
> > at ../../lto-plugin/lto-plugin.c:1025
> >
> > #3 0x7feb2c49796b in ?? () from
> > /usr/lib/x86_64-linux-gnu/libbfd-2.31.1-multiarch.so
> >
> > #4 0x7feb2c497bef in ?? () from
> > /usr/lib/x86_64-linux-gnu/libbfd-2.31.1-multiarch.so
> >
> > #5 0x7feb2c30880a in bfd_check_format_matches () from
> > /usr/lib/x86_64-linux-gnu/libbfd-2.31.1-multiarch.so
> > #6 0x5638b4012cb0 in ?? ()
> > #7 0x5638b40109e6 in ?? ()
> > #8 0x7feb2c07f09b in __libc_start_main (main=0x5638b4010590, argc=4,
> > argv=0x7ffd5884ceb8, init=,
> > fini=, rtld_fini=,
> > stack_end=0x7ffd5884cea8) at ../csu/libc-start.c:308
> > #9 0x5638b4010a5a in ?? ()
> > ```
> >
> > Thanks
> > Ren
[Bug preprocessor/91037] New: #pragma GCC diagnostic ignored "-Wunused-macros" ignored for doubly-defined macro with g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91037 Bug ID: 91037 Summary: #pragma GCC diagnostic ignored "-Wunused-macros" ignored for doubly-defined macro with g++ Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: f.heckenb...@fh-soft.de Target Milestone: --- % cat unused.cpp #pragma GCC diagnostic ignored "-Wunused-macros" #define YYUSE #define YYUSE YYUSE % g++ -Wunused-macros unused.cpp unused.c:2: warning: macro "YYUSE" is not used [-Wunused-macros] Notably, this only seems to happen in C++, not in C. It not's like the pragma doesn't work at all. In this program, it correctly suppresses the warning: #pragma GCC diagnostic ignored "-Wunused-macros" #define YYUSE It also doesn't matter if I omit the last line of the original program. AIUI, the warning regarding the 2nd definition is correctly suppressed, but regarding the 1st definition is not.
[Bug bootstrap/91034] In tree build of gmp fails on Raspberry Pi4 (ARM Cortex A72) with `mls r1,r4,r8,r11' not supported in ARM mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034 --- Comment #2 from Andrew Roberts --- Building 9.1.0 with gmp 6.1.2 using "-v -save-temps" gives: gcc -v -save-temps -c -DHAVE_CONFIG_H -I. -I../../../gcc-9.1.0/gmp/mpn -I.. -D__GMP_WITHIN_GMP -I../../../gcc-9.1.0/gmp -DOPERATION_divrem_1 -DNO_ASM -O2 -g -pipe -Wa,--noexecstack tmp-divrem_1.s -o divrem_1.o gcc: warning: -pipe ignored because -save-temps specified Using built-in specs. COLLECT_GCC=gcc Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Raspbian 8.3.0-6+rpi1' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --disable-werror --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 8.3.0 (Raspbian 8.3.0-6+rpi1) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-D' 'HAVE_CONFIG_H' '-I' '.' '-I' '../../../gcc-9.1.0/gmp/mpn' '-I' '..' '-D' '__GMP_WITHIN_GMP' '-I' '../../../gcc-9.1.0/gmp' '-D' 'OPERATION_divrem_1' '-D' 'NO_ASM' '-O2' '-g' '-pipe' '-o' 'divrem_1.o' '-mfloat-abi=hard' '-mfpu=vfp' '-mtls-dialect=gnu' '-marm' '-march=armv6+fp' as --gdwarf2 -v -I . -I ../../../gcc-9.1.0/gmp/mpn -I .. -I ../../../gcc-9.1.0/gmp -march=armv6 -mfloat-abi=hard -mfpu=vfp -meabi=5 --noexecstack -o divrem_1.o tmp-divrem_1.s GNU assembler version 2.31.1 (arm-linux-gnueabihf) using BFD version (GNU Binutils for Raspbian) 2.31.1 tmp-divrem_1.s: Assembler messages: tmp-divrem_1.s:129: Error: selected processor does not support `mls r1,r4,r8,r11' in ARM mode tmp-divrem_1.s:145: Error: selected processor does not support `mls r1,r4,r8,r11' in ARM mode tmp-divrem_1.s:158: Error: selected processor does not support `mls r1,r4,r8,r11' in ARM mode tmp-divrem_1.s:175: Error: selected processor does not support `mls r1,r4,r3,r8' in ARM mode tmp-divrem_1.s:209: Error: selected processor does not support `mls r11,r4,r12,r3' in ARM mode Whereas building gmp 6.1.2 standalone (./configure ; make) using -v -save-temps gives: gcc -v -save-temps -c -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_divrem_1 -O2 -pedantic -fomit-frame-pointer -march=armv8-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a72 -Wa,--noexecstack tmp-divrem_1.s -fPIC -DPIC -o .libs/divrem_1.o Using built-in specs. COLLECT_GCC=gcc Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Raspbian 8.3.0-6+rpi1' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8 --program-prefix=arm-linux-gnueabihf- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-sjlj-exceptions --with-arch=armv6 --with-fpu=vfp --with-float=hard --disable-werror --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 8.3.0 (Raspbian 8.3.0-6+rpi1) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-D' 'HAVE_CONFIG_H' '-I' '.' '-I' '..' '-D' '__GMP_WITHIN_GMP' '-I' '..' '-D' 'OPERATION_divrem_1' '-O2' '-Wpedantic' '-fomit-frame-pointer' '-mfloat-abi=hard' '-mfpu=neon' '-mtune=cortex-a72' '-fPIC' '-D' 'PIC' '-o' '.libs/divrem_1.o' '-mtls-dialect=gnu' '-marm' '-march=armv8-a+simd' as -v -I . -I .. -I .. -march=armv8-a -mfloat-abi=hard -mfpu=neon -meabi=5 --noexecstack -o .libs/divrem_1.o tmp-divrem_1.s GNU assembler version 2.31.1 (arm-linux-gnueabihf) using BFD version (GNU Binutils for Raspbian) 2.31.1 COMPILER_PATH=/usr/lib/gcc/arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/ LIBRARY_PATH=/usr/lib/gcc/arm-linux-gnueabihf/8/:/usr/lib/gcc/arm-linux-gnueabihf/8/../../../arm-linux-gnueabihf/:/usr/lib/gcc/arm-linux-gnueabihf/8/../../../:/lib/arm-linux-gnueabihf/:/lib/:
[Bug bootstrap/91034] In tree build of gmp fails on Raspberry Pi4 (ARM Cortex A72) with `mls r1,r4,r8,r11' not supported in ARM mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034 --- Comment #3 from Andrew Roberts --- Created attachment 46535 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46535&action=edit tmp-divrem_1.s file generated using m4 from divrem_1.asm in gmp/mpn This is the gmp 6.1.2 version, from the gcc 9.1.0 build directory.
[Bug middle-end/47307] Uninitialized in this function: warning for initialized, no warning for uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47307 Eric Gallager changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org, ||dodji at gcc dot gnu.org --- Comment #5 from Eric Gallager --- cc-ing diagnostics maintainers
[Bug c++/71637] -Wmisleading-indentation only triggered when using integrated cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71637 Eric Gallager changed: What|Removed |Added CC||dodji at gcc dot gnu.org --- Comment #3 from Eric Gallager --- cc-ing other diagnostics maintainer (i.e. besides David, since he's already on this)
[Bug fortran/35276] Doc should described how to compile mixed-language programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276 --- Comment #7 from Eric Gallager --- (In reply to Thomas Koenig from comment #6) > (In reply to Eric Gallager from comment #5) > > (In reply to Jürgen Reuter from comment #4) > > > It seems that at least Thomas and Dominique believe that this can be > > > closed. > > > > with which status? > > We need to extend that chapter with the new status for gcc 9 after > Paul's fixes have all gone in. > > After that, I we should close this as FIXED. Have Paul's fixes all gone in yet?
[Bug go/91035] [10 Regression] gotools fails to build on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035 --- Comment #1 from Ian Lance Taylor --- As far as I know I don't have access to an S/390 system. Anything you can do to narrow down the problem would be helpful. Like, for example, which function has the undefined reference?
[Bug bootstrap/91034] In tree build of gmp fails on Raspberry Pi4 (ARM Cortex A72) with `mls r1,r4,r8,r11' not supported in ARM mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91034 --- Comment #4 from Marc Glisse --- Does it make a difference if you replace gmp 6.1.2 with a recent snapshot from https://gmplib.org/download/snapshot/ ?
