[Bug fortran/89079] "Invalid compiler error: Segmentation fault" in module with "equivalence" statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89079 Thomas Koenig changed: What|Removed |Added Status|WAITING |RESOLVED Blocks||47030 Resolution|--- |DUPLICATE --- Comment #6 from Thomas Koenig --- OK, I think I have this figured out. What you are seeing is a result of a patch that has been applied to Cygwin, but not to the main gfortran sources. So, it is out of our scope. Specifically, this look like the patch in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47030 which was proposed (but not formally submitted) to the gfortran mailing list at https://gcc.gnu.org/ml/fortran/2018-11/msg00015.html . It was mentioned in https://gcc.gnu.org/ml/fortran/2019-01/msg00037.html that an earlier version of this patch had already been applied in Cygwin. So, I am closing this as a duplicate of 47030. We can then discuss there how to avoid this problem. *** This bug has been marked as a duplicate of bug 47030 *** Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47030 [Bug 47030] !GCC$ Attributes do not work for COMMON variables in procedures and BLOCK DATA
[Bug fortran/47030] !GCC$ Attributes do not work for COMMON variables in procedures and BLOCK DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47030 Thomas Koenig changed: What|Removed |Added Depends on||89079 CC||airplanemath at aol dot com --- Comment #12 from Thomas Koenig --- *** Bug 89079 has been marked as a duplicate of this bug. *** Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89079 [Bug 89079] "Invalid compiler error: Segmentation fault" in module with "equivalence" statement
[Bug fortran/47030] !GCC$ Attributes do not work for COMMON variables in procedures and BLOCK DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47030 Bug 47030 depends on bug 89079, which changed state. Bug 89079 Summary: "Invalid compiler error: Segmentation fault" in module with "equivalence" statement https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89079 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/47030] !GCC$ Attributes do not work for COMMON variables in procedures and BLOCK DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47030 Thomas Koenig changed: What|Removed |Added Status|WAITING |NEW
[Bug fortran/47030] !GCC$ Attributes do not work for COMMON variables in procedures and BLOCK DATA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47030 --- Comment #13 from Thomas Koenig --- The application of this patch caused PR 89079.
[Bug lto/84995] Documentation gcc-ar and gcc-ranlib vs {libdir}/bfd-plugins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84995 Liviu Ionescu changed: What|Removed |Added CC||ilg at livius dot net --- Comment #19 from Liviu Ionescu --- I'm the maintainer of GNU MCU Eclipse ARM Embedded GCC, a distribution based on Arm Embedded GCC, and I confirm that I got bitten by this issue too. FYI, Eclipse uses arm-none-eabi-ar to build static Arm libraries, and when I tried to use LTO, the result was an error like 'plugin needed to handle lto object'. The workaround was to update my distribution build scripts to copy (on Windows) or link (on Linux and macOS) the LTO plugin to lib/bfd-plugins, a local folder present in the distribution. In my oppinion, the LTO plugin should be copied to bfd-plugins by the 'make install', and not be left at the discretion of the distribution.
[Bug target/89165] miscompile calling SSE function from non-SSE code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89165 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from Jakub Jelinek --- Yeah, I don't think there is anything to do, if users ignore warnings, it is their fault, and we can't error on this.
[Bug middle-end/66459] bogus warning 'w.offset' may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66459
Thomas Koenig changed:
What|Removed |Added
Last reconfirmed|2015-06-08 00:00:00 |2019-2-3
CC||tkoenig at gcc dot gnu.org
Component|fortran |middle-end
--- Comment #4 from Thomas Koenig ---
The code that gfortran generates is correct, it is just that
the middle-end does not quite understand it and generates a
warning for it.
The -fdump-tree-original dump shows
if (*l)
{
{
[...]
w.dtype = {.elem_len=4, .rank=2, .type=1};
D.3881 = (integer(kind=8)) MAX_EXPR <*m, 0>;
D.3882 = NON_LVALUE_EXPR <__builtin_expect ((integer(kind=8))
(D.3881 == 0), 0, 46) ? 0 : __builtin_expect ((integer(kind=8))
(9223372036854775807 / D.3881 <= 0), 0, 41) ? 1 : 0>;
D.3883 = NON_LVALUE_EXPR ;
D.3884 = (integer(kind=8)) MAX_EXPR <*n, 0>;
D.3885 = (__builtin_expect ((integer(kind=8)) (D.3884 == 0), 0, 46)
? 0 : __builtin_expect ((integer(kind=8)) (9223372036854775807 / D.3884 <
D.3883), 0, 41) ? 1 : 0) + D.3882;
D.3886 = D.3883 * D.3884;
D.3887 = D.3886;
D.3888 = (__builtin_expect ((integer(kind=8)) ((unsigned long)
D.3886 > 4611686018427387903), 0, 41) ? 1 : 0) + D.3885;
D.3889 = ~NON_LVALUE_EXPR ;
if (D.3891)
{
size.0 = 0;
}
else
{
size.0 = (unsigned long) D.3886 * 4;
}
overflow.1 = D.3888;
if (__builtin_expect ((integer(kind=8)) (overflow.1 != 0), 0, 41))
{
_gfortran_runtime_error (&"Ganzzahl\xc3\xbcberlauf bei der
Berechnung des zu reservierenden Speichers"[1]{lb: 1 sz: 1});
}
else
{
if (__builtin_expect ((integer(kind=8)) (w.data != 0B), 0, 43))
{
_gfortran_runtime_error_at (&"At line 9 of file b.f"[1]{lb:
1 sz: 1}, &"Versuch, bereits reservierte Variable \xc2\xbb%s\xc2\xab zu
reservieren"[1]{lb: 1 sz: 1}, &"w"[1]{lb: 1 sz: 1});
}
else
{
w.data = (void * restrict) __builtin_malloc (MAX_EXPR
);
if (__builtin_expect ((integer(kind=8)) (w.data == 0B), 0,
42))
{
_gfortran_os_error (&"Reservierung w\xc3\xbcrde
Speichergrenze \xc3\xbcberschreiten"[1]{lb: 1 sz: 1});
}
}
}
w.dim[0].lbound = 1;
w.dim[0].ubound = (integer(kind=8)) *m;
w.dim[0].stride = 1;
w.dim[1].lbound = 1;
w.dim[1].ubound = (integer(kind=8)) *n;
w.dim[1].stride = D.3883;
w.offset = D.3889;
}
}
and then
if ((integer(kind=4)[0:] * restrict) w.data != 0B)
{
(*(integer(kind=4)[0:] * restrict) w.data)[(w.offset
+ (integer(kind=8)) i * w.dim[1].stride) + (integer(kind=8)) j] = 0;
Now, the thing is that, on leaving the if (*l) block, data has to be non-zero,
otherwise _gfortran_os_error would have been called (which is marked
with TREE_THIS_VOLATILE, hence noreturn). So, the variables
Is there something the Fortran front end can do better? If not, I think
this is better classified as a middle-end bug.
[Bug lto/89166] New: -static prevents liblto_plugin to be created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89166 Bug ID: 89166 Summary: -static prevents liblto_plugin to be created 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: --- Passing -static to the GCC configure/make prevents the LTO plugin to be properly created; the build is successful, but, for example for the Windows build, the file liblto_plugin-0.dll is not created, instead a warning is issued. For GCC executables this is not a problem, but some binutils executables also need this plugin (like ar). I think that the configure/make code for the LTO plugin should ignore the -static option (even when passed via LDFLAGS) and always build the dll/so.
[Bug debug/87295] [8 Regression][early debug] ICE with -ffat-lto-objects -fdebug-types-section -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87295 --- Comment #14 from Richard Biener --- Author: rguenth Date: Sun Feb 3 10:53:01 2019 New Revision: 268485 URL: https://gcc.gnu.org/viewcvs?rev=268485&root=gcc&view=rev Log: 2019-02-03 Richard Biener PR debug/87295 * dwarf2out.c (copy_ancestor_tree): Register non-stubs as orig. * g++.dg/debug/dwarf2/pr87295.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/pr87295.C Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug c/89167] New: internal compiler error due to mpfr assert at init2.c:52
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89167
Bug ID: 89167
Summary: internal compiler error due to mpfr assert at
init2.c:52
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: marco.maggi-ipsu at poste dot it
Target Milestone: ---
Created attachment 45593
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45593&action=edit
Preprocessed source file
On my x86_64-pc-linux-gnu, Slackware64 14.2, running a custom installation of
GCC 8.2.0, under the stock Slackware package glibc-2.23-x86_64-2_slack14.2, I
get a C compiler crash when compiling the following source:
/* demo.c */
#include
int
main (void)
{
double complexE = catan(CMPLX(0.5, 0.6));
return 0;
}
/* end of file */
with the command line:
gcc -v -save-temps -c -o demo demo.c
The package GCC is compiled with:
$ /path/to/gcc-8.2.0/configure \
--prefix=/opt/gcc/8.2.0 \
--enable-languages=fortran,c,c++ \
--disable-multilib
The output of the compiler command is:
>> gcc -v -save-temps -c -o demo demo.c
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-linux-gnu
Configured with: /home/marco/var/build/devel/gcc-8.2.0/configure
--prefix=/opt/gcc/8.2.0 --enable-languages=fortran,c,c++ --disable-multilib
Thread model: posix
gcc version 8.2.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-o' 'demo' '-mtune=generic'
'-march=x86-64'
/opt/gcc/8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/cc1 -E -quiet -v demo.c
-mtune=generic -march=x86-64 -fpch-preprocess -o demo.i
ignoring nonexistent directory
"/opt/gcc/8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/gcc/8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include
/usr/local/include
/opt/gcc/8.2.0/include
/opt/gcc/8.2.0/lib/gcc/x86_64-pc-linux-gnu/8.2.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-o' 'demo' '-mtune=generic'
'-march=x86-64'
/opt/gcc/8.2.0/libexec/gcc/x86_64-pc-linux-gnu/8.2.0/cc1 -fpreprocessed demo.i
-quiet -dumpbase demo.c -mtune=generic -march=x86-64 -auxbase-strip demo
-version -o demo.s
GNU C17 (GCC) version 8.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version none
warning: MPFR header version 4.0.1 differs from library version 3.1.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 8.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version none
warning: MPFR header version 4.0.1 differs from library version 3.1.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 142bb8855e8bf5550c1afdcffac827d9
init2.c:52: MPFR assertion failed: p >= 2 && p <=
((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
demo.c: In function 'main':
demo.c:6:42: internal compiler error: Aborted
double complex E = catan(CMPLX(0.5, 0.6));
^
0xa2861f crash_signal
/home/marco/var/build/devel/gcc-8.2.0/gcc/toplev.c:325
0x7cab90 do_mpc_arg1
/home/marco/var/build/devel/gcc-8.2.0/gcc/fold-const-call.c:346
0x7cce92 fold_const_call_cc
/home/marco/var/build/devel/gcc-8.2.0/gcc/fold-const-call.c:1032
0x7cce92 fold_const_call_1
/home/marco/var/build/devel/gcc-8.2.0/gcc/fold-const-call.c:1125
0x67c41c fold_builtin_1
/home/marco/var/build/devel/gcc-8.2.0/gcc/builtins.c:8966
0x67c41c fold_builtin_n(unsigned int, tree_node*, tree_node**, int, bool)
/home/marco/var/build/devel/gcc-8.2.0/gcc/builtins.c:9254
0x7c9cb2 fold(tree_node*)
/home/marco/var/build/devel/gcc-8.2.0/gcc/fold-const.c:11937
0x604767 c_fully_fold_internal
/home/marco/var/build/devel/gcc-8.2.0/gcc/c/c-fold.c:626
0x605d19 c_fully_fold(tree_node*, bool, bool*, bool)
/home/marco/var/build/devel/gcc-8.2.0/gcc/c/c-fold.c:125
0x5d07b7 digest_init
/home/marco/var/build/devel/gcc-8.2.0/gcc/c/c-typeck.c:7359
0x5d10e5 store_init_value(unsigned int, tree_node*, tree_node*, tree_node*)
/home/marco/var/build/devel/gcc-8.2.0/gcc/c/c-typeck.c:7150
0x5b9fbe finish_decl(tree_node*, unsigned int, tree_node*, tree_node*,
tree_node*)
/home/marco/var/build/devel/gcc-8.2.0/gcc/c/c-decl.c:4926
0x5fc972 c_parser_declaration_or_fndef
/home/marco/var/build/devel/gcc-8.2.0/gcc/c/c-parser.c:2129
0x5fc24a c_parser_compound_statement_nostart
/home/marco/var/build/devel/gcc-8.2.0/gcc/c/c-parser.c:5000
0x5fc396 c_parser_compound_statement
/home/marco/var/build/devel/gcc-8.2.0/gcc/c/c-parser.c:4912
0x5fd9e3 c_parser_declaration_or_fndef
/home/marco/var/buil
[Bug middle-end/66459] bogus warning 'w.offset' may be used uninitialized in this function [-Wmaybe-uninitialized]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66459 Marc Glisse changed: What|Removed |Added Keywords||diagnostic --- Comment #5 from Marc Glisse --- ESRA creates w$offset_132 = PHI before we read n. LIM later pulls some computations using w$offset_132 before the test on w.data, but that's not really relevant. I don't think there is anything the front-end can do about that, it seems to be purely middle-end, SRA creating exactly what uninit likes to warn about.
[Bug go/89168] New: FAIL: cmd/go/internal/load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89168
Bug ID: 89168
Summary: FAIL: cmd/go/internal/load
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: sch...@linux-m68k.org
CC: cmang at google dot com
Target Milestone: ---
Target: powerpc64-*-*
_testmain.go:9:24: error: incompatible type for field 2 in struct construction
9 | {"TestMainDeps", load.TestMainDeps},
|^
FAIL: cmd/go/internal/load
[Bug go/89169] New: FAIL: internal/cpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89169 Bug ID: 89169 Summary: FAIL: internal/cpu Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: sch...@linux-m68k.org CC: cmang at google dot com Target Milestone: --- Target: powerpc64-*-* --- FAIL: TestMinimalFeatures (0.00s) cpu_test.go:28: power8 expected true, got false --- FAIL: TestDisableAllCapabilities (0.43s) cpu_test.go:56: TestAllCapabilitiesDisabled with GODEBUG=cpu.all=off: want PASS, got FAIL FAIL FAIL: internal/cpu
[Bug go/89170] New: FAIL: net/http
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89170 Bug ID: 89170 Summary: FAIL: net/http Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: sch...@linux-m68k.org CC: cmang at google dot com Target Milestone: --- Target: powerpc64-*-* 2019/02/03 13:30:21 http: TLS handshake error from 127.0.0.1:39152: read tcp 127.0.0.1:40261->127.0.0.1:39152: use of closed network connection --- FAIL: TestServeFile (0.05s) fs_test.go:160: range="bytes=0-0,-2": part Content-Range = ""; want "bytes 0-0/11" fs_test.go:160: range="bytes=0-0,-2": part Content-Range = ""; want "bytes 9-10/11" fs_test.go:160: range="bytes=0-1,5-8": part Content-Range = ""; want "bytes 0-1/11" fs_test.go:160: range="bytes=0-1,5-8": part Content-Range = ""; want "bytes 5-8/11" fs_test.go:160: range="bytes=0-1,5-": part Content-Range = ""; want "bytes 0-1/11" fs_test.go:160: range="bytes=0-1,5-": part Content-Range = ""; want "bytes 5-10/11" FAIL FAIL: net/http
[Bug go/89171] New: FAIL: go/build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89171 Bug ID: 89171 Summary: FAIL: go/build Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: sch...@linux-m68k.org CC: cmang at google dot com Target Milestone: --- Target: riscv64-*-* --- FAIL: TestDependencies (8.67s) deps_test.go:531: unexpected dependency: debug/gcc8-8.2.1+r264010-7.1.riscv64/libgo/go/archive/tar imports [bytes errors fmt io io/ioutil math os os/user path reflect runtime sort strconv strings sync syscall time] deps_test.go:531: unexpected dependency: debug/gcc8-8.2.1+r264010-7.1.riscv64/libgo/go/archive/zip imports [bufio compress/flate encoding/binary errors fmt hash hash/crc32 io io/ioutil os path sync time unicode/utf8] deps_test.go:531: unexpected dependency: debug/gcc8-8.2.1+r264010-7.1.riscv64/libgo/go/bufio imports [bytes errors io unicode/utf8] deps_test.go:531: unexpected dependency: debug/gcc8-8.2.1+r264010-7.1.riscv64/libgo/go/bytes imports [errors io unicode unicode/utf8] deps_test.go:531: unexpected dependency: debug/gcc8-8.2.1+r264010-7.1.riscv64/libgo/go/cmd/cgo imports [bytes cmd/internal/edit cmd/internal/objabi crypto/md5 debug/dwarf debug/elf debug/macho debug/pe debug/xcoff encoding/binary errors flag fmt go/ast go/parser go/printer go/scanner go/token io io/ioutil math os os/exec path/filepath reflect runtime sort strconv strings unicode unicode/utf8] deps_test.go:531: unexpected dependency: debug/gcc8-8.2.1+r264010-7.1.riscv64/libgo/go/cmd/go imports [cmd/go/internal/base cmd/go/internal/bug cmd/go/internal/cfg cmd/go/internal/clean cmd/go/internal/doc cmd/go/internal/envcmd cmd/go/internal/fix cmd/go/internal/fmtcmd cmd/go/internal/generate cmd/go/internal/get cmd/go/internal/help cmd/go/internal/list cmd/go/internal/run cmd/go/internal/test cmd/go/internal/tool cmd/go/internal/version cmd/go/internal/vet cmd/go/internal/work flag fmt log os path/filepath runtime strings] deps_test.go:531: unexpected dependency: debug/gcc8-8.2.1+r264010-7.1.riscv64/libgo/go/cmd/go/internal/base imports [bytes cmd/go/internal/cfg cmd/go/internal/str errors flag fmt go/build go/scanner log os os/exec os/signal path/filepath runtime strings sync syscall] deps_test.go:531: unexpected dependency: debug/gcc8-8.2.1+r264010-7.1.riscv64/libgo/go/cmd/go/internal/bug imports [bytes cmd/go/internal/base cmd/go/internal/cfg cmd/go/internal/envcmd cmd/go/internal/web fmt io io/ioutil os os/exec path/filepath regexp runtime strings] deps_test.go:531: unexpected dependency: debug/gcc8-8.2.1+r264010-7.1.riscv64/libgo/go/cmd/go/internal/cache imports [bytes crypto/sha256 encoding/hex errors fmt hash io io/ioutil os path/filepath runtime strconv strings sync time] deps_test.go:531: unexpected dependency: debug/gcc8-8.2.1+r264010-7.1.riscv64/libgo/go/cmd/go/internal/cfg imports [cmd/internal/objabi fmt go/build os path/filepath runtime] deps_test.go:531: unexpected dependency: debug/gcc8-8.2.1+r264010-7.1.riscv64/libgo/go/cmd/go/internal/clean imports [cmd/go/internal/base cmd/go/internal/cache cmd/go/internal/cfg cmd/go/internal/load cmd/go/internal/work fmt io/ioutil os path/filepath strings time] deps_test.go:531: unexpected dependency: debug/gcc8-8.2.1+r264010-7.1.riscv64/libgo/go/cmd/go/internal/cmdflag imports [cmd/go/internal/base flag fmt os strconv strings] deps_test.go:531: unexpected dependency: debug/gcc8-8.2.1+r264010-7.1.riscv64/libgo/go/cmd/go/internal/doc imports [cmd/go/internal/base cmd/go/internal/cfg] deps_test.go:531: unexpected dependency: debug/gcc8-8.2.1+r264010-7.1.riscv64/libgo/go/cmd/go/internal/envcmd imports [cmd/go/internal/base cmd/go/internal/cache cmd/go/internal/cfg cmd/go/internal/load cmd/go/internal/work encoding/json fmt os runtime strings] deps_test.go:531: unexpected dependency: debug/gcc8-8.2.1+r264010-7.1.riscv64/libgo/go/cmd/go/internal/fix imports [cmd/go/internal/base cmd/go/internal/cfg cmd/go/internal/load cmd/go/internal/str] deps_test.go:531: unexpected dependency: debug/gcc8-8.2.1+r264010-7.1.riscv64/libgo/go/cmd/go/internal/fmtcmd imports [cmd/go/internal/base cmd/go/internal/cfg cmd/go/internal/load cmd/go/internal/str os path/filepath runtime strings sync] deps_test.go:531: unexpected dependency: debug/gcc8-8.2.1+r264010-7.1.riscv64/libgo/go/cmd/go/internal/generate imports [bufio bytes cmd/go/internal/base cmd/go/internal/cfg cmd/go/internal/load cmd/go/internal/work fmt io log os os/exec path/filepath regexp strconv strings] deps_test.go:531: unexpected dependency: debug/gcc8-8.2.1+r264010-7.1.riscv64/libgo/go/cmd/go/internal/get imports [bytes cmd/go/internal/base cmd/go/internal/cfg cmd/go/internal/load cmd/go/internal/str cmd/go/internal/web cmd/go/internal/work encoding/json encoding/xml errors fmt go/build inte
[Bug go/89172] New: FAIL: runtime/pprof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89172 Bug ID: 89172 Summary: FAIL: runtime/pprof Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: sch...@linux-m68k.org CC: cmang at google dot com Target Milestone: --- Target: powerpc64-*-* --- FAIL: TestEmptyCallStack (0.00s) pprof_test.go:953: got: "test18836_0 profile: total 1\n1 @ 0x104e8931\n#\t0x0\n\n" does not contain: "lostProfileEvent" FAIL FAIL: runtime/pprof
[Bug go/89173] New: FAIL: runtime/pprof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89173 Bug ID: 89173 Summary: FAIL: runtime/pprof Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: sch...@linux-m68k.org CC: cmang at google dot com Target Milestone: --- Target: riscv64-*-* --- FAIL: TestMemoryProfiler (0.75s) mprof_test.go:114: The entry did not match: 32: 1024 \[32: 1024\] @ 0x[0-9,a-f x]+ # 0x[0-9,a-f]+pprof\.allocatePersistent1K\+0x[0-9,a-f]+ .*/mprof_test\.go:40 # 0x[0-9,a-f]+runtime/pprof\.TestMemoryProfiler\+0x[0-9,a-f]+ .*/mprof_test\.go:74 Profile: heap profile: 53: 35392 [3128: 7407208] @ heap/2 4: 10752 [4: 10752] @ 0xcd5aa 0x2b4d6 0xc7ce0 0xca214 0xca214 0xce9ee 0xd132a 0x176e6 0x1799e 0x100ed2 0xc4b42 # 0x176e5 pprof.allocateTransient2M+0x1d /daten/riscv64/gcc/gcc-20190202/Build/riscv64-suse-linux/libgo/gotest9866/test/mprof_test.go:27 # 0x1799d runtime/pprof.TestMemoryProfiler+0xe9 /daten/riscv64/gcc/gcc-20190202/Build/riscv64-suse-linux/libgo/gotest9866/test/mprof_test.go:73 # 0x100ed1testing.tRunner+0x7f ../../../libgo/go/testing/testing.go:862 2: 5376 [2: 5376] @ 0xcd5aa 0x2b4d6 0xb7dce 0xb7dce 0xc3b50 0xc527a 0xc561e 0xc5918 0xc5918 0xc707c 0xc707c 0xcc204 0x2b2f0 # 0xcd5a9 runtime.allocg+0xf ../../../libgo/go/runtime/stubs.go:358 # 0x2b4d5 runtime.malg+0x1f ../../../libgo/runtime/proc.c:801 # 0xb7dcd runtime.mpreinit+0x81 ../../../libgo/go/runtime/os_gccgo.go:21 # 0xb7dcd runtime.mcommoninit+0x81 ../../../libgo/go/runtime/proc.go:607 # 0xc3b4f runtime.allocm+0xab ../../../libgo/go/runtime/proc.go:1493 # 0xc5279 runtime.newm+0x15 ../../../libgo/go/runtime/proc.go:1800 # 0xc561d runtime.startm+0xff ../../../libgo/go/runtime/proc.go:1949 # 0xc5917 runtime.wakep+0x1d ../../../libgo/go/runtime/proc.go:2030 # 0xc5917 runtime.wakep+0x1d ../../../libgo/go/runtime/proc.go:2025 # 0xc707b runtime.resetspinning+0x283 ../../../libgo/go/runtime/proc.go:2409 # 0xc707b runtime.schedule+0x283 ../../../libgo/go/runtime/proc.go:2518 # 0xcc203 runtime.mstart1+0x55 ../../../libgo/go/runtime/proc.go:1223 # 0x2b2ef runtime_mstart+0x9b ../../../libgo/runtime/proc.c:614 2: 5376 [2: 5376] @ 0xcd5aa 0x2b4d6 0xc3b5c 0xc527a 0xc561e 0xc5918 0xc5918 0xc707c 0xc707c 0xcc204 0x2b2f0 # 0xcd5a9 runtime.allocg+0xf ../../../libgo/go/runtime/stubs.go:358 # 0x2b4d5 runtime.malg+0x1f ../../../libgo/runtime/proc.c:801 # 0xc3b5b runtime.allocm+0xb7 ../../../libgo/go/runtime/proc.go:1495 # 0xc5279 runtime.newm+0x15 ../../../libgo/go/runtime/proc.go:1800 # 0xc561d runtime.startm+0xff ../../../libgo/go/runtime/proc.go:1949 # 0xc5917 runtime.wakep+0x1d ../../../libgo/go/runtime/proc.go:2030 # 0xc5917 runtime.wakep+0x1d ../../../libgo/go/runtime/proc.go:2025 # 0xc707b runtime.resetspinning+0x283 ../../../libgo/go/runtime/proc.go:2409 # 0xc707b runtime.schedule+0x283 ../../../libgo/go/runtime/proc.go:2518 # 0xcc203 runtime.mstart1+0x55 ../../../libgo/go/runtime/proc.go:1223 # 0x2b2ef runtime_mstart+0x9b ../../../libgo/runtime/proc.c:614 2: 4096 [2: 4096] @ 0xc3bd8 0xc527a 0xc561e 0xc5918 0xc5918 0xc707c 0xc707c 0xcc204 0x2b2f0 # 0xc3bd7 runtime.allocm+0x133 ../../../libgo/go/runtime/proc.go:1491 # 0xc5279 runtime.newm+0x15 ../../../libgo/go/runtime/proc.go:1800 # 0xc561d runtime.startm+0xff ../../../libgo/go/runtime/proc.go:1949 # 0xc5917 runtime.wakep+0x1d ../../../libgo/go/runtime/proc.go:2030 # 0xc5917 runtime.wakep+0x1d ../../../libgo/go/runtime/proc.go:2025 # 0xc707b runtime.resetspinning+0x283 ../../../libgo/go/runtime/proc.go:2409 # 0xc707b runtime.schedule+0x283 ../../../libgo/go/runtime/proc.go:2518 # 0xcc203 runtime.mstart1+0x55 ../../../libgo/go/runtime/proc.go:1223 # 0x2b2ef runtime_mstart+0x9b ../../../libgo/runtime/proc.c:614 1: 2688 [1: 2688] @ 0xcd5aa 0x2b4d6 0xb7dce 0xb7dce 0xc3b50 0xc527a 0xc55a0 0xc5798 0xc5798 0xc5
[Bug fortran/67679] [7/8/9 Regression] -Wunitialized reports on compiler-generated variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67679 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org
[Bug fortran/67679] [7/8/9 Regression] -Wunitialized reports on compiler-generated variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67679
--- Comment #5 from Thomas Koenig ---
This patch
Index: trans-array.c
===
--- trans-array.c (Revision 268432)
+++ trans-array.c (Arbeitskopie)
@@ -5960,19 +5960,7 @@ gfc_array_allocate (gfc_se * se, gfc_expr * expr,
}
set_descriptor = gfc_finish_block (&set_descriptor_block);
- if (status != NULL_TREE)
-{
- cond = fold_build2_loc (input_location, EQ_EXPR,
- logical_type_node, status,
- build_int_cst (TREE_TYPE (status), 0));
- gfc_add_expr_to_block (&se->pre,
-fold_build3_loc (input_location, COND_EXPR, void_type_node,
- cond,
- set_descriptor,
- build_empty_stmt (input_location)));
-}
- else
- gfc_add_expr_to_block (&se->pre, set_descriptor);
+ gfc_add_expr_to_block (&se->pre, set_descriptor);
return true;
}
gets rid of the undefined warnings, but it would also change
the array bounds after a failed allocation. Not sure if this
is standard conforming (see PR 49755).
[Bug fortran/89174] New: [8/9 Regression] Allocation segfault with CLASS(*) MOLD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174 Bug ID: 89174 Summary: [8/9 Regression] Allocation segfault with CLASS(*) MOLD Product: gcc Version: 8.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- Some relatively recent change (since ~Sept) has broken 8.2.1 and 9.0. Code that contained the type of allocation given in the following example used to work but now segfaults. module mod type :: array_data class(*), allocatable :: mold contains procedure :: push end type contains subroutine push(this, value) class(array_data), intent(inout) :: this class(*), intent(in) :: value allocate(this%mold, mold=value) ! <== SEGFAULTS HERE end subroutine end module use mod type(array_data) :: foo call foo%push(42) end This example segfaults on the current 8.2.1 and 9.0, but works on 7.3.1. Here's the output from valgrind: $ valgrind ./a.out ==18450== Memcheck, a memory error detector ==18450== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==18450== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info ==18450== Command: ./a.out ==18450== ==18450== Invalid read of size 2 ==18450==at 0x4C31618: memcpy@GLIBC_2.2.5 (vg_replace_strmem.c:1033) ==18450==by 0x400D9B: __mod_MOD_push (bug.f90:11) ==18450==by 0x400E17: MAIN__ (bug.f90:17) ==18450==by 0x400E4E: main (bug.f90:15) ==18450== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==18450== Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x5a9f7cf in ??? #1 0x4c31618 in _vgr20181ZZ_libcZdsoZa_memcpyZAGLIBCZu2Zd2Zd5 at ../shared/vg_replace_strmem.c:1033 #2 0x400d9b in ??? #3 0x400e17 in ??? #4 0x400e4e in ??? #5 0x5a8bfe9 in ??? #6 0x400699 in ??? #7 0x in ??? ==18450== ==18450== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==18450==at 0x5A9F72E: raise (in /usr/lib64/libc-2.26.so) ==18450==by 0x5A9F7CF: ??? (in /usr/lib64/libc-2.26.so) ==18450==by 0x4C31617: memcpy@GLIBC_2.2.5 (vg_replace_strmem.c:1033) ==18450==by 0x400D9B: __mod_MOD_push (bug.f90:11) ==18450==by 0x400E17: MAIN__ (bug.f90:17) ==18450==by 0x400E4E: main (bug.f90:15)
[Bug fortran/67679] [7/8/9 Regression] -Wunitialized reports on compiler-generated variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67679 --- Comment #6 from Thomas Koenig --- (In reply to Thomas Koenig from comment #5) > Not sure if this > is standard conforming (see PR 49755). Actually, it's not.
[Bug fortran/88685] [8/9 regression] pointer class array argument indexing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88685 --- Comment #7 from Paul Thomas --- Author: pault Date: Sun Feb 3 14:37:08 2019 New Revision: 268486 URL: https://gcc.gnu.org/viewcvs?rev=268486&root=gcc&view=rev Log: 2019-02-02 Paul Thomas PR fortran/88685 * expr.c (is_subref_array): Move the check for class pointer dummy arrays to after the reference check. If we haven't seen an array reference other than an element and a component is not class or derived, return false. 2019-02-02 Paul Thomas PR fortran/88685 * gfortran.dg/pointer_array_component_3.f90 : New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pointer_array_component_3.f90 Modified: branches/gcc-8-branch/gcc/fortran/expr.c
[Bug fortran/88685] [8/9 regression] pointer class array argument indexing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88685 --- Comment #8 from Paul Thomas --- Author: pault Date: Sun Feb 3 14:40:17 2019 New Revision: 268487 URL: https://gcc.gnu.org/viewcvs?rev=268487&root=gcc&view=rev Log: 2019-02-03 Paul Thomas Backport from trunk PR fortran/88685 * expr.c (is_subref_array): Move the check for class pointer dummy arrays to after the reference check. If we haven't seen an array reference other than an element and a component is not class or derived, return false. 2019-02-03 Paul Thomas Backport from trunk PR fortran/88685 * gfortran.dg/pointer_array_component_3.f90 : New test. Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog 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
[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/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/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 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 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 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 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 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 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 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 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/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 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 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 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 #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 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 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 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 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/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/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 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 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 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 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/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 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 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 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 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 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 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 --- 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 #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 #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/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 #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++/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 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 #8 from Andrew Pinski --- You still have not answered my question about precompiled headers? Do you 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 #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 #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 #12 from Vincent --- Thanks, Andrew.
[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 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/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 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 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/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 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++/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 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 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++/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 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++/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 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/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 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 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 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 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 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++/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 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/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/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 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++/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 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++/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; ~~ ^
