[Bug lto/89183] GCC 8 LTO fails on Windows with -g/-g3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89183 --- Comment #2 from Andrew Pinski --- This is already fixed in the sources and will be included for GCC 8.3. You should ask ARM to backport the fix and have them release a new toolchain since that is where you got the binaries from.
[Bug lto/89183] GCC 8 LTO fails on Windows with -g/-g3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89183 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 88422 ***
[Bug lto/88422] collect2.exe: fatal error: lto-wrapper returned 1 exit status: file not recognized: file truncated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88422 Andrew Pinski changed: What|Removed |Added CC||ilg at livius dot net --- Comment #11 from Andrew Pinski --- *** Bug 89183 has been marked as a duplicate of this bug. ***
[Bug fortran/78746] charlen_03, charlen_10 ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746 Thomas Koenig changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code CC||tkoenig at gcc dot gnu.org Severity|normal |enhancement --- Comment #18 from Thomas Koenig --- Still worth fixing, but IMHO a low priority.
[Bug fortran/77678] ICE in fold_read_from_constant_string, at fold-const.c:13706
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77678 Thomas Koenig changed: What|Removed |Added Status|NEW |RESOLVED CC||tkoenig at gcc dot gnu.org Resolution|--- |FIXED --- Comment #9 from Thomas Koenig --- (In reply to kargl from comment #8) > I think that this should be closed. Yes.
[Bug fortran/78746] charlen_03, charlen_10 ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746 Arseny Solokha changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #17 from Arseny Solokha --- Just in case, w/ gcc/testsuite/gfortran.dg/class_61.f90 (as of r268503): ==20572== Invalid read of size 8 ==20572==at 0x8150A4: resolve_component(gfc_component*, gfc_symbol*) (resolve.c:13809) ==20572==by 0x815BB2: resolve_fl_derived0(gfc_symbol*) [clone .part.54] (resolve.c:14258) ==20572==by 0x8161FF: resolve_fl_derived0 (resolve.c:14357) ==20572==by 0x8161FF: resolve_fl_derived(gfc_symbol*) (resolve.c:14387) ==20572==by 0x812957: resolve_symbol(gfc_symbol*) (resolve.c:14761) ==20572==by 0x83B222: do_traverse_symtree(gfc_symtree*, void (*)(gfc_symtree*), void (*)(gfc_symbol*)) (symbol.c:4155) ==20572==by 0x81FA55: resolve_types(gfc_namespace*) (resolve.c:16673) ==20572==by 0x8118FE: gfc_resolve(gfc_namespace*) (resolve.c:16787) ==20572==by 0x8036D6: resolve_all_program_units (parse.c:6073) ==20572==by 0x8036D6: gfc_parse_file() (parse.c:6323) ==20572==by 0x850FDE: gfc_be_parse_file() (f95-lang.c:204) ==20572==by 0xDA085C: compile_file() (toplev.c:456) ==20572==by 0x76966E: do_compile (toplev.c:2176) ==20572==by 0x76966E: toplev::main(int, char**) (toplev.c:2311) ==20572==by 0x76BADD: main (main.c:39) ==20572== Address 0x4fafcb0 is 192 bytes inside a block of size 344 free'd ==20572==at 0x4833FEB: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==20572==by 0x841E40: gfc_restore_last_undo_checkpoint() (symbol.c:3705) ==20572==by 0x7F9786: reject_statement() (parse.c:2576) ==20572==by 0x7FA577: match_word (parse.c:70) ==20572==by 0x7FA577: decode_statement() (parse.c:376) ==20572==by 0x7FE341: next_free (parse.c:1241) ==20572==by 0x7FE341: next_statement() (parse.c:1473) ==20572==by 0x800194: parse_derived (parse.c:3285) ==20572==by 0x800194: parse_spec(gfc_statement) (parse.c:3826) ==20572==by 0x802AAF: parse_progunit(gfc_statement) (parse.c:5680) ==20572==by 0x803671: gfc_parse_file() (parse.c:6220) ==20572==by 0x850FDE: gfc_be_parse_file() (f95-lang.c:204) ==20572==by 0xDA085C: compile_file() (toplev.c:456) ==20572==by 0x76966E: do_compile (toplev.c:2176) ==20572==by 0x76966E: toplev::main(int, char**) (toplev.c:2311) ==20572==by 0x76BADD: main (main.c:39) ==20572== Block was alloc'd at ==20572==at 0x48351A6: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==20572==by 0x1671700: xcalloc (xmalloc.c:162) ==20572==by 0x840848: gfc_new_symbol(char const*, gfc_namespace*) (symbol.c:3123) ==20572==by 0x840C77: gfc_get_sym_tree(char const*, gfc_namespace*, gfc_symtree**, bool) (symbol.c:3373) ==20572==by 0x840EE1: gfc_get_symbol(char const*, gfc_namespace*, gfc_symbol**) (symbol.c:3426) ==20572==by 0x79385F: gfc_match_decl_type_spec(gfc_typespec*, int) (decl.c:4325) ==20572==by 0x795E51: gfc_match_data_decl() (decl.c:5934) ==20572==by 0x7FA55B: match_word (parse.c:65) ==20572==by 0x7FA55B: decode_statement() (parse.c:376) ==20572==by 0x7FE341: next_free (parse.c:1241) ==20572==by 0x7FE341: next_statement() (parse.c:1473) ==20572==by 0x800194: parse_derived (parse.c:3285) ==20572==by 0x800194: parse_spec(gfc_statement) (parse.c:3826) ==20572==by 0x802AAF: parse_progunit(gfc_statement) (parse.c:5680) ==20572==by 0x803671: gfc_parse_file() (parse.c:6220)
[Bug lto/89183] New: GCC 8 LTO fails on Windows with -g/-g3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89183 Bug ID: 89183 Summary: GCC 8 LTO fails on Windows with -g/-g3 Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: ilg at livius dot net CC: marxin at gcc dot gnu.org Target Milestone: --- I encountered the problem while using arm-none-eabi-gcc 8-2018-q4 on a Windows 10 64-bit. To reproduce it, create an empty main.c and try to compile it with -g or -g3: C:\Users\ilg\tmp>"C:\Users\ilg\AppData\Roaming\GNU Tools ARM Embedded\8-2018-q4\bin\arm-none-eabi-gcc.exe" -flto -g main.c c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: C:\Users\ilg\AppData\Local\Temp\cck5e5XRdebugobjtem: file not recognized: file truncated collect2.exe: error: ld returned 1 exit status lto-wrapper.exe: fatal error: C:\Users\ilg\AppData\Roaming\GNU Tools ARM Embedded\8-2018-q4\bin\arm-none-eabi-gcc.exe returned 1 exit status compilation terminated. c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: error: lto-wrapper failed collect2.exe: error: ld returned 1 exit status C:\Users\ilg\tmp>"C:\Users\ilg\AppData\Roaming\GNU Tools ARM Embedded\8-2018-q4\bin\arm-none-eabi-gcc.exe" -flto -g3 main.c c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: C:\Users\ilg\AppData\Local\Temp\ccg9waOldebugobjtem has a corrupt section with a size (a0d66) larger than the file size c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: C:\Users\ilg\AppData\Local\Temp\ccg9waOldebugobjtem: invalid string offset 2048 >= 22975072851460187 for section `(null)' c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: C:\Users\ilg\AppData\Local\Temp\ccg9waOldebugobjtem: invalid string offset 2048 >= 22975072851460187 for section `(null)' c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: C:\Users\ilg\AppData\Local\Temp\ccg9waOldebugobjtem: invalid string offset 12032 >= 22975072851460187 for section `(null)' c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: C:\Users\ilg\AppData\Local\Temp\ccg9waOldebugobjtem: invalid string offset 16640 >= 22975072851460187 for section `(null)' c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: C:\Users\ilg\AppData\Local\Temp\ccg9waOldebugobjtem: invalid string offset 16640 >= 22975072851460187 for section `(null)' collect2.exe: error: ld returned 5 exit status lto-wrapper.exe: fatal error: C:\Users\ilg\AppData\Roaming\GNU Tools ARM Embedded\8-2018-q4\bin\arm-none-eabi-gcc.exe returned 1 exit status compilation terminated. c:/users/ilg/appdata/roaming/gnu tools arm embedded/8-2018-q4/bin/../lib/gcc/arm-none-eabi/8.2.1/../../../../arm-none-eabi/bin/ld.exe: error: lto-wrapper failed collect2.exe: error: ld returned 1 exit status Linux and macOS builds seem ok, only the mingw-w64 build is affected. Previous Arm releases, using GCC 7, were ok on Windows too, the problem occured after switching to GCC 8.
[Bug fortran/88247] [8/9 Regression] ICE in get_array_ctor_var_strlen, at fortran/trans-array.c:2068
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88247
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Comment #3 from Paul Thomas ---
Created attachment 45594
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45594&action=edit
A fix for the PR and more besides
This represents where I have got to:
program p
type t
character(:), allocatable :: c
character(:), dimension(:), allocatable :: d
end type
type(t), allocatable :: x
call foo ('abcdef','ghijkl')
associate (y => [x%c(:)])
if (y(1) .ne. 'abcdef') stop 1
end associate
call foo ('ghi','ghi')
associate (y => [x%c(2:)])
if (y(1) .ne. 'hi') stop 2
end associate
call foo ('lmnopq','ghijkl')
associate (y => [x%c(:3)])
! if (y(1) .ne. 'lmn') stop 3
end associate
call foo ('abcdef','ghijkl')
associate (y => [x%c(2:4)])
if (y(1) .ne. 'bcd') stop 4
end associate
call foo ('lmnopqrst','ghijklmno')
associate (y => x%d(:))
if (y(1) .ne. 'lmnopqrst') stop 5
end associate
! Substrings of arrays still do not work.
! associate (y => x%d(:)(2:4))
! if (y(1) .ne. 'mno') stop 6
! end associate
! This is what I am working on now:
call foo ('abcdef','ghijkl')
associate (y => [x%d(:)])
print *, y(1), ' ', y(2)
if (y(1) .ne. 'abcdef') stop 7
end associate
! call foo ('lmnopqrst','ghijklmno')
! associate (y => [x%d(2:2)])
! if (y(1) .ne. 'ghijklmno') print *, y(1)
! end associate
deallocate (x)
contains
subroutine foo (c1, c2)
character(*) :: c1, c2
if (allocated (x)) deallocate (x)
allocate (x)
x%c = c1
x%d = [c1, c2]
end subroutine foo
end
[Bug tree-optimization/89182] New: [8/9 Regression] [graphite] ICE in extract_affine, at graphite-sese-to-poly.c:280
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89182 Bug ID: 89182 Summary: [8/9 Regression] [graphite] ICE in extract_affine, at graphite-sese-to-poly.c:280 Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- gfortran-9.0.0-alpha20190127 snapshot (r268327) ICEs when compiling the following testcase reduced from gcc/testsuite/gfortran.dg/pr68251.f90 w/ -m32 -O3 (-Ofast) -fgraphite-identity --param max-completely-peeled-insns=8: MODULE hfx_contract_block INTEGER, PARAMETER :: dp=8 CONTAINS SUBROUTINE contract_block(mb_max,mc_max,kbc,ks_bc) REAL(KIND=dp) :: kbc(mb_max*mc_max), ks_bc CALL block_1_2_1_2(kbc,ks_bc) CALL block_1_2_1_3(kbc,ks_bc) CALL block_1_2_1_3(kbc,ks_bc) END SUBROUTINE contract_block SUBROUTINE block_1_2_1_2(kbc,ks_bc) REAL(KIND=dp) :: kbc(2*1), ks_bc DO mc = 1,2 DO mb = 1,2 kbc((mc-1)*2+mb) = ks_bc END DO END DO END SUBROUTINE block_1_2_1_2 SUBROUTINE block_1_2_1_3(kbc,ks_bc) REAL(KIND=dp) :: kbc(2*1), ks_bc DO md = 1,3 DO mc = 1,1 DO mb = 1,2 kbc((mc-1)*2+mb) = kbc((mc-1)*2+mb) - ks_bc END DO END DO END DO END SUBROUTINE block_1_2_1_3 END MODULE hfx_contract_block % powerpc-e300c3-linux-gnu-gfortran-9.0.0-alpha20190127 -m32 -O3 -fgraphite-identity --param max-completely-peeled-insns=8 -c vlehb6sh.f90 during GIMPLE pass: graphite vlehb6sh.f90:4:0: 4 | SUBROUTINE contract_block(mb_max,mc_max,kbc,ks_bc) | internal compiler error: in extract_affine, at graphite-sese-to-poly.c:280 0x14e8572 extract_affine /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/graphite-sese-to-poly.c:280 0x14e8337 extract_affine /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/graphite-sese-to-poly.c:293 0x14e8609 extract_affine /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/graphite-sese-to-poly.c:259 0x14e8d16 add_loop_constraints /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/graphite-sese-to-poly.c:788 0x14e8b78 add_loop_constraints /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/graphite-sese-to-poly.c:749 0x14e9187 build_iteration_domains /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/graphite-sese-to-poly.c:850 0x14e979f build_poly_scop(scop*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/graphite-sese-to-poly.c:1213 0x14da111 graphite_transform_loops() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/graphite.c:406 0x14da6a0 graphite_transforms /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/graphite.c:476 0x14da6a0 execute /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190127/work/gcc-9-20190127/gcc/graphite.c:553 (While my target here is powerpc, the ICE is not target-specific.)
[Bug fortran/83246] internal compiler error or loader problem might be related to a PARAMETER statement being in a BLOCK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83246 --- Comment #7 from urbanjost at comcast dot net --- Thanks!
[Bug fortran/78746] charlen_03, charlen_10 ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746
--- Comment #16 from kargl at gcc dot gnu.org ---
(In reply to Dominique d'Humieres from comment #15)
> I still get
>
> % gfcg charlen_10.f90
> charlen_10.f90:5:39:
>
> 5 | character(:), allocatable :: x(y)1 ! { dg-error "must have a
> deferred shape" }
> | 1
> Error: Allocatable component of structure at (1) must have a deferred shape
> =
> ==64346==ERROR: AddressSanitizer: heap-use-after-free on address
> 0x60401028 at pc 0x0001003ef71b bp 0x7ffeefbfe4d0 sp 0x7ffeefbfe4c8
> READ of size 8 at 0x60401028 thread T0
> #0 0x1003ef71a in gfc_resolve_expr(gfc_expr*) resolve.c:6839
> #1 0x10001556f in resolve_array_bound(gfc_expr*, int) array.c:346
> #2 0x10001c067 in gfc_resolve_array_spec(gfc_array_spec*, int)
> array.c:387
> #3 0x1003e3709 in resolve_component(gfc_component*, gfc_symbol*)
> resolve.c:14148
> ...
So what? An error message has been emitted and gfortran is exiting.
[Bug fortran/78746] charlen_03, charlen_10 ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746
--- Comment #15 from Dominique d'Humieres ---
I still get
% gfcg charlen_10.f90
charlen_10.f90:5:39:
5 | character(:), allocatable :: x(y)1 ! { dg-error "must have a
deferred shape" }
| 1
Error: Allocatable component of structure at (1) must have a deferred shape
=
==64346==ERROR: AddressSanitizer: heap-use-after-free on address 0x60401028
at pc 0x0001003ef71b bp 0x7ffeefbfe4d0 sp 0x7ffeefbfe4c8
READ of size 8 at 0x60401028 thread T0
#0 0x1003ef71a in gfc_resolve_expr(gfc_expr*) resolve.c:6839
#1 0x10001556f in resolve_array_bound(gfc_expr*, int) array.c:346
#2 0x10001c067 in gfc_resolve_array_spec(gfc_array_spec*, int) array.c:387
#3 0x1003e3709 in resolve_component(gfc_component*, gfc_symbol*)
resolve.c:14148
...
[Bug tree-optimization/81679] use attribute unused on function arguments as an optimization hint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81679 Martin Sebor changed: What|Removed |Added Status|WAITING |UNCONFIRMED Ever confirmed|1 |0 --- Comment #7 from Martin Sebor --- It's the feature that I think would be useful. The name of the new attribute itself or its placement are secondary, although being able to repurpose the intuitive name "unused" would be nice. If applying attribute unused to parameters wouldn't work then making unused a function attribute might be an alternative, like so: __attribute__ ((unused (1))) void f (void*); meaning the first parameter isn't used by the function definition.
[Bug libstdc++/89181] Can std C++ library follow ISO spec parameter names?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89181 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- https://gcc.gnu.org/onlinedocs/libstdc++/manual/source_code_style.html Name patterns: For nonstandard names appearing in Standard headers, we are constrained to use names that begin with underscores. This is called "uglification". The convention is: Local and argument names: __[a-z].* Examples: __count __ix __s1 Type names and template formal-argument names: _[A-Z][^_].*
[Bug fortran/77678] ICE in fold_read_from_constant_string, at fold-const.c:13706
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77678 --- Comment #8 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #6) > (In reply to Richard Biener from comment #5) > > ICE fixed. > > Add -fcheck=all to your command line options. > > With the ICE fixed, I think that this falls squarely in the > WONTFIX or INVALID category. It is the user's responsibility > to check if the value of i is within the bounds of the string. > > > % gfc7 -o z -O2 -fcheck=all -finit-integer=-123456 a.f90 && ./z > At line 5 of file a.f90 > Fortran runtime error: Substring out of bounds: lower bound (-123456) > is less than one I think that this should be closed.
[Bug fortran/78746] charlen_03, charlen_10 ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #14 from kargl at gcc dot gnu.org --- Both charlen_03.f90 and charlen_10.f90 now issue errors without an ICE on FreeBSD. valgrind is currently broken, so I cannot to a deeper test. I suspect that one of Paul's recent patches may have accidentally fixed the remaining issues.
[Bug c++/21678] Using inline disables warnings about missing return statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21678
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Known to fail|4.1.0 |4.1.3, 4.3.5, 4.4.7, 4.8.5,
||4.9.4, 5.4.0, 6.4.0, 7.3.0,
||8.2.0, 9.0
--- Comment #7 from Martin Sebor ---
No change in GCC 9. The problem affects both C and C++.
$ cat pr21678.C && gcc -S -Wall -Wextra -xc pr21678.C
static inline __attribute__((always_inline)) int foo(int a)
{
if (a==0)
return 0;
}
Clang issues the expected diagnostic in both modes:
$ clang -S pr21678.C
pr21678.C:5:1: warning: control may reach end of non-void function
[-Wreturn-type]
}
^
1 warning generated.
[Bug c++/80458] [-Wreturn-type] false negative on missing return statement in a member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80458
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||msebor at gcc dot gnu.org
Resolution|--- |DUPLICATE
Known to fail||4.1.3, 4.3.5, 4.4.7, 4.8.5,
||4.9.4, 5.4.0, 6.4.0, 7.3.0,
||8.2.0, 9.0
--- Comment #6 from Martin Sebor ---
I believe this is a duplicate of the ancient bug 21678 that affects both C and
C++:
$ cat pr80458.C && gcc -S -Wall -Wextra -xc pr80458.C
__attribute__ ((always_inline)) inline int
f (int i)
{
if (!i) __builtin_abort ();
}
Clang diagnoses the problem as expected, as does ICC:
pr80458.C:5:1: warning: control may reach end of non-void function
[-Wreturn-type]
}
^
*** This bug has been marked as a duplicate of bug 21678 ***
[Bug c++/21678] Using inline disables warnings about missing return statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21678 Martin Sebor changed: What|Removed |Added CC||skvadrik at gmail dot com --- Comment #6 from Martin Sebor --- *** Bug 80458 has been marked as a duplicate of this bug. ***
[Bug libstdc++/89181] New: Can std C++ library follow ISO spec parameter names?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89181 Bug ID: 89181 Summary: Can std C++ library follow ISO spec parameter names? Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: jg at jguk dot org Target Milestone: --- Can the libstd++ header files show the same parameter names as the spec without __ etc? Eg latest C++ spec draft page 679 shows http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713.pdf basic_string& erase(size_type pos = 0, size_type n = npos); vs /usr/include/c++/8/bits/basic_string.h:1788 basic_string& erase(size_type __pos = 0, size_type __n = npos) I thought the __ is really reserved for compilers internal use, not for library interfaces, and it just fills the build output, I know it is only 2 bytes the __, but it adds up and makes the stl interfaces look messy.
[Bug c/78989] Missing -Waddress warning due to -Wno-system-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78989 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-03 CC||msebor at gcc dot gnu.org Summary|Missing -Waddress warning |Missing -Waddress warning ||due to -Wno-system-headers Ever confirmed|0 |1 Known to fail||6.4.0, 7.3.0, 8.2.0, 9.0 --- Comment #8 from Martin Sebor --- Confirmed there's no change in GCC 9.0.
[Bug target/88834] [SVE] Poor addressing mode choices for LD2 and ST2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834 kugan at gcc dot gnu.org changed: What|Removed |Added CC||kugan at gcc dot gnu.org --- Comment #2 from kugan at gcc dot gnu.org --- I'll assign it to myself unless it is being looked at by someone else.
[Bug c++/74765] missing uninitialized warning (parenthesis, TREE_NO_WARNING abuse)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=74765
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-02-03
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||7.3.0, 8.2.0, 9.0
--- Comment #5 from Martin Sebor ---
No change in GCC 9 so confirmed:
$ cat pr74765.C && gcc -O2 -S -Wall -Wextra -Wpedantic pr74765.C
int foo(int x, int y)
{
int i;
if ((i ==0)) return x;
return y;
}
int foo2(int x, int y)
{
int i;
if (i ==0) return x;
return y;
}
pr74765.C: In function ‘int foo2(int, int)’:
pr74765.C:11:5: warning: ‘i’ is used uninitialized in this function
[-Wuninitialized]
11 | if (i ==0) return x;
| ^~
[Bug sanitizer/85663] [9 Regression]: sanitizer fails to build on mips-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85663 Sergei Trofimovich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #13 from Sergei Trofimovich --- I didn't realize --enable-sanitizer has such an overriding effect. Having looked at top-level configure.ac I now see that similar behaviour is applied to other libraries. We'll change downstream and stop passing explicit --enable-sanitizer flag at least on mips. I'll open a new bug if gcc-9's sanitizer fails on mips. Thanks all!
[Bug c++/70180] missing -Wpointer-arith on NULL arithmetic cast to a an object type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70180 --- Comment #4 from Martin Sebor --- With -Wextra, Clang warns on one of the cases: 70180.cc:3:22: warning: performing pointer arithmetic on a null pointer has undefined behavior if the offset is nonzero [-Wnull-pointer-arithmetic] void *p = (int*)NULL + 1; ~~ ^
[Bug c++/70180] missing -Wpointer-arith on NULL arithmetic cast to a an object type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70180 Martin Sebor changed: What|Removed |Added Known to fail||4.1.3, 4.3.5, 4.4.7, 4.8.5, ||4.9.4, 5.4.0, 6.4.0, 7.3.0, ||8.2.0, 9.0 --- Comment #3 from Martin Sebor --- No improvement in GCC 9.0 with either NULL (expanded to __null) or nullptr: $ cat pr70180.C && gcc -S -Wall -Wextra -Wpedantic pr70180.C void *p = (int*)nullptr + 1; void *q = (int*)nullptr + 0; void *r = (void *)((int*)nullptr - (int*)nullptr);
[Bug c++/70181] missing -Wtautological-compare for constant expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70181
Martin Sebor changed:
What|Removed |Added
Known to fail|6.0 |6.3.0, 7.3.0, 8.2.0, 9.0
--- Comment #3 from Martin Sebor ---
No change in GCC 9.0. Clang 6.0 and later issue the following warnings:
pr70181.C:1:23: warning: self-comparison always evaluates to true
[-Wtautological-compare]
int f (int i) { if (i == i) return 1; return 0; }
^
pr70181.C:4:19: warning: self-comparison always evaluates to true
[-Wtautological-compare]
const bool b0 = i == i;
^
pr70181.C:4:12: warning: unused variable 'b0' [-Wunused-const-variable]
const bool b0 = i == i;
^
pr70181.C:7:16: warning: unused variable 'b1' [-Wunused-const-variable]
constexpr bool b1 = j == j;
^
[Bug middle-end/70125] attributes diagnostics missing essential context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70125
Martin Sebor changed:
What|Removed |Added
Component|c++ |middle-end
Known to fail||9.0
--- Comment #3 from Martin Sebor ---
No progress in GCC 9.0. This problem also isn't limited to C++. It affects
all front-ends that support attributes that take arguments. The test case in
comment #0 can be modified to illustrate the same issue in C source code:
$ cat pr70125.C && gcc -S -Wall -xc pr70125.C
void f (void*);
__attribute__ ((always_inline, artificial)) static inline
void g (int N)
{
typedef int V __attribute__ ((vector_size (N)));
V v = { 0 };
f (&v);
}
void h (void)
{
g (16);
g (31);
}
pr70125.C: In function ‘g’:
pr70125.C:6:3: warning: ‘vector_size’ attribute ignored [-Wattributes]
6 | typedef int V __attribute__ ((vector_size (N)));
| ^~~
[Bug c/69661] missing -Wsequence-point warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69661 --- Comment #3 from Martin Sebor --- Author: msebor Date: Sun Feb 3 22:47:41 2019 New Revision: 268504 URL: https://gcc.gnu.org/viewcvs?rev=268504&root=gcc&view=rev Log: PR c/69661 - missing -Wsequence-point warning gcc/testsuite.ChangeLog: * c-c++-common/Wsequence-point-2.c: New test. Added: trunk/gcc/testsuite/c-c++-common/Wsequence-point-2.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug c/69661] missing -Wsequence-point warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69661 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED CC||msebor at gcc dot gnu.org Known to work||7.3.0, 8.2.0, 9.0 Resolution|--- |FIXED Known to fail||6.4.0 --- Comment #2 from Martin Sebor --- The warning has been issued since GCC 7.1.0 as a result of r237775: r237775 | jason | 2016-06-24 17:57:13 -0400 (Fri, 24 Jun 2016) | 7 lines P0145R2: Refining Expression Order for C++ (complex LHS of =). gcc/c-common/ * c-common.c (verify_tree) [COMPOUND_EXPR]: Fix handling on LHS of MODIFY_EXPR. gcc/cp/ * typeck.c (cp_build_modify_expr): Leave COMPOUND_EXPR on LHS. Let me add a test case and resolve this as fixed.
[Bug c/67759] [4.9 only] Missing warning "makes pointer from integer without a cast" after multiline assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67759 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Martin Sebor --- I see the warning with all supported GCC releases so resolving as fixed: pr67759.c: In function ‘should_warn’: pr67759.c:18:6: warning: passing argument 1 of ‘get’ makes pointer from integer without a cast [-Wint-conversion] 18 | get(1); | ^ | | | int pr67759.c:10:17: note: expected ‘void *’ but argument is of type ‘int’ 10 | void *get(void *con) | ~~^~~
[Bug c++/66439] Diagnostic on failed function template lookup is missing a line
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66439 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-03 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||5.4.0, 6.3.0, 7.3.0, 8.2.0, ||9.0 --- Comment #2 from Martin Sebor --- Confirmed. The output is the same in GCC 9.0: pr66439.C: In function ‘void g(A::B)’: pr66439.C:12:12: error: no matching function for call to ‘f<3>(A::B&)’ 12 | C::f<3>(b); //ill-formed; argument dependent lookup |^ pr66439.C:6:26: note: candidate: ‘template void C::f(T)’ 6 | template void f(T t); | ^ pr66439.C:6:26: note: template argument deduction/substitution failed:
[Bug sanitizer/85663] [9 Regression]: sanitizer fails to build on mips-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85663 --- Comment #12 from Hans-Peter Nilsson --- (In reply to Sergei Trofimovich from comment #9) > (In reply to Hans-Peter Nilsson from comment #8) > > The report is misleading regarding version, thus I'm resetting the versions. > > For mips, sanitizer support was neither in gcc-8.0.1 nor gcc-8.1.0 nor > > gcc-8.2.0. I suppose the reporter meant "trunk after gcc-8.0.1", but is > > confused by the change in versioning scheme. > > (As was I, trying to correct the information in the report. I'm not sure I > > have it correct even now...) > > > > Reporter, please confirm or correct. > > Original bug was reported against gcc-8.1.0. Apologies for the confusion. > > gcc-8.2.0 has the same problem. Oh, I missed the --enable-libsanitizer option. You really have a *huge* list of configure options there. > With workaround it manages to build and > install asan libraries: > > > /usr/lib/gcc/mips-unknown-linux-gnu/8.2.0/include/sanitizer/asan_interface.h > /usr/lib/gcc/mips-unknown-linux-gnu/8.2.0/plugin/include/asan.h > /usr/lib/gcc/mips-unknown-linux-gnu/8.2.0/libasan.a > /usr/lib/gcc/mips-unknown-linux-gnu/8.2.0/libasan.so > /usr/lib/gcc/mips-unknown-linux-gnu/8.2.0/libasan.so.5 > /usr/lib/gcc/mips-unknown-linux-gnu/8.2.0/libasan.so.5.0.0 > /usr/lib/gcc/mips-unknown-linux-gnu/8.2.0/libasan_preinit.o > > I'm a bit confused by lack of sanitizer support. I was too, but that's (supposedly) fixed on trunk, modulo effects from later sanitizer imports. Care to try it out on a 9.0 snapshot? We can keep this PR open if you notice issues, otherwise I think it's time to close it as invalid. > I guess you mean that libsanitizer/configure.tgt has no mips entry and > should fail ./configure or silently skip sanitizer build/install. As Jakub says; by default, yes.
[Bug c/63886] float will fit into int with abs - possible missing warning Wabsolute-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63886
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||msebor at gcc dot gnu.org
Known to work||9.0
Resolution|--- |FIXED
Target Milestone|--- |9.0
Known to fail||5.4.0, 6.3.0, 7.3.0, 8.2.0
--- Comment #13 from Martin Sebor ---
Yes, thanks Eric, the request has been implemented in GCC 9 and can be resolved
as fixed.
$ cat pr63886.c && gcc -S -Wall -Wextra pr63886.c
# include
extern void g(int);
void f( float qw)
{
int n = abs(qw);
g(n);
}
pr63886.c: In function ‘f’:
pr63886.c:7:10: warning: using integer absolute value function ‘abs’ when
argument is of floating point type ‘float’ [-Wabsolute-value]
7 | int n = abs(qw);
| ^~~
[Bug middle-end/63518] missing Wuninitialized warning independent of order of arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63518 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-03 CC||msebor at gcc dot gnu.org Version|unknown |4.7.4 Ever confirmed|0 |1 --- Comment #3 from Martin Sebor --- Confirmed. Both Clang and with -O also GCC 4.7 and later warn on one of the two instances of the problem. Clang on line 15: $ clang -S -Wall pr63518.C pr63518.C:16:9: warning: variable 't' is uninitialized when used here [-Wuninitialized] wait(t, setTimeout(t)); ^ pr63518.C:15:12: note: initialize the variable 't' to silence this warning Timeout t; ^ = 0 1 warning generated. and GCC on line 23: $ gcc -O -S -Wall pr63518.C pr63518.C: In function ‘void bar()’: pr63518.C:23:9: warning: ‘t’ is used uninitialized in this function [-Wuninitialized] 23 |wait2(setTimeout(t),t); |~^
[Bug sanitizer/85663] [9 Regression]: sanitizer fails to build on mips-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85663 --- Comment #11 from Jakub Jelinek --- Ah, no, you are forcing it to ignore that through --enable-libsanitizer. Don't do that for unsupported targets.
[Bug sanitizer/85663] [9 Regression]: sanitizer fails to build on mips-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85663
--- Comment #10 from Jakub Jelinek ---
That is not really possible, as libsanitizer/configure.tgt in 8.x doesn't
support mips at all, only GCC 9 has added:
+ mips*64*-*-linux*)
+ # This clause is only here to not match the supported mips*-*-linux*.
+ UNSUPPORTED=1
+ ;;
+ mips*-*-linux*)
+ ;;
lines to libsanitizer/configure.tgt, before that it would fall through to:
*)
UNSUPPORTED=1
;;
which then means the toplevel configury doesn't build libsanitizer at all:
# Disable libsanitizer on unsupported systems.
if test -d ${srcdir}/libsanitizer; then
if test x$enable_libsanitizer = x; then
AC_MSG_CHECKING([for libsanitizer support])
if (srcdir=${srcdir}/libsanitizer; \
. ${srcdir}/configure.tgt; \
test -n "$UNSUPPORTED")
then
AC_MSG_RESULT([no])
noconfigdirs="$noconfigdirs target-libsanitizer"
else
AC_MSG_RESULT([yes])
fi
fi
fi
Of course, unless you are patching this in gcc 8.x somehow, but then you are on
your own.
[Bug c/89180] New: [meta-bug] bogus/missing -Wunused warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89180 Bug ID: 89180 Summary: [meta-bug] bogus/missing -Wunused warnings Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- This bug tracks -Wunused false negatives and positives.
[Bug ada/89178] equality for composed types failt when a component has a discriminant and redefines equality
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89178 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-03 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Curious that ACATS doesn't cover this; too obscure I presume.
[Bug c++/60212] missing warning for unused variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60212 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Known to fail||4.8.5, 4.9.4, 5.4.0, 6.4.0, ||7.3.0, 8.2.0, 9.0 --- Comment #3 from Martin Sebor --- No change in GCC 9.0.
[Bug sanitizer/85663] [9 Regression]: sanitizer fails to build on mips-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85663 --- Comment #9 from Sergei Trofimovich --- (In reply to Hans-Peter Nilsson from comment #8) > The report is misleading regarding version, thus I'm resetting the versions. > For mips, sanitizer support was neither in gcc-8.0.1 nor gcc-8.1.0 nor > gcc-8.2.0. I suppose the reporter meant "trunk after gcc-8.0.1", but is > confused by the change in versioning scheme. > (As was I, trying to correct the information in the report. I'm not sure I > have it correct even now...) > > Reporter, please confirm or correct. Original bug was reported against gcc-8.1.0. Apologies for the confusion. gcc-8.2.0 has the same problem. With workaround it manages to build and install asan libraries: /usr/lib/gcc/mips-unknown-linux-gnu/8.2.0/include/sanitizer/asan_interface.h /usr/lib/gcc/mips-unknown-linux-gnu/8.2.0/plugin/include/asan.h /usr/lib/gcc/mips-unknown-linux-gnu/8.2.0/libasan.a /usr/lib/gcc/mips-unknown-linux-gnu/8.2.0/libasan.so /usr/lib/gcc/mips-unknown-linux-gnu/8.2.0/libasan.so.5 /usr/lib/gcc/mips-unknown-linux-gnu/8.2.0/libasan.so.5.0.0 /usr/lib/gcc/mips-unknown-linux-gnu/8.2.0/libasan_preinit.o I'm a bit confused by lack of sanitizer support. I guess you mean that libsanitizer/configure.tgt has no mips entry and should fail ./configure or silently skip sanitizer build/install.
[Bug c++/46224] Enhancement: Issue warning when matching placement delete operator is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46224 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Version|unknown |4.3.0 Known to fail||4.4.7, 4.8.5, 4.9.4, 5.4.0, ||6.4.0, 7.3.0, 8.2.0, 9.0 --- Comment #4 from Martin Sebor --- No change in GCC 9.0.
[Bug c++/44648] missing -Wunused warning on a const variable in if statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44648 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Sebor --- I don't think it makes sense to keep this open just for the last missing instance in C++ 98 mode. The xfail in the test suite should be enough.
[Bug c++/44648] missing -Wunused warning on a const variable in if statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44648 --- Comment #7 from Martin Sebor --- Author: msebor Date: Sun Feb 3 21:48:27 2019 New Revision: 268503 URL: https://gcc.gnu.org/viewcvs?rev=268503&root=gcc&view=rev Log: PR c++/44648 - missing -Wunused warning on a const variable in if statement gcc/testsuite/ChangeLog: * g++.dg/warn/Wunused-var-35.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wunused-var-35.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/44648] missing -Wunused warning on a const variable in if statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44648 Martin Sebor changed: What|Removed |Added Known to work||8.2.0 --- Comment #6 from Martin Sebor --- GCC 8 and 9 diagnose all four instances in the test case in comment #5. The last one being the result of r249083 (except in C++ 98 mode where it still isn't diagnosed): r249083 | jason | 2017-06-09 18:46:51 -0400 (Fri, 09 Jun 2017) | 5 lines Don't fold conversion from a constant variable. * call.c (convert_like_real): Remove "inner" parameter. Don't replace a constant with its value. * cp-gimplify.c (cp_fully_fold): Use cp_fold_rvalue. Let me add the test to the test suite and xfailing the last case in C++ 98 mode.
[Bug sanitizer/85663] [9 Regression]: sanitizer fails to build on mips-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85663 Hans-Peter Nilsson changed: What|Removed |Added Version|8.1.0 |unknown Target Milestone|8.3 |--- Summary|[8/9 Regression] gcc-8.0.1 |[9 Regression]: sanitizer |regression: sanitizer fails |fails to build on |to build on |mips-unknown-linux-gnu |mips-unknown-linux-gnu | --- Comment #8 from Hans-Peter Nilsson --- The report is misleading regarding version, thus I'm resetting the versions. For mips, sanitizer support was neither in gcc-8.0.1 nor gcc-8.1.0 nor gcc-8.2.0. I suppose the reporter meant "trunk after gcc-8.0.1", but is confused by the change in versioning scheme. (As was I, trying to correct the information in the report. I'm not sure I have it correct even now...) Reporter, please confirm or correct.
[Bug c/16804] Function pointer assignment/initialization (missing warning)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16804 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #6 from Martin Sebor --- GCC does diagnose the initialization with -Wc++-compat so it seems that making this work as suggested is just a matter of including the same warning in -Wincompatible-pointer-types: $ gcc -S -Wc++-compat -xc z.C z.C:3:27: warning: pointer target types incompatible in C++ [-Wc++-compat] 3 | enum Moo (*Miau) (void) = quack; | ^ Even if enums are strictly compatible with unsigned the mismatch still is suggestive of a mistake on the part of the programmer and the warning would help detect it.
[Bug c++/16093] Bad error messages for missing declarations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16093 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Known to fail||4.1.0, 8.2.0, 9.0 --- Comment #8 from Martin Sebor --- No change since 2013. I suspect that if this changes it will not be in response to this report but some other change so this might as well be resolved as good enough.
[Bug c/14030] missing parameter count check ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14030 Martin Sebor changed: What|Removed |Added Known to fail|7.0 |7.3.0, 8.2.0, 9.0 --- Comment #6 from Martin Sebor --- No change in GCC 8 or 9.
[Bug fortran/84394] [7/8 Regression] compiler error when using modules with derived types in block data subprograms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84394 Thomas Koenig changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code Summary|[7/8/9 Regression] compiler |[7/8 Regression] compiler |error when using modules|error when using modules |with derived types in block |with derived types in block |data subprograms|data subprograms --- Comment #4 from Thomas Koenig --- This has been fixed in the meantime, at least there is a (double) error now: $ gfortran orig.f90 orig.f90:43:6: 43 | use mod1 | 1 Error: PRIVATE attribute not allowed in BLOCK DATA program unit at (1) orig.f90:43:6: 43 | use mod1 | 1 Error: PRIVATE attribute not allowed in BLOCK DATA program unit at (1) The error is correct, according to F2018: C1415 (R1420) A block-data specification-part shall contain only derived-type definitions and ASYNCHRONOUS, BIND, COM- MON, DATA, DIMENSION, EQUIVALENCE, IMPLICIT, INTRINSIC, PARAMETER, POINTER, SAVE, TARGET, USE, VOLATILE, and type declaration statements. So, I'd say commit a test case and close. I don't think it is worth chasing down which particular patch fixed this.
[Bug sanitizer/85663] [8/9 Regression] gcc-8.0.1 regression: sanitizer fails to build on mips-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85663
Hans-Peter Nilsson changed:
What|Removed |Added
Version|8.0.1 |8.1.0
--- Comment #7 from Hans-Peter Nilsson ---
(In reply to Jakub Jelinek from comment #6)
> Hans-Peter, any comments on this?
(In reply to Sergei Trofimovich from comment #2)
> > - FIRST_32_SECOND_64(144, 216);
> > + FIRST_32_SECOND_64(160, 216);
>
> I think mips has really 3 stat values:
> 32 ABI: 144
> n32 ABI: 160
> 64 ABI: 216
>
> $ cat a.c
> #include
> #include
> #include
>
> int main() {
> return sizeof(struct stat);
> }
This is misleading. What needs to be checked is the size of the *kernel* stat.
See https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01263.html where I fixed it
correctly and explained the issue. I'm guessing a later import unfixed it, but
I'll go check.
I'm changing the related version (8.0.1 -> 8.1.0), as from the comments it
seems obvious that this is 8.1.0 (and later, presumably?), not 8.0.1.
[Bug fortran/83700] [Meta-bug] Fortran Coarray issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700 Bug 83700 depends on bug 84848, which changed state. Bug 84848 Summary: [8/9 Regression] FAIL: gfortran.dg/coarray/event_3.f08/9 -fcoarray=single -O2 -latomic execution test https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84848 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/84848] [8/9 Regression] FAIL: gfortran.dg/coarray/event_3.f08/9 -fcoarray=single -O2 -latomic execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84848 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Uroš Bizjak --- This is fixed in r268325 by [1]. The patch was backported to all release branches. [1] https://gcc.gnu.org/ml/gcc-patches/2019-01/msg01573.html
[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179 --- Comment #12 from Vincent --- Thanks, Andrew.
[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179 --- Comment #11 from Andrew Pinski --- (In reply to Vincent from comment #10) > Yes, sorry about that. > Alas, I don't use them... https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction might be a good thing to look into.
[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179 --- Comment #10 from Vincent --- Yes, sorry about that. Alas, I don't use them...
[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179 --- Comment #9 from Andrew Pinski --- (In reply to Andrew Pinski from comment #8) > You still have not answered my question about precompiled headers? Do you > use them? If so the workaround is not to use them at all. See PR 61250 for information on random PCH bugs on darwin (it only happens on darwin).
[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179 --- Comment #8 from Andrew Pinski --- You still have not answered my question about precompiled headers? Do you use them?
[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 Thomas Koenig changed: What|Removed |Added Status|REOPENED|WAITING CC||tkoenig at gcc dot gnu.org --- Comment #9 from Thomas Koenig --- I've read the discussion, but I am not clear about what the problem actually is. Is this something that we can close now?
[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179 --- Comment #7 from Vincent --- I understand. It might have something to do with 67650, which was been in gcc since 2005, and is fully reproducible until now (8.2.0). It seems to be a memory error too. Sadly, nobody ever gave it a try.
[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179 --- Comment #6 from Andrew Pinski --- Read https://gcc.gnu.org/bugs/ . There is nothing we can help you with without any way of trying to reproduce the bug. A crash in ggc_set_mark means one of two things: * Precompiled Headers were used and there are some known issues on some hosts (like Darwin/Mac OS) * There is a bug in the compiler where we don't mark something for GC correctly.
[Bug c/89167] internal compiler error due to mpfr assert at init2.c:52
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89167 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- > warning: MPFR header version 4.0.1 differs from library version 3.1.4. That is most likely the cause. You are using the MPFR 4.0.1 headers but dynamically linking against 3.1.4. MPFR ABI has changed.
[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179 --- Comment #5 from Vincent --- Hmm, hard to do, it is monumental and contains a ton of stuff I cannot share... Sorry about that, I realize it makes diagnosis quite difficult.
[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179 --- Comment #4 from Andrew Pinski --- Can you add -save-temps and attach the preprocessed source?
[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179 --- Comment #3 from Vincent --- It on MacOS Mojave 10.14.2. The command line options are: /usr/local/bin/g++-8 -c -DNDEBUG -O3 -fvisibility=hidden -Wall -Wextra -pedantic-errors -DDARWIN -std=c++17 -fvisibility-inlines-hidden
[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179 --- Comment #2 from Andrew Pinski --- Oh what host is this on?
[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-02-03 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Can you show the command line which is this happening? Are you using Precompiled Headers?
[Bug lto/89166] -static prevents liblto_plugin to be created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89166 --- Comment #3 from Liviu Ionescu --- I tried all sort of configurations to build static executables, but I could not find one that works while building Windows binaries (with mingw) and still allow the liblto_plugin-0.dll to be created. If the subject is not appropriate, please suggest a better one, but that is the idea, building static binaries had the side effect of disabling the plugin. The current workaround I used in my build script was to make the binaries 'almost' static, except libwinpthread.dll, which I had to copy in the distribution. Far from perfect, but apparently functional. If there is a better way to do this, I'm ready to give it a try.
[Bug fortran/67679] [7/8/9 Regression] -Wunitialized reports on compiler-generated variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67679 --- Comment #7 from Thomas Koenig --- Author: tkoenig Date: Sun Feb 3 19:38:25 2019 New Revision: 268502 URL: https://gcc.gnu.org/viewcvs?rev=268502&root=gcc&view=rev Log: 2019-02-03 Thomas Koenig PR fortran/67679 * trans-array.c (gfc_array_allocate): For setting the bounds on the new array, add a condition for a not previously allocated variable. 2019-02-03 Thomas Koenig PR fortran/67679 * gfortran.dg/warn_undefined_1.f90: New test. * gfortran.dg/coarray_lock_7.f90: Fix patterns in test. Modified: trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/gfortran.dg/coarray_lock_7.f90
[Bug c++/89179] New: compiler error: in ggc_set_mark, at ggc-page.c:1532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179
Bug ID: 89179
Summary: compiler error: in ggc_set_mark, at ggc-page.c:1532
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent.lextrait at gmail dot com
Target Milestone: ---
/usr/local/Cellar/gcc/8.2.0/include/c++/8.2.0/bits/cpp_type_traits.h:420:20:
internal compiler error: in ggc_set_mark, at ggc-page.c:1532
{ return __it; }
^
Erratic, looks like an uninitialized memory read, or something of the kind.
[Bug ada/89178] New: equality for composed types failt when a component has a discriminant and redefines equality
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89178
Bug ID: 89178
Summary: equality for composed types failt when a component has
a discriminant and redefines equality
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
Assignee: unassigned at gcc dot gnu.org
Reporter: nicolas at debian dot org
Target Milestone: ---
'gnatmake p && ./p' outputs twice 'Should be TRUE: FALSE'.
with Ada.Text_IO;
procedure P is
type T (D : Integer := 0) is record
case D is
when others =>
null;
end case;
end record;
overriding function "=" (A, B : in T) return Boolean is (True);
T1 : constant T := (D => 1);
T2 : constant T := (D => 2);
type R is record
F : T;
end record;
R1 : constant R := (F => T1);
R2 : constant R := (F => T2);
type A is array (Positive range 1 .. 1) of T;
A1 : constant A := (1 => T1);
A2 : constant A := (1 => T2);
begin
Ada.Text_IO.Put_Line ("Should be TRUE: " & Boolean'Image (R1 = R2));
Ada.Text_IO.Put_Line ("Should be TRUE: " & Boolean'Image (A1 = A2));
end P;
[Bug fortran/86893] implement F202x .andthen. / .orelse. operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86893 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2019-02-03 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- > There are rumors that new "short-circuiting" operators might be part > of an upcoming F202x standard. Those could be named .andthen., .andelse., > .orelse. or similar. Alternatively one could use C-style operators (&& and > ||). Please wait for their inclusion is the standard. > Consequently the old .and. / .or. operators would be guaranteed > to *not* do short-circuiting (or only in cases where it makes no difference). Wait for the standard to draw such conclusion.
[Bug fortran/89033] gfortran accepts invalid code in select type construct with pointer assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89033 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-03 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from at least 4.8 up to trunk (9.0). Note that my understanding of the code is too shallow to confirm that its is invalid.
[Bug fortran/89030] gfortran accepts invalid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89030 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-03 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 7.3.0 up to trunk (9.0). Compiling the test with 4.9 up to 6 gives x = t(5) 1 Error: Assignment to an allocatable polymorphic variable at (1) is not yet supported
[Bug target/89071] AVX vcvtsd2ss lets us avoid PXOR dependency breaking for scalar float<->double and other scalar xmm,xmm instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89071 Uroš Bizjak changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #20 from Uroš Bizjak --- (In reply to H.J. Lu from comment #19) > > Do we need XOR for cvtsd2ss mem->xmm? > > Yes, we do since > > vcvtss2sd f(%rip), %xmm0, %xmm0 > > partially updates %xmm0. This is part of PR 87007, so let's call this PR FIXED.
[Bug target/89071] AVX vcvtsd2ss lets us avoid PXOR dependency breaking for scalar float<->double and other scalar xmm,xmm instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89071 Uroš Bizjak changed: What|Removed |Added Target Milestone|--- |9.0
[Bug fortran/88393] [7/8/9 Regression] [OOP] Segfault with type-bound assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88393 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Paul Thomas --- Fixed on all affected branches. Thanks for the report Paul
[Bug fortran/88393] [7/8/9 Regression] [OOP] Segfault with type-bound assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88393 --- Comment #7 from Paul Thomas --- Author: pault Date: Sun Feb 3 18:23:25 2019 New Revision: 268501 URL: https://gcc.gnu.org/viewcvs?rev=268501&root=gcc&view=rev Log: 2019-02-03 Paul Thomas Backport from trunk PR fortran/88393 * trans-expr.c (gfc_conv_procedure_call): For derived entities, passed in parentheses to class formals, invert the order of copying allocatable components to taking the _data of the class expression. 2019-02-03 Paul Thomas Backport from trunk PR fortran/88393 * gfortran.dg/alloc_comp_assign_16.f03 : New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/alloc_comp_assign_16.f03 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/trans-expr.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/89092] Host-associated generic used instead of use-associated TBP in call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89092 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-02-03 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from at least 4.8 up to trunk (9.0).
[Bug fortran/85953] [7 Regression] ICE in fold_convert_loc, at fold-const.c:2370
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85953 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Paul Thomas --- I agree. It will take some digging around to find out which patch fixed it :-( Thanks for the report. Paul
[Bug lto/89166] -static prevents liblto_plugin to be created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89166 --- Comment #2 from Andrew Pinski --- If you use -static in LDFLAGS, you will have other issues. What are you trying to do? This is like telling the doctor it hurts when I bend my arm the wrong way and then the doctor tells you stop doing that.
[Bug lto/89166] -static prevents liblto_plugin to be created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89166 --- Comment #1 from Liviu Ionescu --- a related bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995
[Bug target/89071] AVX vcvtsd2ss lets us avoid PXOR dependency breaking for scalar float<->double and other scalar xmm,xmm instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89071 --- Comment #19 from H.J. Lu --- (In reply to Uroš Bizjak from comment #18) > The only remaining question is on cvtsd2ss mem->xmm, where ICC goes with the > same strategy as with other non-conversion SSE unops: > >vmovsdd(%rip), %xmm0 >vcvtsd2ss %xmm0, %xmm0, %xmm0 > > but with cvtss2sd: > >vxorpd%xmm0, %xmm0, %xmm0 >vcvtss2sd f(%rip), %xmm0, %xmm0 > > Do we need XOR for cvtsd2ss mem->xmm? Yes, we do since vcvtss2sd f(%rip), %xmm0, %xmm0 partially updates %xmm0.
[Bug target/89071] AVX vcvtsd2ss lets us avoid PXOR dependency breaking for scalar float<->double and other scalar xmm,xmm instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89071 --- Comment #18 from Uroš Bizjak --- The only remaining question is on cvtsd2ss mem->xmm, where ICC goes with the same strategy as with other non-conversion SSE unops: vmovsdd(%rip), %xmm0 vcvtsd2ss %xmm0, %xmm0, %xmm0 but with cvtss2sd: vxorpd%xmm0, %xmm0, %xmm0 vcvtss2sd f(%rip), %xmm0, %xmm0 Do we need XOR for cvtsd2ss mem->xmm?
[Bug target/89071] AVX vcvtsd2ss lets us avoid PXOR dependency breaking for scalar float<->double and other scalar xmm,xmm instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89071 --- Comment #17 from uros at gcc dot gnu.org --- Author: uros Date: Sun Feb 3 16:48:41 2019 New Revision: 268496 URL: https://gcc.gnu.org/viewcvs?rev=268496&root=gcc&view=rev Log: PR target/89071 * config/i386/i386.md (*sqrt2_sse): Add (v,0) alternative. Do not prefer (v,v) alternative for non-AVX targets and (m,v) alternative for speed when TARGET_SSE_PARTIAL_REG_DEPENDENCY is set. (*rcpsf2_sse): Ditto. (*rsqrtsf2_sse): Ditto. (sse4_1_round
[Bug other/89177] New: unaligned memory access in libphobos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89177
Bug ID: 89177
Summary: unaligned memory access in libphobos
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
While bootstrapping gcc on an ARMv7 target,
I observe many kernel messages as follows, when running the testsuite:
Alignment trap: unittest_static (23723) PC=0x00e280e4 Instr=0xe893000e
Address=0x7e8100b5 FSR 0x011
disassembly of armv7l-unknown-linux-gnueabihf/libphobos/src/unittest_static
e28080: e51b30d8ldr r3, [fp, #-216] ; 0xff28
e28084: e51b2008ldr r2, [fp, #-8]
e28088: e1520003cmp r2, r3
e2808c: 2a1bbcs e28100
<_D3std6digest10murmurhash28__T11MurmurHash3Vki128Vki32Z11MurmurHash33putMFNaNbNiNfMAxhXv+0x468>
e28090: e51b20d4ldr r2, [fp, #-212] ; 0xff2c
e28094: e51b30d8ldr r3, [fp, #-216] ; 0xff28
e28098: e51b1008ldr r1, [fp, #-8]
e2809c: e1510003cmp r1, r3
e280a0: 3a08bcc e280c8
<_D3std6digest10murmurhash28__T11MurmurHash3Vki128Vki32Z11MurmurHash33putMFNaNbNiNfMAxhXv+0x430>
e280a4: e59f21b4ldr r2, [pc, #436] ; e28260
<_D3std6digest10murmurhash28__T11MurmurHash3Vki128Vki32Z11MurmurHash33putMFNaNbNiNfMAxhXv+0x5c8>
e280a8: e08f2002add r2, pc, r2
e280ac: e24b3048sub r3, fp, #72 ; 0x48
e280b0: e8920003ldm r2, {r0, r1}
e280b4: e8830003stm r3, {r0, r1}
e280b8: e3002207movwr2, #519; 0x207
e280bc: e24b3048sub r3, fp, #72 ; 0x48
e280c0: e8930003ldm r3, {r0, r1}
e280c4: eb4cef27bl 2163d68 <_d_arraybounds>
e280c8: e51b3008ldr r3, [fp, #-8]
e280cc: e1a03203lsl r3, r3, #4
e280d0: e0823003add r3, r2, r3
e280d4: e50b3018str r3, [fp, #-24] ; 0xffe8
e280d8: e51b3018ldr r3, [fp, #-24] ; 0xffe8
e280dc: e593200cldr r2, [r3, #12]
e280e0: e58d2000str r2, [sp]
e280e4: e893000eldm r3, {r1, r2, r3}
e280e8: e51b00e0ldr r0, [fp, #-224] ; 0xff20
e280ec: ebfffa47bl e26a10
<_D3std6digest10murmurhash28__T11MurmurHash3Vki128Vki32Z11MurmurHash310putElementMFNaNbNiNfG4kZv>
e280f0: e51b3008ldr r3, [fp, #-8]
e280f4: e2833001add r3, r3, #1
e280f8: e50b3008str r3, [fp, #-8]
e280fc: eadfb e28080
<_D3std6digest10murmurhash28__T11MurmurHash3Vki128Vki32Z11MurmurHash33putMFNaNbNiNfMAxhXv+0x3e8>
ldm is not able to use unaligned memory address in r3,
the kernel trap emuates the ldm and complains afterwards.
The debug info points to this which looks like invalid, casting
unaligned data to 4-byte aligned Element:
(gdb) b *0x00e280e4
Breakpoint 1 at 0xe280e4: file
../../../../gcc-9-20190127/libphobos/src/std/digest/murmurhash.d, line 521.
const numElements = data.length / Element.sizeof;
const remainderStart = numElements * Element.sizeof;
foreach (ref const Element block; cast(const(Element[]))(data[0 ..
remainderStart]))
{
putElement(block);
}
[Bug fortran/85953] [7 Regression] ICE in fold_convert_loc, at fold-const.c:2370
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85953 Thomas Koenig changed: What|Removed |Added CC||pault at gcc dot gnu.org, ||tkoenig at gcc dot gnu.org Known to work|9.0 |8.2.1 Summary|[7/8 Regression] ICE in |[7 Regression] ICE in |fold_convert_loc, at|fold_convert_loc, at |fold-const.c:2370 |fold-const.c:2370 --- Comment #6 from Thomas Koenig --- Also works on gcc-8 now. Not sure if backporting to gcc-7 is worth it. Paul, do you have plans to do this? If not, we might as well mark this as RESOLVED FIXED.
[Bug target/89071] AVX vcvtsd2ss lets us avoid PXOR dependency breaking for scalar float<->double and other scalar xmm,xmm instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89071
--- Comment #16 from Uroš Bizjak ---
(In reply to Peter Cordes from comment #15)
> (In reply to Uroš Bizjak from comment #13)
> > I assume that memory inputs are not problematic for SSE/AVX {R,}SQRT, RCP
> > and ROUND instructions. Contrary to CVTSI2S{S,D}, CVTSS2SD and CVTSD2SS, we
> > currently don't emit XOR clear in front of these instrucitons, when they
> > operate with memory input.
>
> They *do* have an output dependency. It might or might not actually be a
> problem and be worth clogging the front-end with extra uops to avoid, it
> depending on surrounding code. >.<
OK, I'll proceed with the patch from Comment #14 then.
> * CVTSS2SD vs. PD, and SD2SS vs. PD2PS
> packed is slower on k8, bdver1-4 (scalar avoids the shuffle uop),
> Nano3000, KNL. On Silvermont by just 1 cycle latency (so even a MOVAPS on
> the critical path would make it equal.) Similar on Atom. Slower on CPUs
> that do 128-bit vectors as two 64-bit uops, like Bobcat, and Pentium M / K8
> and older.
>
> packed is *faster* on K10, Goldmont/GDM Plus (same latency, 1c vs. 2c
> throughput), Prescott, P4. Much faster on Jaguar (1c vs. 8c throughput, and
> 1 uop vs. 2).
We do have infrastructure to convert scalar conversions to packed:
/* X86_TUNE_USE_VECTOR_FP_CONVERTS: Prefer vector packed SSE conversion
from FP to FP. This form of instructions avoids partial write to the
destination. */
DEF_TUNE (X86_TUNE_USE_VECTOR_FP_CONVERTS, "use_vector_fp_converts",
m_AMDFAM10)
/* X86_TUNE_USE_VECTOR_CONVERTS: Prefer vector packed SSE conversion
from integer to FP. */
DEF_TUNE (X86_TUNE_USE_VECTOR_CONVERTS, "use_vector_converts", m_AMDFAM10)
And, as can be seen from above tunes, they are currently enabled for AMDFAM10,
it is just a matter of selecting relevant tune for the selected target.
[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678 --- Comment #25 from uros at gcc dot gnu.org --- Author: uros Date: Sun Feb 3 16:21:06 2019 New Revision: 268493 URL: https://gcc.gnu.org/viewcvs?rev=268493&root=gcc&view=rev Log: 2019-02-03 Uroš Bizjak PR libfortran/88678 Revert: 2016-11-16 Szabolcs Nagy PR libfortran/78314 * config/fpu-glibc.h (support_fpu_trap): Use feenableexcept. 2019-02-03 Uroš Bizjak PR libfortran/88678 * config/fpu-glibc.h (set_fpu_trap_exceptions): Clear stalled exception flags before changing trap mode. Optimize to call feenableexcept and fedisableexcept only once. Modified: branches/gcc-7-branch/libgfortran/ChangeLog branches/gcc-7-branch/libgfortran/config/fpu-glibc.h
[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 --- Comment #21 from uros at gcc dot gnu.org --- Author: uros Date: Sun Feb 3 16:21:06 2019 New Revision: 268493 URL: https://gcc.gnu.org/viewcvs?rev=268493&root=gcc&view=rev Log: 2019-02-03 Uroš Bizjak PR libfortran/88678 Revert: 2016-11-16 Szabolcs Nagy PR libfortran/78314 * config/fpu-glibc.h (support_fpu_trap): Use feenableexcept. 2019-02-03 Uroš Bizjak PR libfortran/88678 * config/fpu-glibc.h (set_fpu_trap_exceptions): Clear stalled exception flags before changing trap mode. Optimize to call feenableexcept and fedisableexcept only once. Modified: branches/gcc-7-branch/libgfortran/ChangeLog branches/gcc-7-branch/libgfortran/config/fpu-glibc.h
[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 --- Comment #20 from uros at gcc dot gnu.org --- Author: uros Date: Sun Feb 3 16:19:36 2019 New Revision: 268492 URL: https://gcc.gnu.org/viewcvs?rev=268492&root=gcc&view=rev Log: 2019-02-03 Uroš Bizjak PR libfortran/88678 Revert: 2016-11-16 Szabolcs Nagy PR libfortran/78314 * config/fpu-glibc.h (support_fpu_trap): Use feenableexcept. 2019-02-03 Uroš Bizjak PR libfortran/88678 * config/fpu-glibc.h (set_fpu_trap_exceptions): Clear stalled exception flags before changing trap mode. Optimize to call feenableexcept and fedisableexcept only once. Modified: branches/gcc-8-branch/libgfortran/ChangeLog branches/gcc-8-branch/libgfortran/config/fpu-glibc.h
[Bug fortran/88678] [9 regression] Many gfortran.dg/ieee/ieee_X.f90 test cases fail starting with r267465
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88678 --- Comment #24 from uros at gcc dot gnu.org --- Author: uros Date: Sun Feb 3 16:19:36 2019 New Revision: 268492 URL: https://gcc.gnu.org/viewcvs?rev=268492&root=gcc&view=rev Log: 2019-02-03 Uroš Bizjak PR libfortran/88678 Revert: 2016-11-16 Szabolcs Nagy PR libfortran/78314 * config/fpu-glibc.h (support_fpu_trap): Use feenableexcept. 2019-02-03 Uroš Bizjak PR libfortran/88678 * config/fpu-glibc.h (set_fpu_trap_exceptions): Clear stalled exception flags before changing trap mode. Optimize to call feenableexcept and fedisableexcept only once. Modified: branches/gcc-8-branch/libgfortran/ChangeLog branches/gcc-8-branch/libgfortran/config/fpu-glibc.h
[Bug fortran/89174] [8/9 Regression] Allocation segfault with CLASS(*) MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||8.2.0 Keywords||wrong-code Last reconfirmed||2019-02-03 Ever confirmed|0 |1 Target Milestone|--- |8.3 Known to fail||8.2.1, 9.0 --- Comment #1 from Dominique d'Humieres --- The change occurred between revisions r264951 (2018-10-09, OK) and r265171 (2018-10-15, serrault).
[Bug tree-optimization/89176] New: Vectorizer fails to consider narrower vector width for res[i] = v1[i] < v2[i] ? v2[i] : v1[i]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89176
Bug ID: 89176
Summary: Vectorizer fails to consider narrower vector width for
res[i] = v1[i] < v2[i] ? v2[i] : v1[i]
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
[hjl@gnu-cfl-1 pr89028]$ cat 2c.i
float v1[] = { 8.3, 3.4, 8.3, 3.4, 5.8, 9.7, 5.8, 9.7, 8.3, 3.4, 8.3, 3.4 };
float v2[] = { 5.8, 9.7, 8.3, 3.4, 8.3, 3.4, 8.3, 3.4, 8.3, 3.4, 5.8, 9.7 };
float res[12];
void
foo (void)
{
int i;
for (i = 0; i < sizeof (res) / sizeof (res[0]); i++)
res[i] = v1[i] < v2[i] ? v2[i] : v1[i];
}
[hjl@gnu-cfl-1 pr89028]$ make 2c.s
/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/ -O3
-march=haswell -S 2c.i
[hjl@gnu-cfl-1 pr89028]$ cat 2c.s
.file "2c.i"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
vmovaps v2(%rip), %ymm1
vmaxps v1(%rip), %ymm1, %ymm0
vmovups %ymm0, res(%rip)
vmovss v2+32(%rip), %xmm0
vmaxss v1+32(%rip), %xmm0, %xmm0
vmovss %xmm0, res+32(%rip)
vmovss v2+36(%rip), %xmm0
vmaxss v1+36(%rip), %xmm0, %xmm0
vmovss %xmm0, res+36(%rip)
vmovss v2+40(%rip), %xmm0
vmaxss v1+40(%rip), %xmm0, %xmm0
vmovss %xmm0, res+40(%rip)
vmovss v2+44(%rip), %xmm0
vmaxss v1+44(%rip), %xmm0, %xmm0
vmovss %xmm0, res+44(%rip)
vzeroupper
ret
.cfi_endproc
We generate 4 scalar res[i] = v1[i] < v2[i] ? v2[i] : v1[i]. But this
works:
[hjl@gnu-cfl-1 pr89028]$ cat 3a.i
float v1[] = { 8.3, 3.4, 8.3, 3.4, 5.8, 9.7, 5.8, 9.7, 8.3, 3.4, 8.3, 3.4 };
float v2[] = { 5.8, 9.7, 8.3, 3.4, 8.3, 3.4, 8.3, 3.4, 8.3, 3.4, 5.8, 9.7 };
float res[12];
void
foo (void)
{
int i;
for (i = 0; i < sizeof (res) / sizeof (res[0]); i++)
res[i] = v2[i] * v1[i];
}
[hjl@gnu-cfl-1 pr89028]$ make 3a.s
/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/ -O3
-march=haswell -S 3a.i
[hjl@gnu-cfl-1 pr89028]$ cat 3a.s
.file "3a.i"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
vmovaps v2(%rip), %ymm1
vmulps v1(%rip), %ymm1, %ymm0
vmovaps v1+32(%rip), %xmm2
vmovups %ymm0, res(%rip)
vmulps v2+32(%rip), %xmm2, %xmm0
vmovaps %xmm0, res+32(%rip)
vzeroupper
ret
[Bug target/89175] New: gcc's conversion code from double to unsigned int handles overflows incorrectly on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89175
Bug ID: 89175
Summary: gcc's conversion code from double to unsigned int
handles overflows incorrectly on x86-64
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: david.monni...@univ-grenoble-alpes.fr
Target Milestone: ---
$ gcc-8 --version
gcc-8 (Ubuntu 8.2.0-1ubuntu2~18.04) 8.2.0
Compile the following:
unsigned conversion(double x) {
return (unsigned) x;
}
The compiled code performs incorrectly if the rounded value of x lies in the
range of the 'signed long long' but not in the range of 'unsigned int': it
should signal a floating-point "invalid operation" exception (as per C99 F.4)
but it does not.
Explanation:
The generated code performs the conversion using
cvttsd2siq %xmm0, %rax
which raises "invalid operation"if the result does not fit into a 64-bit signed
number.
It suggest that, unless -ffast-math or similar option is set, the result of
this conversion should be checked for being in the correct range for unsigned,
and if not, the exception should be flagged.
The following code demonstrates the issue: it should display invalid=1 but does
not (it does display invalid=1 if compiled under CompCert, which performs a
range check).
#include
#include
#include
#include
int main() {
double x = 1E10;
uint32_t u=x;
printf("x=%lf u=%" PRIu32 " %" PRIx32 " equal=%d invalid=%x\n", x, u, u,
u==x, fetestexcept(FE_INVALID | FE_OVERFLOW));
double y= 0;
y = y / y;
printf("invalid2=%x\n", fetestexcept(FE_INVALID | FE_OVERFLOW));
return 0;
}
[Bug fortran/88980] [9 regression] segfault on allocatable string member assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88980 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Paul Thomas --- Fixed on 9-branch. Although it had no effect because finalization is not implemented in this case, the fix was applied to 8-branch as well so that the testcase is included in the tree. Thanks for the report. Paul
[Bug fortran/68241] [meta-bug] [F03] Deferred-length character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68241 Bug 68241 depends on bug 88980, which changed state. Bug 88980 Summary: [9 regression] segfault on allocatable string member assignment https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88980 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/88685] [8/9 regression] pointer class array argument indexing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88685 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Paul Thomas --- Fixed on 8- and 9-branches. Thanks for the report. Paul
[Bug fortran/88393] [7/8/9 Regression] [OOP] Segfault with type-bound assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88393 --- Comment #6 from Paul Thomas --- Author: pault Date: Sun Feb 3 14:50:07 2019 New Revision: 268489 URL: https://gcc.gnu.org/viewcvs?rev=268489&root=gcc&view=rev Log: 2019-02-03 Paul Thomas Backport from trunk PR fortran/88393 * trans-expr.c (gfc_conv_procedure_call): For derived entities, passed in parentheses to class formals, invert the order of copying allocatable components to taking the _data of the class expression. 2019-02-03 Paul Thomas Backport from trunk PR fortran/88393 * gfortran.dg/alloc_comp_assign_16.f03 : New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/alloc_comp_assign_16.f03 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/trans-expr.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/88980] [9 regression] segfault on allocatable string member assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88980 --- Comment #4 from Paul Thomas --- Author: pault Date: Sun Feb 3 14:44:19 2019 New Revision: 268488 URL: https://gcc.gnu.org/viewcvs?rev=268488&root=gcc&view=rev Log: 2019-02-02 Paul Thomas Backport from trunk PR fortran/88980 * trans-array.c (gfc_array_init_size): Add element_size to the arguments. (gfc_array_allocate): Remove the recalculation of the size of the element and use element_size from the call to the above. Unconditionally set the span field of the descriptor. 2019-02-02 Paul Thomas Backport from trunk PR fortran/88980 * gfortran.dg/realloc_on_assign_32.f90 : New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/realloc_on_assign_32.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/trans-array.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
