[Bug target/67636] New: [6 Regression][SH] gcc.target/sh/pr54236-1.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67636
Bug ID: 67636
Summary: [6 Regression][SH] gcc.target/sh/pr54236-1.c failures
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
CC: segher at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
The following new failure popped up a while ago.
non-SH2A:
FAIL: gcc.target/sh/pr54236-1.c scan-assembler-times negc 2
SH2A:
FAIL: gcc.target/sh/pr54236-1.c scan-assembler-times bld 1
FAIL: gcc.target/sh/pr54236-1.c scan-assembler-times movt 1
The failing sub test is:
int
test_07 (int *vec)
{
/* Must not see a 'sett' or 'addc' here.
This is a case where combine tries to produce
'a + (0 - b) + 1' out of 'a - b + 1'.
On non-SH2A there is a 'tst + negc', on SH2A a 'bld + movt'. */
int z = vec[0];
int vi = vec[1];
int zi = vec[2];
if (zi != 0 && z < -1)
vi -= (((vi >> 7) & 0x01) << 1) - 1;
return vi;
}
For non-SH2A GCC 5 produces:
mov.l @(8,r4),r1
tst r1,r1
bt/s.L9
mov.l @(4,r4),r0
mov.l @r4,r1
mov #-1,r2
cmp/gt r1,r2
bf/s.L9
tst #128,r0
mov #-1,r1
negcr1,r1
add r1,r1 r1 = T << 1
sub r1,r0 r0 = r0 - (T << 1)
add #1,r0 r0 = r0 - (T << 1) + 1
.L9:
rts
nop
For SH2A GCC 5 produces:
mov.l @(8,r4),r1
mov.l @(4,r4),r0
tst r1,r1
bt.s.L9
mov #-1,r1
mov.l @r4,r2
cmp/ge r1,r2
bt.s.L9
bld #7,r0
movtr1
add r1,r1
sub r1,r0
add #1,r0
.L9:
rts/n
Now, trunk produces for both, non-SH2A and SH2A (only the relevant BB):
...
bt.s.L9
mov r0,r1
shlr2 r1
shlr2 r1
shlr2 r1
mov #2,r2
and r2,r1
sub r1,r0
add #1,r0
In GCC 5 combine was using zero_extract for the bit test. Now it tries
something like:
Failed to match this instruction:
(set (reg/v:SI 162 [ vi ])
(plus:SI (minus:SI (reg/v:SI 162 [ vi ])
(and:SI (lshiftrt:SI (reg/v:SI 162 [ vi ])
(const_int 6 [0x6]))
(const_int 2 [0x2])))
(const_int 1 [0x1])))
i.e. x - ((y >> 6) & 2) + 1
Both GCC 5 and trunk are not optimal.
On non-SH2A the T bit calculation goes like this:
r0 = r0 - 2*(1 - T) - 1
= r0 - 2 + 2*T - 1
= r0 - 3 + 2*T
which could be realized as:
tst #128,r0
mov #-3,r1
movtr2
addcr1,r0
add r2,r0
On SH2A the bld insn can be used:
bld #7,r0
movtr2
mov #-1,r1
addcr1,r0
add r2,r0
If the constants for addc are hoisted out of the loop, this results in 4 insns
for non-SH2A and for SH2A. However, without the zero_extract this is a bit
clunky to catch.
It'd be easier if this sub-rtx:
(and:SI (lshiftrt:SI (reg/v:SI 162 [ vi ])
(const_int 6 [0x6]))
(const_int 2 [0x2])))
... was matched as:
(ashift:SI (zero_extract:SI (reg/v:SI 162 [ vi ])
(const_int 1)
(const_int 7))
(const_int 1))
[Bug libstdc++/67632] explicit instantiation omits copy constructor and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67632 Markus Trippelsdorf changed: What|Removed |Added CC||redi at gcc dot gnu.org Component|c++ |libstdc++ --- Comment #4 from Markus Trippelsdorf --- Might be a libstdc++ issue. Adding CC. markus@x4 /tmp % g++ -c -O0 -std=c++11 t.cpp markus@x4 /tmp % nm t.o | grep _ZNSt13unordered_mapIiiSt4hashIiESt8equal_toIiESaISt4pairIKiiEEEC1ERKS8_ W _ZNSt13unordered_mapIiiSt4hashIiESt8equal_toIiESaISt4pairIKiiEEEC1ERKS8_RKS7_ markus@x4 /tmp % g++ -Wl,--no-demangle -O0 -std=c++11 t.cpp x.cpp /tmp/ccMHoCTz.o:x.cpp:function _Z4copyRKSt13unordered_mapIiiSt4hashIiESt8equal_toIiESaISt4pairIKiiEEE: error: undefined reference to '_ZNSt13unordered_mapIiiSt4hashIiESt8equal_toIiESaISt4pairIKiiEEEC1ERKS8_' collect2: error: ld returned 1 exit status markus@x4 /tmp % c++filt _ZNSt13unordered_mapIiiSt4hashIiESt8equal_toIiESaISt4pairIKiiEEEC1ERKS8_ std::unordered_map, std::equal_to, std::allocator > >::unordered_map(std::unordered_map, std::equal_to, std::allocator > > const&) markus@x4 /tmp % c++filt _ZNSt13unordered_mapIiiSt4hashIiESt8equal_toIiESaISt4pairIKiiEEEC1ERKS8_RKS7_ std::unordered_map, std::equal_to, std::allocator > >::unordered_map(std::unordered_map, std::equal_to, std::allocator > > const&, std::allocator > const&)
[Bug c/28901] -Wunused-variable ignores unused const initialised variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901 --- Comment #13 from Manuel López-Ibáñez --- (In reply to Paul Eggert from comment #12) > (In reply to Manuel López-Ibáñez from comment #11) > > > Another alternative is to only warn if the variable is defined in the main > > file (MAIN_FILE_P) as opposed to an included file. > > Thanks, this is a reasonable suggestion; it would fix the cry-wolf problem > for tzcode, which is what prompted me to object to the original proposal. > > The alternative of littering the code with many instances of __attribute__ > ((unused)) (or is it __attribute ((used)? I can never remember) is less > appealing. https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#index-g_t_0040code_007bunused_007d-variable-attribute-3382 unused This attribute, attached to a variable, means that the variable is meant to be possibly unused. GCC does not produce a warning for this variable. used This attribute, attached to a variable with static storage, means that the variable must be emitted even if it appears that the variable is not referenced. (I think "used" should also silence the warning).
[Bug libstdc++/67085] priority queue should not copy comparators when calling push_heap and pop_heap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67085 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2015-09-19 Resolution|WONTFIX |--- Ever confirmed|0 |1 --- Comment #5 from Jonathan Wakely --- Although the workarounds suggested here are not valid, I think we can do better internally in the library, maybe by adding a private __push_heap that takes a reference and using that instead of push_heap.
[Bug target/64345] [SH] Improve single bit extraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64345 --- Comment #4 from Oleg Endo --- (In reply to Oleg Endo from comment #2) > A recent change in the middle end has triggered this: > > FAIL: gcc.target/sh/pr54236-1.c scan-assembler-times negc 2 > I've created a new PR 67636 for this.
[Bug target/67636] [6 Regression][SH] gcc.target/sh/pr54236-1.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67636 --- Comment #1 from Oleg Endo --- See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64345#c2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64345#c3
[Bug libstdc++/67632] explicit instantiation omits copy constructor and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67632 --- Comment #5 from Jonathan Wakely --- Not sure how it can be a libstdc++ issue, the copy constructor exists, the library can't force the front-end to instantiate it. I'm travelling without access to proper computers, but as far as I can tell from coliru.stacked-crooked.com it links fine using clang++ -stdlib=libstdc++ (with libstdc++ 5.2.0).
[Bug libstdc++/67632] explicit instantiation omits copy constructor and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67632 --- Comment #6 from Markus Trippelsdorf --- (In reply to Jonathan Wakely from comment #5) > Not sure how it can be a libstdc++ issue, the copy constructor exists, the > library can't force the front-end to instantiate it. > > I'm travelling without access to proper computers, but as far as I can tell > from coliru.stacked-crooked.com it links fine using clang++ > -stdlib=libstdc++ (with libstdc++ 5.2.0). No, it doesn't for -O0. Higher -O values make the issue go away. markus@x4 /tmp % clang++ -stdlib=libc++ -O0 -std=c++11 t.cpp x.cpp markus@x4 /tmp % clang++ -Wl,--no-demangle -O0 -std=c++11 t.cpp x.cpp /tmp/x-5ef538.o:x.cpp:function _Z4copyRKSt13unordered_mapIiiSt4hashIiESt8equal_toIiESaISt4pairIKiiEEE: error: undefined reference to '_ZNSt13unordered_mapIiiSt4hashIiESt8equal_toIiESaISt4pairIKiiEEEC1ERKS8_' clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation) markus@x4 /tmp % icpc -Wl,--no-demangle -O0 -std=c++11 t.cpp x.cpp /tmp/icpcMamJXz.o:x.cpp:function _Z4copyRKSt13unordered_mapIiiSt4hashIiESt8equal_toIiESaISt4pairIKiiEEE: error: undefined reference to '_ZNSt13unordered_mapIiiSt4hashIiESt8equal_toIiESaISt4pairIKiiEEEC1ERKS8_'
[Bug libstdc++/67632] explicit instantiation omits copy constructor and others
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67632 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-19 Ever confirmed|0 |1 --- Comment #7 from Jonathan Wakely --- (In reply to Markus Trippelsdorf from comment #6) > No, it doesn't for -O0. Higher -O values make the issue go away. Oh, ok, weird. I probably won't be able to look into this further until Monday.
[Bug ipa/66181] [6 Regression]: /usr/include/bits/types.h:134:16: ICE: verify_type failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66181 --- Comment #16 from Oleg Endo --- Can this be closed?
[Bug target/55298] [SH] Add support to disable FPU usage for individual functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55298 --- Comment #2 from Oleg Endo --- Something similar has been done for ARM: https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00939.html
[Bug target/67637] New: [SH] Optimize {shll,shlr} {bf/bt} sequences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67637
Bug ID: 67637
Summary: [SH] Optimize {shll,shlr} {bf/bt} sequences
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
There are some cases, where shll or shlr insns are used to conditionally branch
on the MSB or LSB of a reg.
The shll case has been mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59533#c7
In the CSiBE set, lpgparse shows the shlr variant:
.L1573:
neg r1,r1
shldr1,r4
mov r4,r1
shlrr1
bf .L2333
On SH2A the bld insn can be used in this case. On non-SH2A it might be better
(at least for lpgparse) to use a tst #1,r0, because r0 is unused at that time.
[Bug target/52795] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE on {x86_64,i386}-apple-darwin{10,11} at -m64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52795 --- Comment #5 from Dominique d'Humieres --- This PR seems fixed on x86_64-apple-darwin14.5 with Xcode 7.
[Bug debug/65809] [5/6 Regression] FAIL: gcc.dg/debug/pr65771.c -gstabs+* -O* (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65809 --- Comment #11 from Dominique d'Humieres --- This PR seems to have been fixed between r224139 (test for excess errors) and 224288 (UNSUPPORTED).
[Bug testsuite/41666] FAIL: g++.dg/debug/dwarf2/ scan-assembler-times "main".*external name 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41666 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-19 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- This PR seems fixed on x86_64-apple-darwin14.5 with Xcode 7.
[Bug target/66609] [sh] Relative address expressions bind at as-time, even if symbol is weak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66609 --- Comment #6 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #5) > Kaz, do you think it's OK to backport this to GCC 5? It looks like the > patch is not so intrusive... Changing relocation is always intrusive, I think. I won't object to backport it, though. The patch does the right thing and will affect only very limited cases.
[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67573 --- Comment #10 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #9) > I think this should be backported to GCC 5. Even if it might not be > triggered often, there is a possibility for silent wrong-code bugs. OK, will do.
[Bug inline-asm/64951] g++ generates incorrect code when using a register variable within a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64951
Guillaume Delugré changed:
What|Removed |Added
Version|4.9.2 |5.2.0
--- Comment #1 from Guillaume Delugré ---
The same problem is present when using C++14 auto arguments instead of
templates:
inline void SetRdx(auto value)
{
register auto __foo asm ("rdx") = value;
asm volatile ( "" :: "r" (__foo) );
}
This code will also store the value parameter inside register rax instead of
rdx on GCC 5.2.0.
[Bug target/67638] New: [SH] ICE with nosave_low_regs ISR and -mfmovd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67638 Bug ID: 67638 Summary: [SH] ICE with nosave_low_regs ISR and -mfmovd Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target Milestone: --- Target: sh*-*-* When compiling the test cases pragma-isr-nosave_low_regs.c and attr-isr-nosave_low_regs.c in gcc.target/sh there's an ICE: attr-isr-nosave_low_regs.c: In function 'isr': attr-isr-nosave_low_regs.c:25:1: internal compiler error: in get_free_reg, at config/sh/sh.c:10204 0xd9ab6a get_free_reg ../../gcc-trunk2/gcc/config/sh/sh.c:10204 0xd9ab6a fpscr_set_from_mem(int, unsigned long*) ../../gcc-trunk2/gcc/config/sh/sh.c:10217 0xd9fe17 push_regs ../../gcc-trunk2/gcc/config/sh/sh.c:7191 0xd9fe17 sh_expand_prologue() ../../gcc-trunk2/gcc/config/sh/sh.c:7942 0xe8b53a gen_prologue() ../../gcc-trunk2/gcc/config/sh/sh.md:11649 0xd8bbc8 target_gen_prologue ../../gcc-trunk2/gcc/config/sh/sh.md:16732 0x812c7d thread_prologue_and_epilogue_insns() ../../gcc-trunk2/gcc/function.c:6119 0x8136e2 rest_of_handle_thread_prologue_and_epilogue ../../gcc-trunk2/gcc/function.c:6670 0x8136e2 execute ../../gcc-trunk2/gcc/function.c:6712 Please submit a full bug report,
[Bug middle-end/67639] New: ICE at -O1 and above on x86_64-linux-gnu in expand_gimple_basic_block, at cfgexpand.c:5697
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67639
Bug ID: 67639
Summary: ICE at -O1 and above on x86_64-linux-gnu in
expand_gimple_basic_block, at cfgexpand.c:5697
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
Target Milestone: ---
The following (invalid) code causes an ICE when compiled with the current gcc
trunk at -O1 and above on x86_64-linux-gnu in the 64-bit mode (but not in
32-bit mode).
This is a regression from 5.2.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150919 (experimental) [trunk revision 227932] (GCC)
$
$ gcc-trunk -m64 -O0 -c small.c
small.c: In function ‘foo’:
small.c:5:17: error: invalid register name for ‘x’
register long x asm ("r2") = p;
^
$ gcc-trunk -m32 -O1 -c small.c
small.c: In function ‘foo’:
small.c:5:17: error: invalid register name for ‘x’
register long x asm ("r2") = p;
^
$ gcc-5.2 -m64 -O1 -c small.c
small.c: In function ‘foo’:
small.c:5:17: error: invalid register name for ‘x’
register long x asm ("r2") = p;
^
$
$ gcc-trunk -m64 -O1 -c small.c
small.c: In function ‘foo’:
small.c:5:17: error: invalid register name for ‘x’
register long x asm ("r2") = p;
^
small.c:2:1: internal compiler error: tree check: expected ssa_name, have
var_decl in expand_gimple_basic_block, at cfgexpand.c:5697
foo (int p)
^
0xd292cc tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc-trunk/gcc/tree.c:9512
0x6f8e36 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc-trunk/gcc/tree.h:2858
0x6f8e36 expand_gimple_basic_block
../../gcc-trunk/gcc/cfgexpand.c:5697
0x6fdfc6 execute
../../gcc-trunk/gcc/cfgexpand.c:6286
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.
$
---
void
foo (int p)
{
int t;
register long x asm ("r2") = p;
__asm ("mov %0, %1;" : "=r" (t), "=r" (t), "=r" (t), "=r" (x) : "0" (x));
}
[Bug ipa/66181] [6 Regression]: /usr/include/bits/types.h:134:16: ICE: verify_type failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66181 Uroš Bizjak changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Uroš Bizjak --- (In reply to Oleg Endo from comment #16) > Can this be closed? Yes.
[Bug driver/67640] New: driver passes -fdiagnostics-color= always last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67640 Bug ID: 67640 Summary: driver passes -fdiagnostics-color= always last Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: manu at gcc dot gnu.org Target Milestone: --- The driver alters the order when passing command-line options to the compiler proper. This means that -fdiagnostics-color has no chance to disable color before the first error is emitted: $. /xgcc -B ./ ~/test.c -fdiagnostics-color=never -Wnoexcept -E -### 2>&1 | grep cc1 ./cc1 -E -quiet -iprefix ./../lib/gcc/x86_64-pc-linux-gnu/6.0.0/ -isystem ./include -isystem ./include-fixed ./test.c "-mtune=generic" "-march=x86-64" -Wnoexcept "-fdiagnostics-color=never" $ ./xgcc -B ./ ~/test.c -Wnoexcept -fdiagnostics-color=never -E -### 2>&1 | grep cc1 ./cc1 -E -quiet -iprefix ./../lib/gcc/x86_64-pc-linux-gnu/6.0.0/ -isystem ./include -isystem ./include-fixed ./test.c "-mtune=generic" "-march=x86-64" -Wnoexcept "-fdiagnostics-color=never"
[Bug libstdc++/67361] std::regex_error::what() should say something about the error_code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67361 --- Comment #3 from Tim Shen --- Author: timshen Date: Sat Sep 19 20:56:27 2015 New Revision: 227936 URL: https://gcc.gnu.org/viewcvs?rev=227936&root=gcc&view=rev Log: PR libstdc++/67361 * include/bits/regex_error.h: Add __throw_regex_error that supports string. * include/bits/regex_automaton.h: Add more specific exception messages. * include/bits/regex_automaton.tcc: Likewise. * include/bits/regex_compiler.h: Likewise. * include/bits/regex_compiler.tcc: Likewise. * include/bits/regex_scanner.h: Likewise. * include/bits/regex_scanner.tcc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/regex_automaton.h trunk/libstdc++-v3/include/bits/regex_automaton.tcc trunk/libstdc++-v3/include/bits/regex_compiler.h trunk/libstdc++-v3/include/bits/regex_compiler.tcc trunk/libstdc++-v3/include/bits/regex_error.h trunk/libstdc++-v3/include/bits/regex_scanner.tcc
[Bug bootstrap/67622] [6 regression] Solaris/SPARC bootstrap fails compiling stage2 stdc++.h.gch/O2ggnu++0x.gch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67622 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-19 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- I can reproduce.
[Bug other/67634] Can't preserve bound register in interrupt handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67634 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #1 from H.J. Lu --- Fixed on hjl/interrupt/master branch.
[Bug other/67552] [meta] x86 interrupt attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67552 Bug 67552 depends on bug 67634, which changed state. Bug 67634 Summary: Can't preserve bound register in interrupt handler https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67634 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug other/67630] ymm and zmm register aren't preserved in interrupt handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67630 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #3 from H.J. Lu --- Fixed on hjl/interrupt/master branch.
[Bug other/67552] [meta] x86 interrupt attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67552 Bug 67552 depends on bug 67630, which changed state. Bug 67630 Summary: ymm and zmm register aren't preserved in interrupt handler https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67630 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/67641] New: gcc segfaults when compiling in debug mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67641 Bug ID: 67641 Summary: gcc segfaults when compiling in debug mode Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ryan.burn at gmail dot com Target Milestone: --- Created attachment 36350 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36350&action=edit files to reproduce The below steps cause gcc to segfault when building with a recent version from trunk: g++ (GCC) 6.0.0 20150915 (experimental) Copyright (C) 2015 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. ## Steps to Reproduce 1. unpack the tartar (I couldn't reproduce if I preprocessed the code) 2. Change into the director and run the following g++ -I. -g -c -o core-test.o core-test.cpp ## Stack Trace rnburn@localhost ~/bugs/gcc_test_segfault/segfault $ /home/rnburn/local/bin/g++ -I. -g -c -o core-test.o core-test.cpp In file included from /home/rnburn/local/include/c++/6.0.0/map:61:0, from ./catch.hpp:3331, from core-test.cpp:2: /home/rnburn/local/include/c++/6.0.0/bits/stl_map.h: In instantiation of ‘class std::map, Catch::SectionTracking::TrackedSection>’: ./catch.hpp:4856:25: required from here /home/rnburn/local/include/c++/6.0.0/bits/stl_map.h:96:11: error: TYPE_CANONICAL is not compatible class map ^ asm_written unsigned SI size unit size align 32 symtab -291691504 alias set -1 canonical type 0x7f7fef0731f8 precision 32 min max values local bindings <(nil)>> value chain local bindings <(nil)>> value chain local bindings <(nil)>> value chain value context chain > readonly constant VOID file ./catch.hpp line 4811 col 13 align 1 context initial chain readonly constant VOID file ./catch.hpp line 4810 col 13 align 1 context initial chain >> context full-name "const class Catch::SectionTracking::TrackedSection" n_parents=0 use_template=0 interface-unknown pointer_to_this reference_to_this > asm_written unsigned SI size unit size align 32 symtab -291691504 alias set -1 canonical type 0x7f7fef0731f8 precision 32 min max values local bindings <(nil)>> value chain local bindings <(nil)>> value chain local bindings <(nil)>> value chain value context chain > private decl_3 VOID file ./catch.hpp line 4855 col 18 align 1 offset_align 1 context chain private decl_3 VOID file ./catch.hpp line 4854 col 21 align 1 offset_align 1 context chain >> context full-name "const mapped_type" n_parents=0 use_template=0 interface-unknown reference_to_this > /home/rnburn/local/include/c++/6.0.0/bits/stl_map.h:96:11: internal compiler error: verify_type failed 0xf4a3e9 verify_type(tree_node const*) ../../gcc/gcc/tree.c:13583 0x9ab124 gen_type_die_with_usage ../../gcc/gcc/dwarf2out.c:20707 0x9abc40 gen_type_die_with_usage ../../gcc/gcc/dwarf2out.c:20805 0x9ac7a6 gen_type_die ../../gcc/gcc/dwarf2out.c:20901 0x9b905f gen_decl_die ../../gcc/gcc/dwarf2out.c:21448 0x9aaacc gen_member_die ../../gcc/gcc/dwarf2out.c:20399 0x9aaacc gen_struct_or_union_type_die ../../gcc/gcc/dwarf2out.c:20483 0x9aaacc gen_tagged_type_die ../../gcc/gcc/dwarf2out.c:20684 0x9abc0d gen_type_die_with_usage ../../gcc/gcc/dwarf2out.c:20846 0x9ac7a6 gen_type_die ../../gcc/gcc/dwarf2out.c:20901 0x9b8de1 gen_decl_die ../../gcc/gcc/dwarf2out.c:21487 0x9b989c dwarf2out_decl ../../gcc/gcc/dwarf2out.c:21937 0x9b9bcb dwarf2out_type_decl ../../gcc/gcc/dwarf2out.c:21647 0xbe84af rest_of_type_compilation(tree_node*, int) ../../gcc/gcc/passes.c:339 0x6cfaec finish_struct_1(tree_node*) ../../gcc/gcc/cp/class.c:6747 0x6976ac instantiate_class_template_1 ../../gcc/gcc/cp/pt.c:10201 0x6976ac instantiate_class_template(tree_node*) ../../gcc/gcc/cp/pt.c:10241 0x73c8ab complete_type(tree_node*) ../../gcc/gcc/cp/typeck.c:138 0x63c8a9 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*, decl_context, int, tree_node**) ../../gcc/gcc/cp/decl.c:11053 0x6dff15 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*, bool, tree_node*, tree_node*) ../
[Bug target/67642] New: [SH] FPSCR not saved,loaded,restored for ISRs and single-precision-only FPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67642 Bug ID: 67642 Summary: [SH] FPSCR not saved,loaded,restored for ISRs and single-precision-only FPU Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target Milestone: --- Target: sh*-*-* If the FPU is (potentially) used in ISRs, it should be brought into a consistent state and should not modify the interrupted context's FPSCR state, even if there is only a single-precision FPU (or the FPU is used as single-precision-only) and FPU mode-switching is not done. The test case gcc.target/sh/pragma-isr-trapa2.c fail when ran with -m2e, -m3e, -m2a-single-only, -m4-single-only, -m4a-single-only The other ISR related test cases seem to miss the check.
[Bug target/67643] New: [SH] ICE with ISR and -mfmovd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67643
Bug ID: 67643
Summary: [SH] ICE with ISR and -mfmovd
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
The following ...
extern void foo (void);
void __attribute__((interrupt_handler))
isr2 (void)
{
foo ();
}
compiled with -m4a -ml -mfmovd -O2 results in:
sh_tmp2.cpp: In function 'isr2':
sh_tmp2.cpp:11:1: error: unrecognizable insn:
}
^
(insn 15 14 16 2 (parallel [
(set (reg:SI 151 )
(mem/c:SI (reg:SI 1 r1) [2 __fpscr_values+4 S4 A32]))
(set (reg:SI 155 fpscr1)
(unspec_volatile:SI [
(const_int 0 [0])
] UNSPECV_FPSCR_STAT))
(set (reg:SI 154 fpscr0)
(unspec_volatile:SI [
(const_int 0 [0])
] UNSPECV_FPSCR_MODES))
]) sh_tmp2.cpp:9 -1
(expr_list:REG_UNUSED (reg:SI 155 fpscr1)
(expr_list:REG_UNUSED (reg:SI 151 )
(nil
sh_tmp2.cpp:11:1: internal compiler error: in extract_insn, at recog.c:2297
0xa18333 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-trunk2/gcc/rtl-error.c:109
0xa18369 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-trunk2/gcc/rtl-error.c:117
0x9e0c0f extract_insn(rtx_insn*)
../../gcc-trunk2/gcc/recog.c:2297
0x9e1d28 extract_constrain_insn(rtx_insn*)
../../gcc-trunk2/gcc/recog.c:2198
0x9e540e copyprop_hardreg_forward_1
../../gcc-trunk2/gcc/regcprop.c:778
0x9e618d execute
../../gcc-trunk2/gcc/regcprop.c:1268
Please submit a full bug report,
[Bug target/52394] SH Target: SH2A defunct bitops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52394
--- Comment #2 from Oleg Endo ---
The SH2A bitops seem to produce some of the insns, but it seems the generated
code is either really bad (defeating the original purpose) or broken.
For example:
volatile struct
{
union
{
unsigned char BYTE;
struct
{
unsigned char BIT7:1;
unsigned char BIT6:1;
unsigned char BIT5:1;
unsigned char BIT4:1;
unsigned char BIT3:1;
unsigned char BIT2:1;
unsigned char BIT1:1;
unsigned char BIT0:1;
}
BIT;
}
ICR0;
}
USRSTR;
int
main (unsigned char a, unsigned char b, unsigned char c)
{
USRSTR.ICR0.BIT.BIT5 |= b & 1;
return 0;
}
compiled with -m2a -mb -mbitops -O2:
mov.l .L2,r2// addr of USRSTR
mov #1,r1
and r1,r5 // b & 1
mov #0,r0
bor.b #5,@(0,r2)// T |= (bit in mem)
movtr7// r7 = T
mov.b @r2,r3// load byte
cmp/pl r7// T = r7
mov #5,r7
movtr1// r1 = T
bclr#5,r3 // clear bit 5 of loaded byte
shldr7,r1 // T << 5
or r3,r1 // OR bit
mov.b r1,@r2// write back
rts/n
It seems that this will produce funny results at the first bor.b insn because
at function entry the T bit is undefined.
The code should actually be something like this:
mov.l .L2,r2
bld #0,r5
mov #0,r0
bor.b #5,@(0,r2)
bst.b #5,@(0,r2)
[Bug target/67644] New: [SH] double load on volatile bitfield mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67644
Bug ID: 67644
Summary: [SH] double load on volatile bitfield mem
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
The following:
struct USRSTR
{
union
{
unsigned char BYTE;
struct
{
unsigned char BIT7:1;
unsigned char BIT6:1;
unsigned char BIT5:1;
unsigned char BIT4:1;
unsigned char BIT3:1;
unsigned char BIT2:1;
unsigned char BIT1:1;
unsigned char BIT0:1;
}
BIT;
}
ICR0;
};
void test_1 (volatile USRSTR* x)
{
x->ICR0.BIT.BIT5 |= 1;
}
compiled with -O2 -m4 -ml results in:
mov.b @r4,r1
mov.b @r4,r0
or #4,r0
mov.b r0,@r4
rts
nop
The double load looks wrong. With normal memory it might do no harm, but when
accessing hardware registers this might result in wrong behavior. For
instance, sometimes hardware register reads clear status bits etc.
It seems this happens only when the bitfield is read and written back. If it's
only read, there is only one load:
int test_2 (volatile USRSTR* x)
{
return x->ICR0.BIT.BIT5;
}
mov.b @r4,r0
tst #4,r0
mov #-1,r0
rts
negcr0,r0
And it happens only when there are bitfields involved:
void test_3 (volatile unsigned char* x)
{
x[0] |= 4;
}
mov.b @r4,r0
extu.b r0,r0
or #4,r0
mov.b r0,@r4
rts
nop
The problem is present on trunk and GCC 5.
[Bug c++/67641] internal error when compiling in debug mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67641 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Markus Trippelsdorf --- dup. *** This bug has been marked as a duplicate of bug 66214 ***
[Bug middle-end/66214] [6 Regression] ICE verify_type failed with -O0 -g via gen_type_die_with_usage's dwarf2out.c:20250
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66214 Markus Trippelsdorf changed: What|Removed |Added CC||ryan.burn at gmail dot com --- Comment #14 from Markus Trippelsdorf --- *** Bug 67641 has been marked as a duplicate of this bug. ***
[Bug target/67645] New: [SH] Inefficient single bit bitfield operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67645
Bug ID: 67645
Summary: [SH] Inefficient single bit bitfield operations
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
Ignoring the volatile bitfield double load issue of PR 67644, there seems to be
some room for improvements w.r.t. operations on single bit bitfields. The
examples below were compiled -m4 -ml -O2.
struct USRSTR
{
union
{
unsigned char BYTE;
struct
{
unsigned char BIT7:1;
unsigned char BIT6:1;
unsigned char BIT5:1;
unsigned char BIT4:1;
unsigned char BIT3:1;
unsigned char BIT2:1;
unsigned char BIT1:1;
unsigned char BIT0:1;
}
BIT;
}
ICR0;
};
void test_0 (volatile USRSTR* x)
{
x->ICR0.BIT.BIT5 |= 0x10;
}
mov.b @r4,r0
mov.b @r4,r2
mov #-5,r1 0b...'1011
and #4,r0 isolate bit #3 from mem
and r2,r1 clear bit #3 from mem
or r1,r0 effectively a nop
mov.b r0,@r4
rts
nop
the equivalent without bitfields:
void test_0_1 (volatile unsigned char* x)
{
x[0] |= 0;
}
mov.b @r4,r1
mov.b r1,@r4
rts
nop
void test_2 (volatile USRSTR* x, unsigned char y)
{
x->ICR0.BIT.BIT5 |= y & 1;
}
mov.b @r4,r0
mov #1,r2
mov.b @r4,r3
tst #4,r0
mov #-1,r1
and r2,r5
negcr1,r1
or r5,r1
mov r3,r5
mov #-5,r2
and r2,r5
shll2 r1
or r5,r1
mov.b r1,@r4
rts
nop
the equivalent without bitfields:
void test2_1 (volatile unsigned char* x, unsigned char y)
{
x[0] |= (y & 1) << 2;
}
mov.b @r4,r1
mov r5,r0
shll2 r0
and #4,r0
or r0,r1
mov.b r1,@r4
rts
nop
In some cases, a shift sequence as above is a good choice, especially when the
bit positions can be reached with a 1,2,8,16 shift. Although this particular
case can be slightly improved (reduce R0 reg pressure):
mov.b @r4,r1
shlrr5use T bit to do the (x & 1)
movtr5
shll2 r5
or r5,r1
mov.b r1,@r4
rts
nop
In some other cases, it might be better to not use shifts:
void test2_2 (volatile unsigned char* x, unsigned char y)
{
x[0] |= ((y >> 7) & 1) << 3;
}
currently results in:
mov r5,r0
mov #-1,r2
tst #128,r0
negcr2,r1
mov.b @r4,r3
shll2 r1
add r1,r1
or r3,r1
mov.b r1,@r4
rts
nop
which could be done as:
mov r5,r0
tst #128,r0sign extract bit through T bit...
subcr0,r0
not r0,r0 ... into r0
and #8,r0 punch out one bit at constant position
mov.b @r4,r3
or r3,r0
mov.b r0,@r4
rts
nop
Interestingly, when using 'unsigned int' instead of 'unsigned char', the code
tends to be better:
void test2_7 (volatile unsigned int* x, unsigned int y)
{
x[0] |= ((y >> 7) & 1) << 3;
}
mov r5,r0
shlr2 r0
mov.l @r4,r1
shlr2 r0
and #8,r0
or r0,r1
mov.l r1,@r4
rts
nop
[Bug target/67646] New: [SH] Improve sign extract of bit test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67646
Bug ID: 67646
Summary: [SH] Improve sign extract of bit test
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: olegendo at gcc dot gnu.org
Target Milestone: ---
Target: sh*-*-*
The following:
unsigned int test (unsigned int x)
{
return (x & 0x30) ? ~0 : 0;
}
compiled with -m4 -ml -O2 results in:
mov r4,r0
tst #48,r0
subcr0,r0
rts
not r0,r0
This is already minimal, but in some cases addc can be used:
mov r4,r0
tst #48,r0
mov #0,r1
mov #-1,r0
addcr1,r0 r0 = 0 + (-1) + T
T = 0: r0 = 0 + (-1) + 0 = -1
T = 1: r0 = 0 + (-1) + 1 = 0
If the constant 0 can be shared with some other insn, this would result in a
mov #imm8, addc sequence, which is good for SH4A, because mov #imm8 is an MT
group insn.
If the test constant is only one bit:
unsigned int test (unsigned int x)
{
return (x & 0x20) ? ~0 : 0;
}
-m4 -ml -O2:
mov r4,r0
tst #32,r0
mov #-1,r0
negcr0,r0
rts
neg r0,r0
This should result in the same code as for the constant 0x30.
[Bug tree-optimization/47679] [4.9/5/6 Regression] Strange uninitialized warning after SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47679 --- Comment #30 from Jeffrey A. Law --- AFACT the testcase in c#16 is bogus. If i is never equal to k, then opt is never assigned any value. It's then used in the conditional outside the loop. That's how it looks at the source level and that's also what it looks like in the dom2 dump.
[Bug tree-optimization/47679] [4.9/5/6 Regression] Strange uninitialized warning after SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47679 --- Comment #31 from Jeffrey A. Law --- Author: law Date: Sun Sep 20 06:37:39 2015 New Revision: 227942 URL: https://gcc.gnu.org/viewcvs?rev=227942&root=gcc&view=rev Log: [PATCH] Fix 47679 by improving jump threading PR tree-optimization/47679 * tree-ssa-dom.c (record_temporary_equivalences): No longer static. * tree-ssa-dom.h (record_temporary_equivalences): Add prototype. * tree-ssa-threadedge.c: Include tree-ssa-dom.h. (thread_through_normal_block): Use record_temporary_equivalences. PR tree-optimization/47679 * g++.dg/warn/Wuninitialized-6.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wuninitialized-6.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-dom.c trunk/gcc/tree-ssa-dom.h trunk/gcc/tree-ssa-threadedge.c
[Bug tree-optimization/47679] [4.9/5 Regression] Strange uninitialized warning after SRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47679 Jeffrey A. Law changed: What|Removed |Added Summary|[4.9/5/6 Regression]|[4.9/5 Regression] Strange |Strange uninitialized |uninitialized warning after |warning after SRA |SRA --- Comment #32 from Jeffrey A. Law --- Fixed on the trunk. Not planning to backport the patch series to any of the release branches.
