[Bug target/64782] -mcpu=native should be supported on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64782 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-01-25 CC||ktkachov at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from ktkachov at gcc dot gnu.org --- I had some work on this for GCC 6
[Bug rtl-optimization/64688] [5 Regression] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64688
Uroš Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Keywords||ra
Status|REOPENED|NEW
Component|target |rtl-optimization
--- Comment #12 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Markus Trippelsdorf from comment #11)
Created attachment 34566 [details]
reduced testcase
trippels@gcc20 % g++ -c -O3 -std=c++11 -march=westmere performance.ii
performance.ii: In function ‘void performance_testtest_method()’:
performance.ii:133:1: internal compiler error: Max. number of generated
reload insns per insn is achieved (90)
Happens when trying to reload for:
(insn 73 72 393 2 (set (reg:V4SI 304)
(vec_merge:V4SI (vec_duplicate:V4SI (subreg:SI (reg:QI 103 [ SR.27 ])
0))
(const_vector:V4SI [
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
(const_int 0 [0])
])
(const_int 1 [0x1]))) 2460 {vec_setv4si_0}
(nil))
Reload goes into infinite loop here.
Changing pseudo 103 in operand 2 of insn 73 on equiv 0
Creating newreg=359, assigning class ALL_REGS to subreg reg r359
73: r304:V4SI=vec_merge(vec_duplicate(r359:QI#0),const_vector,0x1)
Inserting subreg reload before:
502: r359:QI=0
2 Non pseudo reload: reject++
alt=0,overall=1,losers=0,rld_nregs=0
Choosing alt 0 in insn 73: (0) =Yr (1) C (2) Yr {vec_setv4si_0}
Change to class NO_REX_SSE_REGS for r359
0 Non input pseudo reload: reject++
1 Non-pseudo reload: reject+=2
1 Non input pseudo reload: reject++
alt=0,overall=16,losers=2,rld_nregs=2
0 Non input pseudo reload: reject++
alt=1,overall=7,losers=1,rld_nregs=1
0 Non input pseudo reload: reject++
1 Non-pseudo reload: reject+=2
1 Non input pseudo reload: reject++
alt=2,overall=16,losers=2 -- refuse
0 Non input pseudo reload: reject++
1 Non-pseudo reload: reject+=2
1 Non input pseudo reload: reject++
alt=3,overall=16,losers=2 -- refuse
0 Non input pseudo reload: reject++
alt=4,overall=7,losers=1,rld_nregs=1
Staticly defined alt reject+=6
0 Non input pseudo reload: reject++
alt=5,overall=13,losers=1 -- refuse
0 Non input pseudo reload: reject++
alt=6,overall=7,losers=1,rld_nregs=0
alt=7: Bad operand -- refuse
alt=8: Bad operand -- refuse
0 Non input pseudo reload: reject++
alt=9: Bad operand -- refuse
Choosing alt 6 in insn 502: (0) m (1) qn {*movqi_internal}
Creating newreg=360 from oldreg=359, assigning class NO_REGS to r360
502: r360:QI=0
Inserting insn reload after:
503: r359:QI=r360:QI
0 Non input pseudo reload: reject++
alt=0,overall=13,losers=2,rld_nregs=2
0 Non input pseudo reload: reject++
alt=1,overall=13,losers=2,rld_nregs=2
0 Non input pseudo reload: reject++
1 Non pseudo reload: reject++
alt=2,overall=8,losers=1,rld_nregs=1
0 Non input pseudo reload: reject++
alt=3,overall=13,losers=2 -- refuse
0 Non input pseudo reload: reject++
alt=4,overall=13,losers=2 -- refuse
Staticly defined alt reject+=6
0 Non input pseudo reload: reject++
alt=5,overall=13,losers=1 -- refuse
0 Non input pseudo reload: reject++
alt=6,overall=13,losers=2 -- refuse
alt=7: Bad operand -- refuse
alt=8: Bad operand -- refuse
0 Non input pseudo reload: reject++
alt=9: Bad operand -- refuse
Choosing alt 2 in insn 503: (0) q (1) qm {*movqi_internal}
Creating newreg=361 from oldreg=359, assigning class GENERAL_REGS to r361
503: r361:QI=r360:QI
Inserting insn reload after:
504: r359:QI=r361:QI
0 Non input pseudo reload: reject++
1 Non pseudo reload: reject++
alt=0,overall=608,losers=1,rld_nregs=1
0 Non input pseudo reload: reject++
1 Non pseudo reload: reject++
alt=1,overall=608,losers=1,rld_nregs=1
0 Non input pseudo reload: reject++
1 Non pseudo reload: reject++
alt=2,overall=608,losers=1,rld_nregs=1
0 Non input pseudo reload: reject++
1 Non pseudo reload: reject++
alt=3,overall=608,losers=1,rld_nregs=1
0 Non input pseudo reload: reject++
1 Non pseudo reload: reject++
alt=4,overall=608,losers=1,rld_nregs=1
Staticly defined
[Bug fortran/64787] New: Invalid code on sourced allocation of class(*) character string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64787
Bug ID: 64787
Summary: Invalid code on sourced allocation of class(*)
character string
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
On trunk
module X
contains
subroutine AddCopy(C)
class(*), intent(in) :: C
class(*), pointer :: P
allocate(P, source=C)
end subroutine
end module X
program test
use X
call AddCopy('test string')
end program test
compiles, but when compiled with -O3 this always gives me a Seg Fault when run
(and probably invalid code more generally).
It may be related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64692
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672
[Bug target/54236] [SH] Improve addc and subc insn utilization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54236 --- Comment #11 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Sun Jan 25 16:41:25 2015 New Revision: 220093 URL: https://gcc.gnu.org/viewcvs?rev=220093root=gccview=rev Log: gcc/testsuite/ PR target/54236 * gcc.target/sh/pr54236-4.c: New. Added: trunk/gcc/testsuite/gcc.target/sh/pr54236-4.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/29366] atomics config for sh is weird
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29366 --- Comment #8 from Oleg Endo olegendo at gcc dot gnu.org --- Author: olegendo Date: Sun Jan 25 16:54:33 2015 New Revision: 220094 URL: https://gcc.gnu.org/viewcvs?rev=220094root=gccview=rev Log: libstdc++-v3/ PR target/29366 * config/cpu/sh/atomicity.h (__exchange_and_add, __atomic_add): Remove SH4A inline asm and lock based implementations and use the defaults from ext/atomicity.h. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/config/cpu/sh/atomicity.h
[Bug middle-end/64353] [5 Regression] ICE: in execute_todo, at passes.c:1986
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64353 tbsaunde at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||tbsaunde at gcc dot gnu.org Resolution|--- |FIXED --- Comment #9 from tbsaunde at gcc dot gnu.org --- fixed
[Bug fortran/61831] [4.9/ 5 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #36 from Mikael Morin mikael at gcc dot gnu.org ---
[...]
(*(struct string_t[1] * restrict) atmp.7.data)[0] = prt_in;
prt_in.chars.data is copied to atmp.7.data[0].
[...]
while (1)
{
[...]
D.3430 = (*(struct string_t[1] * restrict) atmp.7.data)[S.10];
atmp.7.data[0].chars.data is copied to D.3430
[...]
if (D.3430.chars.data != 0B)
{
__builtin_free ((void *) D.3430.chars.data);
}
D.3430.chars.data = 0B;
D.3430.chars.data is freed.
So every iteration of the do loop has the side-effect of freeing
prt_in.chars.data.
[Bug target/59533] [SH] Missed cmp/pz opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59533
--- Comment #5 from Oleg Endo olegendo at gcc dot gnu.org ---
The issues mentioned above have been fixed by the treg_set_expr patch
(r220081).
There is one more thing, though:
int test2 (int x)
{
return x 0;
}
It's effectively a lshiftrt 31 and compiles to:
shllr4
rts
movtr0
On SH2A the same can be done as:
cmp/pz r4
rts
movrt r0
which avoids mutating the input operand of the comparison. On non-SH2A this
would end up as:
cmp/pz r4
mov #-1,r0
rts
negcr0,r0
which could be better than shll-movt in cases where the input operand is not
dead after the insn and even better if the -1 constant can be shared.
[Bug target/59533] [SH] Missed cmp/pz opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59533
--- Comment #6 from Oleg Endo olegendo at gcc dot gnu.org ---
(In reply to Oleg Endo from comment #5)
The same would apply to:
int test (unsigned char* x, int y, int z)
{
return ((*x 7) ^ 0) 1;
}
which compiles to
mov.b @r4,r1
shllr1
rts
movtr0
on non-SH2A. The insn selection goes like this:
zero_extract - tstsi_t - cmp/pz - shll-movt
[Bug c/64743] minor issue with the location of -Wlong-long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64743 Mikhail Maltsev maltsevm at gmail dot com changed: What|Removed |Added CC||maltsevm at gmail dot com --- Comment #1 from Mikhail Maltsev maltsevm at gmail dot com --- It's very easy to fix. In fact, I've already written a patch. But just one clarification. Consider: typedef void (*pf_t)(const long unsigned long *); typedef unsigned long long int long_t; clang always puts warnings at first long. Same behavior for C89 and C++98. Should we do the same or, maybe, point the warning to the beginning of type specifiers/qualifiers list?
[Bug fortran/64692] Incorrect result for sourced allocate of class(*) array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64692 vehre at gcc dot gnu.org changed: What|Removed |Added CC||vehre at gcc dot gnu.org --- Comment #3 from vehre at gcc dot gnu.org --- IMHO, this is not only related to 60322, but the same bug. The major difference in the output is due to the bug being applied multiple times consecutively.
[Bug middle-end/57748] [4.8 Regression] ICE when expanding assignment to unaligned zero-sized array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #63 from Mikael Pettersson mikpelinux at gmail dot com --- The backport request has been posted: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02192.html
[Bug c++/64786] Eliminate exceptions thrown/caught inside a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64786 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- See also PR53294 and PR64501.
[Bug target/64792] New: [5 Regression][SH] movu.b movu.w not working
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64792 Bug ID: 64792 Summary: [5 Regression][SH] movu.b movu.w not working Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target: sh*-*-* The treg_set_expr patch from r220081 disabled early matching of the SH2A movu.b and movu.w patterns during RTL expansion and combine. This was done because it's otherwise difficult to convert zero-extending loads back to sign-extending loads in cases where using sign-extended values is fine. Sign-extending loads are shorter (2 bytes vs. 4 bytes insns) and the zero-extending loads should be formed as a last resort option, after combine and split1, but before RA. The idea is to do that in a simple peephole-like RTL pass.
[Bug libfortran/64770] [5 Regression] Segmentation fault when opening a file with status=new and the file exists.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64770 --- Comment #5 from Janne Blomqvist jb at gcc dot gnu.org --- Author: jb Date: Sun Jan 25 23:04:50 2015 New Revision: 220098 URL: https://gcc.gnu.org/viewcvs?rev=220098root=gccview=rev Log: PR 64770 Make testcase work properly under DejaGNU. 2015-01-26 Janne Blomqvist j...@gcc.gnu.org PR libfortran/64770 * gfortran.dg/open_new_segv.f90: Add dg- stuff to make test work correctly, clean up afterwards. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/open_new_segv.f90
[Bug target/64793] New: [SH] missed delay slot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64793
Bug ID: 64793
Summary: [SH] missed delay slot
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
The following test case
int test0 (const char* x, int a, int b, int c)
{
if (x[a] == 92)
return b;
return c;
}
compiled with -O2 -m4 results in:
mov r5,r0
mov.b @(r0,r4),r1
mov r1,r0
cmp/eq #92,r0
bt .L3
mov r7,r0 this insn
rts
nopshould go into the delay slot
.L3:
rts
mov r6,r0
[Bug fortran/60718] [4.8/4.9 regression] Test case gfortran.dg/select_type_4.f90 fails on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60718 --- Comment #22 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Hmm I tried to boot-strap a clean gcc 4.9.2 with this patch, but it did not make it. Looks like some one spoiled the armv7l-unknown-linux-gnueabihf target. So it is currently pointless to fix this for 4.9.x and as far as I remember the situation for 4.8.x was similar. /home/ed/gnu/gcc-test/./prev-gcc/xg++ -B/home/ed/gnu/gcc-test/./prev-gcc/ -B/home/ed/gnu/arm-linux-gnueabihf/armv7l-unknown-linux-gnueabihf/bin/ -nostdinc++ -B/home/ed/gnu/gcc-test/prev-armv7l-unknown-linux-gnueabihf/libstdc++-v3/src/.libs -B/home/ed/gnu/gcc-test/prev-armv7l-unknown-linux-gnueabihf/libstdc++-v3/libsupc++/.libs -I/home/ed/gnu/gcc-test/prev-armv7l-unknown-linux-gnueabihf/libstdc++-v3/include/armv7l-unknown-linux-gnueabihf -I/home/ed/gnu/gcc-test/prev-armv7l-unknown-linux-gnueabihf/libstdc++-v3/include -I/home/ed/gnu/gcc-4.9.2/libstdc++-v3/libsupc++ -L/home/ed/gnu/gcc-test/prev-armv7l-unknown-linux-gnueabihf/libstdc++-v3/src/.libs -L/home/ed/gnu/gcc-test/prev-armv7l-unknown-linux-gnueabihf/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.9.2/gcc -I../../gcc-4.9.2/gcc/. -I../../gcc-4.9.2/gcc/../include -I../../gcc-4.9.2/gcc/../libcpp/include -I/home/ed/gnu/gcc-test/./gmp -I/home/ed/gnu/gcc-4.9.2/gmp -I/home/ed/gnu/gcc-test/./mpfr -I/home/ed/gnu/gcc-4.9.2/mpfr -I/home/ed/gnu/gcc-4.9.2/mpc/src -I../../gcc-4.9.2/gcc/../libdecnumber -I../../gcc-4.9.2/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-4.9.2/gcc/../libbacktrace -DCLOOG_INT_GMP -I/home/ed/gnu/gcc-test/./cloog/include -I/home/ed/gnu/gcc-4.9.2/cloog/include -I../gcc-4.9.2/cloog/include -I/home/ed/gnu/gcc-test/./isl/include -I/home/ed/gnu/gcc-4.9.2/isl/include -o haifa-sched.o -MT haifa-sched.o -MMD -MP -MF ./.deps/haifa-sched.TPo ../../gcc-4.9.2/gcc/haifa-sched.c ../../gcc-4.9.2/gcc/haifa-sched.c: In function 'bool schedule_block(basic_block_def**, state_t)': ../../gcc-4.9.2/gcc/haifa-sched.c:6507:1: internal compiler error: in lra_create_copy, at lra.c:1532 } ^ 0x951cfb lra_create_copy(int, int, int) ../../gcc-4.9.2/gcc/lra.c:1532 0x97bc5f process_bb_lives ../../gcc-4.9.2/gcc/lra-lives.c:568 0x97d81f lra_create_live_ranges(bool) ../../gcc-4.9.2/gcc/lra-lives.c:1008 0x9544b7 lra(_IO_FILE*) ../../gcc-4.9.2/gcc/lra.c:2372 0x8ecd27 do_reload ../../gcc-4.9.2/gcc/ira.c:5457 0x8ed193 rest_of_handle_reload ../../gcc-4.9.2/gcc/ira.c:5598 0x8ed1ff execute ../../gcc-4.9.2/gcc/ira.c:5627 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [haifa-sched.o] Error 1 make[3]: Leaving directory `/home/ed/gnu/gcc-test/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/ed/gnu/gcc-test' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/ed/gnu/gcc-test' make: *** [all] Error 2
[Bug inline-asm/64681] gcc assign wrong register for arm inline assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64681 David gccbugzilla at limegreensocks dot com changed: What|Removed |Added CC||gccbugzilla@limegreensocks. ||com --- Comment #4 from David gccbugzilla at limegreensocks dot com --- Until very recently, *none* of the modifiers were documented. In the current docs (https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#i386Operandmodifiers), only the i386 modifiers are doc'ed. That said, you can always check out the gcc source. For example: The comments above output_asm_insn in https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/final.c?view=cocontent-type=text%2Fplain describe some global modifiers. For i386-specific modifiers, look above ix86_print_operand in https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/i386.c?view=cocontent-type=text%2Fplain For arm, look above arm_print_operand in https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/arm/arm.c?view=cocontent-type=text%2Fplain Presumably there are similar sections for other configs.
[Bug middle-end/64340] [5 Regression] FAIL: gnat.dg/lto8.adb (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64340 --- Comment #7 from tbsaunde at gcc dot gnu.org --- (In reply to tbsaunde from comment #6) It seems like the right thing to do is make varpool_node::create_alias() set ref_list.references, does that seem correct? O.O that was for another bug.
[Bug target/59533] [SH] Missed cmp/pz opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59533
--- Comment #7 from Oleg Endo olegendo at gcc dot gnu.org ---
If a shll is followed by a cbranch:
unsigned int
test_09_0 (int x, unsigned int y, unsigned int z)
{
return ~(x 31) ? y : z;
}
shllr4
bf .L4
mov r6,r5
.L4:
rts
movr5,r0
it's better to use cmp/pz and invert the branch condition.
Combine is looking for the following pattern:
Failed to match this instruction:
(set (pc)
(if_then_else (ge (reg:SI 4 r4 [ x ])
(const_int 0 [0]))
(label_ref:SI 17)
(pc)))
One option could be adding a pattern like:
(define_insn_and_split *cbranch
[(set (pc)
(if_then_else (match_operand 0 treg_set_expr)
(label_ref (match_operand 1))
(pc)))
(clobber (reg:SI T_REG))]
[Bug c++/51747] [DR 1467] [C++11] cannot call defaulted copy constructor using list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51747
--- Comment #10 from Ville Voutilainen ville.voutilainen at gmail dot com ---
This code fails with the current trunk:
struct B {};
struct D : B {D(B b) : B{b} {}};
base-aggr-init.cpp: In constructor ‘D::D(B)’:
base-aggr-init.cpp:2:27: error: too many initializers for ‘B’
struct D : B {D(B b) : B{b} {}};
^
As far as I can see, the function process_init_constructor_record in typeck2.c
emits the diagnostic.
[Bug libstdc++/64504] Invalid free() with _GLIBCXX_DEBUG and -fwhole-program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64504
--- Comment #3 from Andrey Vihrov andrey.vihrov at gmail dot com ---
I compiled the example program without and with -fwhole-program to assembly
code, and here are the differences: http://pastie.org/9859649
As I understand, normally the .weak directive ensures that there is only one
definition of std::string::_Rep::_S_empty_rep_storage per whole program. But
with -fwhole-program the .weak directive disappears, and instead another local
definition is created.
Looking at libstdc++ source code, I see
// The following storage is init'd to 0 by the linker, resulting
// (carefully) in an empty string with one reference.
static size_type _S_empty_rep_storage[];
. . .
// Linker sets _S_empty_rep_storage to all 0s (one reference, empty string)
// at static init time (before static ctors are run).
templatetypename _CharT, typename _Traits, typename _Alloc
typename basic_string_CharT, _Traits, _Alloc::size_type
basic_string_CharT, _Traits, _Alloc::_Rep::_S_empty_rep_storage[
(sizeof(_Rep_base) + sizeof(_CharT) + sizeof(size_type) - 1) /
sizeof(size_type)];
I can get kind of the same difference in assembly by compiling this code:
templatetypename T = void
struct S
{
static char arr[];
};
templatetypename T
char ST::arr[3];
int main()
{
return S::arr[1];
}
Without -fwhole-program .weak and stuff is emitted, with the option the array
probably becomes static and so the program is compiled to return 0.
So it looks like the problem here is that with -fwhole-program GCC does not
consider the possible existence of the same template instantiation in other
translation units.
[Bug c++/51747] [DR 1467] [C++11] cannot call defaulted copy constructor using list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51747
--- Comment #11 from Ville Voutilainen ville.voutilainen at gmail dot com ---
Also,
struct base {
int x;
};
struct derived : base {
derived(const base state)
: base{state}
{}
};
is diagnosed with
base-aggr-init2.cpp: In constructor ‘derived::derived(const base)’:
base-aggr-init2.cpp:7:17: error: cannot convert ‘const base’ to ‘int’ in
initialization
: base{state}
^
so it doesn't look like Core 1467 is handled in base class initializers
at all.
[Bug c++/64794] New: GCC failed at virtual function with override trailing return type name, followed by override virt-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64794
Bug ID: 64794
Summary: GCC failed at virtual function with override
trailing return type name, followed by override
virt-specifier
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: boostcpp at gmail dot com
GCC failed at virtual function with override
trailing return type name, followed by override virt-specifier.
Following code should be well-formed.
struct override { } ;
struct Base
{
virtual auto f() - override ;
} ;
struct Derived : Base
{
// GCC issues error: two or more data types in declaration of 'type name'
auto f() - override override ;
} ;
[Bug ipa/61548] [5 Regression] FAIL: gcc.dg/tls/alias-1.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61548 --- Comment #13 from Jan Hubicka hubicka at ucw dot cz --- So, what is here is: emutls calls varpool_node::create_alias(decl(emutls_v.bar), decl(emutls_v.foo)) which sets alias = true and alias_target = node(emutls_v.foo) on the node for emutls_v.bar, however it does not set up ref_list.references on node(emutls_v.bar) to point at node(emutls_v.foo). Then during varification we call symtab_node::get_alias_target() which gets the alias from node(emutls_v.bar).ref_list.references but that crashes becauses references doesn't contain an element for the alias target. The way to get the references for alias is to call alias-resolve_alias. The resolution normally happens at the end of parsing but if someone introduces new alias late, he needs to cal the resolve_alias manually. Honza
[Bug fortran/62044] [4.8/4.9 Regression] ICE in USE statement with RENAME for extended derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044 paul.richard.thomas at gmail dot com paul.richard.thomas at gmail dot com changed: What|Removed |Added CC||paul.richard.thomas at gmail dot c ||om --- Comment #6 from paul.richard.thomas at gmail dot com paul.richard.thomas at gmail dot com --- (In reply to Mikael Morin from comment #4) Author: mikael Date: Sun Jan 25 20:30:53 2015 New Revision: 220097 URL: https://gcc.gnu.org/viewcvs?rev=220097root=gccview=rev Log: fortran/ PR fortran/62044 * decl.c (gfc_match_derived_decl): Don't insert a new symtree element. * module.c (MOD_VERSION): Bump. (write_module): Don't write list of extensions. (read_module): Don't jump over list of extensions; don't load list of extensions. (load_derived_extensions, write_dt_extensions, write_derived_extensions): Remove. testsuite/ PR fortran/62044 * gfortran.dg/use_rename_7.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/use_rename_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog Mikael, The following, which works OK with another brand, selects the wrong type with trunk. 4.9 still segfaults. Without the use rename, 4.9 runs and gives the wrong result. module GridImageSilo_Template implicit none ! private type, public, abstract :: GridImageSiloTemplate end type GridImageSiloTemplate end module GridImageSilo_Template module UnstructuredGridImageSilo_Form use GridImageSilo_Template implicit none ! private type, public, extends ( GridImageSiloTemplate ) :: UnstructuredGridImageSiloForm end type UnstructuredGridImageSiloForm end module UnstructuredGridImageSilo_Form module UnstructuredGridImages use UnstructuredGridImageSilo_Form, UnstructuredGridImageForm = UnstructuredGridImageSiloForm contains subroutine foo class (GridImageSiloTemplate), allocatable :: a type (UnstructuredGridImageForm) :: b allocate (a, mold = b) select type (a) type is (UnstructuredGridImageForm) print *, correct type selected class default print *, wrong type end select end subroutine end module UnstructuredGridImages use UnstructuredGridImages call foo end I think that it should be reopened as a placeholder. I suspect that removing the inheritance information is not the right way to go. Cheers Paul
[Bug target/64342] [5 Regression] Tests failing when compiled with '-m32 -fpic' after r216154.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64342 --- Comment #7 from vries at gcc dot gnu.org --- (In reply to Igor Zamyatin from comment #1) avx512f-kandnw-1.c and funcspec-5.c seem to be non-PIC related issues. I asked Kirill to look at them. I cannot reproduce the funcspec-5.c failure with r216154, so that failure was unrelated (and fixed in r220079). I can reproduce that avx512f-kandnw-1.c started failing with r216154, in -fpic -m32 mode only. Given comment 6, it could be a benign case of different code generation, split triggered, output scan failure. Others are not stability but more performance issues - generated code is less effective than it should be - in one case for some reasons compiler uses callee-saved ebx in PIC mode instead of edx in non-PIC mode and in xmm case compiler uses stack in PIC mode instead of xmm register in non-PIC mode I see that differencies between PIC and non-PIC modes start on reload pass so I'd like Vlad to look at these cases I can reproduce that fuse-caller-save.c started failing with r216154, in -fpic -m32 mode only. The code is less optimal with r216154: ... foo: .LFB1: .cfi_startproc -movl%eax, %edx +pushl%ebx +.cfi_def_cfa_offset 8 +.cfi_offset 3, -8 +movl%eax, %ebx callbar -addl%edx, %eax +addl%ebx, %eax +popl%ebx +.cfi_restore 3 +.cfi_def_cfa_offset 4 ret .cfi_endproc ... Before r216154, bx is considered clobbered in bar by collect_fn_hard_reg_set_usage, because it's part of fixed_reg_set. With r216154, bx is no longer part of fixed_reg_set, and bx becomes available for register allocation in foo. I'm not familiar with the pic register code, so I don't know whether this is safe. Register allocation seems to progress similarly, up until this message in reload, with seems to be directly related to the r216154 patch: ... Spill r86 after risky transformations Reassigning non-reload pseudos Assign 3 to r86 (freq=3000) ... So, it seems the r216154 patch introduces a performance degradation for -m32 -fpic for the fuse-caller-save example.
[Bug target/64785] New: [5 Regression][SH] and|or|xor #imm not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64785
Bug ID: 64785
Summary: [5 Regression][SH] and|or|xor #imm not used
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target: sh*-*-*
It seems that for some reason loading a constant is now favored instead of
using the #imm,R0 alternative.
void test000 (int* x, int xb)
{
x[0] = xb 128;
}
void test001 (int* x, int xb)
{
x[0] = xb | 128;
}
void test002 (int* x, int xb)
{
x[0] = xb ^ 128;
}
trunk:
_test000:
mov.w.L7,r1! 15*movhi/1[length = 2]
andr1,r5! 7*andsi_compact/4[length = 2]
rts! 18*return_i[length = 2]
mov.lr5,@r4! 8movsi_ie/9[length = 2]
4.9:
movr5,r0! 15movsi_ie/2[length = 2]
and#128,r0! 7*andsi_compact/3[length = 2]
rts! 18*return_i[length = 2]
mov.lr0,@r4! 8movsi_ie/9[length = 2]
The RTL before RA is the same in both cases:
(insn 7 4 8 2 (set (reg:SI 163 [ D.1431 ])
(and:SI (reg:SI 5 r5 [ xb ])
(const_int 128 [0x80]))) sh_tmp.cpp:257 124 {*andsi_compact}
(expr_list:REG_DEAD (reg:SI 5 r5 [ xb ])
(nil)))
(insn 8 7 0 2 (set (mem:SI (reg:SI 4 r4 [ x ]) [1 *x_4(D)+0 S4 A32])
(reg:SI 163 [ D.1431 ])) sh_tmp.cpp:257 257 {movsi_ie}
(expr_list:REG_DEAD (reg:SI 4 r4 [ x ])
(expr_list:REG_DEAD (reg:SI 163 [ D.1431 ])
(nil
Reload on trunk says:
Reloads for insn # 7
Reload 0: reload_in (SI) = (const_int 128 [0x80])
GENERAL_REGS, RELOAD_FOR_INPUT (opnum = 2)
reload_in_reg: (const_int 128 [0x80])
reload_reg_rtx: (reg:SI 1 r1)
While reload on 4.9 says:
Reloads for insn # 7
Reload 0: reload_in (SI) = (reg:SI 5 r5 [ xb ])
reload_out (SI) = (reg:SI 0 r0 [orig:163 D.1377 ] [163])
R0_REGS, RELOAD_OTHER (opnum = 0)
reload_in_reg: (reg:SI 5 r5 [ xb ])
reload_out_reg: (reg:SI 0 r0 [orig:163 D.1377 ] [163])
reload_reg_rtx: (reg:SI 0 r0 [orig:163 D.1377 ] [163])
Maybe this is because the function argument from hardreg r5 is propagated into
the insn. This propagation is also causing unnecessary sign/zero extensions,
see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53987#c9
[Bug c++/64786] New: Eliminate exceptions thrown/caught inside a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64786
Bug ID: 64786
Summary: Eliminate exceptions thrown/caught inside a function
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
If I'm not mistaken, in the following example:
int test (int a, int b, int* c)
{
enum err_a_t { ERR_A };
enum err_b_t { ERR_B };
try
{
if ((a + b) == 123)
throw ERR_A;
if ((a - b) == 5)
throw ERR_B;
for (int i = 0; i b; ++i)
c[i] = 4;
return 0;
}
catch (err_a_t)
{
c[0] = 0;
return -1;
}
catch (err_b_t)
{
c[0] = 1;
return -1;
}
catch (...)
{
__builtin_abort ();
}
}
... the exceptions can be eliminated and converted into something like this
unless -fnon-call-exceptions is used (the mem accesses could throw).
int test (int a, int b, int* c)
{
if ((a + b) == 123)
{
c[0] = 0;
return -1;
}
if ((a - b) == 5)
{
c[0] = 0;
return -1;
}
for (int i = 0; i b; ++i)
c[i] = 4;
return 0;
}
.. because all possible exceptions are known and are also known to be caught in
the function itself and there's nothing to stack-unwind.
[Bug fortran/59093] Segfault in gfc_trans_pointer_assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59093 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #8 from Harald Anlauf anlauf at gmx dot de --- (In reply to Matt Thompson from comment #7) I'm not sure if anyone is even looking at this bug anymore, but I wanted to say it is still present in gcc 4.9.1. Using the test from ja...@gcc.gnu.org: Still present in gcc 5 trunk rev. 220062.
[Bug c++/64791] New: Generic lambda fails to implicitly capture `const` variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64791
Bug ID: 64791
Summary: Generic lambda fails to implicitly capture `const`
variable
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at kera dot name
From http://stackoverflow.com/q/28141403/560648
Reproduction:
/
#include iostream
#include functional
int main()
{
const int a = 2;
std::functionvoid(int) f = [](auto b) { std::cout a , b
std::endl; };
f(3);
}
/
Taking any of the following steps allows the program to build and run with the
expected output 2, 3:
- remove `const` from declaration of a
- name `a` in the capture-list instead of relying on implicit capture
- change declaration of `f` from `std::functionvoid(int)` to `auto`
- make the lambda non-generic by changing `auto b` to `int b`
- use Clang (e.g. v3.5.0)
Suspect detection of odr-use is breaking, or this could be related to bug
61814, or something else entirely?
[Bug c++/64755] Error in optimization with std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64755 mednafen at gmail dot com changed: What|Removed |Added CC||mednafen at gmail dot com --- Comment #2 from mednafen at gmail dot com --- It looks like your code violates strict aliasing rules. Does the code in question work as you intend it to if you compile with -fno-strict-aliasing ?
[Bug c++/64791] Generic lambda fails to implicitly capture `const` variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64791
--- Comment #1 from Tomalak Geret'kal tom at kera dot name ---
Build error:
/
main.cpp: In instantiation of 'main()::lambda(auto:1) [with auto:1 = int]':
/usr/local/include/c++/4.9.2/functional:2149:71: required by substitution of
'templateclass _Res, class ... _ArgTypes templateclass _Functor using
_Invoke = decltype
(std::__callable_functor(declval_Functor())((declval_ArgTypes)()...))
[with _Functor = main()::lambda(auto:1) _Res = void; _ArgTypes = {int}]'
/usr/local/include/c++/4.9.2/functional:2225:9: required by substitution of
'templateclass _Functor, class std::function_Res(_ArgTypes
...)::function(_Functor) [with _Functor = main()::lambda(auto:1)
template-parameter-1-2 = missing]'
main.cpp:7:90: required from here
main.cpp:7:58: error: 'a' was not declared in this scope
std::functionvoid(int) f = [](auto b) { std::cout a , b
std::endl; };
^
/
[Bug c++/64755] Error in optimization with std::array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64755 --- Comment #3 from mednafen at gmail dot com --- It looks like your code violates strict aliasing rules. Does the code in question work as you intend it to if you compile with -fno-strict-aliasing ?
[Bug c++/64791] Generic lambda fails to implicitly capture `const` variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64791 --- Comment #2 from Tomalak Geret'kal tom at kera dot name --- Actually, I'm no longer sure that `a` *is* odr-used...
[Bug c/64790] New: gcc generates unreliable code on arm with -mstructure-size-boundary=32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64790 Bug ID: 64790 Summary: gcc generates unreliable code on arm with -mstructure-size-boundary=32 Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mittorn at sibmail dot com After rebuilding many of system libraries with -mstructure-size-boundary=32 i found that fsck.fat does not work propertly and all gtk applications does not correctly handle input and xfce4-desktop shows icons with wrong coordinates After rebuilding dosfstools and libX11 problem was solved
[Bug fortran/62044] [4.8/4.9/5 Regression] ICE in USE statement with RENAME for extended derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044 --- Comment #4 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Sun Jan 25 20:30:53 2015 New Revision: 220097 URL: https://gcc.gnu.org/viewcvs?rev=220097root=gccview=rev Log: fortran/ PR fortran/62044 * decl.c (gfc_match_derived_decl): Don't insert a new symtree element. * module.c (MOD_VERSION): Bump. (write_module): Don't write list of extensions. (read_module): Don't jump over list of extensions; don't load list of extensions. (load_derived_extensions, write_dt_extensions, write_derived_extensions): Remove. testsuite/ PR fortran/62044 * gfortran.dg/use_rename_7.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/use_rename_7.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug target/64790] gcc generates unreliable code on arm with -mstructure-size-boundary=32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64790 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |target Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- From https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/ARM-Options.html#index-mstructure-size-boundary-1270: Different values are potentially incompatible. Code compiled with one value cannot necessarily expect to work with code or libraries compiled with another value, if they exchange information using structures or unions. So not a bug as mentioned in the documentation already. You need to rebuild everything to be compatible at all.
[Bug fortran/62044] [4.8/4.9 Regression] ICE in USE statement with RENAME for extended derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62044 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mikael at gcc dot gnu.org Resolution|--- |FIXED Summary|[4.8/4.9/5 Regression] ICE |[4.8/4.9 Regression] ICE in |in USE statement with |USE statement with RENAME |RENAME for extended derived |for extended derived type |type| --- Comment #5 from Mikael Morin mikael at gcc dot gnu.org --- Fixed for 5.0. No backport to 4.9/4.8 to preserve module file compatibility. Closing.
