[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490 --- Comment #8 from Jakub Jelinek --- (In reply to Bernd Edlinger from comment #5) > Adding zero bytes after each string constant makes no sense IMHO, > since the linker will merge the constants, and so aligning the > constants with .zero does probably not work, but the should be > benign, except for that the alignment of the string constants. The linker string merging code is not working with the asm directives, it doesn't really care what part of the string comes from .string or .ascii and what part comes from .zero directives. And, what do you find wrong on the alignment? The section name indicates 8 byte alignment and .align 3 directive (which is like .balign 8 on this target) says the alignment of the strings is 8 byte, so all the strings (including a single terminating '\0') must be padded to multiples of 8 bytes by zeros.
[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490 --- Comment #7 from Bernd Edlinger --- (In reply to Alan Modra from comment #6) > The zero bytes are added by the -fsection-anchors code. They used to align > the next object. Now, the number of zero bytes is wrong (in cases where we > used to have an unterminated string), *and* gcc's calculation of the offset > to the object within the section-anchor block is wrong. > > Misaligned strings will mean poorer performance on some targets. > Miscalculating the offset will result in wrong-code errors when it results > in too many objects being placed into a block. Well, I see, the alignment is not right, but even if the strings are near to each other, they will be moved to other segments, if the string constant was already used in another module. Are there cases where the string constants need to be near the section anchor, what is that and how does it look like in an assembly file?
[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 --- Comment #4 from Piotr Kubaj --- Sorry, that was for a build with GCC 6. A build with GCC 4.2.1 is done with the following. Configure: /usr/bin/env CC="cc" CPP="cpp" CXX="c++" CFLAGS="-O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing " CPPFLAGS="-DLIBICONV_PLUG" CXXFLAGS="-O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -DLIBICONV_PLUG " LDFLAGS=" " LIBS="" INSTALL="/usr/bin/install -c" INSTALL_DATA="install -m 0644" INSTALL_LIB="install -s -m 0644" INSTALL_PROGRAM="install -s -m 555" INSTALL_SCRIPT="install -m 555" MAKE=gmake ac_cv_path_PERL=/usr/local/bin/perl ac_cv_path_PERL_PATH=/usr/local/bin/perl PERL_USE_UNSAFE_INC=1 UNAME_m="powerpc64" XDG_DATA_HOME=/usr/local/poudriere/ports/default/lang/gcc9-devel/work XDG_CONFIG_HOME=/usr/local/poudriere/ports/default/lang/gcc9-devel/work HOME=/usr/local/poudriere/ports/default/lang/gcc9-devel/work PATH=/usr/local/poudriere/ports/default/lang/gcc9-devel/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin SHELL=/bin/sh CONFIG_SHELL=/bin/sh ADDR2LINE="/usr/local/bin/addr2line" AR="/usr/local/bin/ar" AS="/usr/local/bin/as" CPPFILT="/usr/local/bin/c++filt" GPROF="/usr/local/bin/gprof" LD="/usr/local/bin/ld" NM="/usr/local/bin/nm" OBJCOPY="/usr/local/bin/objcopy" OBJDUMP="/usr/local/bin/objdump" RANLIB="/usr/local/bin/ranlib" READELF="/usr/local/bin/readelf" SIZE="/usr/local/bin/size" STRINGS="/usr/local/bin/strings" CONFIG_SITE=/usr/local/poudriere/ports/default/Templates/config.site lt_cv_sys_max_cmd_len=262144 /usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/configure --enable-multilib --with-build-config=bootstrap-debug --disable-nls --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc9 --libexecdir=/usr/local/libexec/gcc9 --program-suffix=9 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc9/include/c++/ --with-ld=/usr/local/bin/ld--with-pkgversion="FreeBSD Ports Collection" --with-system-zlib --enable-languages=c,c++,objc,fortran --prefix=/usr/local Make: /usr/bin/env PERL_USE_UNSAFE_INC=1 XDG_DATA_HOME=/usr/local/poudriere/ports/default/lang/gcc9-devel/work XDG_CONFIG_HOME=/usr/local/poudriere/ports/default/lang/gcc9-devel/work HOME=/usr/local/poudriere/ports/default/lang/gcc9-devel/work PATH=/usr/local/poudriere/ports/default/lang/gcc9-devel/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin NO_PIE=yes MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh NO_LINT=YES ADDR2LINE="/usr/local/bin/addr2line" AR="/usr/local/bin/ar" AS="/usr/local/bin/as" CPPFILT="/usr/local/bin/c++filt" GPROF="/usr/local/bin/gprof" LD="/usr/local/bin/ld" NM="/usr/local/bin/nm" OBJCOPY="/usr/local/bin/objcopy" OBJDUMP="/usr/local/bin/objdump" RANLIB="/usr/local/bin/ranlib" READELF="/usr/local/bin/readelf" SIZE="/usr/local/bin/size" STRINGS="/usr/local/bin/strings" PREFIX=/usr/local LOCALBASE=/usr/local CC="cc" CFLAGS="-O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing " CPP="cpp" CPPFLAGS="-DLIBICONV_PLUG" LDFLAGS=" " LIBS="" CXX="c++" CXXFLAGS="-O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -DLIBICONV_PLUG " MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install -s -m 555" BSD_INSTALL_LIB="install -s -m 0644" BSD_INSTALL_SCRIPT="install -m 555" BSD_INSTALL_DATA="install -m 0644" BSD_INSTALL_MAN="install -m 444" gmake -f Makefile -j16 MAKEINFOFLAGS="--no-split" bootstrap-lean
[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 --- Comment #3 from Piotr Kubaj --- Make is executed with: /usr/bin/env PERL_USE_UNSAFE_INC=1 XDG_DATA_HOME=/usr/local/poudriere/ports/default/lang/gcc9-devel/work XDG_CONFIG_HOME=/usr/local/poudriere/ports/default/lang/gcc9-devel/work HOME=/usr/local/poudriere/ports/default/lang/gcc9-devel/work PATH=/usr/local/poudriere/ports/default/lang/gcc9-devel/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin NO_PIE=yes MK_DEBUG_FILES=no MK_KERNEL_SYMBOLS=no SHELL=/bin/sh NO_LINT=YES ADDR2LINE="/usr/local/bin/addr2line" AR="/usr/local/bin/ar" AS="/usr/local/bin/as" CPPFILT="/usr/local/bin/c++filt" GPROF="/usr/local/bin/gprof" LD="/usr/local/bin/ld" NM="/usr/local/bin/nm" OBJCOPY="/usr/local/bin/objcopy" OBJDUMP="/usr/local/bin/objdump" RANLIB="/usr/local/bin/ranlib" READELF="/usr/local/bin/readelf" SIZE="/usr/local/bin/size" STRINGS="/usr/local/bin/strings" PREFIX=/usr/local LOCALBASE=/usr/local CC="gcc6" CFLAGS="-O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing " CPP="cpp6" CPPFLAGS="-DLIBICONV_PLUG" LDFLAGS=" " LIBS="" CXX="g++6" CXXFLAGS="-O2 -pipe -DLIBICONV_PLUG -DLIBICONV_PLUG " MANPREFIX="/usr/local" BSD_INSTALL_PROGRAM="install -s -m 555" BSD_INSTALL_LIB="install -s -m 0644" BSD_INSTALL_SCRIPT="install -m 555" BSD_INSTALL_DATA="install -m 0644" BSD_INSTALL_MAN="install -m 444" gmake -f Makefile -j16 MAKEINFOFLAGS="--no-split" bootstrap-lean
[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 --- Comment #2 from Piotr Kubaj --- I compile from FreeBSD ports tree (just change the port's Makefile not to use external (newer) GCC, but the in-base 4.2.1), so it adds some environment variables. /usr/bin/env CC="g cc6" CPP="cpp6" CXX="g++6" CFLAGS="-O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing " CPPFLAGS="-DLIBICONV_PLUG" CXXFLAGS="-O2 -pipe -DLIBICONV_PLUG -DLIBICONV_PLUG " LDFLAGS=" " LIBS="" INSTALL="/usr/bin/install -c" INSTALL_DATA="install -m 0644" INSTALL_LIB="install -s -m 0644" INSTALL_PROGRAM="install -s -m 555" INSTALL_SCRIPT="install -m 555" MAKE=gmake ac_cv_path_PERL=/usr/local/bin/perl ac_cv_path_PERL_PATH=/usr/local/bin/perl PERL_USE_UNSAFE_INC=1 UNAME_m="powerpc64" XDG_DATA_HOME=/usr/local/poudriere/ports/default/lang/gcc9-devel/work XDG_CONFIG_HOME=/usr/local/poudriere/ports/default/lang/gcc9-devel/work HOME=/usr/local/poudriere/ports/default/lang/gcc9-devel/work PATH=/usr/local/poudriere/ports/default/lang/gcc9-devel/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin SHELL=/bin/sh CONFIG_SHELL=/bin/sh ADDR2LINE="/usr/local/bin/addr2line" AR="/usr/local/bin/ar" AS="/usr/local/bin/as" CPPFILT="/usr/local/bin/c++filt" GPROF="/usr/local/bin/gprof" LD="/usr/local/bin/ld" NM="/usr/local/bin/nm" OBJCOPY="/usr/local/bin/objcopy" OBJDUMP="/usr/local/bin/objdump" RANLIB="/usr/local/bin/ranlib" READELF="/usr/local/bin/readelf" SIZE="/usr/local/bin/size" STRINGS="/usr/local/bin/strings" CONFIG_SITE=/usr/local/poudriere/ports/default/Templates/config.site lt_cv_sys_max_cmd_len=262144 /usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/configure --enable-multilib --with-build-config=bootstrap-debug --disable-nls --enable-gnu-indirect-function --libdir=/usr/local/lib/gcc9 --libexecdir=/usr/local/libexec/gcc9 --program-suffix=9 --with-as=/usr/local/bin/as --with-gmp=/usr/local --with-gxx-include-dir=/usr/local/lib/gcc9/include/c++/ --with-ld=/usr/local/bin/ld--with-pkgversion="FreeBSD Ports Collection" --with-system-zlib --enable-languages=c,c++,objc,fortran --prefix=/usr/local
[Bug go/86535] FreeBSD/PowerPC64 - Building Go Frontend support for gcc 7.3.0 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
Piotr Kubaj changed:
What|Removed |Added
CC||pkubaj at anongoth dot pl
--- Comment #13 from Piotr Kubaj ---
I have similar errors when building GCC 9:
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/cpuprof.go:73:26:
error: reference to undefined name 'nanotime'
73 | cpuprof.log.write(nil, nanotime(), hdr[:], nil)
| ^
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/cpuprof.go:105:33:
error: reference to undefined name 'nanotime'
105 | cpuprof.log.write(, nanotime(), hdr[:], stk)
| ^
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/lock_futex.go:199:14:
error: reference to undefined name 'nanotime'
199 | deadline := nanotime() + ns
| ^
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/lock_futex.go:213:10:
error: reference to undefined name 'nanotime'
213 | now := nanotime()
| ^
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/mgc.go:591:20:
error: reference to undefined name 'nanotime'
591 | assistDuration := nanotime() - c.markStartTime
|^
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/mgc.go:721:12:
error: reference to undefined name 'nanotime'
721 | delta := nanotime() - gcController.markStartTime
|^
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/mgc.go:745:9:
error: reference to undefined name 'nanotime'
745 | now := nanotime()
| ^
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/mgc.go:1279:9:
error: reference to undefined name 'nanotime'
1279 | now := nanotime()
| ^
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/mgc.go:1492:9:
error: reference to undefined name 'nanotime'
1492 | now := nanotime()
| ^
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/mgc.go:1591:15:
error: reference to undefined name 'nanotime'
1591 | startTime := nanotime()
| ^
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/mgc.go:1656:9:
error: reference to undefined name 'nanotime'
1656 | now := nanotime()
| ^
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/mgc.go:1882:16:
error: reference to undefined name 'nanotime'
1882 | startTime := nanotime()
|^
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/mgc.go:1933:15:
error: reference to undefined name 'nanotime'
1933 | duration := nanotime() - startTime
| ^
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/mgcmark.go:437:15:
error: reference to undefined name 'nanotime'
437 | startTime := nanotime()
| ^
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/mgcmark.go:480:14:
error: reference to undefined name 'nanotime'
480 | duration := nanotime() - startTime
| ^
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/mheap.go:1215:19:
error: reference to undefined name 'nanotime'
1215 | s.unusedsince = nanotime()
| ^
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/netpoll.go:220:8:
error: reference to undefined name 'nanotime'
220 | d += nanotime()
|^
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/os_freebsd.go:18:19:
error: reference to undefined name '_CTL_HW'
18 | mib := [2]uint32{_CTL_HW, _HW_PAGESIZE}
| ^
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/os_freebsd.go:18:28:
error: reference to undefined name '_HW_PAGESIZE'
18 | mib := [2]uint32{_CTL_HW, _HW_PAGESIZE}
|^
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/os_freebsd.go:21:9:
error: reference to undefined name 'sysctl'
21 | ret := sysctl([0], 2, (*byte)(unsafe.Pointer()), , nil,
0)
| ^
/usr/local/poudriere/ports/default/lang/gcc9-devel/work/gcc-9-20190217/libgo/go/runtime/os_freebsd.go:15:75:
error: use of undefined type 'umtx_time'
15 | func sys_umtx_op(addr *uint32, mode int32, val uint32, uaddr1 uinptr,
ts *umtx_time) int32
There are more of those errors, all are
[Bug rtl-optimization/80791] [8/9 regression] test case gcc.dg/sms-1.c fail2 starting with r247885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80791 --- Comment #22 from Kewen Lin --- As the discussion above, on Power any IV should have an extend (sign/zero) if its width is less than the GPR width (POINTER_SIZE equivalent here). Although we don't model this precisely on Power, in most cases it's trivial since we have TYPE_PRECISION check for those inconsistent width uses, extra cost will be added, the IV is still the one we prefer even with extension consideration in cost modeling, that is, considering extension or not doesn't affect the result. In this case, we have one GENERIC use and one CMP use. Cand 4 was chosen as the best, but later RTL opts can eliminate CMP use by using counter register for the loop closing, it means we don't need to consider CMP use in ivopts phase. Since there is no any uses for 32bit IV, the extension cost can NOT be covered (ignored) as usual. The cost for GENERIC use looks like [cand $index ($iv_cost + $comp_cost)]: 1) without considering extension cost, cand 4 (4 + 4) vs. cand 6 (5 + 0) 2) with considering extension cost, cand 4 (8 + 4) vs. cand 6 (9 + 0) Since cand 6 can't be used for CMP use, so if we still need to consider CMP, cand 4 is always selected, the cost would be larger introducing cand 6. But if can predict CMP is useless and model extension, the cost would be: cand 4 (8 + 4) vs. cand 6 (9 + 0). Cand 6 is better. I did some hacks locally and it works. But the most tricky and hardest part would be how to predict CMP will be optimized away with CTR eventually, the correctness of predict is more important. It looks better to think about the simplest case first. The proposed idea is that: 1) one target specific hook/flag to enable this adjust 2) one target specific predict function to determine the loop can benefit do_loop CTR transformation (like innermost loop, no calls, niter determined etc.) 3) check only one CMP with biv after find_interesting_uses, biv's width < POINTER_SIZE, remove the group 4) mark the biv preserved to avoid to be removed in remove_unused_ivs 5) adjust determine_iv_cost for those IVs which require extension (optinal, for this case, it's not necessary but probably good as more precise modeling) Hi All, I'm a new comer to gcc and not sure the above idea is practical enough, could you kindly give me some comments and suggestion?
[Bug c/80409] Document that va_arg(ap, void*) can be used to consume any pointer argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80409 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from sandra at gcc dot gnu.org --- Fixed on trunk.
[Bug c/80409] Document that va_arg(ap, void*) can be used to consume any pointer argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80409 --- Comment #5 from sandra at gcc dot gnu.org --- Author: sandra Date: Tue Feb 26 02:33:26 2019 New Revision: 269203 URL: https://gcc.gnu.org/viewcvs?rev=269203=gcc=rev Log: 2019-02-25 Sandra Loosemore PR c/80409 gcc/ * doc/extend.texi (Variadic Pointer Args): New section. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi
[Bug rtl-optimization/89487] [8/9 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7993
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89487 bin cheng changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org --- Comment #4 from bin cheng --- Sorry for the breakage, I will investigate this. Thanks
[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490 Alan Modra changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed|2019-02-25 00:00:00 |2019-02-26 Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug target/89502] Error: can't encode segment `%fs' with 32-bit address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89502 --- Comment #2 from H.J. Lu --- (In reply to H.J. Lu from comment #1) > > Ever better, we can use UNSPEC_TP to handle it: > > movl%fs:24, %ecx > This is how TCB is accessed in glibc.
[Bug c++/88987] [9 Regression] ICE: unexpected expression '(bool)sm' of kind implicit_conv_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88987 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #3 from Paolo Carlini --- Mine.
[Bug target/89502] Error: can't encode segment `%fs' with 32-bit address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89502 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-26 CC||ubizjak at gmail dot com Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- We should do movl$24, %edx movl%fs:(%rdx), %ecx instead of movl$24, %edx movl%fs:(%edx), %ecx Ever better, we can use UNSPEC_TP to handle it: movl%fs:24, %ecx to save a register.
[Bug ada/81956] [7/8/9 regression] calling a null procedure is not skipped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81956 --- Comment #3 from yuta tomino --- I'm trying gcc-8.3. This is probably fixed in 8.x. Thanks.
[Bug target/89502] New: Error: can't encode segment `%fs' with 32-bit address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89502
Bug ID: 89502
Summary: Error: can't encode segment `%fs' with 32-bit address
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
Target: x32
[hjl@gnu-cfl-1 xx]$ cat x.i
typedef unsigned int uint32_t;
struct ctx
{
uint32_t A;
};
void *
buffer_copy (const struct ctx *ctx, void *resbuf)
{
uint32_t buffer[4];
buffer[0] = (ctx->A);
__builtin_memcpy (resbuf, buffer, sizeof (buffer));
return resbuf;
}
[hjl@gnu-cfl-1 xx]$ make x.o
/export/build/gnu/tools-build/gcc-mmx-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-mmx-debug/build-x86_64-linux/gcc/
-fstack-protector-strong -O1 -frename-registers -mx32 -S x.i
/export/build/gnu/tools-build/gcc-mmx-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-mmx-debug/build-x86_64-linux/gcc/
-fstack-protector-strong -O1 -frename-registers -mx32 -c -o x.o x.s
x.s: Assembler messages:
x.s:11: Error: can't encode segment `%fs' with 32-bit address
x.s:18: Error: can't encode segment `%fs' with 32-bit address
make: *** [Makefile:21: x.o] Error 1
[hjl@gnu-cfl-1 xx]$
The problem is
movl%fs:(%edx), %ecx
In x32, we can't have 0x67 prefix (from %edx) with segment override
since final address will be
segment base + zero-extended (base + index * scale + disp)
Since assembler
https://sourceware.org/bugzilla/show_bug.cgi?id=24263
doesn't know %edx is always positive, it issues an error.
[Bug libstdc++/64132] [7/8/9 Regression] FAIL: 22_locale/numpunct/members/char/3.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64132 John David Anglin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from John David Anglin --- This was fixed on trunk somewhere between r264889 and r265360.
[Bug c++/89450] RFC: Strengthen -fstrict-enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89450 --- Comment #10 from Marc Glisse --- I still think some __attribute__((exhaustive)) on an enum definition would be useful for this sort of thing.
[Bug c/89495] [9 Regression] gcc/c-family/c-format.c:1272:20: runtime error: signed integer overflow: 214748365 * 10 cannot be represented in type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89495 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 89495, which changed state. Bug 89495 Summary: [9 Regression] gcc/c-family/c-format.c:1272:20: runtime error: signed integer overflow: 214748365 * 10 cannot be represented in type 'int' https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89495 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug libstdc++/89461] FAIL: experimental/net/timer/waitable/cons.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89461 --- Comment #3 from dave.anglin at bell dot net --- On 2019-02-23 2:34 p.m., redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89461 > > --- Comment #2 from Jonathan Wakely --- > Oops, that should be: > > --- a/libstdc++-v3/include/experimental/io_context > +++ b/libstdc++-v3/include/experimental/io_context > @@ -134,7 +134,8 @@ inline namespace v1 >io_context* _M_ctx; > }; > > -using count_type = size_t; > +using count_type > + = conditional_t int>; > > // construct / copy / destroy: Makes things worse. I think we need to be using a mutes.
[Bug c/89495] [9 Regression] gcc/c-family/c-format.c:1272:20: runtime error: signed integer overflow: 214748365 * 10 cannot be represented in type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89495 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Mon Feb 25 23:43:51 2019 New Revision: 269198 URL: https://gcc.gnu.org/viewcvs?rev=269198=gcc=rev Log: PR c/89495 * c-format.c (maybe_read_dollar_number): Compute nargnum in HOST_WIDE_INT type to avoid overflows and change overflow_flag checking. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-format.c
[Bug tree-optimization/18501] [7/8/9 Regression] Missing 'used uninitialized' warning (CCP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 Jeffrey A. Law changed: What|Removed |Added CC||torvalds@linux-foundation.o ||rg --- Comment #89 from Jeffrey A. Law --- *** Bug 89501 has been marked as a duplicate of this bug. ***
[Bug middle-end/89501] Odd lack of warning about missing initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501 Jeffrey A. Law changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||law at redhat dot com Resolution|--- |DUPLICATE --- Comment #4 from Jeffrey A. Law --- Dup. 18501 is the canonical bug for this issue. *** This bug has been marked as a duplicate of bug 18501 ***
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 89501, which changed state. Bug 89501 Summary: Odd lack of warning about missing initialization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/89501] Odd lack of warning about missing initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501 --- Comment #3 from Jeffrey A. Law --- Yup. It's the same as 18501. We meet UNDEFINED and [0,0] resulting in [0,0] and nothing ever causes reevaluation of the PHI. Things are working as "expected". My approach from 2005 would almost certainly address this instance since we'd see the uninitialized use in the early uninit pass, and later see it went away. It'd ultimately generate indicating there was an uninitialized use of "ret" that was optimized away. But I'm not inclined to rip the scabs of those old wounds and reopen that discussion (for the umpteenth time)
[Bug middle-end/89501] Odd lack of warning about missing initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
--- Comment #2 from Linus Torvalds ---
(In reply to Andrew Pinski from comment #1)
> I think it comes down to the same issue as PR 18501.
Very possibly the same issue in just a different guise.
NOTE! I have in the meantime verified that yes, it does seem to be about the
pattern
int x;
if (somecondition) {
x = something();
if (x != XYZ)
return x;
}
return x;
where gcc seems to turn the "if (x != XYZ) return x" to mean that "x" clearly
_has_ to be XYZ elsewhere.
If I change my kernel-based test-case to do
if (ret != 1)
return ret;
instead of the original
if (ret)
return ret;
then gcc will actually generate code that ends with
movl$1, %eax
popq%rbp
popq%r12
ret
ie it will basically consider "ret" to be initialized to that value "1", even
if the basic block that assigned it was never actually executed.
Knowing how SSA works, I'm not entirely surprised, but obviously if you'd like
to see the warning about buggy source code, it's less than optimal.
Anyway, this shouldn't be a high priority, but it does strike me as a
potentially fairly common pattern that people might be missing warnings for.
Linus
[Bug libquadmath/89459] Incorrect rounding for fma in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89459 --- Comment #3 from joseph at codesourcery dot com --- GCC 8 branched off mainline in April 2018, long before that merge; it's necessary to test mainline (that will become GCC 9 and later), not any existing release, to see if that merge fixed things.
[Bug middle-end/89501] Odd lack of warning about missing initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501 --- Comment #1 from Andrew Pinski --- I think it comes down to the same issue as PR 18501.
[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490 Alan Modra changed: What|Removed |Added Priority|P1 |P3 Status|NEW |UNCONFIRMED Target Milestone|9.0 |--- Ever confirmed|1 |0 --- Comment #6 from Alan Modra --- The zero bytes are added by the -fsection-anchors code. They used to align the next object. Now, the number of zero bytes is wrong (in cases where we used to have an unterminated string), *and* gcc's calculation of the offset to the object within the section-anchor block is wrong. Misaligned strings will mean poorer performance on some targets. Miscalculating the offset will result in wrong-code errors when it results in too many objects being placed into a block.
[Bug c/77754] [7/8/9 Regression] internal compiler error : tree code 'call_expr' is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77754 --- Comment #14 from Jakub Jelinek --- Author: jakub Date: Mon Feb 25 22:58:45 2019 New Revision: 269197 URL: https://gcc.gnu.org/viewcvs?rev=269197=gcc=rev Log: PR c/77754 * gcc.c-torture/compile/pr77754-1.c: New test. * gcc.c-torture/compile/pr77754-2.c: New test. * gcc.c-torture/compile/pr77754-3.c: New test. * gcc.c-torture/compile/pr77754-4.c: New test. * gcc.c-torture/compile/pr77754-5.c: New test. * gcc.c-torture/compile/pr77754-6.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr77754-1.c trunk/gcc/testsuite/gcc.c-torture/compile/pr77754-2.c trunk/gcc/testsuite/gcc.c-torture/compile/pr77754-3.c trunk/gcc/testsuite/gcc.c-torture/compile/pr77754-4.c trunk/gcc/testsuite/gcc.c-torture/compile/pr77754-5.c trunk/gcc/testsuite/gcc.c-torture/compile/pr77754-6.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug c/89501] New: Odd lack of warning about missing initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89501
Bug ID: 89501
Summary: Odd lack of warning about missing initialization
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: torva...@linux-foundation.org
Target Milestone: ---
Created attachment 45820
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45820=edit
You can compile this to see a lack of warning.
We had a simple kernel patch that introduced a stupid bug due to an
uninitialized variable, and while we got it all sorted out and the fix was
trivial, people were surprised by the lack of warning for the uninitialized
case.
I'm adding a test-case as an attachment that largely matches the kernel code
that didn't warn. But it boils down to a pattern of
int ret; /* UNINITIALIZED */
if (somecondition) {
ret = functioncall(x);
if (ret)
return ret;
}
.. some more work ..
return ret; /* Possibly uninitialized return value! */
What I *suspect* happens is
(a) gcc sees that there is only one assignment to "ret"
(b) in the same basic block as the assignment, there is a test against "ret"
being nonzero that goes out.
and what I think happens is that (a) causes gcc to consider that assignment to
be the defining assignment (which makes all kinds of sense in an SSA world),
and then (b) means that gcc decides that clearly "ret" has to be zero in any
case that doesn't go out due to the if-test.
So it turns out that gcc almost by mistake generates code that works (and
doesn't warn about it, exactly because it works), even though the source code
was clearly buggy.
The attached test-case is stupid but intentionally made to be as close to the
kernel source case as possible. With it, I can do:
Look, ma: no warning:
gcc -O2 -S -Wall test.c
but this gives the expected warning:
gcc -O2 -S -Wall -DHIDE_PROBLEM test.c
regardless, this is not a huge problem for us, but I decided to make a report
since we have a test case, and maybe somebody gets excited about it.
Thanks,
Linus
[Bug fortran/84779] [7/8/9 Regression] Compiling gfortran.fortran-torture/execute/entry_4.f90 with -O1 or -Os and -fdefault-integer-8 gives an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84779 --- Comment #6 from Harald Anlauf --- Adding the option -fno-tree-sra to -O1 (or -Os for the original case) makes the ICE go away for me.
[Bug c++/89450] RFC: Strengthen -fstrict-enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89450 --- Comment #9 from Martin Liška --- (In reply to Andrew Pinski from comment #8) > (In reply to Martin Liška from comment #7) > > in switch statements, we have a huge patch: > > https://build.opensuse.org/package/view_file/network:chromium/chromium-beta/ > > chromium-non-void-return.patch?expand=1 > > Part of it should be resolved if you define NOTREACHED correctly Maybe > to __builtin_unreachable. Yep, that's exactly what we've been doing :)
[Bug fortran/89492] [9 Regression] Endless compilation of an invalid TRANSFER after r269177
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89492 --- Comment #4 from Harald Anlauf --- Patch with slightly extended testcase posted here: https://gcc.gnu.org/ml/fortran/2019-02/msg00218.html
[Bug tree-optimization/89500] [9 Regression] ICE: tree check: expected integer_cst, have ssa_name in get_len, at tree.h:5653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89500 --- Comment #4 from Jakub Jelinek --- Created attachment 45819 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45819=edit gcc9-pr89500.patch Untested fix.
[Bug tree-optimization/89500] [9 Regression] ICE: tree check: expected integer_cst, have ssa_name in get_len, at tree.h:5653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89500 --- Comment #3 from Jakub Jelinek --- The simplest fix might be: --- gcc/tree-ssa-strlen.c.jj2019-01-18 00:33:19.466003372 +0100 +++ gcc/tree-ssa-strlen.c 2019-02-25 21:59:18.743419101 +0100 @@ -1302,6 +1302,7 @@ handle_builtin_strlen (gimple_stmt_itera = fold_build2_loc (loc, MIN_EXPR, TREE_TYPE (rhs), rhs, bound); noncst_bound = (TREE_CODE (new_rhs) != INTEGER_CST + || TREE_CODE (rhs) != INTEGER_CST || tree_int_cst_lt (new_rhs, rhs)); rhs = new_rhs; The problem is that even when rhs is not INTEGER_CST, when bound is size_zero_node, then new_rhs is size_zero_node too, but we can't really use tree_int_cst_lt in that case (nor know anything about the string length). But, I think we don't want to stay at that, noncst_bound seems to be really misnamed, but furthermore, I fail to see when it is ever useful to record something (or when it actually would record anything, because it doesn't it si->nonzero_chars is INTEGER_CST.
[Bug fortran/89496] [9 Regression] gcc/fortran/trans-types.c:3015:9: runtime error: member access within null pointer of type 'struct gfc_formal_arglist'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89496 --- Comment #3 from Thomas Koenig --- This test case also segfaults with a non-instrumeted compiler: program main call sub(10, *10, 20) stop 1 10 continue end program main
[Bug bootstrap/89494] Bootstrap error when using GCC 4.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-02-25 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- What configure options are you using? How are you invoking make?
[Bug fortran/89496] [9 Regression] gcc/fortran/trans-types.c:3015:9: runtime error: member access within null pointer of type 'struct gfc_formal_arglist'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89496
--- Comment #2 from Thomas Koenig ---
This looks pretty obvious to me, at least looking at the
-fdump-fortran-original dump. I will try to come up with
a test case.
Would it be possible to check that this also fixes the
nullpointer offset access?
Index: trans-types.c
===
--- trans-types.c (Revision 269161)
+++ trans-types.c (Arbeitskopie)
@@ -2988,9 +2988,9 @@
f = >formal;
for (a = actual_args; a != NULL; a = a->next)
{
+ (*f) = gfc_get_formal_arglist ();
if (a->expr)
{
- (*f) = gfc_get_formal_arglist ();
snprintf (name, GFC_MAX_SYMBOL_LEN, "_formal_%d", var_num ++);
gfc_get_symbol (name, NULL, );
if (a->expr->ts.type == BT_PROCEDURE)
@@ -3012,6 +3012,9 @@
s->attr.intent = INTENT_UNKNOWN;
(*f)->sym = s;
}
+ else
+ (*f)->sym = NULL;
+
f = &((*f)->next);
}
}
[Bug c++/89450] RFC: Strengthen -fstrict-enums
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89450 --- Comment #8 from Andrew Pinski --- (In reply to Martin Liška from comment #7) > in switch statements, we have a huge patch: > https://build.opensuse.org/package/view_file/network:chromium/chromium-beta/ > chromium-non-void-return.patch?expand=1 Part of it should be resolved if you define NOTREACHED correctly Maybe to __builtin_unreachable.
[Bug rtl-optimization/89490] [9 Regression] char array constant put in string merge section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #5 from Bernd Edlinger ---
The patch should probably work, and a powerpc cross fixes the test case.
At least bootstrap and reg-test on x86_64-pc-linux-gnu is fine,
but that proves not too much.
When I look at the merge-all-constants-2.c test case, I think
the mergeable string secrtion looks bogus (unrelated to this):
$ cat merge-all-constants-2.c
/* { dg-do compile } */
/* { dg-require-effective-target string_merging } */
/* { dg-options "-w -O2 -fmerge-all-constants" } */
const char str1[36] = "0123456789abcdefghijklmnopqrstuvwxyz";
const char str2[37] = "0123456789abcdefghijklmnopqrstuvwxyz";
const char str3[10] = "0123456789abcdefghijklmnopqrstuvwxyz";
/* { dg-final { scan-assembler-not "\\.rodata\[\n\r\]" } } */
$ powerpc64-unknown-linux-gcc -O2 -S merge-all-constants-2.c
merge-all-constants-2.c:7:23: warning: initializer-string for array of chars is
too long
7 | const char str3[10] = "0123456789abcdefghijklmnopqrstuvwxyz";
| ^~
$ cat merge-all-constants-2.s
.file "merge-all-constants-2.c"
.machine power4
.section".text"
.globl str3
.globl str2
.globl str1
.section.rodata.str1.8,"aMS",@progbits,1
.align 3
.type str3, @object
.size str3, 10
str3:
.string "0123456789"
.zero 6
.type str2, @object
.size str2, 37
str2:
.string "0123456789abcdefghijklmnopqrstuvwxyz"
.zero 3
.type str1, @object
.size str1, 36
str1:
.string "0123456789abcdefghijklmnopqrstuvwxyz"
.ident "GCC: (GNU) 9.0.1 20190222 (experimental)"
Adding zero bytes after each string constant makes no sense IMHO,
since the linker will merge the constants, and so aligning the
constants with .zero does probably not work, but the should be
benign, except for that the alignment of the string constants.
[Bug debug/89498] [8/9 Regression] ICE in AT_loc_list, at dwarf2out.c:4871
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89498 Andrew Pinski changed: What|Removed |Added Component|c |debug Target Milestone|--- |8.4
[Bug tree-optimization/89500] [9 Regression] ICE: tree check: expected integer_cst, have ssa_name in get_len, at tree.h:5653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89500
--- Comment #2 from Jakub Jelinek ---
Even better testcase without any UB in it:
typedef __SIZE_TYPE__ size_t;
extern size_t strlen (const char *);
extern size_t strnlen (const char *, size_t);
extern void bar (char *);
void
foo (int *a)
{
char c[64];
bar (c);
a[0] = strlen (c);
a[1] = strnlen (c, 0);
}
[Bug fortran/89492] [9 Regression] Endless compilation of an invalid TRANSFER after r269177
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89492
--- Comment #3 from Harald Anlauf ---
I found another issue for uses of transfer('',['']), so here's an updated
version with a clearer error message:
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 269177)
+++ gcc/fortran/check.c (working copy)
@@ -5487,6 +5487,26 @@
if (!gfc_element_size (mold, _elt_size))
return false;
+ if (result_elt_size == 0 && *source_size > 0)
+{
+ gfc_error ("% argument of % intrinsic at %L "
+ "shall not have storage size 0 when % "
+"argument has size greater than 0", >where);
+ return false;
+}
+
+ /* If MOLD is a scalar and SIZE is absent, the result is a scalar.
+ * If MOLD is an array and SIZE is absent, the result is an array and of
+ * rank one. Its size is as small as possible such that its physical
+ * representation is not shorter than that of SOURCE.
+ */
+ if (result_elt_size == 0 && *source_size == 0 && !size)
+{
+ *result_size = 0;
+ *result_length_p = 0;
+ return true;
+}
+
if ((result_elt_size > 0 && (mold->expr_type == EXPR_ARRAY || mold->rank))
|| size)
{
Suggested testcase:
! { dg-do compile }
!
! PR fortran/89492 - Endless compilation of an invalid TRANSFER after r269177
! Test error recovery for invalid uses of TRANSFER
! Test proper simplification for MOLD with size 0
!
! Derived from original testcase by Dominique d'Humieres
program bug4a
implicit none
type bug4
! Intentionally left empty
end type bug4
integer, parameter :: k = size(transfer('',[''])) ! k = 0
integer, parameter :: m(k) = k
print *, transfer(1,[''])! { dg-error "shall not have
storage size 0" }
print *, size(transfer(1,[''])) ! { dg-error "shall not have
storage size 0" }
print *, size(transfer([1],[bug4()])) ! { dg-error "shall not have
storage size 0" }
print *, transfer(transfer([1],[bug4()]),[1]) ! { dg-error "shall not have
storage size 0" }
end program bug4a
[Bug tree-optimization/89500] [9 Regression] ICE: tree check: expected integer_cst, have ssa_name in get_len, at tree.h:5653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89500
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2019-02-25
CC||jakub at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Target Milestone|--- |9.0
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek ---
Started with r262114. Looking into this.
Slightly adjusted testcase, no need for c[0] nor storing strnlen into the same
element as strlen:
typedef __SIZE_TYPE__ size_t;
extern size_t strlen (const char *);
extern size_t strnlen (const char *, size_t);
void
foo (int *a)
{
char c[4];
a[0] = strlen (c);
a[1] = strnlen (c, 0);
}
[Bug c++/71446] Incorrect overload resolution when using designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446 --- Comment #6 from Jakub Jelinek --- GCC 4.7 through 7.x emit: sorry, unimplemented: non-trivial designated initializers not supported here (and 4.6 and earlier didn't support C++11 enough to grok it). That said, you're right, the skipping is implemented regardless of the -std= mode, though you get -pedantic warnings if you do before -std=c++2a: warning: C++ designated initializers only available with -std=c++2a or -std=gnu++2a
[Bug c++/71446] Incorrect overload resolution when using designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446
--- Comment #5 from Harald van Dijk ---
(In reply to Jakub Jelinek from comment #3)
> Well, before C++2a it is an extension, so outside of the C++ standard, and
> GCC has been implementing it as not allowing to skip any fields.
Not exactly. Outside of overload resolution, GCC does implement it as allowing
skipping of fields. Test case:
struct S {
int a, b;
bool equals(S other) const { return a == other.a && b == other.b; }
} s = {.a = 0, .b = 1};
int main() { return !s.equals({.b = 1}); }
This program should and does return 0, showing that {.b = 1} initialises the
second field, not the first.
[Bug fortran/89492] [9 Regression] Endless compilation of an invalid TRANSFER after r269177
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89492 --- Comment #2 from Dominique d'Humieres --- > Can you please verify that your testcases work? With the patch I get pr34202_red.f90:8:54: 8 |write(*,*) transfer(transfer([1],[bug4()]),[1],size[1]) | 1 Error: Function 'size' requires an argument list at (1) pr34202_red.f90:7:30: 7 |write(*,*) size(transfer(1,[''])) | 1 Error: 'MOLD' argument of 'TRANSFER' intrinsic at (1) has storage size 0 Full test in progress. Thanks for the quick answer.
[Bug c/89500] New: [9 Regression] ICE: tree check: expected integer_cst, have ssa_name in get_len, at tree.h:5653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89500
Bug ID: 89500
Summary: [9 Regression] ICE: tree check: expected integer_cst,
have ssa_name in get_len, at tree.h:5653
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with gcc-9 at -O[23] :
$ cat z1.c
extern __SIZE_TYPE__ strlen (const char*);
extern __SIZE_TYPE__ strnlen (const char*, __SIZE_TYPE__);
void foo (int *a)
{
char c[0];
a[0] = strlen (c);
a[0] = strnlen (c, 0);
}
$ gcc-9-20190224 -c z1.c -O1
$
$ gcc-9-20190224 -c z1.c -O2
during GIMPLE pass: strlen
z1.c: In function 'foo':
z1.c:3:6: internal compiler error: tree check: expected integer_cst, have
ssa_name in get_len, at tree.h:5653
3 | void foo (int *a)
| ^~~
0x5cf414 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9848
0xc517a7 tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3432
0xc517a7 wi::extended_tree<192>::get_len() const
../../gcc/tree.h:5653
0xc517a7 wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int >
const&)
../../gcc/wide-int.h:964
0xc517a7 wide_int_ref_storage::wide_int_ref_storage >
>(generic_wide_int > const&, unsigned int)
../../gcc/wide-int.h:1013
0xc517a7 generic_wide_int
>::generic_wide_int >
>(generic_wide_int > const&, unsigned int)
../../gcc/wide-int.h:788
0xc517a7 bool wi::lts_p >,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../gcc/wide-int.h:1880
0xe1a9ae wi::binary_traits >,
generic_wide_int >,
wi::int_traits > >::precision_type,
wi::int_traits >
>::precision_type>::signed_predicate_result operator<
>,
generic_wide_int >
>(generic_wide_int > const&,
generic_wide_int > const&)
../../gcc/wide-int.h:3227
0xe1a9ae tree_int_cst_lt(tree_node const*, tree_node const*)
../../gcc/tree.h:5809
0xe1a9ae handle_builtin_strlen
../../gcc/tree-ssa-strlen.c:1305
0xe1cf63 strlen_check_and_optimize_stmt
../../gcc/tree-ssa-strlen.c:3574
0xe1cf63 strlen_dom_walker::before_dom_children(basic_block_def*)
../../gcc/tree-ssa-strlen.c:3927
0x1483d67 dom_walker::walk(basic_block_def*)
../../gcc/domwalk.c:353
0xe16c97 execute
../../gcc/tree-ssa-strlen.c:4007
[Bug c/89499] New: [7/8/9 Regression] ICE in expand_UNIQUE, at internal-fn.c:2605
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89499
Bug ID: 89499
Summary: [7/8/9 Regression] ICE in expand_UNIQUE, at
internal-fn.c:2605
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with gcc-6 at -O[23] :
$ cat z1.c
#pragma acc routine vector
void Vector (int *ptr, int n, const int inc)
{
#pragma acc loop vector
for (int i = 0; i < n; i++)
ptr[i] += inc;
return;
}
void foo (void)
{
const int m = 16;
int ary[m][m];
Vector ([0][0], m*m, (1 << 24) - (1 << 16));
return;
}
$ gcc-9-20190224 -c z1.c -fopenacc -O0
$ gcc-9-20190224 -c z1.c -fopenacc -O1
$
$ gcc-9-20190224 -c z1.c -fopenacc -O2
during RTL pass: expand
z1.c: In function 'foo':
z1.c:4:11: internal compiler error: in expand_UNIQUE, at internal-fn.c:2605
4 | #pragma acc loop vector
| ^~~
0x8a133f expand_UNIQUE
../../gcc/internal-fn.c:2605
0x6d3a57 expand_call_stmt
../../gcc/cfgexpand.c:2633
0x6d3a57 expand_gimple_stmt_1
../../gcc/cfgexpand.c:3691
0x6d3a57 expand_gimple_stmt
../../gcc/cfgexpand.c:3850
0x6d5a57 expand_gimple_basic_block
../../gcc/cfgexpand.c:5886
0x6db096 execute
../../gcc/cfgexpand.c:6509
[Bug c/89498] New: [8/9 Regression] ICE in AT_loc_list, at dwarf2out.c:4871
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89498
Bug ID: 89498
Summary: [8/9 Regression] ICE in AT_loc_list, at
dwarf2out.c:4871
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Affects several testsuite cases at -O1+.
Changed between 2018 and 20181118 :
$ cat pr71078-2.c
#include
float f1(float x)
{
float t1 = fabsf (x);
float t2 = t1 / x;
return t2;
}
$ gcc-9-2018 -c pr71078-2.c -O2 -gdwarf-5 -gsplit-dwarf
$
$ gcc-9-20190224 -c pr71078-2.c -O0 -gdwarf-5 -gsplit-dwarf
$
$ gcc-9-20190224 -c pr71078-2.c -O2 -gdwarf-5 -gsplit-dwarf
pr71078-2.c:8:1: internal compiler error: in AT_loc_list, at dwarf2out.c:4871
8 | }
| ^
0x755b87 AT_loc_list
../../gcc/dwarf2out.c:4871
0x76c693 AT_loc_list
../../gcc/dwarf2out.c:9874
0x76c693 value_format
../../gcc/dwarf2out.c:9735
0x76c84c build_abbrev_table
../../gcc/dwarf2out.c:9094
0x76c9d8 build_abbrev_table
../../gcc/dwarf2out.c:9117
0x76c9d8 build_abbrev_table
../../gcc/dwarf2out.c:9117
0x77060f output_comp_unit
../../gcc/dwarf2out.c:11034
0x797441 dwarf2out_finish
../../gcc/dwarf2out.c:31569
[Bug fortran/89492] [9 Regression] Endless compilation of an invalid TRANSFER after r269177
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89492
Harald Anlauf changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #1 from Harald Anlauf ---
Potential patch:
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 269177)
+++ gcc/fortran/check.c (working copy)
@@ -5487,6 +5487,13 @@
if (!gfc_element_size (mold, _elt_size))
return false;
+ if (result_elt_size == 0 && *source_size > 0)
+{
+ gfc_error ("% argument of % intrinsic at %L "
+ "has storage size 0", >where);
+ return false;
+}
+
if ((result_elt_size > 0 && (mold->expr_type == EXPR_ARRAY || mold->rank))
|| size)
{
Can you please verify that your testcases work?
[Bug c++/67650] undef reference with -fdevirtualize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67650 --- Comment #33 from Vincent --- Still in gcc 8.3.0.
[Bug target/89339] sse-movmskb-1.c fails for PPC Big Endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89339 pc at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from pc at gcc dot gnu.org --- fixes committed
[Bug target/89338] sse-cvtss2si-[12].c fails on PPC Big Endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89338 pc at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from pc at gcc dot gnu.org --- fixes committed
[Bug target/89338] sse-cvtss2si-[12].c fails on PPC Big Endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89338 --- Comment #2 from pc at gcc dot gnu.org --- Author: pc Date: Mon Feb 25 19:36:05 2019 New Revision: 269195 URL: https://gcc.gnu.org/viewcvs?rev=269195=gcc=rev Log: [rs6000] PR89338, PR89339: Fix compat vector intrinsics for BE and 32-bit Test FAILS: sse2-cvtpd2dq-1, sse2-cvtpd2ps, sse2-cvttpd2dq on powerpc64 (big-endian). _mm_cvtpd_epi32, _mm_cvtpd_ps, _mm_cvttpd_epi32: Type conversion from vector doubleword type to vector word type leaves the results in even lanes in big endian mode. Test FAILS: sse-cvtss2si-1, sse-cvtss2si-2, sse-movmskb-1 on powerpc (32-bit big-endian). Incorrect type for interpreting the result from mfvsrd instruction leads to incorrect results. Also, mfvsrd instruction only works as expected in 64-bit mode or for 32-bit quantities in 32-bit mode. A more general, if slower, solution is needed for 32-bit mode. 2019-02-25 Paul A. Clarke [gcc] * config/rs6000/emmintrin.h (_mm_cvtpd_epi32): Fix big endian. (_mm_cvtpd_ps): Likewise. (_mm_cvttpd_epi32): Likewise. PR target/89338 * config/rs6000/xmmintrin.h (_mm_cvtss_f32): Fix type mismatch. (_mm_cvt_ss2si): Fix type mismatch and 32-bit. PR target/89339 * config/rs6000/xmmintrin.h (_mm_movemask_pi8): Fix 32-bit. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/emmintrin.h trunk/gcc/config/rs6000/xmmintrin.h
[Bug target/89339] sse-movmskb-1.c fails for PPC Big Endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89339 --- Comment #2 from pc at gcc dot gnu.org --- Author: pc Date: Mon Feb 25 19:36:05 2019 New Revision: 269195 URL: https://gcc.gnu.org/viewcvs?rev=269195=gcc=rev Log: [rs6000] PR89338, PR89339: Fix compat vector intrinsics for BE and 32-bit Test FAILS: sse2-cvtpd2dq-1, sse2-cvtpd2ps, sse2-cvttpd2dq on powerpc64 (big-endian). _mm_cvtpd_epi32, _mm_cvtpd_ps, _mm_cvttpd_epi32: Type conversion from vector doubleword type to vector word type leaves the results in even lanes in big endian mode. Test FAILS: sse-cvtss2si-1, sse-cvtss2si-2, sse-movmskb-1 on powerpc (32-bit big-endian). Incorrect type for interpreting the result from mfvsrd instruction leads to incorrect results. Also, mfvsrd instruction only works as expected in 64-bit mode or for 32-bit quantities in 32-bit mode. A more general, if slower, solution is needed for 32-bit mode. 2019-02-25 Paul A. Clarke [gcc] * config/rs6000/emmintrin.h (_mm_cvtpd_epi32): Fix big endian. (_mm_cvtpd_ps): Likewise. (_mm_cvttpd_epi32): Likewise. PR target/89338 * config/rs6000/xmmintrin.h (_mm_cvtss_f32): Fix type mismatch. (_mm_cvt_ss2si): Fix type mismatch and 32-bit. PR target/89339 * config/rs6000/xmmintrin.h (_mm_movemask_pi8): Fix 32-bit. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/emmintrin.h trunk/gcc/config/rs6000/xmmintrin.h
[Bug lto/89497] [8.2 regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497 --- Comment #1 from darkkirb at darkkirb dot de --- (In reply to darkkirb from comment #0) > Full offending command line: > x86_64-pc-linux-gnu-gcc -m32 -L../cgi-bin -L../cups -L../filter -L../ppdc > [...] This happens for both 32 bit and 64 bit compilation, portage just built the 32 bit variant first (independent from -m32 flag)
[Bug lto/89497] New: [8.2 regression] ICE caused by Segmentation Fault when compiling cups 2.2.10 with LTO flags enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89497
Bug ID: 89497
Summary: [8.2 regression] ICE caused by Segmentation Fault when
compiling cups 2.2.10 with LTO flags enabled
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: darkkirb at darkkirb dot de
CC: marxin at gcc dot gnu.org
Target Milestone: ---
I have found a Regression in 8.3 involving cups 2.2.10 and LTO on Gentoo Linux
(x86_64). The package built fine with the C/LDFLAGS found below on 8.2, making
me believe it was recently introduced.
I have not yet tested this out on any recent development version.
Steps to reproduce:
1. Have the following variables set and exported:
a) CFLAGS="-march=native -O3 -fgraphite-identity -floop-nest-optimize
-fipa-pta -fno-semantic-interposition -flto=8 -fuse-linker-plugin -pipe
-falign-functions=32 -fPIC"
b) CXXFLAGS="${CFLAGS}"
c) LDFLAGS="${CFLAGS} -Wl,--hash-style=gnu"
2. untar the cups 2.2.10 release tarball and go into its directory
3. CC=gcc CXX=g++ ./configure
4. make -j$(nproc) libs
The compiler will report an ICE:
during GIMPLE pass: vrp
ppd-localize.c: In function ‘ppdLocalize’:
ppd-localize.c:51:1: internal compiler error: Segmentation fault
ppdLocalize(ppd_file_t *ppd) /* I - PPD file */
^
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug fortran/89496] [9 Regression] gcc/fortran/trans-types.c:3015:9: runtime error: member access within null pointer of type 'struct gfc_formal_arglist'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89496 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org
[Bug c++/70644] Warn about implicit conversion of 'this' to pointer to virtual base class during construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70644
--- Comment #2 from Eric Gallager ---
(In reply to Jonathan Wakely from comment #0)
> (Reduced from PR 58822)
>
> struct Base { Base(int) { } };
>
> int foo(Base*) { return 0; }
>
> struct X : virtual Base {
> X() : Base(foo(this)) { }
> };
>
> int main() {
> X x;
> }
>
> The implicit conversion in the call foo(this) is undefined behaviour. It
> violates [basic.life] 3.8p6 (6.3) by converting the object's address to a
> pointer to virtual base before it is constructed.
>
> There is no warning, and no ubsan error.
>
> If the implicit conversion happens in a different scope, not inside the
> constructor, then we get a ubsan error (and segfault):
>
> struct Base { Base(int) { } };
>
> struct X;
> int foo(X*);
>
> struct X : virtual Base {
> X() : Base(foo(this)) { }
> };
>
> int foo(X* x) { Base* b = x; return 0; }
>
> int main() {
> X x;
> }
>
> vb.cc:10:27: runtime error: cast to virtual base of address 0x7ffd25ef32f0
> which does not point to an object of type 'X'
> 0x7ffd25ef32f0: note: object has invalid vptr
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 90 0a 40 00
> 00 00 00 00 80 65 20 63
> ^~~
> invalid vptr
> Segmentation fault (core dumped)
>
>
> Since the original example is also UB it would be good to either get a
> diagnostic from the front end at the point of the implicit conversion, or at
> least get a ubsan error..
idea for a name for the proposed new warning?
[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501
--- Comment #19 from Andrey Drobyshev ---
(In reply to Martin Liška from comment #17)
> > 2. What should we do with sections like .data.rel.ro, .data.rel.ro.local?
> > They suffer from this bug too, but it's not that easy to put globals there,
> > as you must set various attributes onto decl to ensure it will receive the
> > right reloc value.
>
> Answer for this would be that we probably can't do that with approach #2 (as
> defined in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501#c1). Btw. how
> can one hit an invalid memory in .data.rel.ro (or .data.rel.ro.local)?
Take a look:
$ cat data_rel_ro.c
extern int a;
int * const b =
int *foo(void)
{
int **ptr =
ptr--;
return *ptr;
}
$ cat main.c
int a = -1;
int *c;
extern int *foo(void);
int main(int argc, char *argv[])
{
c = foo();
return 0;
}
Now compile this thing with -fPIE (assuming we want ASLR):
$ gcc -fsanitize=address -fPIE data_rel_ro.c main.c
...and b is put to .data.rel.ro:
$ objdump -t a.out
a.out: file format elf64-x86-64
SYMBOL TABLE:
00601040 g O .data.rel.ro 0008 b
foo() hits invalid memory to the left of b, but our patched ASan doesn't detect
(as expected though):
$ ./a.out
$
However, there's still a redzone to the right, as it should be:
$ cat data_rel_ro.c
extern int a;
int * const b =
int *foo(void)
{
int **ptr =
ptr++;
return *ptr;
}
$ ./a.out
==32200==ERROR: AddressSanitizer: global-buffer-overflow on address
0x00601048 at pc 0x004007d8 bp 0x7ffee53dc6a0 sp 0x7ffee53dc680
READ of size 8 at 0x00601048 thread T0
#0 0x4007d7 in foo /home/src/gcc/obj/data_rel_ro.c:8
#1 0x40082c in main /home/src/gcc/obj/main.c:8
#2 0x7f80ea98682f in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#3 0x4006b8 in _start (/home/src/gcc/obj/a.out+0x4006b8)
0x00601048 is located 0 bytes to the right of global variable 'b' defined
in 'data_rel_ro.c:2:13' (0x601040) of size 8
SUMMARY: AddressSanitizer: global-buffer-overflow
/home/src/gcc/obj/data_rel_ro.c:8 in foo
Shadow bytes around the buggy address:
0x800b81b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800b81c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800b81d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800b81e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800b81f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x800b8200: 00 00 00 00 00 00 00 00 00[f9]f9 f9 f9 f9 f9 f9
0x800b8210: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800b8220: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800b8230: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800b8240: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x800b8250: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
So I guess we still have to detect relocations. I cannot see limitations coming
particularly from approach #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501#c1. We just need to pass the
right reloc value to categorize_decl_for_section().
[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501 --- Comment #18 from Andrey Drobyshev --- (In reply to Martin Liška from comment #16) > Created attachment 45797 [details] > Patch candidate > > Patch candidate where I made some refactoring and come up with tests. > Works fine on x86_64, on ppc64le there are some issues with > -fsection-anchors, but that would be possible to resolve. > > Please let me know if you're fine with that and we can submit that to > gcc-patches ML? Looks good to me. By not setting TREE_PUBLIC flag we give our dummy globals internal linkage (as if they were static), thus allowing linker to mix multiple TUs with these dummies. However, this way number of dummy globals in the resulting executable is proportional to the number of TUs, and each of them occupies additional 64b for redzone (due to alignment) + its poisoned metadata (struct __asan_global, also 64b on x86_64). I guess that's what was meant by "wasting more memory" in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501#c1. I'm not sure, are we ok with such a waste?
[Bug target/88530] [8/9 Regression] AArch64 Unsupported options passed to assemblers when it doesn't need to.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88530 --- Comment #3 from Tamar Christina --- Author: tnfchris Date: Mon Feb 25 17:57:01 2019 New Revision: 269193 URL: https://gcc.gnu.org/viewcvs?rev=269193=gcc=rev Log: AArch64: Fix command line options canonicalization version #2. (PR target/88530) Commandline options on AArch64 don't get canonicalized into the smallest possible set before output to the assembler. This means that overlapping feature sets are emitted with superfluous parts. Normally this isn't an issue, but in the case of crypto we have retro-actively split it into aes and sha2. We need to emit only +crypto to the assembler so old assemblers continue to work. Because of how -mcpu=native and -march=native work they end up enabling all feature bits. Instead we need to get the smallest possible set, which would also fix the problem with older the assemblers and the retro-active split. The function that handles this is called quite often. It is called for any push/pop options or attribute that changes arch, cpu etc. In order to not make this search for the smallest set too expensive we sort the options based on the number of features (bits) they enable. This allows us to process the list linearly instead of quadratically (Once we have enabled a feature, we know that anything else that enables it can be ignored. By sorting we'll get the biggest groups first and thus the smallest combination of commandline flags). The Option handling structures have been extended to have a boolean to indicate whether the option is synthetic, with that I mean if the option flag itself enables a new feature. e.g. +crypto isn't an actual feature, it just enables other features, but others like +rdma enable multiple dependent features but is itself also a feature. There are two ways to solve this. 1) Either have the options that are feature bits also turn themselves on, e.g. change rdma to turn on FP, SIMD and RDMA as dependency bits. 2) Make a distinction between these two different type of features and have the framework handle it correctly. Even though it's more code I went for the second approach, as it's the one that'll be less fragile (people can't forget it) and gives the least surprises. Effectively this patch changes the following: The values before the => are the old compiler and after the => the new code. -march=armv8.2-a+crypto+sha2 => -march=armv8.2-a+crypto -march=armv8.2-a+sha2+aes => -march=armv8.2-a+crypto The remaining behaviors stay the same. gcc/ChangeLog: PR target/88530 * common/config/aarch64/aarch64-common.c (struct aarch64_option_extension): Add is_synthetic. (all_extensions): Use it. (TARGET_OPTION_INIT_STRUCT): Define hook. (struct gcc_targetm_common): Moved to end. (all_extensions_by_on): New. (opt_ext_cmp, typedef opt_ext): New. (aarch64_option_init_struct): New. (aarch64_contains_opt): New. (aarch64_get_extension_string_for_isa_flags): Output smallest set. * config/aarch64/aarch64-option-extensions.def (AARCH64_OPT_EXTENSION): Explicitly include AES and SHA2 in crypto. (fp, simd, crc, lse, fp16, rcpc, rdma, dotprod, aes, sha2, sha3, sm4, fp16fml, sve, profile, rng, memtag, sb, ssbs, predres): Set is_synthetic to false. (crypto): Set is_synthetic to true. * config/aarch64/driver-aarch64.c (AARCH64_OPT_EXTENSION): Add SYNTHETIC. gcc/testsuite/ChangeLog: PR target/88530 * gcc.target/aarch64/options_set_1.c: New test. * gcc.target/aarch64/options_set_2.c: New test. * gcc.target/aarch64/options_set_3.c: New test. * gcc.target/aarch64/options_set_4.c: New test. * gcc.target/aarch64/options_set_5.c: New test. * gcc.target/aarch64/options_set_6.c: New test. * gcc.target/aarch64/options_set_7.c: New test. * gcc.target/aarch64/options_set_8.c: New test. * gcc.target/aarch64/options_set_9.c: New test. Added: trunk/gcc/testsuite/gcc.target/aarch64/options_set_1.c trunk/gcc/testsuite/gcc.target/aarch64/options_set_2.c trunk/gcc/testsuite/gcc.target/aarch64/options_set_3.c trunk/gcc/testsuite/gcc.target/aarch64/options_set_4.c trunk/gcc/testsuite/gcc.target/aarch64/options_set_5.c trunk/gcc/testsuite/gcc.target/aarch64/options_set_6.c trunk/gcc/testsuite/gcc.target/aarch64/options_set_7.c trunk/gcc/testsuite/gcc.target/aarch64/options_set_8.c trunk/gcc/testsuite/gcc.target/aarch64/options_set_9.c Modified: trunk/gcc/ChangeLog trunk/gcc/common/config/aarch64/aarch64-common.c trunk/gcc/config/aarch64/aarch64-option-extensions.def trunk/gcc/config/aarch64/driver-aarch64.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/43210] Initializer of huge static arrays should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43210 --- Comment #9 from Jakub Jelinek --- Created attachment 45818 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45818=edit gcc9-pr43210.patch Like this (untested so far).
[Bug fortran/43210] Initializer of huge static arrays should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43210
--- Comment #8 from Jakub Jelinek ---
Well, I'm not convinced the #c0 transformation should be done by default, but
what should and can be done is instead of emitting {42, 42, 42, , 42}; emit
like the C or C++ FEs emit {[1..100] = 42} which is much more compile time
memory friendly, and if the user doesn't require that it is SAVEd, e.g. the
gimplifier has code to decide if having a .rodata initializer vs. initializing
by a loop is beneficial. See PR82294 or PR87436 for the C++ counterparts.
I see a single spot with RANGE_EXPR even in the Fortran FE, so maybe it does it
already.
[Bug fortran/43210] Initializer of huge static arrays should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43210 --- Comment #7 from Dominique d'Humieres --- > This is definitely an area where improvement would be quite helpful - > our performance there is abysmal. Compiling the test on my laptop takes less than 3s!
[Bug c/77754] [7/8/9 Regression] internal compiler error : tree code 'call_expr' is not supported in LTO streams
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77754 --- Comment #13 from Jakub Jelinek --- Created attachment 45817 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45817=edit gcc9-pr77754.patch Seems all the ICEs went away with r266271 aka PR87229 fix. I'll test these tests for the testsuite.
[Bug fortran/43210] Initializer of huge static arrays should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43210 Thomas Koenig changed: What|Removed |Added Status|RESOLVED|NEW CC||tkoenig at gcc dot gnu.org Resolution|WONTFIX |--- Severity|normal |enhancement --- Comment #6 from Thomas Koenig --- Sorry, I missed that one. This is definitely an area where improvement would be quite helpful - our performance there is abysmal. Dominique, I'm all for closing bugs :-) but I think one or two of them should stay. Just because nobody has found time, inclination or knowledge to work on them does not mean nobody should.
[Bug target/86019] [8/9 Regression] Unref implementation using atomic_thread_fence generates worse code on x86-64 in gcc 8.1 than 7.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86019
--- Comment #5 from Jakub Jelinek ---
This used to be handled by peephole2, but that can't do anything with multiple
basic blocks and
(insn 12 11 13 3 (set (mem/v:BLK (scratch:DI) [0 A8])
(unspec:BLK [
(mem/v:BLK (scratch:DI) [0 A8])
] UNSPEC_MEMORY_BLOCKAGE))
"/usr/src/gcc-7/obj/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/atomic_base.h":102:26
688 {*memory_blockag
e}
(nil))
emitted in there. And generic code doesn't know anything about the memory
blockage instruction that it would e.g. be able to move it from the conditional
to unconditional if it was the only thing (say let ifcvt pass do it?).
[Bug fortran/43210] Initializer of huge static arrays should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43210 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Dominique d'Humieres --- > This PR is almost ten year old. Any point to let it rot anymore? No answer: WONTFIX.
[Bug fortran/70149] [F08] Character pointer initialization causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #14 from Dominique d'Humieres --- > Any answer to this question? No feedback, closing. Please open a new PR for any related issue.
[Bug fortran/31392] [meta-bug] gfortran problems with initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31392 Bug 31392 depends on bug 70149, which changed state. Bug 70149 Summary: [F08] Character pointer initialization causes ICE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/68241] [meta-bug] [F03] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 70149, which changed state. Bug 70149 Summary: [F08] Character pointer initialization causes ICE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70149 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug c++/89480] internal compiler error: in unify, at cp/pt.c:22160 with the template argument force conversio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89480 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-25 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/89101] [Aarch64] vfmaq_laneq_f32 generates unnecessary dup instrcutions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89101 Richard Earnshaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Earnshaw --- Fixed on trunk (aka gcc-9). Not a regression, so no backport.
[Bug fortran/71544] gfortran compiler optimization bug when dealing with c-style pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71544 Dominique d'Humieres changed: What|Removed |Added CC||relliott at umn dot edu --- Comment #12 from Dominique d'Humieres --- *** Bug 71412 has been marked as a duplicate of this bug. ***
[Bug fortran/71412] [F03] iso_c_bindings and optimization interaction bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71412 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #15 from Dominique d'Humieres --- > Indeed I think that is a duplicate of pr71544. So let mark this PR as a duplicate. *** This bug has been marked as a duplicate of bug 71544 ***
[Bug c++/88256] [7/8/9 Regression] ICE: Segmentation fault (in make_ssa_name_fn), C++ FE missing DECL_EXPRs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88256 Jakub Jelinek changed: What|Removed |Added CC||gs...@t-online.de --- Comment #7 from Jakub Jelinek --- *** Bug 89439 has been marked as a duplicate of this bug. ***
[Bug c++/89439] [7/8/9 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:268
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89439 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Jakub Jelinek --- So dup of PR88256. *** This bug has been marked as a duplicate of bug 88256 ***
[Bug fortran/71935] [7/8/9 Regression] ICE is_c_interoperable(): gfc_simplify_expr failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71935 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #10 from Dominique d'Humieres --- > I've read the discussion, but I am not clear about > what the problem actually is. > > Is this something that we can close now? The same for me. Let close this PR. If a related problem appears in a real code, please file a new PR.
[Bug libstdc++/89466] [7/8/9 Regression] Accessing the Internet while boostrapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89466 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Severity|blocker |normal
[Bug c++/89495] [9 Regression] gcc/c-family/c-format.c:1272:20: runtime error: signed integer overflow: 214748365 * 10 cannot be represented in type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89495
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
Looks like a regression only because the test is new.
I see the same code in there e.g. in GCC 3.2.
That said, I think we can do something like:
2019-02-25 Jakub Jelinek
PR c++/89495
* c-format.c (maybe_read_dollar_number): Compute nargnum in
HOST_WIDE_INT type to avoid overflows and change overflow_flag
checking.
--- gcc/c-family/c-format.c.jj 2019-01-16 09:35:04.565323073 +0100
+++ gcc/c-family/c-format.c 2019-02-25 16:26:07.872810237 +0100
@@ -1268,9 +1268,9 @@ maybe_read_dollar_number (const char **f
overflow_flag = 0;
while (ISDIGIT (*fcp))
{
- int nargnum;
- nargnum = 10 * argnum + (*fcp - '0');
- if (nargnum < 0 || nargnum / 10 != argnum)
+ HOST_WIDE_INT nargnum
+ = HOST_WIDE_INT_UC (10) * argnum + (*fcp - '0');
+ if ((int) nargnum != nargnum)
overflow_flag = 1;
argnum = nargnum;
fcp++;
[Bug fortran/89282] Garbage arithmetics results in fortran with -O3 and overloaded operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89282 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from Dominique d'Humieres --- > It stopped failing with r240291, but because it just added early VRP, > it just went latent. With -O3 -fno-tree-vrp it was miscompiled until > r240303 aka PR77648 fix. That fix has been backported to 6.3 and 5.5. Closing.
[Bug fortran/89282] Garbage arithmetics results in fortran with -O3 and overloaded operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89282 --- Comment #6 from dominiq at gcc dot gnu.org --- Author: dominiq Date: Mon Feb 25 15:19:45 2019 New Revision: 269190 URL: https://gcc.gnu.org/viewcvs?rev=269190=gcc=rev Log: 2019-02-25 Dominique d'Humieres PR fortran/89282 * gfortran.dg/overload_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/overload_3.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/89487] [8/9 Regression] ICE in expand_expr_addr_expr_1, at expr.c:7993
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89487 Jakub Jelinek changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Started with r249994.
[Bug rtl-optimization/86096] [8/9 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86096 --- Comment #5 from Alexander Monakov --- Author: amonakov Date: Mon Feb 25 15:14:39 2019 New Revision: 269189 URL: https://gcc.gnu.org/viewcvs?rev=269189=gcc=rev Log: df-scan: fix use of mw_order in df_mw_compare (PR 86096) PR rtl-optimization/86096 * df-scan.c (df_mw_compare): Do not check mw_reg fields when comparing mw_order values. Modified: trunk/gcc/ChangeLog trunk/gcc/df-scan.c
[Bug c++/89481] constexpr function allows writing one active union member and reading another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89481 --- Comment #3 from Michael Veksler --- Thanks for looking into it. With the fix, does it behave the same way for: - runtime evaluation of all_zeros() - compile time evaluation such as std::integral_constant::value; Currently (trunk 20190223 (experimental) with -std=c++2a), it returns different results for both cases, which does not feel right.
[Bug c++/71446] Incorrect overload resolution when using designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446
--- Comment #4 from Roman Perepelitsa ---
Please take a look at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446#c1.
This code compiles. Given that it contains `{.value = 0}`, one would reasonably
expect that it creates an instance of a struct with the data member `value` set
to zero. However, it doesn't. The literal `{.value = 0}` creates an instance of
type `std::initialize_list`. This is very misleading. The code should
either not compile or do what was intended (which is also what C++20 requires
and what clang does).
[Bug c++/89285] [8 Regression] ICE after casting the this pointer in the constructor in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89285 Jakub Jelinek changed: What|Removed |Added Known to work||9.0 Summary|[8/9 Regression] ICE after |[8 Regression] ICE after |casting the this pointer in |casting the this pointer in |the constructor in C++17|the constructor in C++17 |mode|mode Known to fail||8.3.0 --- Comment #19 from Jakub Jelinek --- Actually, #c16 comment is incorrect, that was the case of the earlier approach (#c4) but not of what has been actually committed. Keeping this open for 8.x, though the patch is unlikely to be backportable.
[Bug c++/89285] [8/9 Regression] ICE after casting the this pointer in the constructor in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89285 --- Comment #18 from Jakub Jelinek --- Author: jakub Date: Mon Feb 25 15:01:01 2019 New Revision: 269188 URL: https://gcc.gnu.org/viewcvs?rev=269188=gcc=rev Log: PR c++/89285 * g++.dg/cpp1y/constexpr-89285-2.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-89285-2.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/89496] [9 Regression] gcc/fortran/trans-types.c:3015:9: runtime error: member access within null pointer of type 'struct gfc_formal_arglist'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89496 Dominique d'Humieres changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P4 CC||tkoenig at gcc dot gnu.org --- Comment #1 from Dominique d'Humieres --- Likely due to r268992 (the ICE occurs in the added block). The PR requires an instrumented compiler.
[Bug c++/71446] Incorrect overload resolution when using designated initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71446 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org, ||redi at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Well, before C++2a it is an extension, so outside of the C++ standard, and GCC has been implementing it as not allowing to skip any fields. In C++2a it is actually a standard language feature, so I guess it needs to participate in the overload resolution.
[Bug fortran/89496] [9 Regression] gcc/fortran/trans-types.c:3015:9: runtime error: member access within null pointer of type 'struct gfc_formal_arglist'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89496 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-25 Known to work||8.2.0 Blocks||63426 Target Milestone|--- |9.0 Ever confirmed|0 |1 Known to fail||9.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 [Bug 63426] [meta-bug] Issues found with -fsanitize=undefined
[Bug fortran/89496] New: [9 Regression] gcc/fortran/trans-types.c:3015:9: runtime error: member access within null pointer of type 'struct gfc_formal_arglist'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89496 Bug ID: 89496 Summary: [9 Regression] gcc/fortran/trans-types.c:3015:9: runtime error: member access within null pointer of type 'struct gfc_formal_arglist' Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- A recent regression: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/altreturn_1.f90 ../../gcc/fortran/trans-types.c:3015:9: runtime error: member access within null pointer of type 'struct gfc_formal_arglist' #0 0xeb78e3 in get_formal_from_actual_arglist ../../gcc/fortran/trans-types.c:3015 #1 0xeb82d5 in gfc_get_function_type(gfc_symbol*, gfc_actual_arglist*) ../../gcc/fortran/trans-types.c:3081 #2 0xd0d1de in gfc_get_extern_function_decl(gfc_symbol*, gfc_actual_arglist*) ../../gcc/fortran/trans-decl.c:2152 #3 0xd6e804 in conv_function_val ../../gcc/fortran/trans-expr.c:3920 #4 0xd8fa14 in gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) ../../gcc/fortran/trans-expr.c:6626 #5 0xe65236 in gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../gcc/fortran/trans-stmt.c:406 #6 0xc7680b in trans_code ../../gcc/fortran/trans.c:1890 #7 0xc76efa in gfc_trans_code(gfc_code*) ../../gcc/fortran/trans.c:2149 #8 0xd3dfce in gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6568 #9 0xc76f85 in gfc_generate_code(gfc_namespace*) ../../gcc/fortran/trans.c:2166 #10 0xad0181 in translate_all_program_units ../../gcc/fortran/parse.c:6134 #11 0xad0d8e in gfc_parse_file() ../../gcc/fortran/parse.c:6337 #12 0xc379c6 in gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204 #13 0x2307a40 in compile_file ../../gcc/toplev.c:456 #14 0x230f68d in do_compile ../../gcc/toplev.c:2204 #15 0x230fcbb in toplev::main(int, char**) ../../gcc/toplev.c:2339 #16 0x469a7c8 in main ../../gcc/main.c:39 #17 0x76e7bb7a in __libc_start_main ../csu/libc-start.c:308 #18 0x86dbe9 in _start (/home/marxin/Programming/gcc2/objdir/gcc/f951+0x86dbe9)
[Bug c++/89495] gcc/c-family/c-format.c:1272:20: runtime error: signed integer overflow: 214748365 * 10 cannot be represented in type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89495 Martin Liška changed: What|Removed |Added CC||msebor at gcc dot gnu.org Known to work||8.2.0 Version|unknown |9.0 Target Milestone|--- |9.0 Known to fail||9.0
[Bug c++/89495] New: gcc/c-family/c-format.c:1272:20: runtime error: signed integer overflow: 214748365 * 10 cannot be represented in type 'int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89495 Bug ID: 89495 Summary: gcc/c-family/c-format.c:1272:20: runtime error: signed integer overflow: 214748365 * 10 cannot be represented in type 'int' Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- It's a recent UBSAN error: $ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/tree-ssa/builtin-printf-warn-2.c -O -Wformat -Wformat-overflow=2 -ftrack-macro-expansion=0 -W ../../gcc/c-family/c-format.c:1272:15: runtime error: signed integer overflow: 2147483640 + 8 cannot be represented in type 'int' #0 0xaeca84 in maybe_read_dollar_number ../../gcc/c-family/c-format.c:1272 #1 0xaf28a1 in argument_parser::read_any_dollar() ../../gcc/c-family/c-format.c:2082 #2 0xafd7c6 in check_format_info_main ../../gcc/c-family/c-format.c:2855 #3 0xaf0b77 in check_format_arg ../../gcc/c-family/c-format.c:1748 #4 0xab18f6 in check_function_arguments_recurse(void (*)(void*, tree_node*, unsigned long), void*, tree_node*, unsigned long) ../../gcc/c-family/c-common.c:5895 #5 0xab1380 in check_function_arguments_recurse(void (*)(void*, tree_node*, unsigned long), void*, tree_node*, unsigned long) ../../gcc/c-family/c-common.c:5827 #6 0xaedc92 in check_format_info ../../gcc/c-family/c-format.c:1471 #7 0xaebc46 in check_function_format(tree_node const*, tree_node*, int, tree_node**, vec*) ../../gcc/c-family/c-format.c:1128 #8 0xab1020 in check_function_arguments(unsigned int, tree_node const*, tree_node const*, int, tree_node**, vec*) ../../gcc/c-family/c-common.c:5802 #9 0x92d079 in build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*) ../../gcc/c/c-typeck.c:3118 #10 0x92dfdc in c_build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*) ../../gcc/c/c-typeck.c:3184 #11 0x9db6b7 in c_parser_postfix_expression_after_primary ../../gcc/c/c-parser.c:9595 #12 0x9d9511 in c_parser_postfix_expression ../../gcc/c/c-parser.c:9270 #13 0x9cc738 in c_parser_unary_expression ../../gcc/c/c-parser.c:7383 #14 0x9cb0b0 in c_parser_cast_expression ../../gcc/c/c-parser.c:7222 #15 0x9c58c7 in c_parser_binary_expression ../../gcc/c/c-parser.c:7025 #16 0x9c4a15 in c_parser_conditional_expression ../../gcc/c/c-parser.c:6759 #17 0x9c4518 in c_parser_expr_no_commas ../../gcc/c/c-parser.c:6676 #18 0x9dc1c6 in c_parser_expression ../../gcc/c/c-parser.c:9731 #19 0x9dc6db in c_parser_expression_conv ../../gcc/c/c-parser.c:9764 #20 0x9c0147 in c_parser_statement_after_labels ../../gcc/c/c-parser.c:5610 #21 0x9be83e in c_parser_compound_statement_nostart ../../gcc/c/c-parser.c:5148 #22 0x9bdf55 in c_parser_compound_statement ../../gcc/c/c-parser.c:4982 #23 0x9b437c in c_parser_declaration_or_fndef ../../gcc/c/c-parser.c:2354 #24 0x9b12a7 in c_parser_external_declaration ../../gcc/c/c-parser.c:1653 #25 0x9b0aa4 in c_parser_translation_unit ../../gcc/c/c-parser.c:1534 #26 0xa16edb in c_parse_file() ../../gcc/c/c-parser.c:19854 #27 0xb39675 in c_common_parse_file() ../../gcc/c-family/c-opts.c:1155 #28 0x1ffdeae in compile_file ../../gcc/toplev.c:456 #29 0x2005afb in do_compile ../../gcc/toplev.c:2204 #30 0x2006129 in toplev::main(int, char**) ../../gcc/toplev.c:2339 #31 0x436822f in main ../../gcc/main.c:39 #32 0x76e7bb7a in __libc_start_main ../csu/libc-start.c:308 #33 0x857579 in _start (/home/marxin/Programming/gcc2/objdir/gcc/cc1+0x857579) ../../gcc/c-family/c-format.c:1272:20: runtime error: signed integer overflow: 214748365 * 10 cannot be represented in type 'int' #0 0xaeca29 in maybe_read_dollar_number ../../gcc/c-family/c-format.c:1272 #1 0xaf28a1 in argument_parser::read_any_dollar() ../../gcc/c-family/c-format.c:2082 #2 0xafd7c6 in check_format_info_main ../../gcc/c-family/c-format.c:2855 #3 0xaf0b77 in check_format_arg ../../gcc/c-family/c-format.c:1748 #4 0xab18f6 in check_function_arguments_recurse(void (*)(void*, tree_node*, unsigned long), void*, tree_node*, unsigned long) ../../gcc/c-family/c-common.c:5895 #5 0xab1380 in check_function_arguments_recurse(void (*)(void*, tree_node*, unsigned long), void*, tree_node*, unsigned long) ../../gcc/c-family/c-common.c:5827 #6 0xaedc92 in check_format_info ../../gcc/c-family/c-format.c:1471 #7 0xaebc46 in check_function_format(tree_node const*, tree_node*, int, tree_node**, vec*) ../../gcc/c-family/c-format.c:1128 #8 0xab1020 in check_function_arguments(unsigned int, tree_node const*, tree_node const*, int, tree_node**, vec*) ../../gcc/c-family/c-common.c:5802 #9 0x92d079 in build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*)
[Bug bootstrap/89494] New: Bootstrap error when using GCC 4.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494 Bug ID: 89494 Summary: Bootstrap error when using GCC 4.2.1 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: pkubaj at anongoth dot pl Target Milestone: --- I use FreeBSD on powerpc64 architecture, which has GCC 4.2.1 as a system compiler. It does support C++98 which, according to https://gcc.gnu.org/install/prerequisites.html is enough to bootstrap GCC. I can compile GCC 6.5 at most. GCC 7 and newer are broken. FreeBSD ports tree has a work around for that to use newer GCC release from FreeBSD's ports, but it means that to compile GCC 7 or newer, we need to compile 5 or 6. Building GCC 9 fails with: /usr/local/poudriere/ports/default/lang/gcc9-devel/work/.build/./gcc/xgcc -B/usr/local/poudriere/ports/default/lang/gcc9-devel/work/.build/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=/usr/local/poudriere/ports/default/lang/g cc9-devel/work/gcc-9-20190217/gcc/testsuite/selftests cc1: internal compiler error: Segmentation fault no stack trace because unwind library not available Building GCC 7 is more verbose: /usr/local/poudriere/ports/default/lang/gcc7/work/.build/./gcc/xgcc -B/usr/local/poudriere/ports/default/lang/gcc7/work/.build/./gcc/ -B/usr/local/powerpc64-portbld-freebsd12.0/bin/ -B/usr/local/powerpc64-portbld-freebsd12.0/lib/ -isystem /usr/local/powerpc64-portbld-freebsd12.0/include -isystem /usr/local/powerpc64-portbld-freebsd12.0/sys-include-g -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -m32 -fPIC -mstrict-align -O2 -g -O2 -pipe -DLIBICONV_PLUG -fno-strict-aliasing -DIN_GCC-W -Wall -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -pthread -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -pthread -mno-minimal-toc -I. -I. -I../../.././gcc -I/usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libgcc -I/usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libgcc/. -I/usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libgcc/../gcc -I/usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libgcc/../include -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS In file included from /usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libgcc/libgcc2.c:56:0: /usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libgcc/libgcc2.c: In function '__muldi3': /usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libgcc/libgcc2.h:219:20: internal compiler error: Segmentation fault #define __NDW(a,b) __ ## a ## di ## b ^ /usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libgcc/libgcc2.h:273:18: note: in expansion of macro '__NDW' #define __muldi3 __NDW(mul,3) ^ /usr/local/poudriere/ports/default/lang/gcc7/work/gcc-7.4.0/libgcc/libgcc2.c:548:1: note: in expansion of macro '__muldi3' __muldi3 (DWtype u, DWtype v) ^~~~ no stack trace because unwind library not available Obviously, I'm not asking to fix GCC 4.2.1, but to make a workaround for newer releases
[Bug tree-optimization/89489] [9 Regression] ICE in gimple_duplicate_bb, at tree-cfg.c:6257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89489 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #2 from Jakub Jelinek --- And due to graphite I can't bisect, Martin, can you?
