[Bug libstdc++/55233] libstdc++ atomic does not support hle_acquire/release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55233 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- Fixed so closing.
[Bug c++/78104] optimizer doesn't grok C++ new/delete yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78104
--- Comment #4 from Richard Biener ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Markus Trippelsdorf from comment #0)
> > A simple example:
> >
> > int main() {
> > int *ob = new int();
> > delete ob;
> > }
> >
> > clang optimizes it away:
>
> Which is funny considering what Chris Lattner wrote in PR 23383 comment #4:
> This would not be legal, there is no reason operator new can't return a
> pointer that already exists in the program.
Note optimizing away is not about aliasing but recognizing a new/delete pair.
But yes, there are (plenty of) duplicates. Just go find them...
[Bug target/78103] Failure to optimize with __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
Status|UNCONFIRMED |NEW
Version|unknown |6.2.1
Keywords||missed-optimization
Last reconfirmed||2016-10-25
Component|tree-optimization |target
CC||rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
There isn't a find-last-set builtin thus this is a target (or RTL optimization)
issue. I believe find-last-set is also computed by ffs (x & -x) so that might
be a more canonical way to express this on GIMPLE?
constexpr
unsigned long findLastSet3(unsigned long x) {
return __builtin_ffsl (x & -x);
}
_Z12findLastSet3m:
.LFB2:
.cfi_startproc
movq%rdi, %rax
movq$-1, %rdx
negq%rax
andq%rax, %rdi
bsfq%rdi, %rax
cmove %rdx, %rax
addq$1, %rax
cltq
ret
not really optimal either though.
[Bug target/78102] [5/6/7 regression] GCC refuses to generate PCMPEQQ instruction for SSE4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target||x86_64-*-*, i?86-*-*
Target Milestone|--- |5.5
--- Comment #2 from Richard Biener ---
IL before vector lowering:
pcmpeqq (const __m128i x, const __m128i y)
{
vector(2) long int _4;
:
_4 = VEC_COND_EXPR ;
return _4;
}
I suppose sse4.1 has only equality compares but not relational ones. We're
missing an optab for this special case and thus can't expand the above.
This means using GCC vector extensions in the header for the intrinsic was
a bad idea in this particular case.
[Bug debug/78100] DWARF symbols for an array sometimes missing the array length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78100 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-25 Ever confirmed|0 |1 Known to fail||7.0 --- Comment #3 from Richard Biener --- Confirmed.
[Bug middle-end/78099] Typo in sem_function::get_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78099 --- Comment #1 from Richard Biener --- Yes.
[Bug middle-end/78098] error: interrupt service routine can't be called directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78098 --- Comment #6 from Richard Biener --- Why would we be not able to tailcall in an interupt handler?
[Bug middle-end/78099] Typo in sem_function::get_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78099 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-25 Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #2 from Martin Liška --- Mine.
[Bug target/78102] [5/6/7 regression] GCC refuses to generate PCMPEQQ instruction for SSE4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102 --- Comment #3 from Marc Glisse --- (In reply to Richard Biener from comment #2) > This means using GCC vector extensions in the header for the intrinsic was > a bad idea in this particular case. Yes, the simplest fix is to revert to using the builtin for this particular intrinsic (the builtins haven't been removed, so this is just changing one line in smmintrin.h). Of course this will regress other code, and we are missing out on automatic vectorization opportunities for the same reason, expand should really be fixed (but that's indeed harder). I am a bit surprised we didn't have a testcase in the testsuite to discover that. Although I did manually test most intrinsics when I converted them, I didn't do it with the minimal flags, so there might be one or two others in the same situation as _mm_cmpeq_epi64...
[Bug middle-end/78098] error: interrupt service routine can't be called directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78098
--- Comment #7 from Martin Liška ---
> Can ICF turn foo1 into a tail call to foo2 when foo2 has an interrupt
> attribute?
Problem here is that comp_type_attributes returns 1 as
$18 = {name = 0x19d357b "interrupt", min_length = 0, max_length = 0,
decl_required = false, type_required = true, function_type_required = true,
handler = 0x1195b30 , affects_type_identity = false}
has set affects_type_identity == false. I would expect to have the flag set to
true? Is it bug?
[Bug target/78102] [5/6/7 regression] GCC refuses to generate PCMPEQQ instruction for SSE4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102 --- Comment #4 from Uroš Bizjak --- Created attachment 39877 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39877&action=edit Patch to enable generic expanders for sse-4.1 We need to enable a couple of expanders for sse-4.1. Hopefully middle-end code is smart enough to not generate unsupported instructions (there are tests for sse-4.1 vs. sse-4.2 in expander support routines). Let's see what breaks with the attached patch. The test compiles OK.
[Bug target/78102] [5/6/7 regression] GCC refuses to generate PCMPEQQ instruction for SSE4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- I'm not sure it is a good idea. Then expand_vec_cond_expr_p will return true, vectorizer will use them heavily etc. and the expander will just find out it can't expand many of those. Looking at expand_vec_cond_expr, it doesn't seem it would manage the fallback. So, either we'd need some way to differentiate between various comparison codes for vcond, the problem is that the optab already now has 2 modes and thus is expensive, adding another parameter would bloat too much. Or have on the side target hook that expand_vec_cond_expr_p/expand_vec_cmp_expr_p could use to find out what comparison codes are supported?
[Bug target/78102] [5/6/7 regression] GCC refuses to generate PCMPEQQ instruction for SSE4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102 --- Comment #6 from Jakub Jelinek --- Or, if we are ok that for SSE4.1 (and not SSE4.2) the vectorizer just won't be able to use those V2DI equality (and gt?) comparisons, then revert part of the r217608 change and fold the builtin into generic vector comparison if SSE4.2+.
[Bug target/71676] [avr] casesi won't handle switch values larger than 16 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71676 --- Comment #1 from Georg-Johann Lay --- Author: gjl Date: Tue Oct 25 08:26:59 2016 New Revision: 241503 URL: https://gcc.gnu.org/viewcvs?rev=241503&root=gcc&view=rev Log: gcc/ PR target/71676 PR target/71678 * config/avr/avr.md (casesi): Rewrite avoiding subregs of SI. gcc/testsuite/ PR target/71676 PR target/71678 * gcc.target/avr/pr71676-1.c: New test. * gcc.target/avr/pr71676-3.c: New test. * gcc.target/avr/pr71676.c: New test. * gcc.target/avr/pr71678.c: New test. Added: trunk/gcc/testsuite/gcc.target/avr/pr71676-1.c trunk/gcc/testsuite/gcc.target/avr/pr71676-3.c trunk/gcc/testsuite/gcc.target/avr/pr71676.c trunk/gcc/testsuite/gcc.target/avr/pr71678.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.md trunk/gcc/testsuite/ChangeLog
[Bug target/71678] [avr] ICE from switch / case on long long (casesi + DImode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71678 --- Comment #1 from Georg-Johann Lay --- Author: gjl Date: Tue Oct 25 08:26:59 2016 New Revision: 241503 URL: https://gcc.gnu.org/viewcvs?rev=241503&root=gcc&view=rev Log: gcc/ PR target/71676 PR target/71678 * config/avr/avr.md (casesi): Rewrite avoiding subregs of SI. gcc/testsuite/ PR target/71676 PR target/71678 * gcc.target/avr/pr71676-1.c: New test. * gcc.target/avr/pr71676-3.c: New test. * gcc.target/avr/pr71676.c: New test. * gcc.target/avr/pr71678.c: New test. Added: trunk/gcc/testsuite/gcc.target/avr/pr71676-1.c trunk/gcc/testsuite/gcc.target/avr/pr71676-3.c trunk/gcc/testsuite/gcc.target/avr/pr71676.c trunk/gcc/testsuite/gcc.target/avr/pr71678.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.md trunk/gcc/testsuite/ChangeLog
[Bug c++/64431] "-Wignored-qualifiers" warning gives misleading position in code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64431 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #7 from Paolo Carlini --- Unfortunately, I'm not actively working on this.
[Bug target/71676] [avr] casesi won't handle switch values larger than 16 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71676 --- Comment #2 from Georg-Johann Lay --- Author: gjl Date: Tue Oct 25 08:35:17 2016 New Revision: 241504 URL: https://gcc.gnu.org/viewcvs?rev=241504&root=gcc&view=rev Log: gcc/ New avt target pass to work around performance loss by PR fix. PR target/71676 PR target/71678 * config/avr/avr.md (casesi__sequence) [qi,hi]: New insn. (*cmp) [qi,qq,uqq,hi,hq,uhq,ha,uha]: Rename to cmp3. * config/avr/predicates.md (extend_operator): New. * config/avr/avr-passes.def (avr_pass_casesi): Register new pass. * config/avr/avr-protos.h (avr_casei_sequence_check_operands) (make_avr_pass_casesi): New prototypes. * config/avr/avr.c (print-rtl.h): Include it. (pass_data avr_pass_data_casesi): Data for new pass. (avr_pass_casesi): New class implementing rtl_opt_pass .avr-casesi. (make_avr_pass_casesi, avr_parallel_insn_from_insns) (avr_is_casesi_sequence, avr_casei_sequence_check_operands) (avr_optimize_casesi): New functions. gcc/testsuite/ PR target/71676 PR target/71678 * gcc.target/avr/pr71676-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/avr/pr71676-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-passes.def trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md trunk/gcc/config/avr/predicates.md trunk/gcc/testsuite/ChangeLog
[Bug target/71678] [avr] ICE from switch / case on long long (casesi + DImode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71678 --- Comment #2 from Georg-Johann Lay --- Author: gjl Date: Tue Oct 25 08:35:17 2016 New Revision: 241504 URL: https://gcc.gnu.org/viewcvs?rev=241504&root=gcc&view=rev Log: gcc/ New avt target pass to work around performance loss by PR fix. PR target/71676 PR target/71678 * config/avr/avr.md (casesi__sequence) [qi,hi]: New insn. (*cmp) [qi,qq,uqq,hi,hq,uhq,ha,uha]: Rename to cmp3. * config/avr/predicates.md (extend_operator): New. * config/avr/avr-passes.def (avr_pass_casesi): Register new pass. * config/avr/avr-protos.h (avr_casei_sequence_check_operands) (make_avr_pass_casesi): New prototypes. * config/avr/avr.c (print-rtl.h): Include it. (pass_data avr_pass_data_casesi): Data for new pass. (avr_pass_casesi): New class implementing rtl_opt_pass .avr-casesi. (make_avr_pass_casesi, avr_parallel_insn_from_insns) (avr_is_casesi_sequence, avr_casei_sequence_check_operands) (avr_optimize_casesi): New functions. gcc/testsuite/ PR target/71676 PR target/71678 * gcc.target/avr/pr71676-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/avr/pr71676-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-passes.def trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.md trunk/gcc/config/avr/predicates.md trunk/gcc/testsuite/ChangeLog
[Bug target/78102] [5/6/7 regression] GCC refuses to generate PCMPEQQ instruction for SSE4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102
--- Comment #7 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #4)
> Let's see what breaks with the attached patch. The test compiles OK.
As expected, fails following test with -msse4.1:
--cut here--
typedef long long __m128i __attribute__ ((__vector_size__ (16),
__may_alias__));
typedef long long __v2di __attribute__ ((__vector_size__ (16)));
__m128i
_mm_cmpeq_epi64 (__m128i __X, __m128i __Y)
{
return (__m128i) ((__v2di)__X == (__v2di)__Y);
}
__m128i
_mm_cmpgt_epi64 (__m128i __X, __m128i __Y)
{
return (__m128i) ((__v2di)__X > (__v2di)__Y);
}
--cut here--
(In reply to Jakub Jelinek from comment #5)
> I'm not sure it is a good idea. Then expand_vec_cond_expr_p will return
> true, vectorizer will use them heavily etc. and the expander will just find
> out it can't
How about teaching these predicates to handle FAIL from the expander? Then we
can change expanders to (e.g. vcondv2di):
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index fde520f..4cd3bb2 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -11086,10 +11086,11 @@
(match_operand:V2DI 5 "general_operand")])
(match_operand:VI8F_128 1)
(match_operand:VI8F_128 2)))]
- "TARGET_SSE4_2"
+ "TARGET_SSE4_1"
{
- bool ok = ix86_expand_int_vcond (operands);
- gcc_assert (ok);
+ if (!ix86_expand_int_vcond (operands))
+FAIL;
+
DONE;
})
[Bug target/78102] [5/6/7 regression] GCC refuses to generate PCMPEQQ instruction for SSE4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102
--- Comment #8 from Jakub Jelinek ---
(In reply to Uroš Bizjak from comment #7)
> (In reply to Jakub Jelinek from comment #5)
>
> > I'm not sure it is a good idea. Then expand_vec_cond_expr_p will return
> > true, vectorizer will use them heavily etc. and the expander will just find
> > out it can't
>
> How about teaching these predicates to handle FAIL from the expander? Then
> we
> can change expanders to (e.g. vcondv2di):
>
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index fde520f..4cd3bb2 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -11086,10 +11086,11 @@
> (match_operand:V2DI 5 "general_operand")])
> (match_operand:VI8F_128 1)
> (match_operand:VI8F_128 2)))]
> - "TARGET_SSE4_2"
> + "TARGET_SSE4_1"
> {
> - bool ok = ix86_expand_int_vcond (operands);
> - gcc_assert (ok);
> + if (!ix86_expand_int_vcond (operands))
> +FAIL;
> +
>DONE;
> })
How would it expand? Repeat all the vector condition/comparison lowering code
from tree-vect-generic.c on RTL? Compared to that I think it would be simpler
to handle it in ix86_expand_int_vcond - if the only problematic mode is
V2DImode, then that might be easier than just writing code that would handle
arbitrary vectors. That still means the vectorizer believes all the
comparisons are supported and might result in really terrible code (rather than
just giving up).
[Bug target/71676] [avr] casesi won't handle switch values larger than 16 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71676 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Georg-Johann Lay --- Fixed in v7.
[Bug target/71678] [avr] ICE from switch / case on long long (casesi + DImode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71678 Georg-Johann Lay changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Georg-Johann Lay --- Fixed in v7.
[Bug target/78102] [5/6/7 regression] GCC refuses to generate PCMPEQQ instruction for SSE4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102 --- Comment #9 from Richard Biener --- For fixing the regression I'd suggest to revert the intrinsic header change (for the branches).
[Bug target/78102] [5/6/7 regression] GCC refuses to generate PCMPEQQ instruction for SSE4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102 --- Comment #10 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #8) > How would it expand? Repeat all the vector condition/comparison lowering > code from tree-vect-generic.c on RTL? Compared to that I think it would be > simpler to handle it in ix86_expand_int_vcond - if the only problematic mode > is V2DImode, then that might be easier than just writing code that would > handle arbitrary vectors. That still means the vectorizer believes all the > comparisons are supported and might result in really terrible code (rather > than just giving up). There are predicates in optabs-tree.c: expand_vec_cmp_expr_p and expand_vec_cond_expr_p) that currently only check if the insn code is available. But, you are right. These predicates don't check if the comparison code can be handled by the optab...
[Bug target/78102] [5/6/7 regression] GCC refuses to generate PCMPEQQ instruction for SSE4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102 --- Comment #11 from Richard Biener --- A separate optab for equality compares would maybe work (if the difference between 4.1 and 4.2 is really equality vs. relational compares). vcond_eq (handling both signed/unsigned obviously).
[Bug middle-end/78103] Failure to optimize with __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103 Uroš Bizjak changed: What|Removed |Added Component|target |middle-end --- Comment #3 from Uroš Bizjak --- (In reply to Richard Biener from comment #2) > There isn't a find-last-set builtin thus this is a target (or RTL > optimization) issue. I believe find-last-set is also computed by ffs (x & > -x) so that might be a more canonical way to express this on GIMPLE? Please try with -mlzcnt that expands the builtin to a single insn. But looking at a _t.optimized dump the RTL/target backend just expands what tree optimizers push to the backend. Probably a __builtin_fls needs to be introduced, to enable middle-end to fold these constructs. This is a middle-end issue, backend can't do anything there...
[Bug target/78102] [5/6/7 regression] GCC refuses to generate PCMPEQQ instruction for SSE4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102 --- Comment #12 from Uroš Bizjak --- (In reply to Richard Biener from comment #11) > A separate optab for equality compares would maybe work (if the difference > between 4.1 and 4.2 is really equality vs. relational compares). > vcond_eq (handling both signed/unsigned obviously). Yes, as shown in [1] the difference is only in the availability of PCMPGTQ [SSE 4.2] besides PCMPEQQ [SSE4.1]. This is all we have for DImode... [1] https://en.wikipedia.org/wiki/SSE4#SSE4.1
[Bug target/78102] [5/6/7 regression] GCC refuses to generate PCMPEQQ instruction for SSE4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102 --- Comment #13 from Jakub Jelinek --- Actually, now that optabs are looked up using a binary search, the argument that conv optabs are very expensive doesn't hold any longer, plus we could arrange for only defining vcond_eq and vec_cmpeq if corresponding vcond, vcondu, vec_cmp and vec_cmpu isn't supported; we'd need to pass the comparison code to the optabs-tree.c predicates, and for EQ_EXPR/NE_EXPR it would just fall back to the *eq variants.
[Bug middle-end/78103] Failure to optimize with __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- I wouldn't introduce a builtin, that would be user accessible, perhaps internal function + corresponding optab and just pattern match it.
[Bug middle-end/78103] Failure to optimize with __builtin_clzl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78103 --- Comment #5 from Richard Biener --- (In reply to Jakub Jelinek from comment #4) > I wouldn't introduce a builtin, that would be user accessible, perhaps > internal function + corresponding optab and just pattern match it. Yeah, IFN + optab is now the canonical way of doing "instruction selection" on GIMPLE. [you could even have target dependent IFNs if you manage to write a md define-insn to match.pd rule plus IFN generator skipping the optab]
[Bug target/78041] Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041 wilco at gcc dot gnu.org changed: What|Removed |Added CC||wilco at gcc dot gnu.org --- Comment #14 from wilco at gcc dot gnu.org --- Patch at: https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01926.html
[Bug target/78105] New: ICE during LTO bootstrap on AARCH64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78105
Bug ID: 78105
Summary: ICE during LTO bootstrap on AARCH64
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: tulipawn at gmail dot com
Target Milestone: ---
Using a recent gcc7 to bootstrap gcc configured with
--with-build-config=bootstrap-lto leads to an ICE:
make[4]: Leaving directory 'build-lto/aarch64-linux-gnu/libgcc'
build-lto/./gcc/xgcc -B/../build-lto/./gcc/ -B/usr/gcc7/aarch64-linux-gnu/bin/
-B/usr/gcc7/aarch64-linux-gnu/lib/ -isystem /usr/gcc7/aarch64-linux-gnu/include
-isystem /usr/gcc7/aarch64-linux-gnu/sys-include-g -O2 -O3
-mtune=cortex-a53 -fomit-frame-pointer -fipa-pta -march=armv8-a+crc
-ftree-vectorize -O2 -g -O2 -O3 -mtune=cortex-a53 -fomit-frame-pointer
-fipa-pta -march=armv8-a+crc -ftree-vectorize -DIN_GCC-W -Wall
-Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -I. -I.
-I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc
-I../../../libgcc/../include -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP
-MF _muldi3.dep -DL_muldi3 -c ../../../libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS
In file included from ../../../libgcc/libgcc2.h:513:0,
from ../../../libgcc/libgcc2.c:56:
../../../libgcc/libgcc2.c: In function ‘__multi3’:
../../../libgcc/../include/longlong.h:1637:10: internal compiler error: tree
check: expected class ‘expression’, have ‘binary’ (bit_and_expr) in
tree_operand_check, at tree.h:3539
__ul = __ll_lowpart (u); \
^
../../../libgcc/../include/longlong.h:1660:5: note: in expansion of macro
‘umul_ppmm’
umul_ppmm (__w.s.high, __w.s.low, u, v);\
^
../../../libgcc/libgcc2.c:551:22: note: in expansion of macro ‘__umulsidi3’
DWunion w = {.ll = __umulsidi3 (uu.s.low, vv.s.low)};
^~~
../../../libgcc/../include/longlong.h:1637:10: internal compiler error:
Segmentation fault
__ul = __ll_lowpart (u); \
^
../../../libgcc/../include/longlong.h:1660:5: note: in expansion of macro
‘umul_ppmm’
umul_ppmm (__w.s.high, __w.s.low, u, v);\
^
../../../libgcc/libgcc2.c:551:22: note: in expansion of macro ‘__umulsidi3’
DWunion w = {.ll = __umulsidi3 (uu.s.low, vv.s.low)};
^~~
xgcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Makefile:488: recipe for target '_muldi3.o' failed
make[3]: *** [_muldi3.o] Error 4
make[3]: Leaving directory
'/home/odroid/gcc-svn-master/build-lto/aarch64-linux-gnu/libgcc'
Makefile:17246: recipe for target 'all-stage2-target-libgcc' failed
[Bug target/78102] [5/6/7 regression] GCC refuses to generate PCMPEQQ instruction for SSE4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102 --- Comment #14 from Jakub Jelinek --- Created attachment 39878 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39878&action=edit Untested patch for the middle-end bits Will try to add the expanders to sse.md now.
[Bug target/78041] Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041 --- Comment #15 from Bernd Edlinger --- FYI: You could merge the two alternatives into one. =?r,?&r 0, r i, i is equivalent to =?&r 0r i
[Bug target/78041] Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041 --- Comment #16 from wilco at gcc dot gnu.org --- Author: wilco Date: Tue Oct 25 10:25:28 2016 New Revision: 241508 URL: https://gcc.gnu.org/viewcvs?rev=241508&root=gcc&view=rev Log: With -fpu=neon DI mode shifts are expanded after reload. DI mode registers can either fully or partially overlap on both ARM and Thumb-2. However the shift expansion code can only deal with the full overlap case, and generates incorrect code for partial overlaps. The fix is to add new variants that support either full overlap or no overlap. gcc/ PR target/78041 * config/arm/neon.md (ashldi3_neon): Add "r 0 i" and "&r r i" variants. Remove partial overlap check for shift by 1. (ashldi3_neon): Likewise. testsuite/ * gcc.target/arm/pr78041.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr78041.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/neon.md trunk/gcc/testsuite/ChangeLog
[Bug target/78105] ICE during LTO bootstrap on AARCH64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78105 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-10-25 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Can you please attach back-trace of the ICE?
[Bug target/78041] Wrong code on ARMv7 with -mthumb -mfpu=neon-fp16 -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78041 --- Comment #17 from wilco at gcc dot gnu.org --- (In reply to Bernd Edlinger from comment #15) > FYI: You could merge the two alternatives into one. > > =?r,?&r > 0, r > i, i > > is equivalent to > > =?&r > 0r > i Yes, that seems possible. These patterns will need to be changed significantly to fix PR 77308, so this can be done as part of that work.
[Bug target/78102] [5/6/7 regression] GCC refuses to generate PCMPEQQ instruction for SSE4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #15 from Jakub Jelinek --- Created attachment 39879 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39879&action=edit gcc7-pr78102.patch Untested full patch.
[Bug target/78105] ICE during LTO bootstrap on AARCH64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78105 --- Comment #2 from PeteVine --- I've run the command in gdb but there's no stack after reproducing the crash - suggestions?
[Bug target/78105] ICE during LTO bootstrap on AARCH64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78105 --- Comment #3 from Martin Liška --- Please try to add following to your compile flags: -wrapper gdb,--args However I guess the problem is that build-lto/./gcc/xgcc binary is somehow miscompiled.
[Bug sanitizer/78106] New: ASAN can't find heap-use-after-free with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78106
Bug ID: 78106
Summary: ASAN can't find heap-use-after-free with -O1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: marxin at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Target Milestone: ---
Running following code snippet:
int *variable;
void release()
{
__builtin_free (variable);
}
int main2(int argc)
{
*variable = 2;
if (argc <= 5)
asm volatile ("call release");
*variable = 2;
__builtin_abort ();
return 0;
}
int main(int argc, char **argv)
{
variable = __builtin_malloc (sizeof(int));
return main2(argc);
}
$ gcc asm-test.c -fsanitize=address -O1 && ./a.out
Aborted (core dumped)
$ gcc asm-test.c -fsanitize=address -O0 && ./a.out
=
==7550==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020eff0
at pc 0x00400885 bp 0x7fff26b46520 sp 0x7fff26b46518
WRITE of size 4 at 0x6020eff0 thread T0
#0 0x400884 in main2 (/tmp/a.out+0x400884)
#1 0x4008be in main (/tmp/a.out+0x4008be)
#2 0x7ff63783a290 in __libc_start_main (/lib64/libc.so.6+0x20290)
#3 0x400719 in _start (/tmp/a.out+0x400719)
...
I'm having patch for that that I'll send shortly.
[Bug target/78105] ICE during LTO bootstrap on AARCH64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78105 --- Comment #4 from PeteVine --- That helped, running gdb --args manually wasn't working obviously: Program received signal SIGSEGV, Segmentation fault. _Unwind_GetGR (index=29, context=0x7fae00) at ../../../libgcc/unwind-dw2.c:240 240 return * (_Unwind_Ptr *) (_Unwind_Internal_Ptr) val; (gdb) bt #0 _Unwind_GetGR (index=29, context=0x7fae00) at ../../../libgcc/unwind-dw2.c:240 #1 _Unwind_GetPtr (index=29, context=0x7fae00) at ../../../libgcc/unwind-dw2.c:251 #2 uw_update_context_1 (context=context@entry=0x7fb260, fs=fs@entry=0x7fb620) at ../../../libgcc/unwind-dw2.c:1410 #3 0x0125f8ac in uw_update_context (fs=0x7fb620, context=0x7fb260) at ../../../libgcc/unwind-dw2.c:1502 #4 _Unwind_Backtrace (trace=0x11a2c70 , trace_argument=0x7fbcc0) at ../../../libgcc/unwind.inc:303 #5 0x011a2e88 in backtrace_full (state=0x7fb7fae000, skip=, callback=, error_callback=, data=) at ../../libbacktrace/backtrace.c:127 #6 0x009a84a4 in diagnostic_action_after_output (context=context@entry=0x1658a18 , diag_kind=) at ../../gcc/diagnostic.c:496 #7 0x009a864c in diagnostic_report_diagnostic (context=0x1658a18 , diagnostic=diagnostic@entry=0x7fbdb0) at ../../gcc/diagnostic.c:956 #8 0x009a8a78 in diagnostic_impl (richloc=richloc@entry=0x7fbe38, opt=opt@entry=-1, gmsgid=gmsgid@entry=0x12d33c8 "tree check: expected class %qs, have %qs (%s) in %s, at %s:%d", ap=ap@entry=0x7fbe28, kind=kind@entry=DK_ICE) at ../../gcc/diagnostic.c:1070 #9 0x009a8b28 in internal_error (gmsgid=0x12d33c8 "tree check: expected class %qs, have %qs (%s) in %s, at %s:%d") at ../../gcc/diagnostic.c:1381 #10 0x00b5b8d0 in tree_class_check_failed (node=, cl=, file=, line=3539, function=0x14184e8 <_ZZ18tree_operand_checkP9tree_nodeiPKciS2_E12__FUNCTION__.lto_priv.3174> "tree_operand_check") at ../../gcc/tree.c:9792 #11 0x007aa1bc in expr_check(tree_node*, char const*, int, char const*) () at ../../gcc/tree.h:3210 #12 tree_operand_check(tree_node*, int, char const*, int, char const*) (__g=, __l=, __f=, __i=, __t=) at ../../gcc/tree.h:3539 #13 extract_ops_from_tree(tree_node*, tree_code*, tree_node**, tree_node**, tree_node**) (expr=, subcode_p=subcode_p@entry=0x7fc044, op1_p=op1_p@entry=0x7fc058, op2_p=op2_p@entry=0x7fc050, op3_p=op3_p@entry=0x7fc048) at ../../gcc/gimple-expr.c:532 #14 0x007b92ec in gimple_build_assign(tree_node*, tree_node*) (lhs=0x7fb70feab0, rhs=) at ../../gcc/gimple.c:395 #15 0x0086f6c8 in gimplify_modify_expr (expr_p=expr_p@entry=0x7fb70f3ce8, pre_p=pre_p@entry=0x7fc548, post_p=post_p@entry=0x7fc210, want_value=want_value@entry=true) at ../../gcc/gimplify.c:5423 #16 0x0085a10c in gimplify_expr (expr_p=0x7fb70f3ce8, pre_p=pre_p@entry=0x7fc548, post_p=0x7fc210, post_p@entry=0x0, gimple_test_f=gimple_test_f@entry=0x81eeb8 , fallback=fallback@entry=0) at ../../gcc/gimplify.c:10998 #17 0x0085ff40 in gimplify_stmt (stmt_p=, seq_p=seq_p@entry=0x7fc548) at ../../gcc/gimplify.c:6260 #18 0x0085a5b8 in gimplify_statement_list (pre_p=0x7fc548, expr_p=0x7fb7118020) at ../../gcc/gimplify.c:1553 #19 gimplify_expr (expr_p=0x7fb7118020, pre_p=pre_p@entry=0x7fc548, post_p=0x7fc3e0, post_p@entry=0x0, gimple_test_f=gimple_test_f@entry=0x81eeb8 , fallback=fallback@entry=0) at ../../gcc/gimplify.c:11411 #20 0x0085ff40 in gimplify_stmt (stmt_p=stmt_p@entry=0x7fb7118020, seq_p=0x7fc548, seq_p@entry=0x7fc5d8) at ../../gcc/gimplify.c:6260 #21 0x0086c32c in gimplify_bind_expr (expr_p=expr_p@entry=0x7fb70f3e80, pre_p=pre_p@entry=0x7fc9b8) at ../../gcc/gimplify.c:1155 #22 0x00859cb8 in gimplify_expr (expr_p=0x7fb70f3e80, pre_p=pre_p@entry=0x7fc9b8, post_p=0x7fc680, post_p@entry=0x0, gimple_test_f=gimple_test_f@entry=0x81eeb8 , fallback=fallback@entry=0) at ../../gcc/gimplify.c:11197 #23 0x0085ff40 in gimplify_stmt (stmt_p=, seq_p=seq_p@entry=0x7fc9b8) at ../../gcc/gimplify.c:6260 #24 0x0085a5b8 in gimplify_statement_list (pre_p=0x7fc9b8, expr_p=0x7fb7118080) at ../../gcc/gimplify.c:1553 #25 gimplify_expr (expr_p=0x7fb7118080, pre_p=pre_p@entry=0x7fc9b8, post_p=0x7fc850, post_p@entry=0x0, gimple_test_f=gimple_test_f@entry=0x81eeb8 , fallback=fallback@entry=0) at ../../gcc/gimplify.c:11411 #26 0x0085ff40 in gimplify_stmt (stmt_p=stmt_p@entry=0x7fb7118080, seq_p=0x7fc9b8, seq_p@entry=0x7fca48) at ../../gcc/gimplify.c:6260 #27 0x0086c32c in gimplify_bind_expr (expr_p=expr_p@entry=0x7fcd28, pre_p=pre_p@entry=0x7fd8f8) at ../../gcc/gimplify.c:1155 #28 0x00859cb8 in gimplify_expr (expr_p=0x7fcd28, expr_p@entry=0x7fcdf8, pre_p=pre_p@entry=0x7fd8f8, post_p=post_p@entry=0x7fcf20, gimple_test_f=gimple_test_f@entry=0x81eeb8 , fallback=fallback@entry
[Bug sanitizer/78106] ASAN can't find heap-use-after-free with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78106 --- Comment #1 from Martin Liška --- Patch has been just sent: https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02010.html
[Bug ipa/78099] Typo in sem_function::get_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78099 --- Comment #3 from Martin Liška --- Author: marxin Date: Tue Oct 25 12:20:19 2016 New Revision: 241510 URL: https://gcc.gnu.org/viewcvs?rev=241510&root=gcc&view=rev Log: Fix 2 typos in IPA ICF pass * gcc.dg/ipa/ipa-icf-32.c: Removed one scanned pattern. Martin Liska PR ipa/78099 * common.opt: Mark flag_ipa_icf_variables as Optimization flag. * ipa-icf.c (sem_function::get_hash): Add target optimization node to hash. Modified: trunk/gcc/ChangeLog trunk/gcc/common.opt trunk/gcc/ipa-icf.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/ipa/ipa-icf-32.c
[Bug ipa/78099] Typo in sem_function::get_hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78099 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed.
[Bug gcov-profile/78086] FAIL: gcc.misc-tests/gcov-1.c, etc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78086 --- Comment #2 from dave.anglin at bell dot net --- On 2016-10-24, at 4:53 AM, marxin at gcc dot gnu.org wrote: > However, 'cannot open data file, assuming not executed' message is very > suspicious. The .gcda files are not being generated. Investigating. -- John David Anglin dave.ang...@bell.net
[Bug sanitizer/77982] deadlock in asan thread initialization/interception.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982 --- Comment #7 from Pawel Sikora --- (In reply to Maxim Ostapenko from comment #6) > The attached testcase works for me with current trunk GCC: > > max@max:/tmp/bug$ make > rm -f m *.so > ~/install/master/bin/g++ -fuse-ld=gold -g2 -Og -flto -fsanitize=address > s.cpp -shared -o s.so -fPIC > ~/install/master/bin/g++ -fuse-ld=gold -g2 -Og -flto -fsanitize=address > m.cpp -o m > max@max:/tmp/bug$ LD_LIBRARY_PATH=/home/max/install/master/lib64 ./m > initializing library... > done. > thread started. > max@max:/tmp/bug$ echo $? > 0 strange, i've tested gcc-trunk and it locks in the same way as 6.2.1. ~/src/gcc-install/usr/local/bin/g++ -v Using built-in specs. COLLECT_GCC=/home/pawels/src/gcc-install/usr/local/bin/g++ COLLECT_LTO_WRAPPER=/home/pawels/src/gcc-install/usr/local/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /home/pawels/src/gcc/configure --with-arch=x86-64 --with-linker-hash-style=gnu --disable-multilib --disable-nls --disable-libssp --disable-libgomp --disable-libquadmath --disable-libitm --disable-libcilkrts --disable-libvtv --disable-liboffloadmic --disable-libmpx --enable-tls --enable-libstdcxx-allocator=new --enable-extern-template --enable-libstdcxx-time=rt --enable-libstdcxx-threads --disable-libstdcxx-dual-abi --enable-libstdcxx-filesystem-ts=no --enable-symvers=gnu-versioned-namespace --disable-libstdcxx-pch --enable-lto --enable-plugin --enable-c99 --enable-long-long --enable-linux-futex --enable-threads=posix --enable-shared --with-pic --enable-gold --enable-__cxa_atexit --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ --enable-checking=release --with-long-double-128 --disable-cld --disable-bootstrap Thread model: posix gcc version 7.0.0 20161025 (experimental) (GCC) ~/src/gcc-install/usr/local/bin/g++ -fuse-ld=gold -g2 -Og -fsanitize=address -Wl,-rpath,/home/pawels/src/gcc-install/usr/local/lib64 -flto s.cpp -shared -o s.so -fPIC -pthread ~/src/gcc-install/usr/local/bin/g++ -fuse-ld=gold -g2 -Og -fsanitize=address -Wl,-rpath,/home/pawels/src/gcc-install/usr/local/lib64 -flto m.cpp -o m -ldl [pawels@pawels]~/src/bug% ./m initializing library... ^C
[Bug sanitizer/77982] deadlock in asan thread initialization/interception.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982 --- Comment #8 from Maxim Ostapenko --- (In reply to Pawel Sikora from comment #7) > (In reply to Maxim Ostapenko from comment #6) > > The attached testcase works for me with current trunk GCC: > > > > max@max:/tmp/bug$ make > > rm -f m *.so > > ~/install/master/bin/g++ -fuse-ld=gold -g2 -Og -flto -fsanitize=address > > s.cpp -shared -o s.so -fPIC > > ~/install/master/bin/g++ -fuse-ld=gold -g2 -Og -flto -fsanitize=address > > m.cpp -o m > > max@max:/tmp/bug$ LD_LIBRARY_PATH=/home/max/install/master/lib64 ./m > > initializing library... > > done. > > thread started. > > max@max:/tmp/bug$ echo $? > > 0 > > > strange, i've tested gcc-trunk and it locks in the same way as 6.2.1. > > > ~/src/gcc-install/usr/local/bin/g++ -v > Using built-in specs. > COLLECT_GCC=/home/pawels/src/gcc-install/usr/local/bin/g++ > COLLECT_LTO_WRAPPER=/home/pawels/src/gcc-install/usr/local/bin/../libexec/ > gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper > Target: x86_64-pc-linux-gnu > Configured with: /home/pawels/src/gcc/configure --with-arch=x86-64 > --with-linker-hash-style=gnu --disable-multilib --disable-nls > --disable-libssp --disable-libgomp --disable-libquadmath --disable-libitm > --disable-libcilkrts --disable-libvtv --disable-liboffloadmic > --disable-libmpx --enable-tls --enable-libstdcxx-allocator=new > --enable-extern-template --enable-libstdcxx-time=rt > --enable-libstdcxx-threads --disable-libstdcxx-dual-abi > --enable-libstdcxx-filesystem-ts=no --enable-symvers=gnu-versioned-namespace > --disable-libstdcxx-pch --enable-lto --enable-plugin --enable-c99 > --enable-long-long --enable-linux-futex --enable-threads=posix > --enable-shared --with-pic --enable-gold --enable-__cxa_atexit > --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ > --enable-checking=release --with-long-double-128 --disable-cld > --disable-bootstrap > Thread model: posix > gcc version 7.0.0 20161025 (experimental) (GCC) > > ~/src/gcc-install/usr/local/bin/g++ -fuse-ld=gold -g2 -Og -fsanitize=address > -Wl,-rpath,/home/pawels/src/gcc-install/usr/local/lib64 -flto s.cpp -shared > -o s.so -fPIC -pthread > ~/src/gcc-install/usr/local/bin/g++ -fuse-ld=gold -g2 -Og -fsanitize=address > -Wl,-rpath,/home/pawels/src/gcc-install/usr/local/lib64 -flto m.cpp -o m -ldl > > [pawels@pawels]~/src/bug% ./m > initializing library... > ^C Hm, perhaps environment issue. What version of Glibc do you use?
[Bug sanitizer/77982] deadlock in asan thread initialization/interception.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982 --- Comment #9 from Pawel Sikora --- (In reply to Maxim Ostapenko from comment #8) > Hm, perhaps environment issue. What version of Glibc do you use? glibc-2.23.1-10.fc24.x86_64
[Bug sanitizer/78106] ASAN can't find heap-use-after-free with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78106 --- Comment #2 from Martin Liška --- Author: marxin Date: Tue Oct 25 14:16:10 2016 New Revision: 241511 URL: https://gcc.gnu.org/viewcvs?rev=241511&root=gcc&view=rev Log: Fix not caught use-after-scope with -O1 (PR sanitize/78106) PR sanitizer/78106 * sanopt.c (imm_dom_path_with_freeing_call): Handle gasm statements as they can also contain possibly a freeing call. PR sanitizer/78106 * gcc.dg/asan/pr78106.c: New test. Added: trunk/gcc/testsuite/gcc.dg/asan/pr78106.c Modified: trunk/gcc/ChangeLog trunk/gcc/sanopt.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/78058] Complex initialization of nested std::optional does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78058 --- Comment #1 from Andrzej Krzemienski --- Fore some background, the bug is caused by GCC correctly implementing p0032r2. Technically GCC is compliant with N4604, however the tags as specified in 20.2 are buggy, as can be seen in the initial example, and as expressed in National Body comments CH 3 and FI 7 (in p0488r0).
[Bug sanitizer/78106] ASAN can't find heap-use-after-free with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78106 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Fixed on trunk.
[Bug middle-end/78098] error: interrupt service routine can't be called directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78098
--- Comment #8 from H.J. Lu ---
(In reply to Martin Liška from comment #7)
> > Can ICF turn foo1 into a tail call to foo2 when foo2 has an interrupt
> > attribute?
>
> Problem here is that comp_type_attributes returns 1 as
>
> $18 = {name = 0x19d357b "interrupt", min_length = 0, max_length = 0,
> decl_required = false, type_required = true, function_type_required = true,
> handler = 0x1195b30 bool*)>, affects_type_identity = false}
>
> has set affects_type_identity == false. I would expect to have the flag set
> to true? Is it bug?
I have a patch for them.
[Bug middle-end/78098] error: interrupt service routine can't be called directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78098 --- Comment #9 from H.J. Lu --- (In reply to Richard Biener from comment #6) > Why would we be not able to tailcall in an interupt handler? We need to verify that the only instruction in an interrupt handler is a tail call to another interrupt handler. On the other hand, this interrupt handler isn't really needed at all.
[Bug middle-end/78098] error: interrupt service routine can't be called directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78098 --- Comment #10 from Martin Liška --- (In reply to H.J. Lu from comment #9) > (In reply to Richard Biener from comment #6) > > Why would we be not able to tailcall in an interupt handler? > > We need to verify that the only instruction in an interrupt handler > is a tail call to another interrupt handler. On the other hand, > this interrupt handler isn't really needed at all. That can be vefief by fact that the symbol should have only one call (tail call) and set node->icf_merged == true.
[Bug target/78102] [5/6/7 regression] GCC refuses to generate PCMPEQQ instruction for SSE4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102 --- Comment #16 from Marc Glisse --- (In reply to Jakub Jelinek from comment #6) > Or, if we are ok that for SSE4.1 (and not SSE4.2) the vectorizer just won't > be able to use those V2DI equality (and gt?) comparisons, then revert part > of the r217608 change and fold the builtin into generic vector comparison > if SSE4.2+. Yeah, actually, if it is just the one instruction on one minor subtarget, that sounds fine to me. But now that you have written this great patch that handles the situation perfectly, that's even better :-) Thanks.
[Bug other/61439] contrib/download_prerequisites script does not verify integrity of packages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61439 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #8 from Jeffrey A. Law --- Fixed on the trunk.
[Bug sanitizer/77982] deadlock in asan thread initialization/interception.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77982 --- Comment #10 from Maxim Ostapenko --- (In reply to Pawel Sikora from comment #9) > (In reply to Maxim Ostapenko from comment #8) > > > Hm, perhaps environment issue. What version of Glibc do you use? > > glibc-2.23.1-10.fc24.x86_64 Reproduced with current trunk Glibc: max@max:/tmp/bug$ make rm -f m *.so ~/install/master/bin/g++ -g2 -Og -flto -fsanitize=address -L/home/max/install/glibc/usr/lib -L/home/max/install/glibc/lib -I/home/max/install/glibc/include -Wl,-rpath=/home/max/install/glibc/lib -Wl,--dynamic-linker=/home/max/install/glibc/lib/ld-2.24.90.so s.cpp -shared -o s.so -fPIC ~/install/master/bin/g++ -g2 -Og -flto -fsanitize=address -L/home/max/install/glibc/usr/lib -L/home/max/install/glibc/lib -I/home/max/install/glibc/include -Wl,-rpath=/home/max/install/glibc/lib -Wl,--dynamic-linker=/home/max/install/glibc/lib/ld-2.24.90.so m.cpp -o m max@max:/tmp/bug$ LD_LIBRARY_PATH=/home/max/install/master/lib64/ ./m initializing library... ^C Seems to be ASan + recent Glibc (probably 2.23+) issue.
[Bug c/65452] strcmp (foo, foo) could give a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65452 --- Comment #8 from Marek Polacek --- Created attachment 39880 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39880&action=edit Wsame-arguments I'm attaching a patch to implement a warning for this, named -Wsame-arguments. The problem is that the C++ FE doesn't have good location information for arguments of functions, so the warning's not really useful for C++. And another problem is that constants/decls don't have location information, so there might be false positives.
[Bug c/65452] strcmp (foo, foo) could give a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65452
--- Comment #9 from Marek Polacek ---
Testcase:
#include
#define STR1 "str"
#define STR2 "str"
#define S1 (s)
#define S2 (s)
int
f (const char *s)
{
int r = 0;
r += strcmp (s, s) == 0;
r += __builtin_strcmp (s, s) == 0;
r += strcmp ("s", "s") == 0;
r += __builtin_strcmp ("s", "s") == 0;
r += strcmp ((const char *) 0, "s") == 0;
r += __builtin_strcmp ((const char *) 0, "s") == 0;
r += strcmp ((const char *) 0, (const char *) 0) == 0;
r += __builtin_strcmp ((const char *) 0, (const char *) 0) == 0;
r += strcmp (STR1, STR2) == 0;
r += __builtin_strcmp (STR1, STR2) == 0;
r += strcmp (STR1, "str") == 0;
r += __builtin_strcmp (STR1, "str") == 0;
r += strcmp ("str", STR2) == 0;
r += __builtin_strcmp ("str", STR2) == 0;
r += strcmp (S1, S2) == 0;
r += __builtin_strcmp (S1, S2) == 0;
r += strcmp (S1, s) == 0;
r += __builtin_strcmp (S1, s) == 0;
r += strcmp (s, S2) == 0;
r += __builtin_strcmp (s, S2) == 0;
return r;
}
[Bug c/65452] strcmp (foo, foo) could give a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65452
--- Comment #10 from Marek Polacek ---
And another
#include
struct S {
int val;
};
int
f (struct S *sym1, struct S *sym2 __attribute__((unused)))
{
return memcmp (&sym1->val, &sym1->val, sizeof (sym1->val));
}
#define N 0
#define M 0
int
f2 (void)
{
extern const char *a[];
return __builtin_strcmp (a[N], a[M]);
}
[Bug classpath/29304] autoconf should be used in libjava to check for fabs, fabsf and scalbn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29304 --- Comment #2 from Eric Gallager --- GCJ has been removed from GCC 7. So "wontfix"?
[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 --- Comment #12 from Eric Gallager --- GCJ has been removed from GCC 7. But on the other hand this isn't really so much a java bug itself as it is an unwinding bug that java just happened to be the one to tickle. So is it worth keeping this bug open?
[Bug target/48097] new Throw_2 failures in libjava under Xcode 4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097 --- Comment #13 from Iain Sandoe --- (In reply to Eric Gallager from comment #12) > GCJ has been removed from GCC 7. But on the other hand this isn't really so > much a java bug itself as it is an unwinding bug that java just happened to > be the one to tickle. So is it worth keeping this bug open? agreed it's an unwinder bug, I suppose we need a non-Java reproducer. As of Darwin11, nothing should be using the libgcc_s unwinder (and really it shouldn't be used for darwin10). The broken unwinder in the darwin9 libgcc_s can't be easily fixed (44107) - and the resolution there is to update the installed lib. It's possible that we're going to struggle to get a fix unless/until we can make output compatible with the compact unwinder. We can leave this open, but as stated, someone should try to find a non-Java reproducer.
[Bug target/78102] [5/6/7 regression] GCC refuses to generate PCMPEQQ instruction for SSE4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102
--- Comment #17 from Jakub Jelinek ---
Author: jakub
Date: Tue Oct 25 16:26:12 2016
New Revision: 241525
URL: https://gcc.gnu.org/viewcvs?rev=241525&root=gcc&view=rev
Log:
PR target/78102
* optabs.def (vcondeq_optab, vec_cmpeq_optab): New optabs.
* optabs.c (expand_vec_cond_expr): For comparison codes
EQ_EXPR and NE_EXPR, attempt vcondeq_optab as fallback.
(expand_vec_cmp_expr): For comparison codes
EQ_EXPR and NE_EXPR, attempt vec_cmpeq_optab as fallback.
* optabs-tree.h (expand_vec_cmp_expr_p, expand_vec_cond_expr_p):
Add enum tree_code argument.
* optabs-query.h (get_vec_cmp_eq_icode, get_vcond_eq_icode): New
inline functions.
* optabs-tree.c (expand_vec_cmp_expr_p): Add CODE argument. For
CODE EQ_EXPR or NE_EXPR, attempt to use vec_cmpeq_optab as
fallback.
(expand_vec_cond_expr_p): Add CODE argument. For CODE EQ_EXPR or
NE_EXPR, attempt to use vcondeq_optab as fallback.
* tree-vect-generic.c (expand_vector_comparison,
expand_vector_divmod, expand_vector_condition): Adjust
expand_vec_cmp_expr_p and expand_vec_cond_expr_p callers.
* tree-vect-stmts.c (vectorizable_condition,
vectorizable_comparison): Likewise.
* tree-vect-patterns.c (vect_recog_mixed_size_cond_pattern,
check_bool_pattern, search_type_for_mask_1): Likewise.
* expr.c (do_store_flag): Likewise.
* doc/md.texi (@code{vec_cmpeq@var{m}@var{n}},
@code{vcondeq@var{m}@var{n}}): Document.
* config/i386/sse.md (vec_cmpeqv2div2di, vcondeqv2di):
New expanders.
testsuite/
* gcc.target/i386/pr78102.c: New test.
Added:
trunk/gcc/testsuite/gcc.target/i386/pr78102.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/sse.md
trunk/gcc/doc/md.texi
trunk/gcc/expr.c
trunk/gcc/optabs-query.h
trunk/gcc/optabs-tree.c
trunk/gcc/optabs-tree.h
trunk/gcc/optabs.c
trunk/gcc/optabs.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vect-generic.c
trunk/gcc/tree-vect-patterns.c
trunk/gcc/tree-vect-stmts.c
[Bug tree-optimization/78107] New: verify_gimple failed ICE caused by Gimple loop splitting patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78107 Bug ID: 78107 Summary: verify_gimple failed ICE caused by Gimple loop splitting patch Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: tamar.christina at arm dot com Target Milestone: --- Created attachment 39881 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39881&action=edit test file The commit r241374 is causing an ICE during verify_gimple on aarch64. Erorr: "/build-aarch64-none-linux-gnu/install/bin/aarch64-none-linux-gnu-gcc" -mcpu=xgene1+crypto -O3 -c /temp/reduce.1131.c temp/reduce.1131.c: In function ‘foo’: temp/reduce.1131.c:1:5: error: non-trivial conversion in unary operation int foo(const char *fmt) ^~~ int char * _42 = -str_33; /temp/reduce.1131.c:1:5: internal compiler error: verify_gimple failed 0xb4411c verify_gimple_in_cfg(function*, bool) /src/gcc/gcc/tree-cfg.c:5208 0xa2b3fa execute_function_todo /src/gcc/gcc/passes.c:1965 0xa2be35 execute_todo /src/gcc/gcc/passes.c:2015
[Bug target/78102] [5/6 regression] GCC refuses to generate PCMPEQQ instruction for SSE4.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78102 Jakub Jelinek changed: What|Removed |Added Summary|[5/6/7 regression] GCC |[5/6 regression] GCC |refuses to generate PCMPEQQ |refuses to generate PCMPEQQ |instruction for SSE4.1 |instruction for SSE4.1 --- Comment #18 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug libfortran/77473] New PRNG causes regressions on DragonFly BSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77473 Rimvydas (RJ) changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Rimvydas (RJ) --- Fixed at OS level by removing pthread_cancel stub from libc.
[Bug fortran/72770] [7 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:263
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72770 --- Comment #8 from vehre at gcc dot gnu.org --- Author: vehre Date: Tue Oct 25 17:01:58 2016 New Revision: 241528 URL: https://gcc.gnu.org/viewcvs?rev=241528&root=gcc&view=rev Log: gcc/testsuite/ChangeLog: 2016-10-25 Andre Vehreschild PR fortran/72770 * gfortran.dg/alloc_comp_class_5.f03: Added test again that caused this pr. gcc/fortran/ChangeLog: 2016-10-25 Andre Vehreschild PR fortran/72770 * class.c (find_intrinsic_vtab): No longer encode the string length into vtype's name and use the char's kind for the size instead of the string_length time the size. * trans-array.c (gfc_conv_ss_descriptor): For deferred length char arrays the dynamically sized type needs to be declared. (build_class_array_ref): Address the i-th array element by multiplying it with the _vptr->_size and the _len to make sure char arrays are addressed correctly. * trans-expr.c (gfc_conv_intrinsic_to_class): Made comment more precise. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/alloc_comp_class_5.f03
[Bug c++/54548] unclear error message for ambiguous type lookup.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54548 Pawel Sikora changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||5.4.1 Resolution|--- |FIXED --- Comment #1 from Pawel Sikora --- pr54548.cpp: In function 'int main()': pr54548.cpp:6:13: error: expected type-specifier before 'X' new X(); ^
[Bug libstdc++/63746] i/o fragmentation inside basic_filebuf::xsputn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63746 Pawel Sikora changed: What|Removed |Added Known to fail||4.9.2, 5.4.1, 6.2.1 --- Comment #2 from Pawel Sikora --- ping. could you review/apply attached trivial patch?
[Bug other/52609] -Wstrict-aliasing / missed diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52609 Pawel Sikora changed: What|Removed |Added Known to fail||7.0 --- Comment #5 from Pawel Sikora --- still missed diagnostics for bug2(): pr52609.c: In function ‘bug1’: pr52609.c:6:9: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing] return *(float*)(&buffer[0]); // warning. ^~
[Bug classpath/29304] autoconf should be used in libjava to check for fabs, fabsf and scalbn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29304 Andrew John Hughes changed: What|Removed |Added CC||gnu_andrew at member dot fsf.org --- Comment #3 from Andrew John Hughes --- No, this is a Classpath bug. Nothing to do with GCJ.
[Bug c++/52231] [missed optimization/diagnostics] address-of-reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52231 Pawel Sikora changed: What|Removed |Added Status|NEW |RESOLVED Known to work||6.2.1, 7.0 Resolution|--- |FIXED --- Comment #8 from Pawel Sikora --- s% ~/src/gcc-install/usr/local/bin/g++ pr52231.cpp -c -O2 -Wall -Wextra -fdump-tree-optimized -fdiagnostics-color=never pr52231.cpp: In function 'void bar()': pr52231.cpp:7:17: warning: the compiler can assume that the address of 'a' will never be NULL [-Waddress] if ( &a == 0 )// <== useless stmt (not diagnosed/not optimized) ~~~^~~~
[Bug tree-optimization/77309] [5/6/7 Regression] wrong code at -Os and above on x86_64-linux-gnu (in the 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77309 Bernd Schmidt changed: What|Removed |Added Status|NEW |ASSIGNED CC||bernds at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |bernds at gcc dot gnu.org --- Comment #2 from Bernd Schmidt --- Investigating.
[Bug target/77974] m68k bootstrap failure due to -Werror=implicit-fallthrough
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77974 Andreas Schwab changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andreas Schwab --- Fixed in r241512.
[Bug plugins/46577] cp-tree.h: c-common.h/hard-reg-set.h needs to be installed into plugin directory.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46577 Pawel Sikora changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Pawel Sikora --- comment #1
[Bug target/77308] surprisingly large stack usage for sha512 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #13 from Bernd Edlinger ---
I am still trying to understand why thumb1 seems to outperform thumb2.
Obviously thumb1 does not have the shiftdi3 pattern,
but even if I remove these from thumb2, the result is still
not par with thumb2. Apparently other patterns still produce di
values that are not enabled with thumb1, they are
xordi3 and anddi3, these are often used. Then there is
adddi3 that is enabled in thumb1 and thumb2, I also disabled
this one, and now the sha512 gets down to inclredible 1152
bytes frame (-Os -march=armv7 -mthumb -float-abi=soft):
I know this is a hack, but 1K stack is what we should expect...
--- arm.md 2016-10-25 19:54:16.425736721 +0200
+++ arm.md.orig 2016-10-17 19:46:59.0 +0200
@@ -448,7 +448,7 @@
(plus:DI (match_operand:DI 1 "s_register_operand" "")
(match_operand:DI 2 "arm_adddi_operand" "")))
(clobber (reg:CC CC_REGNUM))])]
- "TARGET_EITHER && !TARGET_THUMB2"
+ "TARGET_EITHER"
"
if (TARGET_THUMB1)
{
@@ -465,7 +465,7 @@
(plus:DI (match_operand:DI 1 "s_register_operand" "%0, 0, r, 0, r")
(match_operand:DI 2 "arm_adddi_operand" "r, 0, r, Dd, Dd")))
(clobber (reg:CC CC_REGNUM))]
- "TARGET_32BIT && !TARGET_NEON && !TARGET_THUMB2"
+ "TARGET_32BIT && !TARGET_NEON"
"#"
"TARGET_32BIT && reload_completed
&& ! (TARGET_NEON && IS_VFP_REGNUM (REGNO (operands[0])))"
@@ -2256,7 +2256,7 @@
[(set (match_operand:DI 0 "s_register_operand" "")
(and:DI (match_operand:DI 1 "s_register_operand" "")
(match_operand:DI 2 "neon_inv_logic_op2" "")))]
- "TARGET_32BIT && !TARGET_THUMB2"
+ "TARGET_32BIT"
""
)
@@ -2264,7 +2264,7 @@
[(set (match_operand:DI 0 "s_register_operand" "=w,w
,&r,&r,&r,&r,?w,?w")
(and:DI (match_operand:DI 1 "s_register_operand" "%w,0 ,0 ,r ,0 ,r
,w ,0")
(match_operand:DI 2 "arm_anddi_operand_neon" "w ,DL,r ,r
,De,De,w ,DL")))]
- "TARGET_32BIT && !TARGET_IWMMXT && !TARGET_THUMB2"
+ "TARGET_32BIT && !TARGET_IWMMXT"
{
switch (which_alternative)
{
@@ -3310,7 +3310,7 @@
[(set (match_operand:DI 0 "s_register_operand" "")
(xor:DI (match_operand:DI 1 "s_register_operand" "")
(match_operand:DI 2 "arm_xordi_operand" "")))]
- "TARGET_32BIT && !TARGET_THUMB2"
+ "TARGET_32BIT"
""
)
@@ -3318,7 +3318,7 @@
[(set (match_operand:DI 0 "s_register_operand" "=w,&r,&r,&r,&r,?w")
(xor:DI (match_operand:DI 1 "s_register_operand" "%w ,0,r ,0 ,r ,w")
(match_operand:DI 2 "arm_xordi_operand" "w ,r ,r ,Dg,Dg,w")))]
- "TARGET_32BIT && !TARGET_IWMMXT && !TARGET_THUMB2"
+ "TARGET_32BIT && !TARGET_IWMMXT"
{
switch (which_alternative)
{
@@ -3983,7 +3983,7 @@
[(set (match_operand:DI0 "s_register_operand" "")
(ashift:DI (match_operand:DI 1 "s_register_operand" "")
(match_operand:SI 2 "general_operand" "")))]
- "TARGET_32BIT && !TARGET_THUMB2"
+ "TARGET_32BIT"
"
if (TARGET_NEON)
{
@@ -4058,7 +4058,7 @@
[(set (match_operand:DI 0 "s_register_operand" "")
(ashiftrt:DI (match_operand:DI 1 "s_register_operand" "")
(match_operand:SI 2 "reg_or_int_operand" "")))]
- "TARGET_32BIT && !TARGET_THUMB2"
+ "TARGET_32BIT"
"
if (TARGET_NEON)
{
What do you think?
[Bug middle-end/78098] error: interrupt service routine can't be called directly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78098
--- Comment #11 from H.J. Lu ---
(In reply to Martin Liška from comment #10)
> (In reply to H.J. Lu from comment #9)
> > (In reply to Richard Biener from comment #6)
> > > Why would we be not able to tailcall in an interupt handler?
> >
> > We need to verify that the only instruction in an interrupt handler
> > is a tail call to another interrupt handler. On the other hand,
> > this interrupt handler isn't really needed at all.
>
> That can be vefief by fact that the symbol should have only one call (tail
> call) and set node->icf_merged == true.
My current change:
@ -28014,7 +28026,19 @@ ix86_expand_call (rtx retval, rtx fnaddr, rtx callarg1,
if (fndecl
&& (lookup_attribute ("interrupt",
TYPE_ATTRIBUTES (TREE_TYPE (fndecl)
- error ("interrupt service routine can't be called directly");
+ {
+if (lookup_attribute ("interrupt",
+ TYPE_ATTRIBUTES (TREE_TYPE (cfun->decl
+ {
+error ("interrupt service routine %q+D can't be called directly",
+ fndecl);
+inform (input_location,
+ "is interrupt service routine %q+D equivalent to %q+D?",
+ fndecl, cfun->decl);
+ }
+else
+ error ("interrupt service routine can't be called directly");
+ }
}
else
fndecl = NULL_TREE;
gives
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -Os -m32 -mno-sse -mno-mmx
-mno-80387 -S -o foo1.s foo1.i
foo1.i: In function ‘foo1’:
foo1.i:10:33: error: interrupt service routine ‘foo2’ can't be called directly
__attribute__((interrupt)) void foo2 (void *p)
^~~~
foo1.i:4:6: note: is interrupt service routine ‘foo2’ equivalent to ‘foo1’?
void foo1 (void *p)
^~~~
Makefile:34: recipe for target 'foo1.s' failed
make: *** [foo1.s] Error 1
[hjl@gnu-6 pr78098]$
Since foo1 == foo2, there is no reason for foo2 at all. It reduces
the code size, which is very important in embedded environment.
[Bug target/77308] surprisingly large stack usage for sha512 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308 --- Comment #14 from Wilco --- (In reply to Bernd Edlinger from comment #13) > I am still trying to understand why thumb1 seems to outperform thumb2. > > Obviously thumb1 does not have the shiftdi3 pattern, > but even if I remove these from thumb2, the result is still > not par with thumb2. Apparently other patterns still produce di > values that are not enabled with thumb1, they are > xordi3 and anddi3, these are often used. Then there is > adddi3 that is enabled in thumb1 and thumb2, I also disabled > this one, and now the sha512 gets down to inclredible 1152 > bytes frame (-Os -march=armv7 -mthumb -float-abi=soft): > > I know this is a hack, but 1K stack is what we should expect... > > --- arm.md 2016-10-25 19:54:16.425736721 +0200 > +++ arm.md.orig 2016-10-17 19:46:59.0 +0200 > @@ -448,7 +448,7 @@ > (plus:DI (match_operand:DI 1 "s_register_operand" "") >(match_operand:DI 2 "arm_adddi_operand" ""))) > (clobber (reg:CC CC_REGNUM))])] > - "TARGET_EITHER && !TARGET_THUMB2" > + "TARGET_EITHER" So you're actually turning the these instructions off for Thumb-2? What does it do instead then? Do the number of instructions go down? I noticed that with or without -mfpu=neon, using -marm is significantly smaller than -mthumb. Most of the extra instructions appear to be moves, which means something is wrong (I would expect Thumb-2 to do better as it supports LDRD with larger offsets than ARM).
[Bug fortran/78108] New: Generic type-bound operator conflicts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78108 Bug ID: 78108 Summary: Generic type-bound operator conflicts Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: damian at sourceryinstitute dot org Target Milestone: --- As demonstrate below, binding a generic operator to a type leads to a name clash if the operator is associated with a procedure whose implementation is in a submodule. (A workaround is to move procedure implementation into the module.) $ cat generic-tbo-submodule.f90 module foo_interface implicit none type foo contains procedure :: add generic :: operator(+) => add end type interface real module function add(lhs,rhs) implicit none class(foo), intent(in) :: lhs,rhs end function end interface end module submodule(foo_interface) foo_implementation contains module procedure add end procedure end submodule $ gfortran -c generic-tbo-submodule.f90 generic-tbo-submodule.f90:15:23: submodule(foo_interface) foo_implementation 1 Error: Entity ‘add’ at (1) is already present in the interface $ gfortran --version GNU Fortran (GCC) 7.0.0 20160904 (experimental)
[Bug other/78109] New: ld with -pie creates a shared library instead of an executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78109 Bug ID: 78109 Summary: ld with -pie creates a shared library instead of an executable Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: hadrien-gcc at psydk dot org Target Milestone: --- I'm using Ubuntu 16.10 which ships with gcc version 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12) I found that most executables in /bin and /usr/bin are actually not real executable (per their ELF header), but shared libraries. This can be seen by browsing a directory containing programs with Nautilus, the default file explorer: the file icon will be different according to the type of program (a purple lozenge for a real executable, a generic white page icon for a shared library). None of those not-really-executables can be started from the file explorer by double-clicking but they can be started from a terminal. It is also possible to run "readelf -h filename" to quickly look at the type reported by the ELF header: EXEC for executable, DYN for shared library. When I build myself any program that uses "ld" (a C++ program, but also a Rust program, which uses GNU ld for linking), the result will be a shared library instead of an executable. I built a minimal program in verbose mode and found that the "-pie" option is used by default when linking on my system. If I remove the "-pie" option, the generated file is, as expected, a real executable. gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 6.2.0-5ubuntu12' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-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 --enable-multilib --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 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12)
[Bug tree-optimization/42195] missed xnor optimization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42195
Pawel Sikora changed:
What|Removed |Added
Known to fail||7.0
--- Comment #2 from Pawel Sikora ---
bool xnor_1(bool, bool) (bool x, bool y)
{
bool _3;
:
_3 = x_1(D) == y_2(D);
return _3;
}
bool xnor_2(bool, bool) (bool x, bool y)
{
bool _1;
bool _4;
:
_1 = ~y_2(D);
_4 = _1 ^ x_3(D);
return _4;
}
[Bug middle-end/34212] spurious warning: value computed is not used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34212 Pawel Sikora changed: What|Removed |Added Status|NEW |RESOLVED Known to work||6.2.1 Resolution|--- |FIXED Known to fail|| --- Comment #15 from Pawel Sikora --- gcc-6.2.1
[Bug sanitizer/78106] ASAN can't find heap-use-after-free with -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78106 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Tue Oct 25 20:15:20 2016 New Revision: 241537 URL: https://gcc.gnu.org/viewcvs?rev=241537&root=gcc&view=rev Log: PR sanitizer/78106 * gcc.dg/asan/pr78106.c: Add -ffat-lto-objects to dg-options. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/asan/pr78106.c
[Bug fortran/45516] [F08] allocatable compontents of recursive type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45516 --- Comment #8 from Paul Thomas --- Author: pault Date: Tue Oct 25 20:37:05 2016 New Revision: 241539 URL: https://gcc.gnu.org/viewcvs?rev=241539&root=gcc&view=rev Log: 2016-10-25 Paul Thomas PR fortran/45516 * class.c (gfc_find_derived_vtab): Detect recursive allocatable derived type components. If present, add '_deallocate' field to the vtable and build the '__deallocate' function. * decl.c (build_struct): Allow recursive allocatable derived type components for -std=f2008 or more. (gfc_match_data_decl): Accept these derived types. * expr.c (gfc_has_default_initializer): Ditto. * resolve.c (resolve_component): Make sure that the vtable is built for these derived types. * trans-array.c(structure_alloc_comps) : Use the '__deallocate' function for the automatic deallocation of these types. * trans-expr.c : Generate the deallocate accessor. * trans.h : Add its prototype. * trans-types.c (gfc_get_derived_type): Treat the recursive allocatable components in the same way as the corresponding pointer components. 2016-10-25 Paul Thomas PR fortran/45516 * gfortran.dg/class_2.f03: Set -std=f2003. * gfortran.dg/finalize_21.f90: Modify tree-dump. * gfortran.dg/recursive_alloc_comp_1.f08: New test. * gfortran.dg/recursive_alloc_comp_2.f08: New test. * gfortran.dg/recursive_alloc_comp_3.f08: New test. * gfortran.dg/recursive_alloc_comp_4.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/recursive_alloc_comp_1.f08 trunk/gcc/testsuite/gfortran.dg/recursive_alloc_comp_2.f08 trunk/gcc/testsuite/gfortran.dg/recursive_alloc_comp_3.f08 trunk/gcc/testsuite/gfortran.dg/recursive_alloc_comp_4.f08 Modified: trunk/gcc/fortran/class.c trunk/gcc/fortran/decl.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-types.c trunk/gcc/fortran/trans.h trunk/gcc/testsuite/gfortran.dg/class_2.f03 trunk/gcc/testsuite/gfortran.dg/finalize_21.f90
[Bug target/77308] surprisingly large stack usage for sha512 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308 --- Comment #15 from Bernd Edlinger --- (In reply to Wilco from comment #14) > (In reply to Bernd Edlinger from comment #13) > > I am still trying to understand why thumb1 seems to outperform thumb2. > > > > Obviously thumb1 does not have the shiftdi3 pattern, > > but even if I remove these from thumb2, the result is still > > not par with thumb2. Apparently other patterns still produce di > > values that are not enabled with thumb1, they are > > xordi3 and anddi3, these are often used. Then there is > > adddi3 that is enabled in thumb1 and thumb2, I also disabled > > this one, and now the sha512 gets down to inclredible 1152 > > bytes frame (-Os -march=armv7 -mthumb -float-abi=soft): > > > > I know this is a hack, but 1K stack is what we should expect... > > > > --- arm.md 2016-10-25 19:54:16.425736721 +0200 > > +++ arm.md.orig 2016-10-17 19:46:59.0 +0200 > > @@ -448,7 +448,7 @@ > > (plus:DI (match_operand:DI 1 "s_register_operand" "") > >(match_operand:DI 2 "arm_adddi_operand" ""))) > > (clobber (reg:CC CC_REGNUM))])] > > - "TARGET_EITHER && !TARGET_THUMB2" > > + "TARGET_EITHER" > > So you're actually turning the these instructions off for Thumb-2? What does > it do instead then? Do the number of instructions go down? > > I noticed that with or without -mfpu=neon, using -marm is significantly > smaller than -mthumb. Most of the extra instructions appear to be moves, > which means something is wrong (I would expect Thumb-2 to do better as it > supports LDRD with larger offsets than ARM). The LDRD may be another detail, that contributes to this mess. Maybe, just a guess, the LDRD does simply not work with DI registers, but only with two SI, at least the pattern looks like targeting two SI moves? I would expect the n DI mode registers to fall apart into 2n SI mode registers, that should happen when the expansion finds no DI pattern, it falls back to use SI pattern, and each SI mode register can be spilled independently and can be dead independently of the other half word. And frankly I am still puzzled, what my brutal patch did to the stack size, and it reduced the code size: frame 2328 -> 1152 code size 0x4188 -> 0x3ab8 I have not tested if the code works, but I assume that it should, or fail in an ICE, which is apparently not the case.
[Bug tree-optimization/78107] [7 Regression] verify_gimple failed ICE caused by Gimple loop splitting patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78107 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2016-10-25 CC||marxin at gcc dot gnu.org, ||matz at gcc dot gnu.org Summary|verify_gimple failed ICE|[7 Regression] |caused by Gimple loop |verify_gimple failed ICE |splitting patch |caused by Gimple loop ||splitting patch Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Highly probably dup of PR78088. Michael will commit shortly patch that should fix that: https://gcc.gnu.org/ml/gcc-patches/2016-10/msg02031.html
[Bug other/78109] ld with -pie creates a shared library instead of an executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78109 --- Comment #1 from joseph at codesourcery dot com --- That's what a PIE is: an ET_DYN that can be directly executed. There is no bug here.
[Bug other/78109] ld with -pie creates a shared library instead of an executable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78109 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- >None of those not-really-executables can be started from the file explorer by >double-clicking but they can be started from a terminal. That is a bug in the file explorer rather than anything else. If the program is marked as executable in the file system the kernel will try to detect which file format it is (but not executable vs shared library though) and use the elf loader that way.
[Bug target/78105] ICE during LTO bootstrap on AARCH64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78105 Andrew Pinski changed: What|Removed |Added Keywords||build, wrong-code --- Comment #5 from Andrew Pinski --- Gimplifying is crashing that is interesting.
[Bug target/78105] ICE during LTO bootstrap on AARCH64 with extra options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78105 --- Comment #6 from Andrew Pinski --- > -O3 -mtune=cortex-a53 -fomit-frame-pointer -fipa-pta -march=armv8-a+crc > -ftree-vectorize Can you show the exact command line which you used to configure GCC? And the output of env? A normal bootstrap with --with-build-config=bootstrap-lto without those options and it worked.
[Bug target/77308] surprisingly large stack usage for sha512 on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77308
--- Comment #16 from Bernd Edlinger ---
Wow.
look at this:
Index: arm.md
===
--- arm.md (revision 241539)
+++ arm.md (working copy)
@@ -448,7 +448,7 @@
(plus:DI (match_operand:DI 1 "s_register_operand" "")
(match_operand:DI 2 "arm_adddi_operand" "")))
(clobber (reg:CC CC_REGNUM))])]
- "TARGET_EITHER"
+ "TARGET_EITHER && !TARGET_THUMB2"
"
if (TARGET_THUMB1)
{
@@ -2256,7 +2256,7 @@
[(set (match_operand:DI 0 "s_register_operand" "")
(and:DI (match_operand:DI 1 "s_register_operand" "")
(match_operand:DI 2 "neon_inv_logic_op2" "")))]
- "TARGET_32BIT"
+ "TARGET_32BIT && !TARGET_THUMB2"
""
)
@@ -3310,7 +3310,7 @@
[(set (match_operand:DI 0 "s_register_operand" "")
(xor:DI (match_operand:DI 1 "s_register_operand" "")
(match_operand:DI 2 "arm_xordi_operand" "")))]
- "TARGET_32BIT"
+ "TARGET_32BIT && !TARGET_THUMB2"
""
)
Thus only disabling adddi3, anddi3, and xordi3,
but not ashldi3 and ashrdi3, because they are not part of the problem.
reduces
arm-linux-gnueabihf-gcc -mthumb -march=armv7 -mfloat-abi=soft -Os -c pr77308.c
frame = 272 (about the same as aarch64 had!)
code = 0x374C
sha512_block_data_order:
@ args = 0, pretend = 0, frame = 272
@ frame_needed = 0, uses_anonymous_args = 0
Maybe I am dreaming, or something is completely wrong now...
[Bug gcov-profile/78086] FAIL: gcc.misc-tests/gcov-1.c, etc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78086
--- Comment #3 from dave.anglin at bell dot net ---
On 2016-10-25, at 8:29 AM, dave.anglin at bell dot net wrote:
>> However, 'cannot open data file, assuming not executed' message is very
>> suspicious.
>
> The .gcda files are not being generated. Investigating.
The problem was introduced in r240529:
2016-09-27 Martin Liska
PR gcov-profile/7970
PR gcov-profile/16855
PR gcov-profile/44779
* coverage.c (build_gcov_exit_decl): New function.
(coverage_obj_init): Call the function and generate __gcov_exit
destructor.
* doc/gcov.texi: Document when __gcov_exit function is called.
It appears to be issue with constructors/destructors. With gcc-6, we had:
.section.ctors,"aw",@progbits
.align 8
.dword P%_GLOBAL__sub_I_65535_0_noop
_GLOBAL__sub_I_65535_0_noop is called.
With r240529, we have:
.section.ctors.1,"aw",@progbits
.align 8
.dword P%_GLOBAL__sub_I_65534_0_noop
[...]
.section.dtors.1,"aw",@progbits
.align 8
.dword P%_GLOBAL__sub_D_65534_1_noop
Neither the constructor or destructor is called.
It looks to me like the priority change has changed the constructor section:
default_named_section_asm_out_constructor (rtx symbol, int priority)
{
section *sec;
if (priority != DEFAULT_INIT_PRIORITY)
sec = get_cdtor_priority_section (priority,
/*constructor_p=*/true);
else
sec = get_section (".ctors", SECTION_WRITE, NULL);
assemble_addr_to_section (symbol, sec);
}
Probably, defining CTORS_SECTION_ASM_OP and DTORS_SECTION_ASM_OP will fix.
On the other hand, I think SUPPORTS_INIT_PRIORITY is 0.
--
John David Anglin dave.ang...@bell.net
[Bug target/43750] -march unconditionally added to COLLECT_GCC_OPTIONS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43750 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #7 from Andrew Pinski --- Fixed in glibc a long time ago.
[Bug rtl-optimization/43515] Basic block re-ordering unconditionally disabled for Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43515 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization --- Comment #5 from Andrew Pinski --- Hmm, I think this changed recently (within the last 2 years).
[Bug libstdc++/78110] New: freestanding libstdc++ fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78110 Bug ID: 78110 Summary: freestanding libstdc++ fails to compile Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de Target Milestone: --- configured with: ../gcc-7-20161023/configure --prefix=/home/ed/gnu/arm-eabi --target=arm-eabi --with-newlib --enable-languages=c,c++ --disable-hosted-libstdcxx --disable-__cxa-atexit --disable-libquadmath --disable-decimal-float libtool: compile: /home/ed/gnu/gcc-build-arm/./gcc/xgcc -shared-libgcc -B/home/ed/gnu/gcc-build-arm/./gcc -nostdinc++ -L/home/ed/gnu/gcc-build-arm/arm-eabi/libstdc++-v3/src -L/home/ed/gnu/gcc-build-arm/arm-eabi/libstdc++-v3/src/.libs -L/home/ed/gnu/gcc-build-arm/arm-eabi/libstdc++-v3/libsupc++/.libs -B/home/ed/gnu/arm-eabi/arm-eabi/bin/ -B/home/ed/gnu/arm-eabi/arm-eabi/lib/ -isystem /home/ed/gnu/arm-eabi/arm-eabi/include -isystem /home/ed/gnu/arm-eabi/arm-eabi/sys-include -I/home/ed/gnu/gcc-7-20161023/libstdc++-v3/../libgcc -I/home/ed/gnu/gcc-build-arm/arm-eabi/libstdc++-v3/include/arm-eabi -I/home/ed/gnu/gcc-build-arm/arm-eabi/libstdc++-v3/include -I/home/ed/gnu/gcc-7-20161023/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=new_opa.lo -g -O2 -std=gnu++1z -c ../../../../gcc-7-20161023/libstdc++-v3/libsupc++/new_opa.cc -o new_opa.o ../../../../gcc-7-20161023/libstdc++-v3/libsupc++/new_opa.cc:51:10: fatal error: malloc.h: No such file or directory #include ^~ compilation terminated. make[4]: *** [new_opa.lo] Error 1 make[4]: Leaving directory `/home/ed/gnu/gcc-build-arm/arm-eabi/libstdc++-v3/libsupc++' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/ed/gnu/gcc-build-arm/arm-eabi/libstdc++-v3' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/ed/gnu/gcc-build-arm/arm-eabi/libstdc++-v3' make[1]: *** [all-target-libstdc++-v3] Error 2 make[1]: Leaving directory `/home/ed/gnu/gcc-build-arm' make: *** [all] Error 2 _GLIBCXX_HAVE_MEMALIGN is 1, but freestanding does not have malloc.h not sure about memalign, likely not available.
[Bug libstdc++/78110] freestanding libstdc++ fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78110
--- Comment #1 from Bernd Edlinger ---
oh, I am using eCos and that is based on newlib but on a very very old one.
I don't know what happens when I dont use --with-newlib, but I can try...
configure.ac has this:
# First, test for "known" system libraries. We may be using newlib even
# on a hosted environment.
if test "x${with_newlib}" = "xyes"; then
os_include_dir="os/newlib"
AC_DEFINE(HAVE_HYPOT)
...
AC_DEFINE(HAVE_ICONV)
AC_DEFINE(HAVE_MEMALIGN)
why are these not compile-time checks, to see if the headers are available?
