[Bug rtl-optimization/57003] [4.8/4.9/5.0 Regression] gcc breaks -O2 optimization with Wine(64) - links/info/bisect of commits included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57003 --- Comment #29 from uros at gcc dot gnu.org --- Author: uros Date: Thu Oct 9 06:36:08 2014 New Revision: 216026 URL: https://gcc.gnu.org/viewcvs?rev=216026&root=gcc&view=rev Log: PR rtl-optimization/57003 * regcprop.c (copyprop_hardreg_forward_1): If ksvd.ignore_set_reg, also check CALL_INSN_FUNCTION_USAGE for clobbers again after killing regs_invalidated_by_call. Modified: trunk/gcc/ChangeLog trunk/gcc/regcprop.c
[Bug c/63495] New: struct __attribute__ ((aligned (8))) broken on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63495
Bug ID: 63495
Summary: struct __attribute__ ((aligned (8))) broken on x86
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: eggert at gnu dot org
Compile and run the following two-line program with an x86 target:
struct __attribute__ ((aligned (8))) s { char c; };
_Static_assert (_Alignof (struct s) >= 8, "wrong alignment");
This should compile, but here are the symptoms I observe with GCC 4.9.1:
$ gcc -m32 t.c
t.c:2:1: error: static assertion failed: "wrong alignment"
_Static_assert (_Alignof (struct s) >= 8, "wrong alignment");
^
On the buggy platform the structure's alignment is 4; it should be 8.
The program compiles fine with GCC 4.8.3, so there is a regression here. The
program also compiles fine on x86-64.
The alignment bug breaks the trunk version of GNU Emacs when built on a 32-bit
platform; see
. I'll
try to fix Emacs to work around the bug, but the GCC bug really should get
fixed.
gcc 4.9.1 Bug or not
The attachment is a piece of C code.
When compile it with -O2 option, a segfault occurs:
##
root@qemux86-64:~# gcc -o test test.c
root@qemux86-64:~# ./test
192.168.1.1
root@qemux86-64:~#
root@qemux86-64:~# gcc -O2 -o test test.c
root@qemux86-64:~# ./test
test[893]: segfault at 0 ip 00400944 sp 7fff87c8f0f0 error 4
in test[40+1000]
Segmentation fault
root@qemux86-64:~#
##
I also test it on some linux distributions, it works well on all of them:
Ubuntu 12.04 x86_64:
gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
Ubuntu 14.04 x86_64:
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
Fedora 20 x86 and x86_64:
gcc version 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC)
#include
#include
#include
static int name_cmp(const char *a, const char *b)
{
/* compare strings a and b, but only upto ',' in a */
while (*a && *b && *a != ',' && *a == *b)
a++, b++;
if (!*b && (!*a || *a == ','))
return 0;
if (!*b) return 1;
if (!*a || *a == ',') return -1;
return *a - *b;
}
char *add_name(char *old, const char *add)
{
int len = strlen(add) + 2;
char *new;
char *cp;
if (old)
len += strlen(old);
new = (char *)malloc(len);
if (!new)
return NULL;
cp = old;
while (cp && *cp && name_cmp(cp, add) < 0) {
/* step cp forward over a name */
char *e = strchr(cp, ',');
if (e)
cp = e+1;
else
cp = cp + strlen(cp);
}
strncpy(new, old, cp-old);
new[cp-old] = 0;
if (cp != old && !*cp)
strcat(new, ",");
strcat(new, add);
if (cp && *cp) {
strcat(new, ",");
strcat(new, cp);
}
return new;
}
int main()
{
printf("%s\n", add_name(0,"192.168.1.1"));
return 0;
}
#include
#include
#include
static int name_cmp(const char *a, const char *b)
{
/* compare strings a and b, but only upto ',' in a */
while (*a && *b && *a != ',' && *a == *b)
a++, b++;
if (!*b && (!*a || *a == ','))
return 0;
if (!*b) return 1;
if (!*a || *a == ',') return -1;
return *a - *b;
}
char *add_name(char *old, const char *add)
{
int len = strlen(add) + 2;
char *new;
char *cp;
if (old)
len += strlen(old);
new = (char *)malloc(len);
if (!new)
return NULL;
cp = old;
while (cp && *cp && name_cmp(cp, add) < 0) {
/* step cp forward over a name */
char *e = strchr(cp, ',');
if (e)
cp = e+1;
else
cp = cp + strlen(cp);
}
strncpy(new, old, cp-old);
new[cp-old] = 0;
if (cp != old && !*cp)
strcat(new, ",");
strcat(new, add);
if (cp && *cp) {
strcat(new, ",");
strcat(new, cp);
}
return new;
}
int main()
{
printf("%s\n", add_name(0,"192.168.1.1"));
return 0;
}
[Bug fortran/63494] New: internal compiler error: Bus error, and out of memory allocating ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63494
Bug ID: 63494
Summary: internal compiler error: Bus error, and out of memory
allocating ...
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jwmwalrus at gmail dot com
With the code below I get two errors while compiling. One with the
preprocessor, and one without.
module my_lrstring
implicit none
private
save
type :: lrStringType
character(:), allocatable :: left
character(:), allocatable :: right
end type
type, public :: lrString
type(lrStringType), allocatable, private :: storage(:)
contains
procedure :: getRight
end type
contains
pure function getRight(this, left) result(right)
character(:), allocatable :: right
class(lrString), intent(IN) :: this
character(*), intent(IN) :: left
integer :: i, j
character(:), allocatable :: text
right = ''
j = INDEX(this%storage(i)%right, '{}')
text = this%storage(i)%right(j+2:)
end function
end module my_lrstring
The output I get is:
$ gfortran-5.0 -c -g -x f95-cpp-input -Dmy_lrstring=my_lrstring_dbg
my_lrstring.f90
f951: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
$ gfortran -c -g my_lrstring.f90
f951: out of memory allocating 20501133024 bytes after a total of 692224 bytes
The compiler and system information is:
$ lsb_release -rd
Description:Debian GNU/Linux testing (jessie)
Release:testing
$ gfortran-5.0 -v
Using built-in specs.
COLLECT_GCC=gfortran-5.0
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20140903-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id
--disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5.0-snap-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5.0-snap-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5.0-snap-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--disable-werror --enable-checking=yes --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.0.0 20140904 (experimental) [trunk revision 214924] (Debian
20140903-1)
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 31147
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 65536
pipe size(512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 31147
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
[Bug bootstrap/63432] [5 Regression] profiledbootstrap failure with bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432 --- Comment #22 from tejohnson at gcc dot gnu.org --- Author: tejohnson Date: Thu Oct 9 04:38:24 2014 New Revision: 216024 URL: https://gcc.gnu.org/viewcvs?rev=216024&root=gcc&view=rev Log: 2014-10-07 Teresa Johnson PR bootstrap/63432. * tree-ssa-threadupdate.c (estimated_freqs_path): New function. (ssa_fix_duplicate_block_edges): Invoke it. (mark_threaded_blocks): Make two passes to avoid ordering dependences. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-threadupdate.c
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #5 from Janne Blomqvist --- Ah, I suspected that other functions might be affected as well. Thanks for finding them. That being said, googling this issue I stumbled upon https://gcc.gnu.org/ml/gcc-patches/2011-03/msg00545.html where you fixed a similar issue for hp-ux 10, seemingly by making the driver always set _REENTRANT. Wouldn't a similar thing be the right thing to do for hp-ux 11 as well? If there are no ill effects of always enabling _REENTRANT that would help other software than just libgfortran, as well as eliminating the risk that unconditionally enabling _REENTRANT in libgfortran might break on some other target?
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #4 from dave.anglin at bell dot net --- There are more functions with this problem. The attached patch enables libgfortran to build on hpux11.11. Dave -- John David Anglindave.ang...@bell.net
[Bug go/63493] New: libgo: write power64 version of reflect.MakeFunc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63493 Bug ID: 63493 Summary: libgo: write power64 version of reflect.MakeFunc Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: ian at airs dot com CC: cmang at google dot com For efficiency, we should write a power64 version of reflect.MakeFunc. This means writing makefunc_power64be.s, makefunc_power64le.s, makefuncgo_power64be.go, and makefuncgo_power64le.go to implement the Power64 ABI calling convention, along the lines of the existing implementations for 386 and amd64. With the corresponding changes to MakeFunc, makeMethodValue, and makeValueMethod the reflect tests should continue to pass.
[Bug other/63492] New: bconfig.h or config.h for gencondmd.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63492 Bug ID: 63492 Summary: bconfig.h or config.h for gencondmd.c Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: pangbw at gmail dot com I know config.h is for program running on host machine, bconfig.h is for program running on build machine, but for gencondmd.c the case is special, it is evaluating the macros would be defined on host instead of build machine, so I think config.h should be used for gencondmd.c.
[Bug target/52941] SH Target: Add support for movco.l / movli.l atomics on SH4A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52941 --- Comment #18 from Oleg Endo --- Author: olegendo Date: Wed Oct 8 23:17:42 2014 New Revision: 216020 URL: https://gcc.gnu.org/viewcvs?rev=216020&root=gcc&view=rev Log: gcc/ Backport from mainline 2014-10-08 Oleg Endo PR target/52941 * config/sh/sync.md (atomic_exchangesi_hard, atomic_exchange_hard, atomic_fetch_si_hard, atomic_fetch__hard, atomic_fetch_nandsi_hard, atomic_fetch_nand_hard, atomic__fetchsi_hard, atomic__fetch_hard, atomic_nand_fetchsi_hard, atomic_nand_fetch_hard): Add missing set of T_REG. Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/sh/sync.md
[Bug target/52941] SH Target: Add support for movco.l / movli.l atomics on SH4A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52941 --- Comment #17 from Oleg Endo --- Author: olegendo Date: Wed Oct 8 23:15:44 2014 New Revision: 216019 URL: https://gcc.gnu.org/viewcvs?rev=216019&root=gcc&view=rev Log: gcc/ Backport from mainline 2014-10-08 Oleg Endo PR target/52941 * config/sh/sync.md (atomic_exchangesi_hard, atomic_exchange_hard, atomic_fetch_si_hard, atomic_fetch__hard, atomic_fetch_nandsi_hard, atomic_fetch_nand_hard, atomic__fetchsi_hard, atomic__fetch_hard, atomic_nand_fetchsi_hard, atomic_nand_fetch_hard): Add missing set of T_REG. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/sh/sync.md
[Bug target/52941] SH Target: Add support for movco.l / movli.l atomics on SH4A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52941 --- Comment #16 from Oleg Endo --- Author: olegendo Date: Wed Oct 8 23:13:02 2014 New Revision: 216018 URL: https://gcc.gnu.org/viewcvs?rev=216018&root=gcc&view=rev Log: gcc/ PR target/52941 * config/sh/sync.md (atomic_exchangesi_hard, atomic_exchange_hard, atomic_fetch_si_hard, atomic_fetch__hard, atomic_fetch_nandsi_hard, atomic_fetch_nand_hard, atomic__fetchsi_hard, atomic__fetch_hard, atomic_nand_fetchsi_hard, atomic_nand_fetch_hard): Add missing set of T_REG. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sync.md
[Bug rtl-optimization/63491] Ice in LRA with simple vector test case on power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63491 Peter Bergner changed: What|Removed |Added Target||powerpc64-linux, ||powerpc64le-linux CC||meissner at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org --- Comment #1 from Peter Bergner --- CCing Vlad and Mike for their input.
[Bug rtl-optimization/63491] New: Ice in LRA with simple vector test case on power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63491
Bug ID: 63491
Summary: Ice in LRA with simple vector test case on power
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bergner at gcc dot gnu.org
The following test case causes an ICE in LRA using trunk:
[bergner@makalu-lp1 LRA]$ cat pack01.i
typedef __int128_t __attribute__((__vector_size__(16))) vector_128_t;
typedef unsigned long long scalar_64_t;
void bar (vector_128_t);
void
foo (void)
{
union {
scalar_64_t i64[2];
vector_128_t v128;
} u;
u.i64[0] = 1;
u.i64[1] = 2;
bar (u.v128);
}
[bergner@makalu-lp1 LRA]$
/home/bergner/gcc/build/gcc-fsf-mainline-bootstrap-lra-debug/gcc/xgcc
-B/home/bergner/gcc/build/gcc-fsf-mainline-bootstrap-lra-debug/gcc/
-mcpu=power8 -O1 -S -m64 -mlra pack01.i
pack01.i: In function ‘foo’:
pack01.i:15:1: internal compiler error: in check_and_process_move, at
lra-constraints.c:1135
}
^
0x1087c5e3 check_and_process_move
/home/bergner/gcc/gcc-fsf-mainline-bootstrap-reload/gcc/lra-constraints.c:1132
0x108845d3 curr_insn_transform
/home/bergner/gcc/gcc-fsf-mainline-bootstrap-reload/gcc/lra-constraints.c:3274
0x10a3 lra_constraints(bool)
/home/bergner/gcc/gcc-fsf-mainline-bootstrap-reload/gcc/lra-constraints.c:4203
0x1086a163 lra(_IO_FILE*)
/home/bergner/gcc/gcc-fsf-mainline-bootstrap-reload/gcc/lra.c:2198
0x107ecc9b do_reload
/home/bergner/gcc/gcc-fsf-mainline-bootstrap-reload/gcc/ira.c:5311
0x107ed25f execute
/home/bergner/gcc/gcc-fsf-mainline-bootstrap-reload/gcc/ira.c:5470
The problematic rtl sequence is setting up the parameter to the call. After
IRA, we have the following rtl with pseudo 156 being allocated to hardreg
(pair) 10 (and 11).
(insn 12 5 13 2 (set (subreg:DI (reg/v:TI 156 [ u ]) 0)
(const_int 1 [0x1])) pack01.i:13 534 {*movdi_internal64}
(nil))
(insn 13 12 7 2 (set (subreg:DI (reg/v:TI 156 [ u ]) 8)
(const_int 2 [0x2])) pack01.i:13 534 {*movdi_internal64}
(nil))
(insn 7 13 8 2 (set (reg:V1TI 79 2)
(subreg:V1TI (reg/v:TI 156 [ u ]) 0)) pack01.i:14 967 {*vsx_movv1ti}
(expr_list:REG_DEAD (reg/v:TI 156 [ u ])
(nil)))
With reload (-mno-lra), we do:
Reload 1: reload_in (V1TI) = (reg:V1TI 10 10)
ALTIVEC_REGS, RELOAD_FOR_INPUT (opnum = 1), can't combine
reload_in_reg: (subreg:V1TI (reg/v:TI 10 10 [orig:156 u ] [156]) 0)
reload_reg_rtx: (reg:V1TI 79 2)
secondary_in_reload = 0
secondary_in_icode = reload_vsx_from_gprv1ti
which leads to:
(insn 12 5 13 2 (set (reg:DI 10 10 [ u ])
(const_int 1 [0x1])) pack01.i:13 534 {*movdi_internal64}
(nil))
(insn 13 12 17 2 (set (reg:DI 11 11 [orig:156 u+8 ] [156])
(const_int 2 [0x2])) pack01.i:13 534 {*movdi_internal64}
(nil))
(insn 17 13 8 2 (parallel [
(set (reg:V1TI 79 2)
(unspec:V1TI [
(reg:V1TI 10 10)
] UNSPEC_P8V_RELOAD_FROM_GPR))
(clobber (reg:TF 32 0))
]) pack01.i:14 513 {reload_vsx_from_gprv1ti}
(nil))
...and all is fine. However, with LRA (-mlra), we hit the assert in
check_and_process_move():
/* Check the target hook consistency. */
lra_assert
((secondary_class == NO_REGS && sri.icode == CODE_FOR_nothing)
|| (old_sclass == NO_REGS && old_sri.icode == CODE_FOR_nothing)
|| (secondary_class == old_sclass && sri.icode == old_sri.icode));
Due to:
(gdb) p secondary_class
$1 = NO_REGS
(gdb) p (enum insn_code) sri.icode
$2 = CODE_FOR_reload_vsx_from_gprti
(gdb) p old_sclass
$3 = NO_REGS
(gdb) p (enum insn_code) old_sri.icode
$4 = CODE_FOR_reload_vsx_from_gprv1ti
The problem seems to be that LRA is trying to use
CODE_FOR_reload_vsx_from_gprti to reload the src rather than
CODE_FOR_reload_vsx_from_gprv1ti. This is due to calling
targetm.secondary_reload() with sreg_mode (ie, TImode) rather than V1TImode
that reload is calling it with. Shouldn't we be using V1TImode since we're
accessing src via a subreg:V1TI?
I'm marking this as an rtl issue for now, since the ICE is coming from LRA, but
I know this could end up as a target bug in the end.
[Bug libstdc++/61107] stl_algo.h: std::__inplace_stable_partition() doesn't process the whole data range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61107 François Dumont changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-10-08 CC||fdumont at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |fdumont at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from François Dumont --- There is indeed a bug, thanks for the report.
[Bug c++/63405] [4.9/5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405 --- Comment #13 from Jason Merrill --- Author: jason Date: Wed Oct 8 21:06:00 2014 New Revision: 216014 URL: https://gcc.gnu.org/viewcvs?rev=216014&root=gcc&view=rev Log: PR c++/63405 * pt.c (tsubst_pack_expansion): Limit simple expansion to type packs. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/variadic162.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/pt.c
[Bug c++/63405] [4.9/5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405 --- Comment #12 from Jason Merrill --- Author: jason Date: Wed Oct 8 21:05:50 2014 New Revision: 216013 URL: https://gcc.gnu.org/viewcvs?rev=216013&root=gcc&view=rev Log: PR c++/63405 * pt.c (tsubst_pack_expansion): Limit simple expansion to type packs. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic162.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/63485] [5 Regression] ICE: canonical types differ for identical types A::type and const char_type [3]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63485 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #3 from Jason Merrill --- Fixed.
[Bug libstdc++/61217] pop_heap can't guarantee At most 2 * log(last - first) comparisons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61217 François Dumont changed: What|Removed |Added CC||fdumont at gcc dot gnu.org --- Comment #1 from François Dumont --- Rather than analysing the code I just add tests to the testsuite validating number of comparisons done for heap algos. See https://gcc.gnu.org/ml/libstdc++/2014-10/msg00058.html and there is no problem with pop_heap.
[Bug c++/63485] [5 Regression] ICE: canonical types differ for identical types A::type and const char_type [3]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63485 --- Comment #2 from Jason Merrill --- Author: jason Date: Wed Oct 8 20:27:11 2014 New Revision: 216012 URL: https://gcc.gnu.org/viewcvs?rev=216012&root=gcc&view=rev Log: PR c++/63485 * tree.c (build_cplus_array_type): Look for a type with no typedef-name or attributes. Added: trunk/gcc/testsuite/g++.dg/template/array29.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c
[Bug libquadmath/63488] large errors in y0q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63488 --- Comment #4 from Francois-Xavier Coudert --- (In reply to jos...@codesourcery.com from comment #3) > (Eventually I think we should provide _Float128 functions directly in > glibc's libm on x86/x86_64, with the TS 18661-3 names, in which case > libquadmath could become a thin wrapper round the libm versions, on > platforms using current glibc or any other library providing the TS > 18661-3 functions.) I would love that. We could even emit those directly from the Fortran front-end, on supported targets.
[Bug target/60693] [4.8 Regression] ICE on funny memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60693 Jakub Jelinek changed: What|Removed |Added CC||pekkanie at student dot oulu.fi --- Comment #9 from Jakub Jelinek --- *** Bug 63490 has been marked as a duplicate of this bug. ***
[Bug c/63490] gcc-4.8 memcpy fails with internal compiler error: in ix86_copy_addr_to_reg, at config/i386/i386.c:21718
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63490 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 60693 ***
[Bug c/63490] New: gcc-4.8 memcpy fails with internal compiler error: in ix86_copy_addr_to_reg, at config/i386/i386.c:21718
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63490
Bug ID: 63490
Summary: gcc-4.8 memcpy fails with internal compiler error: in
ix86_copy_addr_to_reg, at config/i386/i386.c:21718
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pekkanie at student dot oulu.fi
Created attachment 33668
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33668&action=edit
Preprocessed source and precompiled *.s and *.i files
Compiling following code with gcc-4.8 produces:
#include
#include
#define SIZEOF_BUFFER 128
int main()
{
static char traceBuffer[SIZEOF_BUFFER];
memcpy((char *)0x40024000, traceBuffer, sizeof(traceBuffer));
return 0;
}
$ gcc memcpy_test.c -g -m32 -Wall -Wno-format -o memcpy.out
memcpy_test.c: In function ‘main’:
memcpy_test.c:10:8: internal compiler error: in ix86_copy_addr_to_reg, at
config/i386/i386.c:21718
memcpy((char *)0x40024000, traceBuffer, sizeof(traceBuffer));
^
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Preprocessed source stored into /tmp/ccZAYKJd.out file, please attach this to
your bugreport.
gcc version in use:
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
System:
$ lsb_release -rd
Description: Ubuntu 14.04.1 LTS
Release: 14.04
$ uname -a
Linux jeppe 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07 UTC 2014 x86_64
x86_64 x86_64 GNU/Linux
Not able to reproduce the issue with following gcc versions:
gcc version 5.0.0 20140919 (experimental) [trunk revision 215403] (Ubuntu
20140919-0ubuntu1))
gcc version 4.6.4 (Ubuntu/Linaro 4.6.4-6ubuntu2)
[Bug c++/63459] operator new and returns_nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63459 --- Comment #6 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63459 > > --- Comment #5 from Jan Hubicka --- > Hi, > does something like this make sense (I also updated the DECL_BY_REFERENCE > check. > We allow to put variable at address NULL with -fno-delete-null-pointer-checks > that IMO can let me to pass it by reference. Hmm, actually in C++ one always gets a local copy. I wonder if other languages use it, but until one is found, I guess we do not need that test. Honza
[Bug c++/63459] operator new and returns_nonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63459
--- Comment #5 from Jan Hubicka ---
Hi,
does something like this make sense (I also updated the DECL_BY_REFERENCE
check.
We allow to put variable at address NULL with -fno-delete-null-pointer-checks
that IMO can let me to pass it by reference.
Why this is not part of tree_expr_nonzero_p and vrp is not simply calling
it to set up the value ranges?
Honza
Index: tree-vrp.c
===
--- tree-vrp.c(revision 215901)
+++ tree-vrp.c(working copy)
@@ -365,6 +365,18 @@ nonnull_arg_p (const_tree arg)
if (arg == cfun->static_chain_decl)
return true;
+ /* THIS argument of method is always non-NULL. */
+ if (TREE_CODE (TREE_TYPE (current_function_decl)) == METHOD_TYPE
+ && arg == DECL_ARGUMENTS (current_function_decl))
+return true;
+
+ /* Parameters passed by invisible reference are also always non-NULL
+ unsless we explicitly allow symbol to have NULL address, that is
+ permitted by -fno-delete-null-pointer-checks. */
+ if (DECL_BY_REFERENCE (arg)
+ && flag_delete_null_pointer_checks)
+return true;
+
fntype = TREE_TYPE (current_function_decl);
for (attrs = TYPE_ATTRIBUTES (fntype); attrs; attrs = TREE_CHAIN (attrs))
{
@@ -772,7 +784,8 @@ get_value_range (const_tree var)
set_value_range_to_varying (vr);
}
else if (TREE_CODE (sym) == RESULT_DECL
- && DECL_BY_REFERENCE (sym))
+ && DECL_BY_REFERENCE (sym)
+ && flag_delete_null_pointer_checks)
set_value_range_to_nonnull (vr, TREE_TYPE (sym));
}
[Bug c++/63489] stack allocated array pointer corrupted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63489 --- Comment #2 from Jonathan Wakely --- That was pretty easily found with -fsanitize=address
[Bug c++/63489] stack allocated array pointer corrupted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63489 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- Do you have a testcase that doesn't exhibit obvious undefined behaviour that's easily pointed out with -Wall, such as dividing by uninitialized values? There's a buffer overflow here: for(int i=0; i<2; i++) invp[oldp[i]] = i; Try adding an assertion that oldp[i] is in range.
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #26 from Jan Hubicka --- > But is warning/error attribute the only thing on aliases that can hold extra > semantics info (now or in the future)? I'd say LTO symtab merging should > merge > what is mergeable, and should leave leave as separate decls with the same > asm-name what holds non-mergeable semantics on it. > Say, if you declare some function (or different, just with same asm name) with > warning attribute in one TU, with error attribute in another TU and without it > on another TU, IMHO those three decls shouldn't be merged together, you should > note in cgraph that you have aliases that have the same asm name but different > semantics and just ensure that you use the right cgraph nodes and decls in the > corresponding callers. A I tried to explain, it is currently design decision to have one declaration and one symtam node for one symbol. The one decl rule was introduced by Codesourcery (Zack) in 2003-4. He updated frontends to avoid copying and dropped code that dealt with duplicated declarations. Due to lack of sanity checking some cases remained, like this one (because at that time we did not really have proper asm name hash). There are couple open PRs since that time that was never corrected. So either we need to fix remaining cases or revisit the decision and audit backend/middleend for duplicated decls. There are cases I know that would need updating - symbol equality folding - alias analysis - Symbol table allowing many to one mapping for symtab entries. I think it would be better to avoid duplicated entries in symbol table, so we will need way to associate all declarations with a given symbol. Probably ont that big deal except for updating code that deals with changing declaration associated with the node and we need to decide what declaration control symbol's visibility. Obviously if user provide two declarations, one is static and ohter public, we either want to error or do someting sane. - we need to produce errors when user defines two different symbols of same name (currently we produce invalid asm) - anchors - Zack dropped some code from dwarf2out - Visibility in varasm - those need to follow the main declaration. I had great fun fixing effects of this on AIX I definitly found the one decl scheme somewhat restrictive, but it also makes things easier and avoids weird bugs. We could revert this decision, but that is a project. Concerning Richards plan to annotate statements with warning strings, I think we could follow same scheme as EH regions and histograms does - i.e. have on side hash table annotating statements. For IPA I am trying to convince Martin Liska to introduce symtab annotation template for me that makes it easy to add data to a symbol that is removed/duplicated along with the symbol. Cgraph has the hook API for it, but convenient C++ wrap would be great. Here I think we want something similar and convert the existing EH/histograms to it. Honza
[Bug libquadmath/63488] large errors in y0q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63488 --- Comment #3 from joseph at codesourcery dot com --- Note that libquadmath has not been updated from glibc since November 2012. So, while in the Bessel function case large errors are already known for all floating-point types in glibc, in general libquadmath bugs are quite likely to have been fixed in glibc since the last update (and testing the glibc code directly on a platform with binary128 long double may be better - AArch64, Alpha, MIPS64, S/390, SPARC are all such platforms, and the GCC Compile Farm has some of them). (It is of course possible there are some bugs specific to libquadmath, arising from the adaptation of the glibc code.) (Eventually I think we should provide _Float128 functions directly in glibc's libm on x86/x86_64, with the TS 18661-3 names, in which case libquadmath could become a thin wrapper round the libm versions, on platforms using current glibc or any other library providing the TS 18661-3 functions.)
[Bug libquadmath/55821] Release tarballs (unconditionally) install libquadmath.info when libquadmath is not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55821 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-08 CC||fxcoudert at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Francois-Xavier Coudert --- Would this work? Gerald, can you try it? Index: Makefile.am === --- Makefile.am(revision 215645) +++ Makefile.am(working copy) @@ -158,6 +158,8 @@ libquadmath.info: $(STAMP_BUILD_INFO) # the relative path from the current `Makefile.am' to `texinfo.tex'. TEXINFO_TEX = ../gcc/doc/include/texinfo.tex +if BUILD_LIBQUADMATH + # Defines info, dvi, pdf and html targets MAKEINFOFLAGS = -I $(srcdir)/../gcc/doc/include info_TEXINFOS = libquadmath.texi @@ -165,3 +167,5 @@ libquadmath_TEXINFOS = libquadmath-vers. libquadmath-vers.texi: echo "@set BUGURL $(REPORT_BUGS_TEXI)" > $@ + +endif BUILD_LIBQUADMATH
[Bug target/62308] A bug with aarch64 big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62308 --- Comment #6 from Venkataramanan --- git bisect experiment showed this revision after which bug disappears. https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=215707
[Bug libquadmath/63488] large errors in y0q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63488 --- Comment #2 from Francois-Xavier Coudert --- The code in question is at libquadmath/math/j0q.c, function y0q, in the branch annotated /* 0 <= x <= 2 */ It has to do with the rational function: /* Y0(x) = 2/pi * log(x) * J0(x) + R(x^2) Peak absolute error 1.7e-36 (relative where Y0 > 1) 0 <= x <= 2 */ Coefficients are in Y0_2N and Y0_2D. It would be useful to confirm this bug in the upstream glibc's j0l(), as it probably manifests on 128-bit long double (glibc/sysdeps/ieee754/ldbl-128/e_j0l.c).
[Bug target/61981] PPC64 Linux Split-Stack Support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61981 David Edelsohn changed: What|Removed |Added Target||powerpc64-linux Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-08 Summary|PowerPC Linux Split-Stack |PPC64 Linux Split-Stack |Support |Support Ever confirmed|0 |1 --- Comment #3 from David Edelsohn --- Oka-san, thank you very much for your interest. The focus is PPC64 Linux and the ABI specifically has allocated space to support split stack. It will be more effective to utilize the POWER8 PPC64LE systems at OSUOSL for development.
[Bug c++/63489] New: stack allocated array pointer corrupted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63489 Bug ID: 63489 Summary: stack allocated array pointer corrupted Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jonathan.hogg at stfc dot ac.uk Created attachment 33667 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33667&action=edit test case The attached code, when compiled as g++ -g -O2 testcase.cxx -o testcase && ./testcase and run, produces: Try 0x7fff1cbe0a00 0x7fff1cbe0a00 Perm exit: 0 1 2 3 4 5 6 7 GO 0x7fff1cbe0a00 Try2 0x1 0x1 Segmentation fault g++ --version: g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2 Copyright (C) 2013 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The lines "Try" and "Try2" should be identical, as they refer to the same stack-allocated array perm[]. Running under valgrind is clean until the last line of ldlt_test() is encountered (which is clearly a segfault as perm is a bad pointer). Compiling without -O2 changes something, and the code crashes differently. I can supply a larger test case (from which this was created) that shuold produce meaningful answers if the code works correctly, but it will need to be provided privately for IP reasons.
[Bug libquadmath/63488] large errors in y0q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63488 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-08 Version|unknown |5.0 Ever confirmed|0 |1 --- Comment #1 from Francois-Xavier Coudert --- Confirmed on trunk. Also visible with the following Fortran source: real(kind=16), parameter :: x = 0.8935761195587725798762818805462843676_16 real(kind=16) :: y print *, bessel_y0(x) y = x ; y = bessel_y0(y) print *, y print *, (y - bessel_y0(x)) / bessel_y0(x) end which outputs: -7.44623881999333920107530266264973398E-0007 -7.44623881999333920107530266281566970E-0007 2.22845016536952266229206331898288934E-0029
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #3 from dave.anglin at bell dot net --- On 10/8/2014 9:43 AM, jb at gcc dot gnu.org wrote: > Hmm, maybe add something like > > AC_CHECK_DECLS_ONCE([ttyname_r]) > > to configure.ac and then in unix.c(stream_ttyname) check with > > #ifdef HAVE_TTYNAME_R && HAVE_DECL_TTYNAME_R Don't we want to use ttyname_r in multithreaded applications? It seems HP-UX is the only platform to hide the declaration of ttyname_r using _REENTRANT :-( If configure finds ttyname_r, then presumably we don't need pthread linking for it. On some platforms (MacOS 10.4 and Solaris 11), ttyname_r may return a 'char *', not 'int'. Dave
[Bug target/62275] ARM should use vcvta instructions when possible for float -> int rounding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62275 --- Comment #6 from Yvan Roux --- Author: yroux Date: Wed Oct 8 15:37:43 2014 New Revision: 216007 URL: https://gcc.gnu.org/viewcvs?rev=216007&root=gcc&view=rev Log: gcc/ 2014-10-08 Yvan Roux Backport from trunk r214825, r214826. 2014-09-02 Kyrylo Tkachov PR target/62275 * config/arm/neon.md (neon_vcvt ): New pattern. * config/arm/iterators.md (NEON_VCVT): New int iterator. * config/arm/arm_neon_builtins.def (vcvtav2sf, vcvtav4sf, vcvtauv2sf, vcvtauv4sf, vcvtpv2sf, vcvtpv4sf, vcvtpuv2sf, vcvtpuv4sf, vcvtmv2sf, vcvtmv4sf, vcvtmuv2sf, vcvtmuv4sf): New builtin definitions. * config/arm/arm.c (arm_builtin_vectorized_function): Handle BUILT_IN_LROUNDF, BUILT_IN_LFLOORF, BUILT_IN_LCEILF. 2014-09-02 Kyrylo Tkachov PR target/62275 * config/arm/iterators.md (FIXUORS): New code iterator. (VCVT): New int iterator. (su_optab): New code attribute. (su): Likewise. * config/arm/vfp.md (lsi2): New pattern. gcc/testsuite/ 2014-10-08 Yvan Roux Backport from trunk r214825, r214826, r215085. 2014-09-09 Kyrylo Tkachov * gcc.target/arm/vect-lceilf_1.c: Make input and output arrays global and 16-byte aligned. * gcc.target/arm/vect-lfloorf_1.c: Likewise. * gcc.target/arm/vect-lroundf_1.c: Likewise. * gcc.target/arm/vect-rounding-btruncf.c: Likewise. * gcc.target/arm/vect-rounding-ceilf.c: Likewise. * gcc.target/arm/vect-rounding-floorf.c: Likewise. * gcc.target/arm/vect-rounding-roundf.c: Likewise. 2014-09-02 Kyrylo Tkachov PR target/62275 * gcc.target/arm/vect-lceilf_1.c: New test. * gcc.target/arm/vect-lfloorf_1.c: Likewise. * gcc.target/arm/vect-lroundf_1.c: Likewise. 2014-09-02 Kyrylo Tkachov PR target/62275 * gcc.target/arm/lceil-vcvt_1.c: New test. * gcc.target/arm/lfloor-vcvt_1.c: Likewise. * gcc.target/arm/lround-vcvt_1.c: Likewise. Added: branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/lceil-vcvt_1.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/lfloor-vcvt_1.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/lround-vcvt_1.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vect-lceilf_1.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vect-lfloorf_1.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vect-lroundf_1.c Modified: branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro branches/linaro/gcc-4_9-branch/gcc/config/arm/arm.c branches/linaro/gcc-4_9-branch/gcc/config/arm/arm_neon_builtins.def branches/linaro/gcc-4_9-branch/gcc/config/arm/iterators.md branches/linaro/gcc-4_9-branch/gcc/config/arm/neon.md branches/linaro/gcc-4_9-branch/gcc/config/arm/vfp.md branches/linaro/gcc-4_9-branch/gcc/testsuite/ChangeLog.linaro branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vect-rounding-btruncf.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vect-rounding-ceilf.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vect-rounding-floorf.c branches/linaro/gcc-4_9-branch/gcc/testsuite/gcc.target/arm/vect-rounding-roundf.c
[Bug libquadmath/63487] typo in documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63487 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Francois-Xavier Coudert --- Fixed on trunk.
[Bug libquadmath/63487] typo in documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63487 --- Comment #1 from Francois-Xavier Coudert --- Author: fxcoudert Date: Wed Oct 8 15:33:41 2014 New Revision: 216006 URL: https://gcc.gnu.org/viewcvs?rev=216006&root=gcc&view=rev Log: PR libquadmath/63487 * libquadmath.texi (sincosq): Fix typo. Modified: trunk/libquadmath/ChangeLog trunk/libquadmath/libquadmath.texi
[Bug target/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #11 from Uroš Bizjak ---
(In reply to Richard Biener from comment #10)
> Ok, I believe that even
>
> char * const a;
> int * const b;
>
> void foo (void)
> {
> a[1] = 1;
> b[2] = 1;
> }
>
> int bar (void)
> {
> return a && b;
> }
>
> does not reproduces the issue.
>
> $foo..ng:
> .prologue 1
> ldq $1,a($29) !literal
> ldq $2,0($1)
> ldq $1,b($29) !literal
> bis $31,$31,$31
> lda $4,1($2)
> ldq_u $3,1($2)
> ldq $5,0($1) <- this is (insn 15)
> lda $1,1($31)
> insbl $1,$4,$1
> mskbl $3,$4,$3
> bis $1,$3,$1
> stq_u $1,1($2)<- this is (insn 13)
> lda $1,1($31)
> stl $1,8($5)
> ret $31,($26),1
$foo..ng:
.prologue 1
lda $1,a # 5*movdi/7[length = 4]
ldq $2,0($1) # 6*movdi/8[length = 4]
lda $1,b # 23 *movdi/7[length = 4]
bis $31,$31,$31 # 31 nop [length = 4]
lda $4,1($2) # 9*adddi_internal/2 [length = 4]
ldq_u $3,1($2) # 8*movdi/8[length = 4]
ldq $5,0($1) # 15 *movdi/8[length = 4]
lda $1,1($31)# 22 *movqi/2[length = 4]
insbl $1,$4,$1 # 11 insbl [length = 4]
mskbl $3,$4,$3 # 10 mskxl [length = 4]
bis $1,$3,$1 # 12 iordi3/1[length = 4]
stq_u $1,1($2) # 13 *movdi/9[length = 4]
lda $1,1($31)# 21 *movsi/2[length = 4]
stl $1,8($5) # 17 *movsi/6[length = 4]
ret $31,($26),1 # 30 *return_internal[length = 4]
5: $1:DI=`a'
REG_EQUIV `a'
6: $2:DI=[$1:DI]
REG_DEAD $1:DI
23: $1:DI=`b'
REG_EQUIV `b'
31: 0
9: $4:DI=$2:DI+0x1
8: $3:DI=[$2:DI+0x1&0xfff8]
15: $5:DI=[$1:DI]
REG_DEAD $1:DI
22: $1:QI=0x1
REG_EQUIV 0x1
11: $1:DI=zero_extend($1:QI)<<$4:DI<<0x3
REG_EQUAL 0x1<<$4:DI<<0x3
10: $3:DI=!0xff<<$4:DI<<0x3&$3:DI
REG_DEAD $4:DI
12: $1:DI=$1:DI|$3:DI
REG_DEAD $3:DI
13: [$2:DI+0x1&0xfff8]=$1:DI
REG_DEAD $2:DI
REG_DEAD $1:DI
21: $1:SI=0x1
REG_EQUIV 0x1
17: [$5:DI+0x8]=$1:SI
REG_DEAD $5:DI
REG_DEAD $1:SI
30: return
29: barrier
20: NOTE_INSN_DELETED
24: NOTE_INSN_DELETED
My dumps were with -mexplicit-relocs for some reason, the above are with
-mno-explicit-relocs.
[Bug libquadmath/54012] printf crash with -lgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54012 Francois-Xavier Coudert changed: What|Removed |Added Status|WAITING |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #13 from Francois-Xavier Coudert --- No feedback in the last 2 years, works for me on x86_64-linux at -m32 and -m64, with all gcc versions from 4.6 to trunk. Closing.
[Bug libquadmath/63488] New: large errors in y0q
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63488 Bug ID: 63488 Summary: large errors in y0q Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libquadmath Assignee: unassigned at gcc dot gnu.org Reporter: zimmerma+gcc at loria dot fr For the input aa below (with 36 digits, we can recover the exact 113-bit binary value by rounding to nearest) mpfr_y0 gets the result cc (more precisely, the corresponding 113-bit binary value) which should be correctly rounded, and y0q gets the result dd which differs from 180688 ulps. aa=8.935761195587725798762818805462843676e-01 cc=-7.446238819993339201075302662649733975e-07 [MPFR] dd=-7.446238819993339201075302662815669696e-07 ulp difference = 180688.00 For other functions and one million random inputs per function, I got much smaller differences (at most 42 ulps). The compiler was gcc 4.6.3. Paul Zimmermann
[Bug libquadmath/63487] New: typo in documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63487 Bug ID: 63487 Summary: typo in documentation Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: libquadmath Assignee: unassigned at gcc dot gnu.org Reporter: zimmerma+gcc at loria dot fr on https://gcc.gnu.org/onlinedocs/libquadmath.pdf, page 7, "simulataneously" should read "simultaneously"
[Bug libquadmath/60349] Any call to expq (or libquadmath function that might possibly call expq) segfaults in mingw-gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60349 Francois-Xavier Coudert changed: What|Removed |Added Status|WAITING |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from Francois-Xavier Coudert --- This was apparently a bug in mingw itself, and was fixed a while back. I'm closing this report. Please reopen it, with added info (such as backtrace), if you still see this problem with latest mingw.
[Bug tree-optimization/63380] [5 Regression] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63380
--- Comment #3 from Richard Biener ---
Hmm. We end up with
main ()
{
int d.0_4;
int e.1_5;
int _7;
int b.7_11;
int a.8_12;
:
d.0_4 = d;
e.1_5 = 1 >> d.0_4;
e = e.1_5;
_7 = 31 / 0;
in the end. Which is caused by tail-merging (part of PRE) optimizing
:
d.0_4 = d;
e.1_5 = 1 >> d.0_4;
e = e.1_5;
if (e.1_5 <= 0)
goto ;
else
goto ;
:
goto ;
:
_7 = 31 / 0;
:
by removing bb 3 as having no side-effect appearantly (_7 is unused). It
produces
:
d.0_4 = d;
e.1_5 = 1 >> d.0_4;
e = e.1_5;
:
_7 = 31 / 0;
:
not sure how it ends up doing that (I suppose it has code to merge an
if diamond).
[Bug libquadmath/56072] info page wrongly defines M_PI_2 and M_PI_4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56072 Francois-Xavier Coudert changed: What|Removed |Added CC||e716018 at rtrtr dot com --- Comment #4 from Francois-Xavier Coudert --- *** Bug 53775 has been marked as a duplicate of this bug. ***
[Bug libquadmath/53775] Errors in libquadmath documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53775 Francois-Xavier Coudert changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Francois-Xavier Coudert --- Duplicate of 56072, has been fixed already. *** This bug has been marked as a duplicate of bug 56072 ***
[Bug lto/61969] [4.8/4.9/5 Regression] wrong code by LTO on i?86-linux-gnu (affecting trunk, 4.9.x, and 4.8.x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61969 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-10-08 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #10 from Richard Biener --- Testing it.
[Bug target/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #10 from Richard Biener ---
Ok, I believe that even
char * const a;
int * const b;
void foo (void)
{
a[1] = 1;
b[2] = 1;
}
int bar (void)
{
return a && b;
}
does not reproduces the issue.
$foo..ng:
.prologue 1
ldq $1,a($29) !literal
ldq $2,0($1)
ldq $1,b($29) !literal
bis $31,$31,$31
lda $4,1($2)
ldq_u $3,1($2)
ldq $5,0($1)
lda $1,1($31)
insbl $1,$4,$1
mskbl $3,$4,$3
bis $1,$3,$1
stq_u $1,1($2)
lda $1,1($31)
stl $1,8($5)
ret $31,($26),1
[Bug target/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #9 from Richard Biener ---
(In reply to Richard Biener from comment #8)
> How can I reproduce this? Even with -mcpu=ev4 I get
>
> $foo..ng:
> foo:
> .frame $30,0,$26,0
> $LFB0:
> .cfi_startproc
> .prologue 0
> mov $31,$2
> ldq_u $1,1($2)
> zapnot $1,253,$1
> stq_u $1,1($2)
> call_pal 0x81
>
> I configured with --target=alphaev68-linux-gnu
>
> And used -O2 -mcpu=ev4 (sounds "earliest").
>
> Note that the pointers 'a' and 'b' are likely made constant by IPA reference
> and thus loads of the pointers can validly get /u, but not loads from the
> pointers (well, we may even figure out their value is always zero...).
Indeed. From my .optimized dump:
foo ()
{
:
MEM[(char *)0B + 1B] ={v} 0;
__builtin_trap ();
> Does it "fix" the testcase if you have a function writing to a and b or
> making a and b not static?
Then I get
$foo..ng:
.prologue 1
ldq $1,a($29) !literal
ldq $2,0($1)
lda $1,1($31)
cpys $f31,$f31,$f31
lda $4,1($2)
ldq_u $3,1($2)
insbl $1,$4,$1
mskbl $3,$4,$3
bis $1,$3,$1
stq_u $1,1($2)
lda $2,1($31)
ldq $1,b($29) !literal
ldq $1,0($1)
stl $2,8($1)
ret $31,($26),1
not sure if that's correct. Adjusted testcase:
char *a;
int *b;
void foo (void)
{
a[1] = 1;
b[2] = 1;
}
int bar (void)
{
return a && b;
}
[Bug target/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483 --- Comment #8 from Richard Biener --- How can I reproduce this? Even with -mcpu=ev4 I get $foo..ng: foo: .frame $30,0,$26,0 $LFB0: .cfi_startproc .prologue 0 mov $31,$2 ldq_u $1,1($2) zapnot $1,253,$1 stq_u $1,1($2) call_pal 0x81 I configured with --target=alphaev68-linux-gnu And used -O2 -mcpu=ev4 (sounds "earliest"). Note that the pointers 'a' and 'b' are likely made constant by IPA reference and thus loads of the pointers can validly get /u, but not loads from the pointers (well, we may even figure out their value is always zero...). Does it "fix" the testcase if you have a function writing to a and b or making a and b not static?
[Bug c++/63485] [5 Regression] ICE: canonical types differ for identical types A::type and const char_type [3]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63485 Markus Trippelsdorf changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf --- Started with r214030.
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 Ian Lance Taylor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #28 from Ian Lance Taylor --- Fixed on trunk.
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 --- Comment #27 from ian at gcc dot gnu.org --- Author: ian Date: Wed Oct 8 14:03:13 2014 New Revision: 216003 URL: https://gcc.gnu.org/viewcvs?rev=216003&root=gcc&view=rev Log: PR go/60406 runtime: Check callers in can_recover if return addressdoesn't match. Also use __builtin_extract_return_address and tighten up the checks in FFI code. Fixes PR 60406. Modified: trunk/libgo/go/reflect/makefunc_ffi_c.c trunk/libgo/runtime/go-defer.c trunk/libgo/runtime/go-panic.h trunk/libgo/runtime/go-recover.c trunk/libgo/runtime/panic.c
[Bug target/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #7 from rguenther at suse dot de ---
On Wed, 8 Oct 2014, ubizjak at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
>
> --- Comment #6 from Uroš Bizjak ---
> (In reply to Richard Biener from comment #5)
> > The bug is clearly in
> >
> > "
> > > Btw, if the mem is MEM_READONLY_P how can it be part of
> > > a {un}aligned_store sequence?
> >
> > This flag is copied from the original memory operand of the store by
> > alpha_set_memflags to all memory operands in the expanded sequence."
> >
> > and thus should be fixed there. What is the "original" memory reference
> > here? It seems for the read-modify-write you should use the target MEM
> > but somehow a source MEM gets used? Or rather you should not use either
> > MEMs flags for _all_ MEMs in the sequence but properly distinguish between
> > MEMs generated for the load of the source and MEMs generated for the store
> > to the destination.
>
> No, this is wrong conclusion. I have new insight into this problem.
>
> Please consider following test:
>
> --cut here--
> static char *a;
> static int *b;
>
> void foo (void)
> {
> a[1] = 1;
> b[2] = 1;
> }
>
> int bar (void)
> {
> return a && b;
> }
> --cut here--
>
> (e.g. changing "static char *b" to "static int *b". This way, the problematic
> insn is generated as "native" read:
>
> (insn 15 14 16 2 (set (reg/f:DI 78)
> (mem/u/f/c:DI (lo_sum:DI (reg:DI 79)
> (symbol_ref:DI ("b") [flags 0x6] b>))
> [2 b+0 S8 A64])) rmw1.c:7 -1
> (nil))
>
> and this is again moved over
>
> (insn 13 12 14 2 (set (mem:DI (and:DI (plus:DI (reg/f:DI 72)
> (const_int 1 [0x1]))
> (const_int -8 [0xfff8])) [0 S8 A64])
> (reg:DI 77)) rmw1.c:6 -1
> (nil))
>
> (note that there is no "/u" suffix on the *store* of "a".)
>
> With this testcase, we have following sequence before sched1 pass:
>
> 5: r73:DI=high(`a')
> 6: r72:DI=[r73:DI+low(`a')]
> REG_DEAD r73:DI
> 7: r74:QI=0x1
> 8: r76:DI=[r72:DI+0x1&0xfff8]
> 9: r75:DI=r72:DI+0x1
>10: r76:DI=!0xff<11: r77:DI=zero_extend(r74:QI)< REG_DEAD r75:DI
> REG_DEAD r74:QI
> REG_EQUAL 0x1<12: r77:DI=r77:DI|r76:DI
> REG_DEAD r76:DI
>13: [r72:DI+0x1&0xfff8]=r77:DI
> REG_DEAD r77:DI
> REG_DEAD r72:DI
>14: r79:DI=high(`b')
>15: r78:DI=[r79:DI+low(`b')]
> REG_DEAD r79:DI
>16: r80:SI=0x1
>17: [r78:DI+0x8]=r80:SI
> REG_DEAD r80:SI
> REG_DEAD r78:DI
>
> and sched1 moves (insn 15) all the way up, past (insn 13):
>
> 5: r73:DI=high(`a')
>14: r79:DI=high(`b')
> 7: r74:QI=0x1
> 6: r72:DI=[r73:DI+low(`a')]
> REG_DEAD r73:DI
>16: r80:SI=0x1
>15: r78:DI=[r79:DI+low(`b')]
> REG_DEAD r79:DI
> 9: r75:DI=r72:DI+0x1
> 8: r76:DI=[r72:DI+0x1&0xfff8]
>11: r77:DI=zero_extend(r74:QI)< REG_DEAD r75:DI
> REG_DEAD r74:QI
> REG_EQUAL 0x1<10: r76:DI=!0xff<12: r77:DI=r77:DI|r76:DI
> REG_DEAD r76:DI
>13: [r72:DI+0x1&0xfff8]=r77:DI
> REG_DEAD r77:DI
> REG_DEAD r72:DI
>17: [r78:DI+0x8]=r80:SI
> REG_DEAD r80:SI
> REG_DEAD r78:DI
>20: NOTE_INSN_DELETED
>
> (this particular sequence won't end in a failure, but the insn shouldn't be
> moved past possibly aliasing (insn 13) anyway.
>
> Patched compiler results in:
>
> 5: r73:DI=high(`a')
> 7: r74:QI=0x1
>14: r79:DI=high(`b')
> 6: r72:DI=[r73:DI+low(`a')]
> REG_DEAD r73:DI
>16: r80:SI=0x1
> 9: r75:DI=r72:DI+0x1
> 8: r76:DI=[r72:DI+0x1&0xfff8]
>11: r77:DI=zero_extend(r74:QI)< REG_DEAD r75:DI
> REG_DEAD r74:QI
> REG_EQUAL 0x1<10: r76:DI=!0xff<12: r77:DI=r77:DI|r76:DI
> REG_DEAD r76:DI
>13: [r72:DI+0x1&0xfff8]=r77:DI
> REG_DEAD r77:DI
> REG_DEAD r72:DI
>15: r78:DI=[r79:DI+low(`b')]
> REG_DEAD r79:DI
>17: [r78:DI+0x8]=r80:SI
> REG_DEAD r80:SI
> REG_DEAD r78:DI
>
> As shown, the code further down in true_dependence_1 function blocks the move,
> since the read is detected as aliased with the preceding store involving AND
> alignment.
>
> There is nothing that can be done in target-dependant code, since the "native"
> read from "b" gets marked as "unchanging" by the generic middle-end code.
Where is that done? It looks bogus to me.
> Please reconsider the "component" setting. There is nothing that can be fixed
> in target-dependent code.
I'm not sure - copying MEM flags to all MEMs from a single source seems
possibly wrong.
[Bug c++/63486] New: Magic Statics lock guard does not include registration into atexit handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63486
Bug ID: 63486
Summary: Magic Statics lock guard does not include registration
into atexit handler
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mira.suk at centrum dot cz
void test()
{
static std::string x;
}
If I'm reading assembly right _cxa_atexit handler is not called inside lock
which could result in static variable being destructed multiple times.
Is compiled into following with -g3
|0x401312push %rbp
│
│0x401313 mov%rsp,%rbp
│
│0x401316 push %r12
│
│0x401318 push %rbx
│
|0x401319 lea0x202e10(%rip),%rax# 0x604130
<_ZGVZ4testvE1x>
│
│0x401320 movzbl (%rax),%eax
│
│0x401323 test %al,%al
│
│0x401325 jne0x401398
│
│0x401327 lea0x202e02(%rip),%rdi# 0x604130
<_ZGVZ4testvE1x>
│
│0x40132e callq 0x400c40 <__cxa_guard_acquire@plt>
│
│0x401333 test %eax,%eax
│
│0x401335 setne %al
│
│0x401338 test %al,%al
│
│0x40133a je 0x401398
│
│0x40133c mov$0x0,%r12d
│
│0x401342 lea0x202dff(%rip),%rdi# 0x604148
<_ZZ4testvE1x>
│
│0x401349 callq 0x400c20 <_ZNSsC1Ev@plt>
│
│0x40134e lea0x202ddb(%rip),%rdi# 0x604130
<_ZGVZ4testvE1x>
│
│0x401355 callq 0x400cb0 <__cxa_guard_release@plt>
│
│0x40135a lea0x202d87(%rip),%rdx# 0x6040e8
│
│0x401361 lea0x202de0(%rip),%rsi# 0x604148
<_ZZ4testvE1x>
│
│0x401368 mov0x202c81(%rip),%rax# 0x603ff0
│
│0x40136f mov%rax,%rdi
│
│0x401372 callq 0x400ef1 <__cxa_atexit(void (*)(void*),
void*, void*)>
│
│0x401377jmp0x401398
│
│0x401379mov%rax,%rbx
│
│0x40137ctest %r12b,%r12b
│
│0x40137fjne0x40138d
[Bug c++/63485] New: [5 Regression] ICE: canonical types differ for identical types A::type and const char_type [3]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63485
Bug ID: 63485
Summary: [5 Regression] ICE: canonical types differ for
identical types A::type and const
char_type [3]
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: trippels at gcc dot gnu.org
Running the Boost testsuite shows:
markus@x4 /tmp % cat date_time_format_parser.ii
template struct A
{
typedef C type;
};
template class B
{
};
template void as_literal (Range &);
template struct C
{
typedef wchar_t char_type;
const char_type on_full_year_placeholder[3];
void
on_extended_iso_date ()
{
B::type> a;
as_literal (on_full_year_placeholder);
}
};
template struct date_time_format_parser_callback : C
{
};
template struct D
{
typedef typename BaseT::char_type char_type;
char_type
parse (const char_type *, const char_type *,
typename BaseT::callback_type p3)
{
p3.on_extended_iso_date ();
}
};
struct F
{
typedef date_time_format_parser_callback callback_type;
typedef wchar_t char_type;
};
template
void
parse_format (CharT *p1, ParserT p2, CallbackT p3)
{
CharT p = p2.parse (&p, p1, p3);
}
template
void
parse_date_time_format (const CharT *, const CharT *p2,
date_time_format_parser_callback &p3)
{
D b;
parse_format (p2, b, p3);
}
template void
parse_date_time_format (const wchar_t *, const wchar_t *,
date_time_format_parser_callback &);
markus@x4 /tmp % g++ -c -w -O0 date_time_format_parser.ii
date_time_format_parser.ii: In instantiation of ‘void C<
>::on_extended_iso_date() [with
= wchar_t]’:
date_time_format_parser.ii:30:5: required from ‘D::char_type
D::parse(const char_type*, const char_type*, typename
BaseT::callback_type) [with BaseT = F; D::char_type = wchar_t; typename
BaseT::callback_type = date_time_format_parser_callback]’
date_time_format_parser.ii:42:33: required from ‘void parse_format(CharT*,
ParserT, CallbackT) [with CharT = const wchar_t; ParserT = D; CallbackT =
date_time_format_parser_callback]’
date_time_format_parser.ii:50:16: required from ‘void
parse_date_time_format(const CharT*, const CharT*,
date_time_format_parser_callback&) [with CharT = wchar_t]’
date_time_format_parser.ii:54:68: required from here
date_time_format_parser.ii:17:16: internal compiler error: canonical types
differ for identical types A::type and const char_type [3]
{aka A::type}
as_literal (on_full_year_placeholder);
^
0x6b6ebe comptypes(tree_node*, tree_node*, int)
../../gcc/gcc/cp/typeck.c:1407
0x6b4ffd structural_comptypes
../../gcc/gcc/cp/typeck.c:1341
0x6b6e77 comptypes(tree_node*, tree_node*, int)
../../gcc/gcc/cp/typeck.c:1399
0x6d1c51 ocp_convert(tree_node*, tree_node*, int, int, int)
../../gcc/gcc/cp/cvt.c:686
0x57baf8 convert_like_real
../../gcc/gcc/cp/call.c:6471
0x57832c build_over_call
../../gcc/gcc/cp/call.c:7209
0x587911 build_new_function_call(tree_node*, vec**, bool, int)
../../gcc/gcc/cp/call.c:4072
0x7060b4 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2366
0x5fb7c6 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:15095
0x5db9d6 tsubst_expr
../../gcc/gcc/cp/pt.c:14272
0x5dbb1f tsubst_expr
../../gcc/gcc/cp/pt.c:13683
0x5db34b tsubst_expr
../../gcc/gcc/cp/pt.c:13669
0x5dc7e0 tsubst_expr
../../gcc/gcc/cp/pt.c:13855
0x5d9a7d instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:20231
0x620192 instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:20347
0x65d4d4 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4367
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #26 from Ian Lance Taylor ---
(In reply to Dominik Vogt from comment #23)
>
> 1) We need to call __builtin_extract_return_address(retaddr) in
> __go_set_defer_retaddr() too. (On s390 (31 bit) this is necessary to remove
> the most significant bit of the address which indicates the addressing mode.)
>
> I.e.
>
> --snip--
> -g->defer->__retaddr = retaddr;
> +g->defer->__retaddr = __builtin_extract_return_addr (retaddr);
> --snip--
Will do.
> 2) The new patch does not compile for me:
>
> --
> In file included from ../../../libgo/runtime/go-check-interface.c:8:0:
> ../../../libgo/runtime/go-panic.h:43:13: error: conflicting types for
> ‘__go_makefunc_can_recover’
> extern void __go_makefunc_can_recover (void *retaddr);
> ^
> In file included from ../../../libgo/runtime/go-check-interface.c:7:0:
> ../../../libgo/runtime/runtime.h:845:9: note: previous declaration of
> ‘__go_makefunc_can_recover’ was here
> void__go_makefunc_can_recover (const void *);
> ^
> --
>
> In runtime.h, __go_makefunc_can_recover still has a "const" argument:
>
> --snip--
> -void__go_makefunc_can_recover (const void *);
> +void__go_makefunc_can_recover (void *);
> --snip--
I think that must be a local change in your tree. In my tree runtime.h does
not declare __go_makefunc_can_recover.
> 3) Couldn't this be written more efficiently by passing a flag?
>
> + /* If we are called from __go_makefunc_can_recover, then we need to
> + look one level higher. */
> + if (locs[0].function.len > 0
> + && __builtin_strcmp ((const char *) locs[0].function.str,
> +"__go_makefunc_can_recover") == 0)
>
> E.g.
>
> _Bool __go_can_recover (void *retaddr, _Bool
> called_by_makefunc_can_recover)
> {
> ...
> if (called_by_makefunc_can_recover)
> { do something }
> else
> { do something else }
> ...
> }
Yes, but I would rather do that later if it seems useful. It seems silly to
change the compiler to always pass an extra argument that will always be false.
Introducing a new function called by both __go_can_recover and
__go_makefunc_can_recover changes the stack layout depending on the compiler's
inlining choices, so must be treated with care. And it's worth remembering
that this case never ever happens outside of tests. It only happens when
somebody constructs a function using reflect.MakeFunc and then defers a call to
that function. That is a bizarre way to code and I am confident that
absolutely no real Go code does it. Making that case slightly less efficient
is not important.
> 4) With the suggested changes from 1 and 2 above:
>
> s390x (64 bit):
>
> * PASS: test/recover.go
> * the test from #4 in my earlier posting works as expected
> * my private defer/recover/panic testsuite works as expected
>
> s390 (31 bit):
>
> * PASS: test/recover.go
> * the test from #4 in my earlier posting works as expected
> * my private defer/recover/panic testsuite works as expected
Thanks for testing.
> 5) I find the assumption in the loop at the end of __go_can_recover() that
> if a caller's name begins with "__go_" that means the panic can be
> recovered, a bit hairy. Even if it is with the current libgo, an unrelated
> change elsewhere could break this logic.
I agree that it's imperfect. However, it's fairly difficult to construct a
case that causes the wrong thing to happen. No Go function can ever start with
__go. Very little code in libgo calls a function written in Go; it's easy to
find such code because it must call __go_set_closure (the defer thunks are a
special case that are known to have no closure). So it can only happen if
somebody writes a Go function that calls recover, and then passes it to C code,
and that C code names a function starting with "__go_" and then calls the Go
function. And this has to happen from a deferred function called while there
is a panic in progress. The result will be that the function called by the C
code will incorrectly recover the panic.
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #2 from Janne Blomqvist --- Hmm, maybe add something like AC_CHECK_DECLS_ONCE([ttyname_r]) to configure.ac and then in unix.c(stream_ttyname) check with #ifdef HAVE_TTYNAME_R && HAVE_DECL_TTYNAME_R
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #26 from Ville Voutilainen ---
(In reply to Jason Merrill from comment #25)
> And the ICE reduces to
>
> struct A {
> A(...);
> };
>
> int main()
> {
> volatile A a;
> volatile A a2(a);
> }
>
> which crashes from infinite recursion trying to copy a for passing to
> So, not an __is_trivially_constructible issue.
Ah, yes, my test for a construct::Ellipsis will do that.
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #25 from Jason Merrill ---
And the ICE reduces to
struct A {
A(...);
};
int main()
{
volatile A a;
volatile A a2(a);
}
which crashes from infinite recursion trying to copy a for passing to So,
not an __is_trivially_constructible issue.
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #1 from Janne Blomqvist --- Hmm, any idea how to fix it? Apparently just defining _REENTRANT globally might not be a good idea, as some systems may require linking in some other C library (libc_rt or such) then. We don't want to use the GCC -pthread flag (which should take care of necessary linking magic) either, since on systems with weakref support we want to avoid using mutexes etc. in single-threaded programs.
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #24 from Ville Voutilainen ---
(In reply to Jason Merrill from comment #23)
> (In reply to Ville Voutilainen from comment #22)
> > This test fails the static_assert for TType (which is a trivial type),
> > PODType and DelDef, and it would be expected that all those static_asserts
> > succeed.
> No:
> struct A { };
> int main()
> {
> volatile A a;
> volatile A a2(a); // ill-formed
> }
> test_category is testing whether volatile TType is trivially
> copy-constructible, and it isn't copy-constructible at all.
Argh, thanks, I'll need to make those tests saner.
> Incidentally, you don't need to test anything else before
> __is_trivially_constructible, it will just return false if the type isn't
> constructible at all. Likewise for assignable.
These library traits require that for a true-answer, the type used
must be referenceable. The 'main' traits do that, I wasn't sure whether
the intrinsic does. The 'main' traits also limit the accepted types
as per the standard, so I'm inclined to leave the general testing
approach as is. Jonathan took a quick look at it and thought it looks
ok. ;)
> Looking at the ICE.
Excellent.
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 --- Comment #25 from Ian Lance Taylor --- (In reply to Dominik Vogt from comment #22) > >> Hm, so the patch penalises platforms that cannot deal with the > >> 16 byte window? > > > Yes, but, recall that on your system almost all tests pass using the > > code that is in the tree today, before your patch. > > But they really only succeed "by accident". The call for any platform might > introduce control flow into the thunk and trigger the problem in any of the > test cases. Yes, I understand that. You suggested that my patch penalized all cases where we have a control flow problem, because it will do a more costly unwind step. That is true. However, in practice, the case arises very rarely. We know that the code in the thunk is always very simple: if (__go_set_defer_retaddr (&&L)) goto L; real_function(args); L: The compiler is not going to start randomly throwing additional control flow statements into that function. The cases where it does do that are the cases where args is very large, so that it uses a block copy to copy them onto the stack. But that essentially never happens. The args here are the args in "defer real_function(args)". 90% of the time there are no arguments at all. 9.9% of the time it's just a couple of pointer/scalar arguments. In real code nobody ever calls defer with large arguments, because it's just a strange way to write; people write a function closure instead. The only code in the standard library that calls defer with a large argument is the recover.go test, to make sure that it works. It's necessary to handle all cases correctly. But there is nothing wrong with using an efficient mechanism when it works, as long as we can correctly fall back to a more expensive mechanism when it fails. I believe that my patch does that. If you like, we can incorporate your patch too, as long as it is only an addition to the existing code. Before calling runtime_callers, we can call _Unwind_FindEnclosingFunction. Then we need only go on to the runtime_callers code if _Unwind_FindEnclosingFunction returns NULL, or in the cases where d->__makefunc_can_recover is true.
[Bug ipa/63482] [5 Regression] ICE: in gimple_get_virt_method_for_vtable, at gimple-fold.c:4857
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63482 --- Comment #1 from Markus Trippelsdorf --- Created attachment 33666 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33666&action=edit somewhat reduced testcase % g++ -c -O2 CustomReactionTest.ii CustomReactionTest.ii:536:44: internal compiler error: in gimple_get_virt_method_for_vtable, at gimple-fold.c:4857
[Bug c++/63362] The c++11 triviality-traits need front-end help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63362
--- Comment #23 from Jason Merrill ---
(In reply to Ville Voutilainen from comment #22)
> This test fails the static_assert for TType (which is a trivial type),
> PODType and DelDef, and it would be expected that all those static_asserts
> succeed.
No:
struct A { };
int main()
{
volatile A a;
volatile A a2(a); // ill-formed
}
test_category is testing whether volatile TType is trivially
copy-constructible, and it isn't copy-constructible at all.
Incidentally, you don't need to test anything else before
__is_trivially_constructible, it will just return false if the type isn't
constructible at all. Likewise for assignable.
Looking at the ICE.
[Bug c/63484] New: misleading/obsolete -fdelete-null-pointer-checks documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63484
Bug ID: 63484
Summary: misleading/obsolete -fdelete-null-pointer-checks
documentation
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent-gcc at vinc17 dot net
The current -fdelete-null-pointer-checks documentation is:
> Assume that programs cannot safely dereference null pointers, and that no
> code or data element resides there. This enables simple constant folding
> optimizations at all optimization levels. In addition, other optimization
> passes in GCC use this flag to control global dataflow analyses that
> eliminate useless checks for null pointers; these assume that if a pointer is
> checked after it has already been dereferenced, it cannot be null.
(both in the manual
https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/Optimize-Options.html#Optimize-Options
and the man page).
However a new check is done as of GCC 4.9, according to:
http://blog.mycre.ws/articles/bind-and-gcc-49/
and in particular:
https://gcc.gnu.org/gcc-4.9/porting_to.html
"GCC might now optimize away the null pointer check in code like:
int copy (int* dest, int* src, size_t nbytes) {
memmove (dest, src, nbytes);
if (src != NULL)
return *src;
return 0;
}
The pointers passed to memmove (and similar functions in ) must be
non-null even when nbytes==0, so GCC can use that information to remove the
check after the memmove call. Calling copy(p, NULL, 0) can therefore deference
a null pointer and crash."
So, this new check makes the old -fdelete-null-pointer-checks documentation
"Assume that programs cannot safely dereference null pointers, and that no code
or data element resides there." obsolete. Indeed, even though calling
memmove (dest, NULL, 0);
is invalid, it doesn't mean that the null src pointer is dereferenced by
memmove (this is not needed if nbytes is 0 like here) or that data reside
there.
Said otherwise, the developer may think "I know that no data reside at address
0, and that null pointers are never dereferenced (otherwise the program would
crash)." and deduce that the -fdelete-null-pointer-checks option is safe on his
code. However it isn't necessarily, just because of some ISO C rule that makes
some function call invalid (and many developers may not be aware of it, as this
rule is very unintuitive).
So, the documentation should be updated. Alternatively the option could be
split between one that removes checks because of code that is obviously wrong
(e.g. would yield a crash in practice on most platforms, or has semantically no
meanings) and one that removes checks because of any invalid code.
[Bug ipa/63403] [5.0 Regression] ICE: in relative_time_benefit at ipa-inline.c:869
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63403 --- Comment #5 from dave.anglin at bell dot net --- Hi Richard, On 7-Oct-14, at 2:48 PM, rsandifo at gcc dot gnu.org wrote: > Can you try the patches I posted here: > > https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02636.html > https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02637.html The patches fix the ICE and restore bootstrap on hppa-unknown-linux- gnu. c and c++ tests are running. Thanks very much, Dave -- John David Anglindave.ang...@bell.net
[Bug c/39589] make -Wmissing-field-initializers=2 work with "designated initializers" ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589 Manuel López-Ibáñez changed: What|Removed |Added Keywords||diagnostic --- Comment #3 from Manuel López-Ibáñez --- Also, I would propose to call the warning -Wmissing-designated-initializers better than a number that does not mean much.
[Bug tree-optimization/62053] [5 Regression] ICE: in remap_type_1, at tree-inline.c:540
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62053 --- Comment #5 from Alexander Ivchenko --- Ping.. any updates? We cannot build Android since the beginning of Jul, and, hence, cannot evaluate 5.0 candidate for it. I find it very unfortunate
[Bug target/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
--- Comment #6 from Uroš Bizjak ---
(In reply to Richard Biener from comment #5)
> The bug is clearly in
>
> "
> > Btw, if the mem is MEM_READONLY_P how can it be part of
> > a {un}aligned_store sequence?
>
> This flag is copied from the original memory operand of the store by
> alpha_set_memflags to all memory operands in the expanded sequence."
>
> and thus should be fixed there. What is the "original" memory reference
> here? It seems for the read-modify-write you should use the target MEM
> but somehow a source MEM gets used? Or rather you should not use either
> MEMs flags for _all_ MEMs in the sequence but properly distinguish between
> MEMs generated for the load of the source and MEMs generated for the store
> to the destination.
No, this is wrong conclusion. I have new insight into this problem.
Please consider following test:
--cut here--
static char *a;
static int *b;
void foo (void)
{
a[1] = 1;
b[2] = 1;
}
int bar (void)
{
return a && b;
}
--cut here--
(e.g. changing "static char *b" to "static int *b". This way, the problematic
insn is generated as "native" read:
(insn 15 14 16 2 (set (reg/f:DI 78)
(mem/u/f/c:DI (lo_sum:DI (reg:DI 79)
(symbol_ref:DI ("b") [flags 0x6] ))
[2 b+0 S8 A64])) rmw1.c:7 -1
(nil))
and this is again moved over
(insn 13 12 14 2 (set (mem:DI (and:DI (plus:DI (reg/f:DI 72)
(const_int 1 [0x1]))
(const_int -8 [0xfff8])) [0 S8 A64])
(reg:DI 77)) rmw1.c:6 -1
(nil))
(note that there is no "/u" suffix on the *store* of "a".)
With this testcase, we have following sequence before sched1 pass:
5: r73:DI=high(`a')
6: r72:DI=[r73:DI+low(`a')]
REG_DEAD r73:DI
7: r74:QI=0x1
8: r76:DI=[r72:DI+0x1&0xfff8]
9: r75:DI=r72:DI+0x1
10: r76:DI=!0xff<
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.0
[Bug tree-optimization/63476] [5 Regression] ICE: tree check: expected ssa_name, have var_decl in walk_aliased_vdefs_1, at tree-ssa-alias.c:2689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63476 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-10-08 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine (finally a small enough testcase...). This means somebody is not updating VDEFs properly (expected for load VUSEs btw).
[Bug ipa/63482] [5 Regression] ICE: in gimple_get_virt_method_for_vtable, at gimple-fold.c:4857
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63482 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.0
[Bug tree-optimization/63445] [5 Regression] request: make -Wstrict-overflow avoid a class of false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63445 --- Comment #8 from Eric Botcazou --- > The range of n_7 is suboptimal and the test on _6 can be eliminated. Which turns out to be counter-productive for the testcase because the test is used to derive information by the sccp pass; as a result, if you eliminate it, the sccp pass does nothing and the loop is not eliminated in the final code...
[Bug target/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
Richard Biener changed:
What|Removed |Added
Target||alpha
Component|rtl-optimization|target
--- Comment #5 from Richard Biener ---
The bug is clearly in
"
> Btw, if the mem is MEM_READONLY_P how can it be part of
> a {un}aligned_store sequence?
This flag is copied from the original memory operand of the store by
alpha_set_memflags to all memory operands in the expanded sequence."
and thus should be fixed there. What is the "original" memory reference
here? It seems for the read-modify-write you should use the target MEM
but somehow a source MEM gets used? Or rather you should not use either
MEMs flags for _all_ MEMs in the sequence but properly distinguish between
MEMs generated for the load of the source and MEMs generated for the store
to the destination.
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #25 from rguenther at suse dot de --- On Wed, 8 Oct 2014, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 > > --- Comment #24 from Jakub Jelinek --- > But is warning/error attribute the only thing on aliases that can hold extra > semantics info (now or in the future)? I'd say LTO symtab merging should > merge > what is mergeable, and should leave leave as separate decls with the same > asm-name what holds non-mergeable semantics on it. > Say, if you declare some function (or different, just with same asm name) with > warning attribute in one TU, with error attribute in another TU and without it > on another TU, IMHO those three decls shouldn't be merged together, you should > note in cgraph that you have aliases that have the same asm name but different > semantics and just ensure that you use the right cgraph nodes and decls in the > corresponding callers. Yes, I tried to fix things in this direction but failed (maybe didn't try hard enough). Basically I'd never merge decls in lto-symtab - tree merging already merges exactly equivalent function decls - but only fixup the cgraph for the tree merging that was done. Richard.
[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63480 --- Comment #6 from Marek Polacek --- Also note PR39589, a request for -Wmissing-field-initializers=2, but it's not as trivial as it seems.
[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63480 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |5.0
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 --- Comment #24 from Dominik Vogt --- > --snip-- > -g->defer->__retaddr = retaddr; > +g->defer->__retaddr = __builtin_extract_return_addr (retaddr); > --snip-- We need to double check whether this would break Sparc.
[Bug fortran/63473] Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus --- It's probably related (but not identical) to not deallocating allocatable-scalars function results after their use [PR55603] and not finalizing function results (after their value has been used) [PR37336 ?].
[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63480 --- Comment #5 from Manuel López-Ibáñez --- The C warning is also nicer than the C++ one because it says where the field is declared. It also only mentions one missing field per declaration, whereas the C++ warning mentions all, which is terribly noisy and repetitive.
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406
--- Comment #23 from Dominik Vogt ---
Regarding the new patch:
1) We need to call __builtin_extract_return_address(retaddr) in
__go_set_defer_retaddr() too. (On s390 (31 bit) this is necessary to remove
the most significant bit of the address which indicates the addressing mode.)
I.e.
--snip--
-g->defer->__retaddr = retaddr;
+g->defer->__retaddr = __builtin_extract_return_addr (retaddr);
--snip--
2) The new patch does not compile for me:
--
In file included from ../../../libgo/runtime/go-check-interface.c:8:0:
../../../libgo/runtime/go-panic.h:43:13: error: conflicting types for
‘__go_makefunc_can_recover’
extern void __go_makefunc_can_recover (void *retaddr);
^
In file included from ../../../libgo/runtime/go-check-interface.c:7:0:
../../../libgo/runtime/runtime.h:845:9: note: previous declaration of
‘__go_makefunc_can_recover’ was here
void__go_makefunc_can_recover (const void *);
^
--
In runtime.h, __go_makefunc_can_recover still has a "const" argument:
--snip--
-void__go_makefunc_can_recover (const void *);
+void__go_makefunc_can_recover (void *);
--snip--
3) Couldn't this be written more efficiently by passing a flag?
+ /* If we are called from __go_makefunc_can_recover, then we need to
+ look one level higher. */
+ if (locs[0].function.len > 0
+ && __builtin_strcmp ((const char *) locs[0].function.str,
+ "__go_makefunc_can_recover") == 0)
E.g.
_Bool __go_can_recover (void *retaddr, _Bool called_by_makefunc_can_recover)
{
...
if (called_by_makefunc_can_recover)
{ do something }
else
{ do something else }
...
}
4) With the suggested changes from 1 and 2 above:
s390x (64 bit):
* PASS: test/recover.go
* the test from #4 in my earlier posting works as expected
* my private defer/recover/panic testsuite works as expected
s390 (31 bit):
* PASS: test/recover.go
* the test from #4 in my earlier posting works as expected
* my private defer/recover/panic testsuite works as expected
5) I find the assumption in the loop at the end of __go_can_recover() that if a
caller's name begins with "__go_" that means the panic can be recovered, a bit
hairy. Even if it is with the current libgo, an unrelated change elsewhere
could break this logic.
[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63480
--- Comment #4 from Manuel López-Ibáñez ---
Found it: PR61489
I think warning for {0} is on purpose, since one cannot tell if the struct
originally had one field and now it has two. But I don't really agree with it.
I think it is too noisy.
[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63480
--- Comment #3 from Marek Polacek ---
In C++ we don't warn for { }. OTOH, C++ warns for { 0 } - I think it should
not.
[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63480
--- Comment #2 from Marek Polacek ---
I think it makes sense just not to warn on { }, much as we intentionally don't
warn for { 0 }.
I'm testing a patch.
[Bug c/63480] -Wmissing-field-initializers should not warn about intentionally empty initializers (or that should be a separate option)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63480 Manuel López-Ibáñez changed: What|Removed |Added Keywords||diagnostic CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez --- Wasn't this fixed for C++ recently? Perhaps the code could be shared... In any case, they should behave similarly.
[Bug rtl-optimization/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-10-08 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Ever confirmed|0 |1
[Bug rtl-optimization/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483 --- Comment #4 from Uroš Bizjak --- Patch at [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00625.html
[Bug tree-optimization/63445] [5 Regression] request: make -Wstrict-overflow avoid a class of false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63445 --- Comment #7 from Eric Botcazou --- > The range of n_7 is suboptimal and the test on _6 can be eliminated. The previous enhancement was apparently: 2010-04-06 Richard Guenther PR tree-optimization/43627 * tree-vrp.c (extract_range_from_unary_expr): Widenings of [1, +INF(OVF)] go to [1, +INF(OVF)] of the wider type, not varying. but it didn't go far enough for this case.
[Bug rtl-optimization/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483 --- Comment #3 from Uroš Bizjak --- The patched compiler creates prevents scheduler to move "unchanging" reference over possibly aliasing memory: 7: r74:QI=0x1 5: r73:DI=`a' 14: r79:DI=`b' 6: r72:DI=[r73:DI] REG_DEAD r73:DI 9: r75:DI=r72:DI+0x1 8: r76:DI=[r72:DI+0x1&0xfff8] 11: r77:DI=zero_extend(r74:QI)<
[Bug rtl-optimization/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483 --- Comment #2 from Uroš Bizjak --- Created attachment 33665 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33665&action=edit Proposed patch Proposed patch prevents MEM_READONLY_P memory references to be moved over possibly aliased memory (with alignment ANDs). The patch prevents early exit for MEM_READONLY_P references when alignemt ANDs are involved. The aliasing is determined in the code later in the function.
[Bug rtl-optimization/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483 --- Comment #1 from Uroš Bizjak --- $foo..ng: .prologue 1 lda $1,1($31) # 7*movqi/2[length = 4] lda $2,a # 27*movdi/7[length = 4] ldq $3,0($2) # 6*movdi/8[length = 4] lda $2,b # 26*movdi/7[length = 4] lda $7,1($3) # 9*adddi_internal/2[length = 4] ldq_u $5,1($3) # 8*movdi/8[length = 4] insbl $1,$7,$4 # 11insbl[length = 4] ldq $2,0($2) # 15*movdi/8[length = 4] mskbl $5,$7,$5 # 10mskxl[length = 4] lda $6,2($2) # 18*adddi_internal/2[length = 4] bis $4,$5,$4 # 12iordi3/1[length = 4] stq_u $4,1($3) # 13*movdi/9[length = 4] insbl $1,$6,$1 # 20insbl[length = 4] ldq_u $3,2($2) # 17*movdi/8[length = 4] mskbl $3,$6,$3 # 19mskxl[length = 4] cpys $f31,$f31,$f31 # 35fnop[length = 4] bis $1,$3,$1 # 21iordi3/1[length = 4] stq_u $1,2($2) # 22*movdi/9[length = 4] ret $31,($26),1 # 34*return_internal[length = 4] .end foo Before sched1 pass, we have: 5: r73:DI=`a' 6: r72:DI=[r73:DI] REG_DEAD r73:DI 7: r74:QI=0x1 8: r76:DI=[r72:DI+0x1&0xfff8] 9: r75:DI=r72:DI+0x1 10: r76:DI=!0xff<
[Bug target/63478] internal compiler error: in sparc_emit_set_const64, at config/sparc/sparc.c:2061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63478 --- Comment #6 from Dennis Clarke --- > > *** This bug has been marked as a duplicate of bug 34191 *** Not really a duplicate but close enough. This is Solaris 10 and I bet we see the same thing on Solaris 11. If anyone actually uses that. dc
[Bug target/63478] internal compiler error: in sparc_emit_set_const64, at config/sparc/sparc.c:2061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63478 --- Comment #5 from Dennis Clarke --- (In reply to Andrew Pinski from comment #3) > Why are you trying to use -mptr64 anyways? Especially without -m64 ? Reasonable question. I often bootstrap GCC and then try a whole series of simple tests *after* I run the whole testsuite. To be honest I had not seen an ICE before and was surprised to see it. As for -mptr64, well yes it was a dumb idea. Given that it isn't documented anywhere. At least it does not seem to exist anywhere here : https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gcc/ Some of the little tests I run involved posix thread dispatch tests as well as slogging memory around and some are simple floating point performance tests. I look at the output assembly from both GCC and Oracle Studio tools. There really is not much of a performance gap anymore unless you are in possession of a Sparc T5 or some server with 256 processor cores. Regardless, looks like a red herring : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34191
[Bug rtl-optimization/63483] New: Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483
Bug ID: 63483
Summary: Scheduler performs Invalid move of aliased memory
reference
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
CC: rguenth at gcc dot gnu.org, rth at gcc dot gnu.org
The original problem is present in [1], and can be illustrated by following
test on alpha-linux-gnu:
--cut here--
static char *a;
static char *b;
void foo (void)
{
a[1] = 1;
b[2] = 1;
}
int bar (void)
{
return a && b;
}
--cut here--
The compilation with -O2 produces:
$foo..ng:
.prologue 1
lda $1,1($31)
lda $2,a
ldq $3,0($2) <-- load a
lda $2,b
lda $7,1($3)
ldq_u $5,1($3) <-- load a
insbl $1,$7,$4
ldq $2,0($2) <-- load b
mskbl $5,$7,$5
lda $6,2($2)
bis $4,$5,$4
stq_u $4,1($3) <-- store a
insbl $1,$6,$1
ldq_u $3,2($2) <-- load b
mskbl $3,$6,$3
cpys $f31,$f31,$f31
bis $1,$3,$1
stq_u $1,2($2) <-- store b
ret $31,($26),1
.end foo
if a and b alias to the same wide memory location, then "b" RMW
sequence corrupts "a".
There is am early shortcut for MEM_READOLNY_P in true_dependence_1 in alias.c.
For the testcase above:
(insn 15 13 18 2 (set (reg/f:DI 78 [ b ])
(mem/u/f/c:DI (reg/f:DI 79) [2 b+0 S8 A64])) rmw.c:7 226 {*movdi}
(expr_list:REG_DEAD (reg/f:DI 79)
(nil)))
is free to be scheduled before
(insn 13 12 15 2 (set (mem:DI (and:DI (plus:DI (reg/f:DI 72 [ a ])
(const_int 1 [0x1]))
(const_int -8 [0xfff8])) [0 S8 A64])
(reg:DI 77)) rmw.c:6 226 {*movdi}
(expr_list:REG_DEAD (reg:DI 77)
(expr_list:REG_DEAD (reg/f:DI 72 [ a ])
(nil
rth explained situation on alpha a bit:
--quote--
It's not the loads, per se, it's the stores that get in the way.
Early alpha can't store sub-4-byte quantities. Altivec can't store anything
but 16 byte quantities. In order to perform smaller stores, we have to do a
read-modify-write sequence on a larger aligned chunk of memory. Two such RMW
sequences must conflict, lest we interleave and thus bork the operation.
I don't recall how much we ever did for this, exactly, but it's certainly
possible to know that some memory operations cannot conflict with these RMW
sequence. E.g. through size + alignment of the other memory operation. E.g.
on Alpha, a byte RMW store can't conflict with a normal DImode memory access.
--/quote--
And:
> Btw, if the mem is MEM_READONLY_P how can it be part of
> a {un}aligned_store sequence?
This flag is copied from the original memory operand of the store by
alpha_set_memflags to all memory operands in the expanded sequence.
[1] https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02251.html
[Bug lto/61886] [4.8/4.9/5 Regression] LTO breaks fread with _FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886 --- Comment #24 from Jakub Jelinek --- But is warning/error attribute the only thing on aliases that can hold extra semantics info (now or in the future)? I'd say LTO symtab merging should merge what is mergeable, and should leave leave as separate decls with the same asm-name what holds non-mergeable semantics on it. Say, if you declare some function (or different, just with same asm name) with warning attribute in one TU, with error attribute in another TU and without it on another TU, IMHO those three decls shouldn't be merged together, you should note in cgraph that you have aliases that have the same asm name but different semantics and just ensure that you use the right cgraph nodes and decls in the corresponding callers.
[Bug target/34191] Using gcc with -mptr64 option on Solaris 5.9 produces the following message: the internal compiler error: in sparc_emit_set_const64, at config/sparc/sparc.c:1669
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34191 Eric Botcazou changed: What|Removed |Added CC||dev at cor0 dot com --- Comment #6 from Eric Botcazou --- *** Bug 63478 has been marked as a duplicate of this bug. ***
[Bug target/63478] internal compiler error: in sparc_emit_set_const64, at config/sparc/sparc.c:2061
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63478 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Eric Botcazou --- . *** This bug has been marked as a duplicate of bug 34191 ***
