[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290 --- Comment #13 from rguenther at suse dot de --- On February 21, 2018 2:13:22 PM GMT+01:00, "egallager at gcc dot gnu.org" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290 > >Eric Gallager changed: > > What|Removed |Added > > Keywords||patch > CC||egallager at gcc dot gnu.org > >--- Comment #11 from Eric Gallager --- >(In reply to Andrew Pinski from comment #10) >> Note this needs at least: >> https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02837.html >> > >This was approved; has it been committed yet? AFAIK no
[Bug fortran/84506] [6/7/8 Regression] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506 --- Comment #11 from Jerry DeLisle --- Tentative patch. Testing now. The intent originally was to prevent unit numbers that don't fit into kind=4. It use to be we had no negative unit numbers. With newunit, now we do. I need to see if this patch allows any invalid code. diff --git a/gcc/fortran/trans-io.c b/gcc/fortran/trans-io.c index 021c788ba54..36adb034475 100644 --- a/gcc/fortran/trans-io.c +++ b/gcc/fortran/trans-io.c @@ -639,12 +639,12 @@ set_parameter_value_inquire (stmtblock_t *block, tree var, /* Don't evaluate the UNIT number multiple times. */ se.expr = gfc_evaluate_now (se.expr, &se.pre); - /* UNIT numbers should be greater than zero. */ + /* UNIT numbers should be greater than the min. */ i = gfc_validate_kind (BT_INTEGER, 4, false); + val = gfc_conv_mpz_to_tree (gfc_integer_kinds[i].pedantic_min_int, 4); cond1 = build2_loc (input_location, LT_EXPR, logical_type_node, se.expr, - fold_convert (TREE_TYPE (se.expr), - integer_zero_node)); + fold_convert (TREE_TYPE (se.expr), val)); /* UNIT numbers should be less than the max. */ val = gfc_conv_mpz_to_tree (gfc_integer_kinds[i].huge, 4); cond2 = build2_loc (input_location, GT_EXPR, logical_type_node,
[Bug fortran/84506] [6/7/8 Regression] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506 Dominique d'Humieres changed: What|Removed |Added Keywords||wrong-code Known to work||4.9.3 Target Milestone|--- |6.5 Summary|INQUIRE(pos=) always sets |[6/7/8 Regression] |pos=0 with |INQUIRE(pos=) always sets |-fdefault-integer-8 |pos=0 with ||-fdefault-integer-8 Known to fail||5.5.0 --- Comment #10 from Dominique d'Humieres --- Gfortran 4.9.3 gives the expected results.
[Bug fortran/84506] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506 --- Comment #9 from Steve Kargl --- On Thu, Feb 22, 2018 at 03:30:01AM +, jvdelisle at gcc dot gnu.org wrote: > > if (D.3772 < -some-reasonable-value || D.3772 > 2147483647) > { > inquire_parm.3.common.unit = -3; > } > _gfortran_st_inquire (&inquire_parm.3); > > It could be something like -32768 simply because the check is to make sure the > value used fits within kind=4 common.unit number. > Is the range check intended as a guard of inquiring on stderr, stdin, and stdout?
[Bug fortran/84506] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506 Jerry DeLisle changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #8 from Jerry DeLisle --- With iUnit as kind=4, the dump ford not have the check. { struct __st_parameter_inquire inquire_parm.2; inquire_parm.2.common.filename = &"pr84506.f90"[1]{lb: 1 sz: 1}; inquire_parm.2.common.line = 7; inquire_parm.2.strm_pos_out = &ipos; inquire_parm.2.common.flags = 8192; inquire_parm.2.common.unit = iunit; _gfortran_st_inquire (&inquire_parm.2); } So we need to adjust the range check to include possible negative unit numbers. In other words, change the test to: if (D.3772 < -some-reasonable-value || D.3772 > 2147483647) { inquire_parm.3.common.unit = -3; } _gfortran_st_inquire (&inquire_parm.3); It could be something like -32768 simply because the check is to make sure the value used fits within kind=4 common.unit number.
[Bug fortran/84506] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506 --- Comment #7 from Jerry DeLisle --- The problem is not related to the newunit functions or neunit alloc stuff. In the call to st_inquire we are passing the correct value of -10 for the unit number. However, the dump-original we have: { struct __st_parameter_inquire inquire_parm.3; integer(kind=8) D.3772; inquire_parm.3.common.filename = &"pr84506.f90"[1]{lb: 1 sz: 1}; inquire_parm.3.common.line = 7; inquire_parm.3.strm_pos_out = &ipos; inquire_parm.3.common.flags = 8192; inquire_parm.3.common.unit = (integer(kind=4)) iunit; D.3772 = iunit; if (D.3772 < 0 || D.3772 > 2147483647) { inquire_parm.3.common.unit = -3; } _gfortran_st_inquire (&inquire_parm.3); } The test is checking the range to be within a kind=4 integer limits and we are passing -3 to the inquire statement. The correct unit number is -10 as provided by newunit. (gdb) r Starting program: /home/jerry/dev/test/pr84506/a.out Breakpoint 1, testinquire () at pr84506.f90:7 7 inquire(iUnit, pos=iPos) (gdb) p iUnit $2 = -10 (gdb) s _gfortran_st_inquire (iqp=0x7fffd930) at ../../../trunk/libgfortran/io/inquire.c:775 775 library_start (&iqp->common); (gdb) p iqp->common.unit $3 = -3
[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508 --- Comment #1 from Jeffrey Walton --- __m128d is a tad bit cleaner. It does not require the casts. $ cat test.c #include int main(int argc, char* argv[]) { unsigned char t[16+1]; __m128d x = _mm_load_sd((const double *)(t+1)); _mm_store_pd((double*)t, x); return 0; } $ gcc -fsanitize=undefined test.c -o test.exe $ ./test.exe /usr/lib/gcc/x86_64-linux-gnu/6/include/emmintrin.h:140:10: runtime error: load of misaligned address 0x7ffd1cf2dd11 for type 'const double', which requires 8 byte alignment 0x7ffd1cf2dd11: note: pointer points here 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c0 c8 e0 ba c4
[Bug sanitizer/84508] New: Load of misaligned address using _mm_load_sd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84508 Bug ID: 84508 Summary: Load of misaligned address using _mm_load_sd Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: noloader at gmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- According to Intel (https://software.intel.com/sites/landingpage/IntrinsicsGuide), there are no alignment requirements for _mm_load_sd, _mm_store_sd and _mm_loaddup_pd. For example, from _mm_load_sd: Description Load a double-precision (64-bit) floating-point element from memory into the lower of dst, and zero the upper element. mem_addr does not need to be aligned on any particular boundary. $ gcc --version gcc (Debian 6.3.0-18) 6.3.0 20170516 $ cat test.c #include int main(int argc, char* argv[]) { unsigned char t[16+1]; __m128i x = _mm_castpd_si128(_mm_load_sd((const double *)(t+1))); _mm_store_pd((double*)t, _mm_castsi128_pd(x)); return 0; } $ gcc -fsanitize=undefined test.c -o test.exe $ ./test.exe /usr/lib/gcc/x86_64-linux-gnu/6/include/emmintrin.h:140:10: runtime error: load of misaligned address 0x7ffc768309b1 for type 'const double', which requires 8 byte alignment 0x7ffc768309b1: note: pointer points here 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 b0 79 38 ee ca 7f 00 00 98 7e 38 ee ca ^
[Bug fortran/84506] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506 kargl at gcc dot gnu.org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org Known to fail||6.4.1, 7.3.1, 8.0 --- Comment #6 from kargl at gcc dot gnu.org --- Add Jerry to CC list.
[Bug fortran/84506] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506 --- Comment #5 from Steve Kargl --- On Thu, Feb 22, 2018 at 12:08:24AM +, sgk at troutmask dot apl.washington.edu wrote: > program TestInquire >implicit none >integer(8) :: iUnit >integer(8) :: iPos >open(newunit=iunit, file='output.txt', access='stream', status='replace') >write(iUnit) 'TEXT' >inquire(iUnit, pos=iPos) >print *, iPos > end program TestInquire > It related to the automatic allocate of UNIT numbers with NEWUNIT. If I do iunit = 10 open(unit=iunit, file='output.txt', access='stream', status='replace') One gets the right answer. Looking in io/inquire.c, one has void st_inquire (st_parameter_inquire *iqp) { gfc_unit *u; library_start (&iqp->common); if ((iqp->common.flags & IOPARM_INQUIRE_HAS_FILE) == 0) { u = find_unit (iqp->common.unit); inquire_via_unit (iqp, u); } (gdb) p iqp->common $1 = {flags = 8192, unit = 10, filename = 0x4a6180 "d.f90", line = 9, iomsg_len = 4806240, iomsg = 0x2008d0010 "", iostat = 0xc} (gdb) p u $2 = (gfc_unit *) 0x200ce6f00 Now with newunit. (gdb) p iqp->common $1 = {flags = 8192, unit = -3, filename = 0x4a6140 "d.f90", line = 9, iomsg_len = 4806192, iomsg = 0x2008d0010 "", iostat = 0xc} (gdb) p u $2 = (gfc_unit *) 0x0 Whoops. u = 0x0, then runs into line 228-229. if ((cf & IOPARM_INQUIRE_HAS_STRM_POS_OUT) != 0) *iqp->strm_pos_out = (u != NULL) ? u->strm_pos : 0; and there's your 0.
[Bug fortran/84506] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506 --- Comment #4 from Steve Kargl --- The problem is related to UNIT. program TestInquire implicit none integer(4) :: iUnit integer(8) :: iPos open(newunit=iunit, file='output.txt', access='stream', status='replace') write(iUnit) 'TEXT' inquire(iUnit, pos=iPos) print *, iPos end program TestInquire The above gives the expected result. program TestInquire implicit none integer(8) :: iUnit integer(8) :: iPos open(newunit=iunit, file='output.txt', access='stream', status='replace') write(iUnit) 'TEXT' inquire(iUnit, pos=iPos) print *, iPos end program TestInquire This gives the wrong result.
[Bug c++/84507] stack corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84507 Justin Chen changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Justin Chen --- Sorry web browser bugged out and created this...
[Bug c++/84507] New: stack corruption
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84507 Bug ID: 84507 Summary: stack corruption Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: justinpopo6 at gmail dot com Target Milestone: ---
[Bug middle-end/61118] [6/7/8 Regression] Indirect call generated for pthread_cleanup_push with constant cleanup function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118 --- Comment #23 from Jeffrey A. Law --- Note that if we fix the abnormal handler to target the block after the setjmp rather than the setjmp itself all the problems magically disappear. That's actually a more accurate CFG and arguably the right thing to do. The concern is whether or not there are assumptions, particularly in the gimple->rtl phase that fixing the CFG would break.
[Bug fortran/84506] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506 --- Comment #3 from Steve Kargl --- Upon closer inspection, gfortran's dump is correct for both INTEGER and INTEGER(8) for program TestInquire integer :: iUnit, iPos ! integer(8) :: iUnit, iPos open(newunit=iunit, file='output.txt', access='stream', status='replace') write(iUnit) 'TEXT' inquire(iUnit, pos=iPos) print *, iPos end program TestInquire INTEGER gives 5 and INTEGER(8) gives 0. Looks like a Jerry issue. :)
[Bug c/66222] gcc error: invalid use of '__builtin_va_arg_pack ()' at -O2 and up & pass at noopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66222 Justin Chen changed: What|Removed |Added CC||justinpopo6 at gmail dot com --- Comment #4 from Justin Chen --- Created attachment 43486 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43486&action=edit Preprocessed File Attached preprocessed c file. I am having a similar error with this build command. (Compiles properly without -Ox flag) gcc -c -o av.o -DSPEC_CPU2000_NEED_BOOL -O1 av.c In file included from /usr/include/stdio.h:936:0, from perlsdio.h:5, from iperlsys.h:203, from perl.h:325, from av.c:16: /usr/include/x86_64-linux-gnu/bits/stdio2.h: In function ‘sprintf’: /usr/include/x86_64-linux-gnu/bits/stdio2.h:33:10: error: invalid use of ‘__builtin_va_arg_pack ()’ return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1, ^ /usr/include/x86_64-linux-gnu/bits/stdio2.h: In function ‘snprintf’: /usr/include/x86_64-linux-gnu/bits/stdio2.h:64:10: error: invalid use of ‘__builtin_va_arg_pack ()’ return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1, ^ /usr/include/x86_64-linux-gnu/bits/stdio2.h: In function ‘fprintf’: /usr/include/x86_64-linux-gnu/bits/stdio2.h:97:10: error: invalid use of ‘__builtin_va_arg_pack ()’ return __fprintf_chk (__stream, __USE_FORTIFY_LEVEL - 1, __fmt, ^ /usr/include/x86_64-linux-gnu/bits/stdio2.h: In function ‘printf’: /usr/include/x86_64-linux-gnu/bits/stdio2.h:104:10: error: invalid use of ‘__builtin_va_arg_pack ()’ return __printf_chk (__USE_FORTIFY_LEVEL - 1, __fmt, __va_arg_pack ()); ^ /usr/include/x86_64-linux-gnu/bits/stdio2.h: In function ‘dprintf’: /usr/include/x86_64-linux-gnu/bits/stdio2.h:141:10: error: invalid use of ‘__builtin_va_arg_pack ()’ return __dprintf_chk (__fd, __USE_FORTIFY_LEVEL - 1, __fmt, gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 5.4.0-6ubuntu1~16.04.9' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.9)
[Bug c++/14710] Warning about useless casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14710 --- Comment #14 from Jonathan Wakely --- I guess because nobody asked for it.
[Bug c++/84453] [8 Regression] ICE in build_type_attribute_qual_variant, at attribs.c:1166
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84453 --- Comment #5 from Jakub Jelinek --- So fixed?
[Bug c++/84453] [8 Regression] ICE in build_type_attribute_qual_variant, at attribs.c:1166
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84453 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Author: jason Date: Wed Feb 21 22:12:08 2018 New Revision: 257883 URL: https://gcc.gnu.org/viewcvs?rev=257883&root=gcc&view=rev Log: PR c++/84314 - ICE with templates and fastcall attribute. * attribs.c (build_type_attribute_qual_variant): Remove assert. Added: trunk/gcc/testsuite/g++.dg/ext/attrib56.C Modified: trunk/gcc/ChangeLog trunk/gcc/attribs.c
[Bug c++/84502] [8 Regression] Argument corruption when passing empty templated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1
[Bug fortran/84506] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|WAITING |NEW CC||kargl at gcc dot gnu.org --- Comment #2 from kargl at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > Use > > integer(4) :: iUnit, iPos > > -fdefault-integer-8 converts iUnit and iPos to integer(8) while open and > inquire expect default integer, i.e., 4. > > IMO this PR should be closed as INVALID. There isn't a problem with OPEN. The dump (removing clutter) looks like testinquire () { integer(kind=8) ipos; integer(kind=8) iunit; { struct __st_parameter_open open_parm.0; integer(kind=4) newunit.1; open_parm.0.newunit = &newunit.1; _gfortran_st_open (&open_parm.0); iunit = (integer(kind=8)) newunit.1; } Here open uses a INTEGER(4) internally and assigns to the promoted INTEGER(8). The INQUIRE is however broken for POS, which looks like { struct __st_parameter_inquire inquire_parm.3; integer(kind=8) D.3764; inquire_parm.3.strm_pos_out = &ipos; inquire_parm.3.common.unit = (integer(kind=4)) iunit; _gfortran_st_inquire (&inquire_parm.3); } } inquire_parm.3.strm_pos_out is likely an INTEGER(4) and gfortran is passing a pointer to an INTEGER(8) ipos. At one point in time, there was a warning that -fdefault-integer-8 changes the ABI and possibly causes problems with libgfortran. I cannot find the warning now. Documentation states '-fdefault-integer-8' Set the default integer and logical types to an 8 byte wide type. which means gfortran should compile and execute this code. In fact, gfortran appears broken. From F03, 9.9.1, R930 has inquire-spec is [ UNIT = ] file-unit-number or POS = scalar-int-variable Note that does not state scalar-default-int-variable. Changing the original code to use INTEGER(8) instead of using the -fdefault-integer-8 shows the same program.
[Bug tree-optimization/84505] [8 Regression] store-merging miscompilation on i586 in xemacs package starting with r254391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84505 --- Comment #2 from Martin Liška --- (In reply to Jakub Jelinek from comment #1) > Might very well be a dup of PR84503, let me finish up the patch. I hope so. According to description it looks very similar ;)
[Bug fortran/84506] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-02-21 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Use integer(4) :: iUnit, iPos -fdefault-integer-8 converts iUnit and iPos to integer(8) while open and inquire expect default integer, i.e., 4. IMO this PR should be closed as INVALID.
[Bug testsuite/83983] FAIL: g++.dg/lto/pr83121 (test for LTO warnings, pr83121_0.C line 8)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83983 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #3 from Steve Ellcey --- I tried digging into this some but was not able to come up with a fix. I compared x86, which gives the expected error messages with aarch64 which gives different errors and tried to find out where they diverged. I tracked it down to get_odr_type in ipa-devirt.c. Just before: if (val->type != type && (!val->types_set || !val->types_set->add (type))) I added this print statement: fprintf(stderr,"%p %p %p\n", (void *) type, (void *) val->type, (void *) val->types_set); On x86 I see: 0x7f98aa018dc8 0x7f98aa018930 (nil) 0x7f98aa0189d8 0x7f98aa018d20 (nil) 0x7f98aa0189d8 0x7f98aa018d20 0x32c9610 0x7f0222cbfc78 0x7f0222cbf9d8 (nil) 0x7f0222cbfa80 0x7f0222cbfa80 (nil) On Aarch64 I see: 0x4002c859aaa0 0x4002c859a758 (nil) 0x4002c859a6b0 0x4002c859a6b0 (nil) 0x4002c859a6b0 0x4002c859a6b0 (nil) 0x4001f45aa9f8 0x4001f45aa758 (nil) 0x4001f45aa800 0x4001f45aa800 (nil) I think the second line where type and val->type are the same for Aarch64 but not for x86 is where the problem is but I am not sure why we have this difference. I think it may be a bug in the odr hash function with an accidental hash collision but I am not sure.
[Bug tree-optimization/84503] [7/8 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503 --- Comment #5 from Jakub Jelinek --- In 7.x this exact problem doesn't really exist, so the issue must be different there. I'd think it might be something fixable by PR82916 - like patch, but haven't actually tried that yet.
[Bug c++/84314] [8 Regression] Another ICE in finish_member_declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84314 --- Comment #8 from Jason Merrill --- Author: jason Date: Wed Feb 21 22:12:08 2018 New Revision: 257883 URL: https://gcc.gnu.org/viewcvs?rev=257883&root=gcc&view=rev Log: PR c++/84314 - ICE with templates and fastcall attribute. * attribs.c (build_type_attribute_qual_variant): Remove assert. Added: trunk/gcc/testsuite/g++.dg/ext/attrib56.C Modified: trunk/gcc/ChangeLog trunk/gcc/attribs.c
[Bug fortran/84506] New: INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506 Bug ID: 84506 Summary: INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8 Product: gcc Version: 7.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: albandil at atlas dot cz Target Milestone: --- INQUIRE(pos=...) seems to set 'pos' to zero when the unit number is 64bit integer. This can be illustrated on the following example, which writes four characters to a stream file and then INQUIRES position: program TestInquire implicit none integer :: iUnit, iPos open(newunit=iunit, file='output.txt', access='stream', position='append', form='unformatted') write(iUnit) 'TEXT' inquire(iUnit, pos=iPos) print *, iPos end program TestInquire The expected output is '5', which can be obtained by compilation using the command gfortran -ffree-form -std=f2008 inquire.f -o inquire However, when the following command is used to compile the program, the output is '0': gfortran -ffree-form -std=f2008 inquire.f -o inquire -fdefault-integer-8 Both 4-byte and 8-byte mode produce '5' when Intel Fortran Compiler 17.0.1 is used, ifort -free -stand=f08 inquire.f -o inquire ifort -free -stand=f08 inquire.f -o inquire -i8
[Bug c/60083] Duplicate conversion warnings from negative integer to unsigned type (gcc-4.3 emits only one warning)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60083 Manuel López-Ibáñez changed: What|Removed |Added Status|NEW |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Manuel López-Ibáñez --- This probably got fixed when early folding was fixed: gcc 8.0 -Wsign-conversion -Wparentheses -Wall -Wextra -Wconversion gives: :3:48: warning: suggest parentheses around comparison in operand of '^' [-Wparentheses] unsigned short s = ~0x4578ADBCAA1DE677LL ^ a == 0; ~~^~~~ :3:44: warning: unsigned conversion from 'long long int' to 'short unsigned int' changes value from '-5005942011641849463' to '6537' [-Woverflow] unsigned short s = ~0x4578ADBCAA1DE677LL ^ a == 0; ~~^~~~ The fix-it notes for -Wparentheses and having some warnings enabled by default would be nice, but they are a different topic altogether.
[Bug fortran/84504] procedure pointer variables cannot be initialized with functions returning pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504 --- Comment #4 from Sriram Swaminarayan --- OK, I will admit that my knowledge here is pretty limited so if someone could point out what I'm missing, I'd appreciate it. On reading the other thread [PR45290] it appears it deals with pointers being initialized with other pointers, be they procedure or data. This compile error has to do with not being able to deal with a specific return type for a function (i.e. those functions that return pointers). The return type of a function should have no bearing on whether or not the initialization should succeed.
[Bug c++/84502] [8 Regression] Argument corruption when passing empty templated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502 --- Comment #6 from patrick.schlangen at bmw dot de --- (In reply to Jakub Jelinek from comment #5) > Completely untested fix: I've applied the patch and it seems to resolve the issue. Thanks a lot!
[Bug c/80793] three signed conversion warnings for the same expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80793 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-21 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Manuel López-Ibáñez --- (In reply to Martin Sebor from comment #0) There are several issues conflated here. > t.c: In function ‘f’: > t.c:3:46: warning: signed and unsigned type in conditional expression > [-Wsign-compare] >unsigned char c = i ? (-__SCHAR_MAX__ - 1) : 1U; This warning should be moved to where -Wsign-conversion is handled to avoid emitting both. The reason we cannot simply remove -Wsign-compare is because -Wsign-conversion is not enabled by neither -Wall nor -Wextra, while -Wsign-compare is. The reason -Wsign-conversion is not enabled by neither -Wall nor -Wextra is because it has annoying false positives like PR40752. Clang doesn't have those. > t.c:3:46: warning: negative integer implicitly converted to unsigned type > [-Wsign-conversion] This is same warning as Clang gives, just less informative than Clang's. Printing the types should be easy. > t.c:3:21: warning: conversion to ‘unsigned char’ alters ‘unsigned int’ > constant value [-Wconversion] >unsigned char c = i ? (-__SCHAR_MAX__ - 1) : 1U; This warning is a bug in my opinion. Probably the patch in PR40752 silences it.
[Bug c++/84489] [6/7/8 Regression] Non-type template parameter dependency
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84489 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||5.4.0 Keywords||rejects-valid Last reconfirmed||2018-02-21 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Summary|Non-type template parameter |[6/7/8 Regression] Non-type |dependency |template parameter ||dependency Known to fail||6.4.0, 7.3.0, 8.0 --- Comment #1 from Martin Sebor --- The error is present with with the top of trunk. The first revision that fails to compile the code is r223301 (gcc 6.0.0). It refers to DR 1391 but I'm not sure that the DR has a bearing on whether the test case is valid. Other compilers including Clang, EDG, Intel ICC, and MSVC, successfully compile the code so I'll confirm this report as valid on that basis. r223301 | jason | 2015-05-18 13:14:11 -0400 (Mon, 18 May 2015) | 3 lines DR 1391 * pt.c (type_unification_real): Check convertibility here. (unify_one_argument): Not here.
[Bug fortran/84504] procedure pointer variables cannot be initialized with functions returning pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504 --- Comment #3 from Steve Kargl --- On Wed, Feb 21, 2018 at 09:15:24PM +, dominiq at lps dot ens.fr wrote: > > > This appears to be related to PR44290. > > Are you sure about the PR? > Argh, fat fingers! r169948 r169948 | janus | 2011-02-08 14:51:04 -0800 (Tue, 08 Feb 2011) | 12 lines 2011-02-08 Janus Weil PR fortran/45290 * expr.c (gfc_check_assign_symbol): Reject pointers as pointer initialization target. 2011-02-08 Janus Weil PR fortran/45290 * gfortran.dg/pointer_init_6.f90: New.
[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149 Thomas Koenig changed: What|Removed |Added CC||pault at gcc dot gnu.org, ||tkoenig at gcc dot gnu.org --- Comment #9 from Thomas Koenig --- I've done a bisection, and r255094 is the first revision that fails.
[Bug c/60018] Bogus conversion warning with optimization flag -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60018 Manuel López-Ibáñez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Manuel López-Ibáñez --- (In reply to Eric Gallager from comment #4) > bug 53277 perhaps? *** This bug has been marked as a duplicate of bug 53277 ***
[Bug c/53277] -Wconversion cannot handle compound expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53277 Manuel López-Ibáñez changed: What|Removed |Added CC||chengniansun at gmail dot com --- Comment #16 from Manuel López-Ibáñez --- *** Bug 60018 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/84480] [8 Regression] bogus -Wstringop-truncation despite assignment with an inlined string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84480 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #3 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01247.html
[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 80787, which changed state. Bug 80787 Summary: gcc -Wmaybe-uninitialized false negative when compiling Emacs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80787 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c/80787] gcc -Wmaybe-uninitialized false negative when compiling Emacs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80787 Manuel López-Ibáñez changed: What|Removed |Added Status|NEW |RESOLVED CC||manu at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Manuel López-Ibáñez --- (In reply to Marc Glisse from comment #1) > This is a DUP of many other PRs, -fno-tree-ccp -fno-tree-vrp gives you the > warning, but otherwise gcc optimises cond?value:undef to value. *** This bug has been marked as a duplicate of bug 18501 ***
[Bug tree-optimization/18501] [6/7/8 Regression] Missing 'used uninitialized' warning (CCP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 --- Comment #83 from Manuel López-Ibáñez --- *** Bug 80787 has been marked as a duplicate of this bug. ***
[Bug fortran/84504] procedure pointer variables cannot be initialized with functions returning pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-02-21 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- > This appears to be related to PR44290. Are you sure about the PR?
[Bug fortran/84504] procedure pointer variables cannot be initialized with functions returning pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- This appears to be related to PR44290. There is a fairly long discussion. The conclusion in that PR suggests that you example is invalid. I'm not so sure that is correct. The EBNF in F2018, 10.2.2 to me seems to permit what you are trying to do, but I don't use pointers so would need to spend too much time unraveling the subtleties.
[Bug c++/84502] [8 Regression] Argument corruption when passing empty templated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Completely untested fix: --- gcc/stor-layout.c.jj2018-02-13 21:23:29.187981310 +0100 +++ gcc/stor-layout.c 2018-02-21 21:43:24.783522853 +0100 @@ -1883,6 +1883,9 @@ finalize_type_size (tree type) && TREE_CODE (TYPE_SIZE_UNIT (type)) != INTEGER_CST) TYPE_SIZE_UNIT (type) = variable_size (TYPE_SIZE_UNIT (type)); + /* Handle empty records as per the x86-64 psABI. */ + TYPE_EMPTY_P (type) = targetm.calls.empty_record_p (type); + /* Also layout any other variants of the type. */ if (TYPE_NEXT_VARIANT (type) || type != TYPE_MAIN_VARIANT (type)) @@ -1895,6 +1898,7 @@ finalize_type_size (tree type) unsigned int precision = TYPE_PRECISION (type); unsigned int user_align = TYPE_USER_ALIGN (type); machine_mode mode = TYPE_MODE (type); + bool empty_p = TYPE_EMPTY_P (type); /* Copy it into all variants. */ for (variant = TYPE_MAIN_VARIANT (type); @@ -1911,11 +1915,9 @@ finalize_type_size (tree type) SET_TYPE_ALIGN (variant, valign); TYPE_PRECISION (variant) = precision; SET_TYPE_MODE (variant, mode); + TYPE_EMPTY_P (variant) = empty_p; } } - - /* Handle empty records as per the x86-64 psABI. */ - TYPE_EMPTY_P (type) = targetm.calls.empty_record_p (type); } /* Return a new underlying object for a bitfield started with FIELD. */
[Bug tree-optimization/83543] strlen of a local array member not optimized on some targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83543 --- Comment #6 from Martin Sebor --- (In reply to Martin Sebor from comment #5) The cutoff between (a) and (b) also depends on whether or not a function is being optimized for speed or for size, so at -Os, the x86_64 target also uses (b) for all sizes. Here's a test case and its output with an x86_64 compiler: $ cat t.c && gcc -S -Wall -fdump-tree-optimized=/dev/stdout t.c #pragma GCC optimize ("O2") int f (void) { struct A { char a[4]; } a = { "123" }; return __builtin_strlen (a.a); } #pragma GCC optimize ("Os") int g (void) { struct B { char b[4]; } b = { "123" }; return __builtin_strlen (b.b); } ;; Function f (f, funcdef_no=0, decl_uid=1957, cgraph_uid=0, symbol_order=0) __attribute__((optimize ("O2"))) f () { [local count: 1073741825]: return 3; } ;; Function g (g, funcdef_no=1, decl_uid=1963, cgraph_uid=1, symbol_order=1) __attribute__((optimize ("O2", "Os"))) g () { struct B b; long unsigned int _1; int _4; [local count: 1073741825]: b.b = "123"; _1 = __builtin_strlen (&b.b); _4 = (int) _1; b ={v} {CLOBBER}; return _4; }
[Bug c++/14710] Warning about useless casts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14710 Ben Elliston changed: What|Removed |Added CC||bje at gcc dot gnu.org --- Comment #13 from Ben Elliston --- Is there a reason this option doesn't extend to the C frontend? The same problem with useless static_casts occurs with conventional C casts, too.
[Bug c/46921] Lost side effect when struct initializer expression uses comma operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46921 Dave Pagan changed: What|Removed |Added Summary|Dropped side effect with|Lost side effect when |combination of statement|struct initializer |expression and struct |expression uses comma |initializer |operator --- Comment #3 from Dave Pagan --- When emitting initializer elements (output_init_element), the left hand expression of a comma operator with result size zero is not evaluated. It should be, however, if the expression is marked as having side effects.
[Bug c++/43064] improve location and text of diagnostics in constructor initializer lists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43064 --- Comment #6 from Manuel López-Ibáñez --- If I remember correctly, the problem here is constants and other non-expression nodes don't have a location, so diagnostics use input_location, which points to the end of the initializer. Something like X+1 should work. If so, David started fixing this problem, but this code may need fixes similar to these: https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00660.html Otherwise, the problem is more insidious, and the nodes are probably built with the wrong location.
[Bug tree-optimization/84505] [8 Regression] store-merging miscompilation on i586 in xemacs package starting with r254391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84505 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Martin Liška --- I can confirm https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503#c3 fixes the issue, thus it's dup. Great work Jakub! *** This bug has been marked as a duplicate of bug 84503 ***
[Bug c++/84502] [8 Regression] Argument corruption when passing empty templated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502 --- Comment #4 from Jonathan Wakely --- Regressed with r255066
[Bug tree-optimization/84503] [7/8 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503 --- Comment #4 from Martin Liška --- *** Bug 84505 has been marked as a duplicate of this bug. ***
[Bug target/69770] [ARM] -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69770 --- Comment #4 from Maxim Kuvyrkov --- Update from Charles: === When I tried to bootstrap the compiler with the patch, it failed because of issues with -fPIC. I'm not sure it's worth pursuing the amount of work required to resolve the -fPIC issue. ===
[Bug middle-end/65041] Improve -Wclobbered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65041 Jeffrey A. Law changed: What|Removed |Added Status|RESOLVED|REOPENED CC||law at redhat dot com Resolution|DUPLICATE |--- --- Comment #6 from Jeffrey A. Law --- The warning on a2 is clearly bogus. ISTM we ought to get a warning on fd, but don't because it's associated DECL_RTL is not set. It almost feels like instead of walking over the variables in the blocks we ought to iterate over the pseudos and check which of them map back to user variables via REG_EXPR. I'm going to re-open -- this is not entirely a duplicate of 21161 as there's a missed warning here.
[Bug tree-optimization/84503] [7/8 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503 --- Comment #3 from Jakub Jelinek --- Created attachment 43485 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43485&action=edit gcc8-pr84503.patch Untested fix.
[Bug c/84229] A valid code rejected with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84229 --- Comment #5 from Jan Hubicka --- Author: hubicka Date: Wed Feb 21 19:05:30 2018 New Revision: 257877 URL: https://gcc.gnu.org/viewcvs?rev=257877&root=gcc&view=rev Log: PR c/84229 * ipa-cp.c (determine_versionability): Do not version functions caling va_arg_pack. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-cp.c
[Bug fortran/70913] ICE in gfc_encode_character, at fortran/target-memory.c:227
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70913 --- Comment #4 from Dominique d'Humieres --- AFAICT the tests in comment 0 and 1 compile at revision r257865, but compiling the test z4.f90 still gives an ICE.
[Bug c/84500] diagnostic says "array of chars" for arrays of wchar_t, char16_t and char32_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84500 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-21 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Confirmed. I think the warning would be the most informative and the least vague if it instead used the name of the array type, and also mentioned the size of the initializer in case it's hidden behind a macro: warning: initializer-string for an object of 'wchar_t[3]' has 5 elements as long as there is a way to get at the name of the typedef. Otherwise, printing the underlying type would be an alternative.
[Bug c++/77285] [5 Regression] extern thread_local linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77285 Jonathan Wakely changed: What|Removed |Added CC||zhykzhykzhyk at gmail dot com --- Comment #15 from Jonathan Wakely --- *** Bug 66971 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/83543] strlen of a local array member not optimized on some targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83543 --- Comment #5 from Martin Sebor --- (In reply to Ramana Radhakrishnan from comment #4) Setting -march=armv7-a doesn't make a difference. The root cause is that initializers of locally defined aggregates such as struct { char a[N]; } S s = { "12345" }; are represented in one of two ways in GIMPLE: a) as an assignment of the string to s.a, or b) as a copy from a label (e.g., 's = *.LC0') and the strlen pass only knows how to deal with (a) but not (b). AFAICS, whether form (a) or form (b) is chosen depends on the size of the size of the aggregate. Some targets use a lower threshold for (b) than others. As far as I can see, x86_64 appears to cut over at 257 bytes, while arm-none-eabi always uses (b).
[Bug fortran/83148] [8 regression] ICE: crash_signal from toplev.c:325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83148 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #5 from Paul Thomas --- (In reply to Thomas Koenig from comment #4) > Reverting the resolve.c part of r254427 makes the problem go away. It's the second part of the patch to resolve.c that offends. Clearly, the possession of a iso_bind_c type component is the problem. I will investigate more on Friday, when I have some time. Paul
[Bug middle-end/61118] [6/7/8 Regression] Indirect call generated for pthread_cleanup_push with constant cleanup function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118 Jeffrey A. Law changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE |--- --- Comment #22 from Jeffrey A. Law --- I don't think this is a duplicate of 21161. AFAICT the core of the problem here is the multiple static assignments to the pseudos holding cancel_arg and cancel_routine. They set the objects to the same value, but the multiple-assignment nature is a key aspect of the longjmp clobbering analysis. I think the multiple assignment largely steps from the PHIs in this block: ;; basic block 5, loop depth 0, count 536656163 (estimated locally), maybe hot ;;prev block 4, next block 6, flags: (NEW, REACHABLE, IRREDUCIBLE_LOOP, VISITED) ;;pred: 4 [always (guessed)] count:268328082 (estimated locally) (FALLTHRU,IRREDUCIBLE_LOOP,EXECUTABLE) ;;6 [always (guessed)] count:1716613 (estimated locally) (ABNORMAL,DFS_BACK,IRREDUCIBLE_LOOP,EXECUTABLE) ;;3 [50.0% (guessed)] count:268328082 (estimated locally) (IRREDUCIBLE_LOOP,FALSE_VALUE,EXECUTABLE) # __cancel_routine_9(ab) = PHI # __cancel_arg_12(ab) = PHI <_1(4), __cancel_arg_13(ab)(6), _1(3)> _24 = __sigsetjmp (&__cancel_buf.__cancel_jmp_buf, 0); goto ; [99.96%] This happens in CCP1 and FRE1 for cancel_routine and cancel_arg respectively. (replacinging a cancel_{arg,routine} with an equivalent). Once replaced, it's exceedingly hard to undo. One could easily argue that we shouldn't to the replacement in an abnormal PHI. Regardless, this is separate from 21161. There is a slim chance that fixing 21161 is a requirement to fix this BZ, but they are not duplicates AFAICT.
[Bug fortran/83980] Various issues with character length in array constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83980 --- Comment #6 from Dominique d'Humieres --- > The fix for pr83823 seems to have fixed the problems reported in > comment #0 and comment #2 for 8.0 trunk. The issues persist up to > 7.2 (haven't checked 7.3). Confirmed.
[Bug tree-optimization/84505] [8 Regression] store-merging miscompilation on i586 in xemacs package starting with r254391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84505 --- Comment #1 from Jakub Jelinek --- Might very well be a dup of PR84503, let me finish up the patch.
[Bug target/69770] [ARM] -mlong-calls does not affect calls to __gnu_mcount_nc generated by -pg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69770 Maxim Kuvyrkov changed: What|Removed |Added Status|ASSIGNED|NEW CC||mkuvyrkov at gcc dot gnu.org Assignee|cbaylis at gcc dot gnu.org |unassigned at gcc dot gnu.org
[Bug c++/66971] thread_local with external linkage and constructor cannot be compiled correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66971 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jonathan Wakely --- It was fixed on trunk by r242607 i.e. PR c++/77285 *** This bug has been marked as a duplicate of bug 77285 ***
[Bug tree-optimization/84505] New: [8 Regression] store-merging miscompilation on i586 in xemacs package starting with r254391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84505 Bug ID: 84505 Summary: [8 Regression] store-merging miscompilation on i586 in xemacs package starting with r254391 Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- I'm still reducing the test-case, but with: $ gcc -O2 -m32 alloc.i -funroll-loops -fdump-tree-optimized=/tmp/bad.txt -c -o /tmp/bad.s -S -fno-strict-aliasing I see following difference in tree-optimized dump: $ diff -u /tmp/good.txt /tmp/bad.txt -U20 --- /tmp/good.txt 2018-02-21 19:15:26.081205161 +0100 +++ /tmp/bad.txt2018-02-21 19:23:04.898349760 +0100 @@ -9831,50 +9831,49 @@ free_marker (Lisp_Object ptr) { struct Lisp_Marker * FFT_ptr; struct Lisp_Free * marker_free_list.705_1; long int consing_since_gc.706_2; long unsigned int consing_since_gc.707_3; long unsigned int _4; long int _5; long unsigned int total_consing.708_6; long unsigned int _7; int profiling_active.709_8; int gc_count_num_marker_freelist.711_10; int _11; long int prephitmp_31; long int pretmp_40; [local count: 1431]: FFT_ptr_15 = (struct Lisp_Marker *) ptr_14(D); unchain_marker (ptr_14(D)); - MEM[(unsigned int *)FFT_ptr_15] = 3735928559; - MEM[(unsigned int *)FFT_ptr_15 + 4B] = 3735928559; MEM[(unsigned int *)FFT_ptr_15 + 8B] = 3735928559; MEM[(unsigned int *)FFT_ptr_15 + 12B] = 3735928559; MEM[(unsigned int *)FFT_ptr_15 + 16B] = 3735928559; MEM[(unsigned int *)FFT_ptr_15 + 20B] = 3735928559; marker_free_list.705_1 = marker_free_list; MEM[(struct Lisp_Free *)FFT_ptr_15].chain = marker_free_list.705_1; marker_free_list = FFT_ptr_15; - MEM[(struct lrecord_header *)FFT_ptr_15].type = 69; + MEM[(void *)FFT_ptr_15] = 3735928389; + MEM[(unsigned int *)FFT_ptr_15 + 4B] = 3735928559; consing_since_gc.706_2 = consing_since_gc; consing_since_gc.707_3 = (long unsigned int) consing_since_gc.706_2; _4 = consing_since_gc.707_3 + 4294967272; _5 = (long int) _4; consing_since_gc = _5; total_consing.708_6 = total_consing; _7 = total_consing.708_6 + 4294967272; total_consing = _7; profiling_active.709_8 = profiling_active; if (profiling_active.709_8 != 0) goto ; [33.00%] else goto ; [67.00%] [local count: 472]: profile_record_unconsing (24); pretmp_40 = consing_since_gc; [local count: 1429]: # prephitmp_31 = PHI I suspect later 2 stores: + MEM[(void *)FFT_ptr_15] = 3735928389; + MEM[(unsigned int *)FFT_ptr_15 + 4B] = 3735928559; which overwrite: MEM[(struct Lisp_Free *)FFT_ptr_15].chain = marker_free_list.705_1; It's probably connected with aliasing analysis that allows store motion after the *.chain store.
[Bug c/70186] RFE: better handling of misspelled attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70186 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=82914 --- Comment #4 from Martin Sebor --- See also bug 82914 that points out cases where GCC silently ignores all attributes, misspelled or otherwise. (It's a different problem than this one and the solutions are different as well.)
[Bug tree-optimization/84480] [8 Regression] bogus -Wstringop-truncation despite assignment with an inlined string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84480 Martin Sebor changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Summary|Unexpected |[8 Regression] bogus |-Wstringop-truncation on|-Wstringop-truncation |strncpy with string literal |despite assignment with an |at -O2 |inlined string literal
[Bug tree-optimization/84480] Unexpected -Wstringop-truncation on strncpy with string literal at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84480 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-21 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Martin Sebor --- Thanks for the test case. The root cause is the same as in bug 84474. The warnings in both of these test cases are issued in gimple-fold.c (see gimple_fold_builtin_strncpy), long before the code in tree-ssa-strlen.c has run. The difference between this case and the one in bug 84474 is that here the next statement is already available. With that, I think there may be a way to avoid the subset of the warnings in this report.
[Bug tree-optimization/84503] [7/8 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503 --- Comment #2 from Jakub Jelinek --- The bug is in the way we handle overlapping stores. The problem is that all we do if there is overlap is: if (IN_RANGE (info->bitpos, merged_store->start, merged_store->start + merged_store->width - 1)) { /* Only allow overlapping stores of constants. */ if (info->rhs_code == INTEGER_CST && merged_store->stores[0]->rhs_code == INTEGER_CST) { merged_store->merge_overlapping (info); continue; } } otherwise we: /* |---store 1---| |---store 2---|. Gap between stores or the rhs not compatible. Start a new group. */ /* Try to apply all the stores recorded for the group to determine the bitpattern they write and discard it if that fails. This will also reject single-store groups. */ if (!merged_store->apply_stores ()) delete merged_store; else m_merged_store_groups.safe_push (merged_store); merged_store = new merged_store_group (info); But the statements here are sorted primarily by bitpos and we emit statements for the group at the location of the last statement (highest order) in the merged store group. So I think we need to check before adding another store if it is not rhs_code INTEGER_CST, whether there is any overlap with following stores. Overlap is fine if the order of all the overlapping statements is higher than MAX (merged_store->last_order, info->order), because then we know we'll start a new group right after info and the merged stores of the current group will come before any overlapping stores (whether merged successfully with something or not), but otherwise we just shouldn't add info into the current group.
[Bug c++/84502] [8 Regression] Argument corruption when passing empty templated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- This might be the reason why building Chromium gn fails (I hope). Related: PR84286
[Bug c++/45431] specify the field for initializer-string for array of chars is too long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45431 --- Comment #4 from Jonathan Wakely --- Because the C front end gets the location info right in recent versions of GCC it also marks the bad initializer with carets: bug.c:4:3: warning: initializer-string for array of chars is too long "Christopher", ^ bug.c:4:3: note: (near initialization for 'sc_me.name') bug.c:5:3: warning: initializer-string for array of chars is too long "Yeleighton" }; ^~~~ bug.c:5:3: note: (near initialization for 'sc_me.surname') This is ideal, as it shows both the bad initializer, and the field it's trying to initialize.
[Bug c++/43064] improve location and text of diagnostics in constructor initializer lists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43064 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=45431 --- Comment #5 from Jonathan Wakely --- In this similar case the C front end gets the location right, and also prints a note with the name of the field: #include struct X { int i; int j; }; struct X x = { NULL, 2 }; $ gcc -Wall s.c -c s.c:4:3: warning: initialization makes integer from pointer without a cast [-Wint-conversion] NULL, ^~~~ s.c:4:3: note: (near initialization for ‘x.i’) $ g++ -Wall s.c -c s.c:6:1: warning: converting to non-pointer type ‘int’ from NULL [-Wconversion-null] }; ^
[Bug c++/84502] [8 Regression] Argument corruption when passing empty templated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502 Jonathan Wakely changed: What|Removed |Added Keywords||ABI Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-21 Known to work||7.3.0 Summary|Argument corruption when|[8 Regression] Argument |passing empty templated |corruption when passing |struct |empty templated struct Ever confirmed|0 |1 Known to fail||8.0.1 --- Comment #2 from Jonathan Wakely --- This is caused by -fabi-version=12 (which is the default for GCC 8). You can get the old handling of empty structs with -fabi-version=11 The bug only seems to happen when the empty struct is a class template. Reduced, this fails at -O0 but not any other optimization level, or with -fabi-version=11: template struct EmptyTemplatedStruct { }; using X = EmptyTemplatedStruct; void func(X, int a1, int a2, int a3, int a4, int a5, int a6, int a7, int a8) { if (a1 != 0) __builtin_abort(); if (a2 != 1) __builtin_abort(); if (a3 != 2) __builtin_abort(); if (a4 != 3) __builtin_abort(); if (a5 != 4) __builtin_abort(); if (a6 != 5) __builtin_abort(); if (a7 != 6) __builtin_abort(); if (a8 != 7) __builtin_abort(); } int main() { func(X{}, 0, 1, 2, 3, 4, 5, 6, 7); }
[Bug c++/84502] [8 Regression] Argument corruption when passing empty templated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502 Jonathan Wakely changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |8.0
[Bug tree-optimization/84503] [7/8 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503 --- Comment #1 from Jakub Jelinek --- Can be reproduced also on x86_64-linux with -O3 -fno-tree-vectorize -fno-ivopts. For the latter, I wonder what's the point in using TARGET_MEM_REF in: MEM[(long int *)p_28] = 0; MEM[(long int *)p_28 + 8B] = 0; MEM[(long int *)p_28 + 16B] = 0; MEM[(long int *)p_28 + 24B] = 0; MEM[(long int *)p_28 + 32B] = 0; MEM[(long int *)p_28 + 40B] = 0; MEM[(long int *)p_28 + 48B] = 0; , isn't that something that MEM_REF can express too? store-merging doesn't handle TARGET_MEM_REFs and only handles MEM_REFs. So, for stage1 shall it handle also TARGET_MEM_REFs that only have base and optionally constant disp and nothing else, or shall ivopts pass instead just generate MEM_REFs in those cases?
[Bug c++/84491] Multiple inheritance and covariant return types causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84491 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-21 CC||dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Confirmed. It's failing this assertion in method.c: 96/* Likewise, we can only be adding thunks to a function declared in 97 the class currently being laid out. */ 98gcc_assert (TYPE_SIZE (DECL_CONTEXT (function)) 99&& TYPE_BEING_DEFINED (DECL_CONTEXT (function)));
[Bug c++/84492] [8 Regression] ICE with statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84492 --- Comment #2 from David Malcolm --- This assertion is failing, where rhs is a STMT_EXPR. 8000 /* There are only a few kinds of expressions that may have a type 8001 dependent on overload resolution. */ 8002 gcc_assert (TREE_CODE (rhs) == ADDR_EXPR 8003 || TREE_CODE (rhs) == COMPONENT_REF 8004 || is_overloaded_fn (rhs) 8005 || (flag_ms_extensions && TREE_CODE (rhs) == FUNCTION_DECL));
[Bug c++/84492] [8 Regression] ICE with statement expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84492 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-21 CC||dmalcolm at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Confirmed. Started with r253599.
[Bug fortran/84495] Incorrect result for concatenation of Fortran allocatable string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84495 --- Comment #4 from Steve Kargl --- On Wed, Feb 21, 2018 at 10:44:07AM +, tkoenig at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84495 > > Thomas Koenig changed: > >What|Removed |Added > > CC||tkoenig at gcc dot gnu.org > > --- Comment #2 from Thomas Koenig --- > This looks like a duplicate of PR81116, fixed by r251125. > > This is not a regression, and in genereal (we have played loose with > this rule) we are not supposed to backport. > > Opinions? > Release Manager would probably say that it is up the Fortran Maintainers on whether something should be backported. If I have a patch on trunk that applies to the branch(es) with minimum effort, I tend to backport to keep code in sync.
[Bug fortran/84504] New: procedure pointer variables cannot be initialized with functions returning pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84504 Bug ID: 84504 Summary: procedure pointer variables cannot be initialized with functions returning pointers Product: gcc Version: 6.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: sriram at pobox dot com Target Milestone: --- Also occurs on gcc 7.2.0 - not tried on other version. procedure pointer variables pointing initialized with functions returning pointers fail to compile. Note that the sample code below compiles if we change the function type to not be a pointer. Source: module test_procedure_pointer implicit none private procedure(the_proc), pointer :: ptr => the_proc contains function the_proc() integer, pointer :: the_proc end function the_proc end module test_procedure_pointer Error: procedure(the_proc), pointer :: ptr => the_proc 1 Error: Pointer initialization target at (1) must have the TARGET attribute save-temps: sn-fey1[1-290] gfortran -v -save-temps ~/procpointer.f90 Driving: gfortran -v -save-temps /users/sriram/procpointer.f90 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/yellow/usr/projects/hpcsoft/toss3/common/gcc/6.4.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.4.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-6.4.0/configure --prefix=/usr/projects/hpcsoft/toss3/common/gcc/6.4.0 --enable-threads=posix --enable-__cxa_atexit --enable-lto --enable-checking=release --disable-multilib --enable-languages=c,c++,fortran Thread model: posix gcc version 6.4.0 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /yellow/usr/projects/hpcsoft/toss3/common/gcc/6.4.0/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.4.0/f951 /users/sriram/procpointer.f90 -quiet -dumpbase procpointer.f90 -mtune=generic -march=x86-64 -auxbase procpointer -version -fintrinsic-modules-path /yellow/usr/projects/hpcsoft/toss3/common/gcc/6.4.0/bin/../lib/gcc/x86_64-pc-linux-gnu/6.4.0/finclude -o procpointer.s GNU Fortran (GCC) version 6.4.0 (x86_64-pc-linux-gnu) compiled by GNU C version 6.4.0, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran2008 (GCC) version 6.4.0 (x86_64-pc-linux-gnu) compiled by GNU C version 6.4.0, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1, isl version 0.15 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 /users/sriram/procpointer.f90:4:50: procedure(the_proc), pointer :: ptr => the_proc 1 Error: Pointer initialization target at (1) must have the TARGET attribute
[Bug go/84484] libgo configure tests fail to find -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484 --- Comment #16 from Andreas Schwab --- Created attachment 43484 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43484&action=edit libgo support for riscv64 With this patch I can sucessfully build libgo for riscv64.
[Bug c++/84502] Argument corruption when passing empty templated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502 --- Comment #1 from patrick.schlangen at bmw dot de --- Note: This problem does not happen with gcc 7.2.1. The problem can also be reproduced with -O3 when the empty struct object passed to the function is actually used in the function. (So it is not optimized out.)
[Bug tree-optimization/84503] [7/8 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P2 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-02-21 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |8.0 Ever confirmed|0 |1
[Bug tree-optimization/84503] New: [7/8 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84503 Bug ID: 84503 Summary: [7/8 Regression] store-merging miscompilation on powerpc64 with -O3 since r241789 Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- typedef __SIZE_TYPE__ size_t; typedef __UINTPTR_TYPE__ uintptr_t; struct S { int a; unsigned short b; int c, d, e; long f, g, h; int i, j; }; static struct S *k; static size_t l = 0; int m; static int bar (void) { unsigned i; int j; if (k[0].c == 0) { ++m; size_t n = l * 2; struct S *o; o = (struct S *) __builtin_realloc (k, sizeof (struct S) * n); if (!o) __builtin_exit (0); k = o; for (i = l; i < n; i++) { void *p = (void *) &k[i]; int q = 0; size_t r = sizeof (struct S); if uintptr_t) p) % __alignof__ (long)) == 0 && r % sizeof (long) == 0) { long __attribute__ ((may_alias)) *s = (long *) p; long *t = (long *) ((char *) s + r); while (s < t) *s++ = 0; } else __builtin_memset (p, q, r); k[i].c = i + 1; k[i].a = -1; } k[n - 1].c = 0; k[0].c = l; l = n; } j = k[0].c; k[0].c = k[j].c; return j; } int main () { k = (struct S *) __builtin_malloc (sizeof (struct S)); if (!k) __builtin_exit (0); __builtin_memset (k, '\0', sizeof (struct S)); k->a = -1; l = 1; for (int i = 0; i < 15; ++i) bar (); if (m != 4) __builtin_abort (); return 0; } is miscompiled with -O3 starting with r241789. The bug can be seen when diffing store_merging dump with the previous one: --- rh1547495.c.192t.widening_mul 2018-02-21 17:25:00.049972838 +0100 +++ rh1547495.c.193t.store-merging 2018-02-21 17:25:00.049972838 +0100 @@ -1,6 +1,10 @@ ;; Function main (main, funcdef_no=1, decl_uid=2691, cgraph_uid=1, symbol_order=4) (executed once) +Coalescing successful! +Merged into 2 stores +New sequence of 2 stmts to replace old one of 3 stmts +Merging successful! main () { unsigned int i; @@ -120,8 +124,6 @@ main () goto ; [57.11%] [local count: 510973054]: - MEM[(long int *)p_28] = 0; - MEM[(long int *)p_28 + 8B] = 0; MEM[(long int *)p_28 + 16B] = 0; MEM[(long int *)p_28 + 24B] = 0; MEM[(long int *)p_28 + 32B] = 0; @@ -130,7 +132,8 @@ main () _14 = i_31 + 1; _119 = (int) _14; MEM[(struct S *)p_28].c = _119; - MEM[(struct S *)p_28].a = -1; + MEM[(void *)p_28] = 18446744069414584320; + MEM[(long int *)p_28 + 8B] = 0; _111 = (long unsigned int) _14; if (n_21 > _111) goto ; [89.00%] MEM[(void *)p_28] = 18446744069414584320; is fine, that stores 0x into the first 8 bytes, but MEM[(struct S *)p_28].c = _119; stores 4 bytes at offset 8 and MEM[(long int *)p_28 + 8B] = 0; overwrites it.
[Bug c++/84502] New: Argument corruption when passing empty templated struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84502 Bug ID: 84502 Summary: Argument corruption when passing empty templated struct Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: patrick.schlangen at bmw dot de Target Milestone: --- Created attachment 43483 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43483&action=edit Minimal example Hi, we've discovered a strange problem when passing many function arguments where one argument is an alias (using = ...) for a templated struct which has no members (e.g. std::integer_sequence). When building in non-optimized mode or with -O1/-O2, all arguments starting from argument #7 seem to be corrupt. Building with -O3 seems to solve the issue. I've attached a small example program. Correct output: --- $ ~/gcc-8/bin/g++ -O3 -o repro repro.cpp && ./repro 0, 1, 2, 3, 4, 5, 6, 7 Wrong outputs: -- $ ~/gcc-8/bin/g++ -O2 -o repro repro.cpp && ./repro 0, 1, 2, 3, 4, 5, 7, 0 $ ~/gcc-8/bin/g++ -O1 -o repro repro.cpp && ./repro 0, 1, 2, 3, 4, 5, 7, 0 $ ~/gcc-8/bin/g++ -O0 -o repro repro.cpp && ./repro 0, 1, 2, 3, 4, 5, 7, 2088590376 gcc version (freshly built): $ ~/gcc-8/bin/g++ -v Using built-in specs. COLLECT_GCC=/home/patrick/gcc-8/bin/g++ COLLECT_LTO_WRAPPER=/home/patrick/gcc-8/libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./configure --prefix=/home/patrick/gcc-8 --disable-multilib Thread model: posix gcc version 8.0.1 20180218 (experimental) (GCC) Best Regards Patrick
[Bug tree-optimization/83126] [8 Regression] ICE in transform_to_exit_first_loop_alt, at tree-parloops.c:1713
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83126 --- Comment #9 from Tom de Vries --- (In reply to Tom de Vries from comment #8) > Created attachment 43476 [details] > Tentative patch > > (In reply to rguent...@suse.de from comment #3) > > > This is the usual "you should not repeat analysis during transform" issue. > > The vectorizer gets around this by caching relevant scalar evolution > > but obviously that's difficult if using generic stuff like > > canonicalize_loop_ivs ... > > This patch caches affine_iv info before calling loop_version, and then uses > that cached info in canonicalize_loop_ivs. This fixes the ICE. Bootstrap and reg-test on x86_64 succeeded. Richard, is this approach ok for stage1 and/or stage4?
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 --- Comment #56 from Martin Sebor --- I'd say any warning option with more than just a handful of pr's against it would benefit from having a meta-bug.
[Bug go/84484] libgo configure tests fail to find -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484 --- Comment #15 from Ian Lance Taylor --- > The first hunk is useless since this is a compile test. Understood, but I would prefer to test the exact options that the build is going to use.
[Bug target/84264] [8 Regression] ICE in rs6000_emit_le_vsx_store, at config/rs6000/rs6000.c:10367 starting with r256656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84264 Peter Bergner changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|kelvin at gcc dot gnu.org |bergner at gcc dot gnu.org --- Comment #5 from Peter Bergner --- I'm looking into this.
[Bug go/84484] libgo configure tests fail to find -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484 --- Comment #14 from Andreas Schwab --- See gcc/config/riscv/linux.h for why it does that.
[Bug go/84484] libgo configure tests fail to find -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484 --- Comment #13 from Andreas Schwab --- The first hunk is useless since this is a compile test.
[Bug fortran/79072] ICE with class(*) pointer function result and character value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072 Thomas Koenig changed: What|Removed |Added Status|WAITING |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution|--- |FIXED --- Comment #23 from Thomas Koenig --- Let's close it then. Thanks for the bug report!
[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290 Andrew Pinski changed: What|Removed |Added Keywords|patch | --- Comment #12 from Andrew Pinski --- (In reply to Eric Gallager from comment #11) > (In reply to Andrew Pinski from comment #10) > > Note this needs at least: > > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02837.html > > > > This was approved; has it been committed yet? Yes. That patch was applied. But that patch is only a support patch and not the full patch to fix this. I was actually going to working on this again but it won't go in until gcc 9.
[Bug c++/84434] [8 Regression] internal compiler error: tree check: expected var_decl or field_decl or function_decl or type_decl or template_decl, have using_decl in build_deduction_guide, at cp/pt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84434 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org
[Bug c++/84447] [8 Regression] ICE with inherited deleted constructor and default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84447 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1
[Bug go/84484] libgo configure tests fail to find -latomic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84484 --- Comment #12 from Ian Lance Taylor --- How about this patch? diff --git a/libgo/configure b/libgo/configure index aba4dc39..dcfc524b 100755 --- a/libgo/configure +++ b/libgo/configure @@ -14209,7 +14209,7 @@ if test "${libgo_cv_lib_pthread+set}" = set; then : $as_echo_n "(cached) " >&6 else CFLAGS_hold=$CFLAGS -CFLAGS="$CFLAGS -pthread" +CFLAGS="$CFLAGS -pthread -L../libatomic/.libs" cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ int i; @@ -14226,7 +14226,8 @@ fi $as_echo "$libgo_cv_lib_pthread" >&6; } PTHREAD_CFLAGS= if test "$libgo_cv_lib_pthread" = yes; then - PTHREAD_CFLAGS=-pthread + # RISC-V apparently adds -latomic when using -pthread. + PTHREAD_CFLAGS="-pthread -L../libatomic/.libs" fi diff --git a/libgo/configure.ac b/libgo/configure.ac index 1264a1d2..1f49aee9 100644 --- a/libgo/configure.ac +++ b/libgo/configure.ac @@ -493,14 +493,15 @@ dnl Test whether the compiler supports the -pthread option. AC_CACHE_CHECK([whether -pthread is supported], [libgo_cv_lib_pthread], [CFLAGS_hold=$CFLAGS -CFLAGS="$CFLAGS -pthread" +CFLAGS="$CFLAGS -pthread -L../libatomic/.libs" AC_COMPILE_IFELSE([[int i;]], [libgo_cv_lib_pthread=yes], [libgo_cv_lib_pthread=no]) CFLAGS=$CFLAGS_hold]) PTHREAD_CFLAGS= if test "$libgo_cv_lib_pthread" = yes; then - PTHREAD_CFLAGS=-pthread + # RISC-V apparently adds -latomic when using -pthread. + PTHREAD_CFLAGS="-pthread -L../libatomic/.libs" fi AC_SUBST(PTHREAD_CFLAGS)
[Bug c/16351] NULL dereference warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=71157, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84315, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84316 --- Comment #55 from Eric Gallager --- Related: bug 71157, bug 84315, and bug 84316 (should this be a meta-bug for all issues with -Wnull-dereference? In which case I should be putting those under "Depends on" instead of "See Also"...)
[Bug target/82096] [6 Regression] ICE in int_mode_for_mode, at stor-layout.c:403 with arm-linux-gnueabi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82096 sudi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from sudi at gcc dot gnu.org --- Backported to gcc-6
[Bug c++/84454] [8 Regression] ICE in invalid_nonstatic_memfn_p at gcc/cp/typeck.c:1882
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84454 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Jason Merrill --- Author: jason Date: Wed Feb 21 14:25:54 2018 New Revision: 257875 URL: https://gcc.gnu.org/viewcvs?rev=257875&root=gcc&view=rev Log: PR c++/84454 - ICE with pack expansion in signature. * error.c (find_typenames_r): Also stop on EXPR_PACK_EXPANSION. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic172.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c --- Comment #2 from Jason Merrill --- Fixed.
[Bug c++/84454] [8 Regression] ICE in invalid_nonstatic_memfn_p at gcc/cp/typeck.c:1882
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84454 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #1 from Jason Merrill --- Author: jason Date: Wed Feb 21 14:25:54 2018 New Revision: 257875 URL: https://gcc.gnu.org/viewcvs?rev=257875&root=gcc&view=rev Log: PR c++/84454 - ICE with pack expansion in signature. * error.c (find_typenames_r): Also stop on EXPR_PACK_EXPANSION. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic172.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c --- Comment #2 from Jason Merrill --- Fixed.