[Bug target/69072] ICE in function_arg_record_value on 7th packed structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69072 --- Comment #3 from Eric Botcazou --- Author: ebotcazou Date: Mon Jan 4 08:06:52 2016 New Revision: 232049 URL: https://gcc.gnu.org/viewcvs?rev=232049&root=gcc&view=rev Log: PR target/69072 * config/sparc/sparc.c (scan_record_type): Take into account subfields to compute the PACKED_P predicate. (function_arg_record_value): Minor tweaks. Added: trunk/gcc/testsuite/gcc.target/sparc/20160104-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.c trunk/gcc/testsuite/ChangeLog
[Bug target/69072] ICE in function_arg_record_value on 7th packed structure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69072 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #4 from Eric Botcazou --- Fixed on mainline.
[Bug target/69100] ICE in final_scan_insn with -msoft-float and __builtin_apply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69100 --- Comment #3 from Eric Botcazou --- Author: ebotcazou Date: Mon Jan 4 08:14:12 2016 New Revision: 232050 URL: https://gcc.gnu.org/viewcvs?rev=232050&root=gcc&view=rev Log: PR target/69100 * config/sparc/sparc.h (FUNCTION_ARG_REGNO_P): Return true in 64-bit mode for %f0-%f31 only if TARGET_FPU. Added: trunk/gcc/testsuite/gcc.target/sparc/20160104-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.h trunk/gcc/testsuite/ChangeLog
[Bug target/69100] ICE in final_scan_insn with -msoft-float and __builtin_apply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69100 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #4 from Eric Botcazou --- Fixed on mainline.
[Bug lto/69133] New: LTO segfault in lto_get_decl_mapping() on 483.xalancbmk with -flto-partitions=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69133 Bug ID: 69133 Summary: LTO segfault in lto_get_decl_mapping() on 483.xalancbmk with -flto-partitions=none Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: prathamesh3492 at gcc dot gnu.org Target Milestone: --- 483.xalancbmk from SPEC CPU2006 fails to build with -flto -flto-partitions=none Trace: lto1: internal compiler error: Segmentation fault 0xa4432f crash_signal ../../gcc/gcc/toplev.c:334 0x90f748 lto_get_decl_name_mapping(lto_file_decl_data*, char const*) ../../gcc/gcc/lto-section-in.c:352 0x690659 cgraph_node::get_untransformed_body() ../../gcc/gcc/cgraph.c:3256 0x69aa45 cgraph_node::expand_thunk(bool, bool) ../../gcc/gcc/cgraphunit.c:1604 0x69bd92 cgraph_node::assemble_thunks_and_aliases() ../../gcc/gcc/cgraphunit.c:1904 0x69bd65 cgraph_node::assemble_thunks_and_aliases() ../../gcc/gcc/cgraphunit.c:1922 0x69bfaf cgraph_node::expand() ../../gcc/gcc/cgraphunit.c:2034 0x69d826 expand_all_functions ../../gcc/gcc/cgraphunit.c:2107 0x69d826 symbol_table::compile() ../../gcc/gcc/cgraphunit.c:2463 0x60cc87 lto_main() ../../gcc/gcc/lto/lto.c:3327 Segfaults on symbol _ZThn8_N10xalanc_1_819XercesParserLiaison11resetErrorsEv demangler.com says the symbol is non-virtual thunk to xalanc_1_8::XercesParserLiaison::resetErrors() For this symbol ./-lm.res has lto resolution == PREVAILING_DEF_IRONLY. Gating cgraph_node::get_untrasnformed_body on lto_file_data seems to work (also passing bootstrap and test) however I wonder if that's the correct approach ? Thanks, Prathamesh
[Bug lto/69133] LTO segfault in lto_get_decl_name_mapping() on 483.xalancbmk with -flto-partitions=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69133 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf --- Could you please try to reduce the issue further? https://gcc.gnu.org/wiki/A_guide_to_testcase_reduction#Reducing_LTO_bugs And the option is: -flto-partition=none (no plural)
[Bug target/69124] arm miss compiled code since gcc 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69124 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #2 from Mikael Pettersson --- I can't reproduce this with either gcc-6-20151227 or gcc-5-20151229 on hard-float armv7l (--with-arch=armv7-a --with-tune=cortex-a9 --with-float=hard --with-fpu=vfpv3-d16 configure options). Debian is known to heavily modify their GCC sources. Unless you can reproduce this with a GCC built from vanilla upstream sources I suggest you report this problem to Debian.
[Bug c++/69132] AVX optimization bug: extra unnecessary code insertion?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69132 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||uros at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Your snippet is not self-contained, the cout in there is supposedly useless for the testcase, but it is unclear what headers are you using and thus whether the sqrt is in the end __builtin_sqrtf or __builtin_sqrt. Also, GCC 4.8 is no longer supported. That said, the "weird" single precision vector division is because it is computing the division using Newton-Rhapson approximation, as a / b = a * ((rcp(b) + rcp(b)) - (b * rcp(b) * rcp (b))) You can disable this e.g. with -mrecip='default,!vec-div' Now, whether this is beneficial even for AVX capable CPUs by default or not depends on the timing/latencies of vrcpps+3*vmulps+vaddps+vsubps instructions vs. vdivps.
[Bug inline-asm/59155] ICE: in reg_overlap_mentioned_p, at rtlanal.c:1473
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59155 --- Comment #7 from Bernd Edlinger --- Created attachment 37216 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37216&action=edit proposed patch this patch bootstraps cleanly and passes regression tests
[Bug bootstrap/69134] New: building a mips-cross compiler with in-tree mpfr-2.4.2 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69134
Bug ID: 69134
Summary: building a mips-cross compiler with in-tree mpfr-2.4.2
fails
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: bernd.edlinger at hotmail dot de
Target Milestone: ---
../gcc-trunk/configure --prefix=/home/ed/gnu/mips-linux-gnu
--target=mips-linux-gnu --enable-languages=c,c++,fortran,ada
--host=mips-linux-gnu
make
...
/bin/bash ./libtool --tag=CC --mode=compile mips-linux-gnu-gcc
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_LOCALE_H=1
-DHAVE_WCHAR_H=1 -DHAVE_STDARG=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1
-DHAVE_VA_COPY=1 -DHAVE_SETLOCALE=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_LONG_LONG=1
-DHAVE_INTMAX_T=1 -DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1
-DHAVE_FLOOR=1 -DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DLT_OBJDIR=\".libs/\"
-DHAVE_ATTRIBUTE_MODE=1 -DHAVE_ALLOCA_H=1 -I. -I../../gcc-trunk/mpfr
-I/home/ed/gnu/gcc-build-mips2/./gmp -g -O2 -MT mul.lo -MD -MP -MF
.deps/mul.Tpo -c -o mul.lo ../../gcc-trunk/mpfr/mul.c
libtool: compile: mips-linux-gnu-gcc -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DTIME_WITH_SYS_TIME=1 -DHAVE_LOCALE_H=1 -DHAVE_WCHAR_H=1 -DHAVE_STDARG=1
-DHAVE_SYS_TIME_H=1 -DHAVE_STDINT_H=1 -DHAVE_VA_COPY=1 -DHAVE_SETLOCALE=1
-DHAVE_GETTIMEOFDAY=1 -DHAVE_LONG_LONG=1 -DHAVE_INTMAX_T=1
-DMPFR_HAVE_FESETROUND=1 -DHAVE_ROUND=1 -DHAVE_TRUNC=1 -DHAVE_FLOOR=1
-DHAVE_CEIL=1 -DHAVE_NEARBYINT=1 -DLT_OBJDIR=\".libs/\" -DHAVE_ATTRIBUTE_MODE=1
-DHAVE_ALLOCA_H=1 -I. -I../../gcc-trunk/mpfr
-I/home/ed/gnu/gcc-build-mips2/./gmp -g -O2 -MT mul.lo -MD -MP -MF
.deps/mul.Tpo -c ../../gcc-trunk/mpfr/mul.c -o mul.o
In file included from ../../gcc-trunk/mpfr/mpfr-impl.h:87:0,
from ../../gcc-trunk/mpfr/mul.c:24:
../../gcc-trunk/mpfr/mul.c: In function 'mpfr_mul':
../../gcc-trunk/mpfr/mpfr-longlong.h:1016:3: error: impossible constraint in
'asm'
__asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
^
../../gcc-trunk/mpfr/mul.c:315:11: note: in expansion of macro 'umul_ppmm'
umul_ppmm (tmp[1], tmp[0], MPFR_MANT (b)[0], MPFR_MANT (c)[0]);
^
../../gcc-trunk/mpfr/mpfr-longlong.h:1016:3: error: impossible constraint in
'asm'
__asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
^
../../gcc-trunk/mpfr/mul.c:322:11: note: in expansion of macro 'umul_ppmm'
umul_ppmm (tmp[1], tmp[0], MPFR_MANT (b)[0], MPFR_MANT (c)[0]);
^
../../gcc-trunk/mpfr/mpfr-longlong.h:1016:3: error: impossible constraint in
'asm'
__asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
^
../../gcc-trunk/mpfr/mul.c:323:11: note: in expansion of macro 'umul_ppmm'
umul_ppmm (tmp[2], t, MPFR_MANT (b)[1], MPFR_MANT (c)[0]);
^
../../gcc-trunk/mpfr/mpfr-longlong.h:1016:3: error: impossible constraint in
'asm'
__asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
^
../../gcc-trunk/mpfr/mul.c:332:11: note: in expansion of macro 'umul_ppmm'
umul_ppmm (tmp[1], tmp[0], MPFR_MANT (b)[0], MPFR_MANT (c)[0]);
^
../../gcc-trunk/mpfr/mpfr-longlong.h:1016:3: error: impossible constraint in
'asm'
__asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
^
../../gcc-trunk/mpfr/mul.c:333:11: note: in expansion of macro 'umul_ppmm'
umul_ppmm (tmp[2], t1, MPFR_MANT (b)[1], MPFR_MANT (c)[0]);
^
../../gcc-trunk/mpfr/mpfr-longlong.h:1016:3: error: impossible constraint in
'asm'
__asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
^
../../gcc-trunk/mpfr/mul.c:336:11: note: in expansion of macro 'umul_ppmm'
umul_ppmm (t1, t2, MPFR_MANT (b)[0], MPFR_MANT (c)[1]);
^
../../gcc-trunk/mpfr/mpfr-longlong.h:1016:3: error: impossible constraint in
'asm'
__asm__ ("multu %2,%3" : "=l" (w0), "=h" (w1) : "d" (u), "d" (v))
^
../../gcc-trunk/mpfr/mul.c:337:11: note: in expansion of macro 'umul_ppmm'
umul_ppmm (tmp[3], t3, MPFR_MANT (b)[1], MPFR_MANT (c)[1]);
^
make[3]: *** [mul.lo] Error 1
make[3]: Leaving directory `/home/ed/gnu/gcc-build-mips2/mpfr'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/ed/gnu/gcc-build-mips2/mpfr'
make[1]: *** [all-mpfr] Error 2
make[1]: Leaving directory `/home/ed/gnu/gcc-build-mips2'
make: *** [all] Error 2
I thought we disable inline asm for in-tree gmp and mpfr.
[Bug middle-end/63669] [AArch64] gcc.dg/torture/asm-subreg-1.c ICEs with -fPIC or -mno-lra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63669 Bernd Edlinger changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #6 from Bernd Edlinger --- This is very similar to pr59155 or maybe even a duplicate.
[Bug c++/69132] AVX optimization bug: extra unnecessary code insertion?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69132 --- Comment #2 from Wang Xuancong --- I assume rcp(b)=1/b, so a/b=a*(1/b)=a*rcp(b). There is no longer a need to do the Newton-Rhapson method. And of course, computing [ a * ((rcp(b) + rcp(b)) - (b * rcp(b) * rcp (b)))] is slower than computing [a*rcp(b)]. I understand that vdivps takes a very long time, but the straight-forward method only takes vrcpps+vmulps time, which is much faster than what the compiler is doing currently, i.e. vrcpps+3*vmulps+vaddps+vsubps time.
[Bug lto/69119] More fun with LTO on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69119 Richard Earnshaw changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Richard Earnshaw --- Reporter indicates this was 'pilot error'.
[Bug c++/69132] AVX optimization bug: extra unnecessary code insertion?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69132 --- Comment #3 from Jakub Jelinek --- (In reply to Wang Xuancong from comment #2) > I assume rcp(b)=1/b, so a/b=a*(1/b)=a*rcp(b). That assumption is wrong. The VRCPPS instruction does not compute reciprocal of the operand, but just an approximation thereof, see the ISA documentation. In particular, |Relative Error| < 1.5 *2^ -12 Such an error is too much even for -Ofast.
[Bug target/69135] New: [5/6][ARM] instruction cannot be conditional -- `vcvtpne.s32.f32 s0,s0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69135
Bug ID: 69135
Summary: [5/6][ARM] instruction cannot be conditional --
`vcvtpne.s32.f32 s0,s0'
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: cctsai57 at gmail dot com
Target Milestone: ---
ARMv8 'vcvtp', 'vcvtm' and 'vcvta' do not support conditional execution, but
gcc-5/6 for ARMv8 target generate them with conditional execution. See
the following steps:
~~ BEGIN ~~
$ cat test.c
int global;
void
lceil_float (float x, int b)
{
if (b) global = __builtin_lceilf (x);
}
void
lceil_double (double x, int b)
{
if (b) global = __builtin_lceil (x);
}
void
lfloor_float (float x, int b)
{
if (b) global = __builtin_lfloorf (x);
}
void
lfloor_double (double x, int b)
{
if (b) global = __builtin_lfloor (x);
}
void
lround_float (float x, int b)
{
if (b) global = __builtin_lroundf (x);
}
void
lround_double (double x, int b)
{
if (b) global = __builtin_lround (x);
}
$ arm-linux-gnu-gcc -march=armv8-a -mfpu=fp-armv8 -O2 -ffast-math -c test.c
/tmp/ccw74V3i.s: Assembler messages:
/tmp/ccw74V3i.s:23: Error: instruction cannot be conditional --
`vcvtpne.s32.f32 s0,s0'
/tmp/ccw74V3i.s:37: Error: instruction cannot be conditional --
`vcvtpne.s32.f64 s0,d0'
/tmp/ccw74V3i.s:51: Error: instruction cannot be conditional --
`vcvtmne.s32.f32 s0,s0'
/tmp/ccw74V3i.s:65: Error: instruction cannot be conditional --
`vcvtmne.s32.f64 s0,d0'
/tmp/ccw74V3i.s:79: Error: instruction cannot be conditional --
`vcvtane.s32.f32 s0,s0'
/tmp/ccw74V3i.s:93: Error: instruction cannot be conditional --
`vcvtane.s32.f64 s0,d0'
~~ END ~~
I think this bug is from gcc/config/arm/vfp.md:(define_insn
"lsi2"...). I use the following patch to fix
it:
diff --git a/gcc/config/arm/vfp.md b/gcc/config/arm/vfp.md
index c297ed9..f73862e 100644
--- a/gcc/config/arm/vfp.md
+++ b/gcc/config/arm/vfp.md
@@ -1338,6 +1338,8 @@
"TARGET_HARD_FLOAT && TARGET_FPU_ARMV8 "
"vcvt%?.32.\\t%0, %1"
[(set_attr "predicable" "no")
+ (set_attr "predicable_short_it" "no")
+ (set_attr "conds" "unconditional")
(set_attr "type" "f_cvtf2i")]
)
[Bug target/69034] ICE: RTL check: expected elt 1 type 'e' or 'u', have 'i' (rtx unspec) in copy_replacements_1, at reload.c:6323 with -fPIC and "X" asm input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69034 --- Comment #2 from Zdenek Sojka --- Created attachment 37217 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37217&action=edit reduced testcase (In reply to Bernd Edlinger from comment #1) > Hi, > > I don't see any test case. Hello Bernd, thanks, I've added it now. It is more or less the same as for the other PRs.
[Bug debug/69077] [6 Regression] omnetpp ICEs with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69077 Jakub Jelinek changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- That doesn't seem to be the reason for the ICE. This at least for me (x86_64-linux) ICEs on 21327 /* Make sure any inlined functions are known to be inlineable. */ 21328 gcc_checking_assert (DECL_ABSTRACT_P (decl) 21329 || cgraph_function_possibly_inlined_p (decl)); The reason why DECL_ABSTRACT_P is not set in this case is that LTO throws away DECL_ABSTRACT_ORIGIN of all decls. And the reason why cgraph_function_possibly_inlined_p is not set seems to be that DECL_POSSIBLY_INLINED isn't set. Supposedly it is not set in t1.o's mean, because it is not inlined in there, and it is set in t2.o's mean, because it has been early inlined in there. So, DECL_POSSIBLY_INLINED ideally should be ored in from all the LTO input files but that is not what is happening. So, do we need to move that flag to cgraph or duplicate it there, and make sure when merging decls from different TUs it is ored in together?
[Bug tree-optimization/69083] [6 Regression] ICE at -O3 in 64-bit mode on x86_64-linux-gnu (verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69083 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-04 CC||ienkovich at gcc dot gnu.org, ||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Started with r230098.
[Bug rtl-optimization/69030] [6 Regression] ICE on x86_64-linux-gnu at -O2 and above in 32-bit mode (ICE in copy_rtx, at rtl.c:358)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69030 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-04 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 Summary|ICE on x86_64-linux-gnu at |[6 Regression] ICE on |-O2 and above in 32-bit |x86_64-linux-gnu at -O2 and |mode (ICE in copy_rtx, at |above in 32-bit mode (ICE |rtl.c:358) |in copy_rtx, at rtl.c:358) Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- ICE with -O3 started with r228231.
[Bug tree-optimization/69097] [6 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69097 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-04 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 Summary|wrong code at -O1 and above |[6 Regression] wrong code |on x86_64-linux-gnu |at -O1 and above on ||x86_64-linux-gnu Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- commit 98b69bccadeae2fb64adde8ff008f79ec5963381 Author: rguenth Date: Tue Jun 30 11:58:48 2015 + 2015-06-30 Richard Biener * fold-const.c (fold_unary_loc): Move abs(abs(x)) -> abs(x), ~ (-A) to A - 1, ~ (A - 1) or ~ (A + -1) to -A and some cases of ~(X ^ Y) to ~X ^ Y or X ^ ~Y if ~X or ~Y simplify to ... * match.pd: ... here. Add a few cases of A - B -> A + (-B) when B "easily" negates. Move (x & y) | x -> x and friends before (x | CST1) & CST2 -> (x & CST2) | (CST1 & CST2). git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@225178 138bc75d-0d04-0410-961f-82ee72b054a4
[Bug sanitizer/69099] ICE when compiling gcc.dg/atomic/c11-atomic-exec-2.c with -fsanitize=float-cast-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69099 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-04 Target Milestone|--- |5.4 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug sanitizer/69099] ICE when compiling gcc.dg/atomic/c11-atomic-exec-2.c with -fsanitize=float-cast-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69099 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- This is good old c_maybe_const_expr leakin' into the gimplifier. Thus mine.
[Bug lto/69119] More fun with LTO on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69119 --- Comment #5 from PeteVine --- Wait, what about #1?
[Bug lto/69133] [6 Regression] LTO segfault in lto_get_decl_name_mapping() on 483.xalancbmk with -flto-partition=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69133
Markus Trippelsdorf changed:
What|Removed |Added
Target|x86_64-unknown-linux-gnu|
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-01-04
CC||hubicka at ucw dot cz
Host|x86_64-unknown-linux-gnu|
Summary|LTO segfault in |[6 Regression] LTO segfault
|lto_get_decl_name_mapping() |in
|on 483.xalancbmk with |lto_get_decl_name_mapping()
|-flto-partitions=none |on 483.xalancbmk with
||-flto-partition=none
Ever confirmed|0 |1
Build|x86_64-unknown-linux-gnu|
--- Comment #2 from Markus Trippelsdorf ---
markus@x4 tmp % cat DTDScanner.ii
namespace xercesc_3_1 {
class XMLEntityHandler {
public:
virtual ~XMLEntityHandler();
virtual void m_fn1();
virtual bool m_fn2();
virtual void m_fn3();
virtual int m_fn4();
virtual void m_fn5();
} * a;
void fn1() {
a->m_fn5();
a->m_fn1();
}
}
markus@x4 tmp % cat XSDDOMParser.ii
namespace xercesc_3_1 {
class A {
virtual void m_fn1();
};
class XMLEntityHandler {
public:
virtual ~XMLEntityHandler();
virtual void m_fn2(const int &);
virtual bool m_fn3();
virtual void m_fn4();
virtual int m_fn5() = 0;
virtual void m_fn6(const int &);
};
class B : A, XMLEntityHandler {};
class C : B {
void m_fn2(const int &);
void m_fn6(const int &);
};
void C::m_fn2(const int &) {}
void C::m_fn6(const int &) {}
}
markus@x4 tmp % g++ -r -nostdlib -flto -flto-partition=none -O2 DTDScanner.ii
XSDDOMParser.ii
lto1: internal compiler error: Segmentation fault
0xa09bef crash_signal
../../gcc/gcc/toplev.c:334
0x7fbffe8ed30f ???
/home/markus/glibc/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x8d4b48 lto_get_decl_name_mapping(lto_file_decl_data*, char const*)
../../gcc/gcc/lto-section-in.c:352
0x655eeb cgraph_node::get_untransformed_body()
../../gcc/gcc/cgraph.c:3319
...
[Bug c/68908] inefficient code for _Atomic operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908 --- Comment #16 from Marek Polacek --- Author: mpolacek Date: Mon Jan 4 12:27:08 2016 New Revision: 232052 URL: https://gcc.gnu.org/viewcvs?rev=232052&root=gcc&view=rev Log: PR c/68908 * c-typeck.c (build_atomic_assign): Improve commentary. Add optimization to use __atomic_fetch_* built-in if possible. * gcc.dg/atomic/c11-atomic-exec-6.c: New test. * gcc.dg/atomic/c11-atomic-exec-7.c: New test. * gcc.dg/atomic/stdatomic-op-5.c: New test. Added: trunk/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-6.c trunk/gcc/testsuite/gcc.dg/atomic/c11-atomic-exec-7.c trunk/gcc/testsuite/gcc.dg/atomic/stdatomic-op-5.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c/68908] inefficient code for _Atomic operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Marek Polacek --- Done for GCC 6.
[Bug tree-optimization/69083] [6 Regression] ICE at -O3 in 64-bit mode on x86_64-linux-gnu (verify_gimple failed)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69083 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 37218 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37218&action=edit gcc6-pr69083.patch Untested fix.
[Bug c++/69132] AVX optimization bug: extra unnecessary code insertion?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69132 Wang Xuancong changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from Wang Xuancong --- Thanks! I have just learned one important thing today, that all *rcp*-based instructions need at least one Newton-Rhapson iteration to restore accuracy, otherwise, it loses 50% accuracy. Take note that the original FLOAT32 has 23-bits in the significand. Without any Newton-Rhapson, you are left with only 11-bits. Ouch!
[Bug target/69034] ICE: RTL check: expected elt 1 type 'e' or 'u', have 'i' (rtx unspec) in copy_replacements_1, at reload.c:6323 with -fPIC and "X" asm input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69034 --- Comment #3 from Bernd Edlinger --- (In reply to Zdenek Sojka from comment #2) > Created attachment 37217 [details] > reduced testcase > > (In reply to Bernd Edlinger from comment #1) > > Hi, > > > > I don't see any test case. > > Hello Bernd, thanks, I've added it now. It is more or less the same as for > the other PRs. Ok, I see. You can try the patch that I attached to PR59155 today.
[Bug lto/69119] More fun with LTO on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69119 --- Comment #6 from Richard Earnshaw --- (In reply to PeteVine from comment #5) > Wait, what about #1? Sorry, I hadn't spotted that there were two issues in the one report. Please create separate bug reports for each issue - it's much easier to merge common bugs than separate distinct ones.
[Bug target/69135] [5/6][ARM] instruction cannot be conditional -- `vcvtpne.s32.f32 s0,s0'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69135 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-04 Ever confirmed|0 |1 --- Comment #1 from Richard Earnshaw --- Confirmed based on inspection. The patch suggested is not correct, since vcvtr can be conditional and it shares the same basic pattern.
[Bug lto/69136] New: [6 Regression] ICE in lto_symtab_prevailing_virtual_decl, at lto/lto-symtab.c:991
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69136
Bug ID: 69136
Summary: [6 Regression] ICE in
lto_symtab_prevailing_virtual_decl, at
lto/lto-symtab.c:991
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Hi
$ cat skia.ii
class GrBufferAllocPool {
virtual ~GrBufferAllocPool();
};
GrBufferAllocPool::~GrBufferAllocPool() { static long a; }
$ c++ skia.ii -flto
lto1: internal compiler error: in lto_symtab_prevailing_virtual_decl, at
lto/lto-symtab.c:991
0x60cd49 lto_symtab_prevailing_virtual_decl(tree_node*)
../../gcc/lto/lto-symtab.c:990
0x5f6f65 lto_symtab_prevailing_decl(tree_node*)
../../gcc/lto/lto-symtab.h:53
0x5f6f65 lto_fixup_prevailing_decls
../../gcc/lto/lto.c:2544
0x6019be lto_fixup_decls
../../gcc/lto/lto.c:2664
0x6019be read_cgraph_and_symbols
../../gcc/lto/lto.c:2897
0x6019be lto_main()
../../gcc/lto/lto.c:3304
Thanks,
Martin
[Bug c/69104] invalid atomic memory order not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69104 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-04 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed; this is 7.17.7 in C11. I think this relates to atomic_compare_exchange as well: "The failure argument shall not be memory_order_release nor memory_order_acq_rel. The failure argument shall be no stronger than the success argument." We don't diagnose these either it seems.
[Bug c/69104] invalid atomic memory order not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69104 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- I'll have a look.
[Bug ipa/69044] [6 regression] [CHKP] internal compiler error: in duplicate_thunk_for_node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69044 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Hello (gdb) p thunk->debug() strncasecmp/1 (strncasecmp) @0x769ec000 Type: function definition analyzed Visibility: externally_visible public Aux: @0x1f39050 References: strncasecmp.chkp/4 (chkp) Referring: Availability: available First run: 0 Function flags: Thunk fixed offset 0 virtual value 0 has virtual offset 0) Called by: special_command.chkp/3 (1.00 per call) Calls: strncasecmp.chkp/4 (1.00 per call) Has instrumented version. $1 = void (gdb) p node->debug() strncasecmp.chkp.constprop.1/8 (strncasecmp.chkp.constprop) @0x769ec730 Type: function definition analyzed Visibility: public artificial References: Referring: Availability: local First run: 0 Function flags: local Called by: Calls: As 'thunk' has set DECL_INITIAL: (gdb) p debug_tree(thunk->decl.decl_common.initial) QI size unit size align 8 symtab 0 alias set -1 canonical type 0x769d2000 attributes > arg-types chain chain chain pointer_to_this > readonly addressable used nothrow public static built-in decl_3 decl_5 QI file /home/marxin/Programming/testcases/PR69044/tc.i line 2 col 5 align 8 built-in BUILT_IN_NORMAL:BUILT_IN_STRNCASECMP context attributes initial result ignored SI file /home/marxin/Programming/testcases/PR69044/tc.i line 2 col 5 size unit size align 32 context > chain nothrow public external built-in decl_6 QI file line 0 col 0 align 8 built-in BUILT_IN_NORMAL:BUILT_IN_STRNCAT context attributes chain >>> The block is copied at: 290 if (!node->clone.args_to_skip) 291 new_decl = copy_node (thunk->decl); That's the way how the checking_assert is triggered. Martin
[Bug c++/69060] Invalid 'cannot bind lvalue to rvalue' error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69060
Sławomir changed:
What|Removed |Added
CC||slawomir.karol.domagala@gma
||il.com
--- Comment #1 from Sławomir ---
The same with version 4.9.4 20150813 (prerelease)
Error:
CXX diag/bin/fsmf_test/collector_handler.o
src/log_collecting/collector_handler.cpp: In member function ‘void
diag::collector_handler::add_file_to_dl_list(const string&, bool)’:
src/log_collecting/collector_handler.cpp:274:47: error: cannot bind ‘bool’
lvalue to ‘bool&&’
observers_list->notify_observers(uri, is_last);
^
In file included from ../diag/src/log_collecting/diag_object.h:8:0,
from src/log_collecting/collector_handler.h:11,
from src/log_collecting/collector_handler.cpp:13:
../diag/src/log_collecting/observers_container.h:52:15: note: initializing
argument 2 of ‘void
diag::observers_container::notify_observers(callback_args_types&&
...) [with callback_args_types = {boost::optional, std::allocator > >, bool}]’
virtual void notify_observers(callback_args_types&&... args) {
Code:
template
class observers_container
{
public:
typedef std::function callback_type;
observers_container() = default;
virtual ~observers_container() = default;
/*!
* Copy constructor
*/
observers_container(const observers_container& o_container) {
observers_list = o_container.observers_list;
}
/*!
* Adds observer
*/
void add(callback_type obs) {
std::lock_guard lock(list_mtx);
observers_list.push_back(obs);
}
/*!
* Removes observer
*/
void remove(const callback_type& obs_to_unregister) {
std::lock_guard lock(list_mtx);
observers_list.remove(obs_to_unregister);
}
/*!
* Notifies observers
*/
virtual void notify_observers(callback_args_types&&... args) {
std::lock_guard lock(list_mtx);
for(auto observer: observers_list) {
observer(std::forward(args)...);
}
}
private:
std::list observers_list;
mutable std::mutex list_mtx;
};
[Bug lto/69119] More fun with LTO on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69119 --- Comment #7 from PeteVine --- That's what normally do; I simply wasn't sure if these were gcc bugs or not. I take it the jemalloc one can be closed on github then?
[Bug target/67710] FAIL: gcc.dg/darwin-*version-*.c (test for excess errors) with Xcode 7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67710 --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #7 from Iain Sandoe --- [...] > Works For Me(™) on 10.10 with XC7.2 and 10.8.5 with XC5.1.1 Same for me on 10.11.3 Beta with XC 7.2 and 10.7 with XC 4.3.2. Thanks. Rainer
[Bug lto/69136] [6 Regression] ICE in lto_symtab_prevailing_virtual_decl, at lto/lto-symtab.c:991
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69136 --- Comment #1 from Martin Liška --- Started with r231671.
[Bug c/69104] invalid atomic memory order not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69104 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|UNCONFIRMED Assignee|mpolacek at gcc dot gnu.org|unassigned at gcc dot gnu.org Ever confirmed|1 |0 --- Comment #3 from Marek Polacek --- Wait, expand_builtin_atomic_load, expand_builtin_atomic_store, and expand_builtin_atomic_compare_exchange already have a code dealing with these invalid arguments!
[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848 --- Comment #27 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #25 from Jack Howarth --- [...] > Did you remember to install the patched build before attempting to run the > libjava test suite? System Integrity Protection on 10.11 will make any usage > of No, I've never done that before and try to avoid it if at all possible on any platform. > DYLD_LIBRARY_PATH by the test suite non-functional so any previously installed > libraries will be used instead of those in the current build directory. I wasn't aware of that: what a pity this is an system-wide all-or-nothing setting without any way to override it e.g. per session with appropriate privilege: makes the system sort of useless for combined development and desktop use ;-( After disabling SIP, I get the same results as you do with your patch. Thanks. Rainer
[Bug c/69104] invalid atomic memory order not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69104 --- Comment #4 from Marek Polacek --- And we warn, with -Wsystem-headers...
[Bug tree-optimization/68911] [6 Regression] wrong code at -Os and above on x86-64-linux-gnu (in 32- and 64-bit modes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68911
--- Comment #5 from amker at gcc dot gnu.org ---
For the case concerned:
:
e_15 = e_1 + 1;
:
# e_1 = PHI
if (e_1 <= 93)
goto ;
else
goto ;
Loop niter gives:
Analyzing # of iterations of loop 2
exit condition [e_8, + , 1] <= 93
bounds on difference of bases: -4294967202 ... 93
result:
zero if e_8 > 94
# of iterations 94 - e_8, bounded by 94
It also records induction variable {e_8, 1} as non-overflow control iv. Thus
below checks in adjust_range_with_scev returns false and value range is updated
with [min, VRP[e_8].max + bound].
dir = scev_direction (chrec);
if (/* Do not adjust ranges if we do not know whether the iv increases
or decreases, ... */
dir == EV_DIR_UNKNOWN
/* ... or if it may wrap. */
|| scev_probably_wraps_p (init, step, stmt, get_chrec_loop (chrec),
true))
return;
Unfortunately, it's possible that the loop exits immediately. When that is the
case, computing VRP[e_8].max + bound would result in overflow.
So maybe we need to check if the loop exits immediately before call to
scev_probably_wraps_p. This should not result any regression since there is no
useful range update anyway if the loop exits immediately.
Also following code in adjust_range_with_scev could be improved to handled
overflow cases. For this given case, we can generate ANTI-range info like
![VRP[e_8].max + bound, VRP[e_8].min].
[Bug target/69124] arm miss compiled code since gcc 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69124 --- Comment #3 from Sebastian Andrzej Siewior --- gcc -v Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Debian 5.3.1-4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --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-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 5.3.1 20151219 (Debian 5.3.1-4) gcc -o fp_mul fp_mul_comba_32.c -g -O2 -march=armv7-a -mtune=cortex-a9 -mhard-float -mfpu=vfpv3-d16 gcc -o fp_mul-nt fp_mul_comba_32.c -g -O2 -march=armv7-a -mhard-float -mfpu=vfpv3-d16 (sid_armhf-dchroot)bigeasy@harris:~/tc$ ./fp_mul (sid_armhf-dchroot)bigeasy@harris:~/tc$ ./fp_mul-nt 27 0x0a7d8ff8 != 0xce804437 28 0x1c8a1f70 != 0x1c8a1f6f -> 3 So it does not trigger here with -mtune=cortex-a9 as well. Do you know what is selected for -mtune as default if it is not specified at build-time? I tried with cortex-a7 but it does not trigger :/
[Bug target/69124] arm miss compiled code since gcc 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69124 --- Comment #4 from Richard Earnshaw --- Does -fno-strict-aliasing help?
[Bug target/69124] arm miss compiled code since gcc 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69124 --- Comment #5 from Mikael Pettersson --- The OP's compiler has --with-mode=thumb! If I compile with -mtune=generic-armv7-a -mthumb then I see the following errors from the test case: 12 0xc0b165f1 != 0xdf5e0cae 13 0x8b329fe4 != 0x8b329fe3 19 0x841bee4e != 0x7b21ac34 20 0x2563cc91 != 0x84be291e 21 0x5f503954 != 0xb8f7b936 22 0x36cb8e86 != 0x36cb8e85 31 0x8c99a1f4 != 0x915bd91c 32 0x22e09d96 != 0x22e09d95 -> 3 This is with -fno-strict-aliasing etc as per the initial description, and both gcc 5 and 6 show this behaviour.
[Bug lto/69137] New: [6 Regression] ICE in odr_type_p, at ipa-utils.h:257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69137
Bug ID: 69137
Summary: [6 Regression] ICE in odr_type_p, at ipa-utils.h:257
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Hello.
Following test case produces ICE:
$ cat tc.ii
typedef struct {
typedef struct { } VarSelectorRecord; } Format14Cmap;
void fn1() { Format14Cmap a; }
$ c++ -flto tc.ii -march=native -std=gnu++0x -g
lto1: internal compiler error: in odr_type_p, at ipa-utils.h:257
0x620957 odr_type_p(tree_node const*)
../../gcc/ipa-utils.h:255
0x620957 lto_read_decls
../../gcc/lto/lto.c:1745
0x621a81 lto_file_finalize
../../gcc/lto/lto.c:2043
0x621a81 lto_create_files_from_ids
../../gcc/lto/lto.c:2053
0x621a81 lto_file_read
../../gcc/lto/lto.c:2094
0x621a81 read_cgraph_and_symbols
../../gcc/lto/lto.c:2804
0x621a81 lto_main()
../../gcc/lto/lto.c:3304
Thanks,
Martin
[Bug lto/69137] [6 Regression] ICE in odr_type_p, at ipa-utils.h:257
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69137 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-01-04 Ever confirmed|0 |1 --- Comment #1 from Jan Hubicka --- Mine.
[Bug tree-optimization/69097] [6 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69097
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Seems like a bogus fold-const.c transformation has been moved into match.pd and
so now it hits even more often. Another testcase:
__attribute__((noinline, noclone)) int
f1 (int x, int y)
{
return x % y;
}
__attribute__((noinline, noclone)) int
f2 (int x, int y)
{
return x % -y;
}
__attribute__((noinline, noclone)) int
f3 (int x, int y)
{
int z = -y;
return x % z;
}
int
main ()
{
if (f1 (-__INT_MAX__ - 1, 1) != 0
|| f2 (-__INT_MAX__ - 1, -1) != 0
|| f3 (-__INT_MAX__ - 1, -1) != 0)
__builtin_abort ();
return 0;
}
The bad optimization has been introduced with
https://gcc.gnu.org/ml/gcc-patches/2004-07/msg00358.html in 2004.
For constant last operand we already do the right thing:
/* X % -C is the same as X % C. */
(simplify
(trunc_mod @0 INTEGER_CST@1)
(if (TYPE_SIGN (type) == SIGNED
&& !TREE_OVERFLOW (@1)
&& wi::neg_p (@1)
&& !TYPE_OVERFLOW_TRAPS (type)
/* Avoid this transformation if C is INT_MIN, i.e. C == -C. */
&& !sign_bit_p (@1, @1))
(trunc_mod @0 (negate @1
because we only do the transformation for negative constants. But for variable
last operand:
/* X % -Y is the same as X % Y. */
(simplify
(trunc_mod @0 (convert? (negate @1)))
(if (!TYPE_UNSIGNED (type)
&& !TYPE_OVERFLOW_TRAPS (type)
&& tree_nop_conversion_p (type, TREE_TYPE (@1)))
(trunc_mod @0 (convert @1
we can turn a valid INT_MIN % -(-1) which yields 0 into invalid INT_MIN % -1
which raises division by zero.
So, if we really want to perform this X % -Y transformation to X % Y, we can do
that only if VRP info tells us that the first operand can't be the signed
minimum, or the operand of the negation can't be -1.
[Bug tree-optimization/69097] [6 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69097 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #3 from Mikael Pettersson --- Looks related to PR50865.
[Bug target/69038] compilation error: unable to find a register to spill in class 'FP_REGS'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69038
--- Comment #7 from Eric Botcazou ---
(insn 1237 1236 1238 9 (set (reg:DF 32 %f0)
(float:DF (reg:SI 2027 [ MEM[base: in_140, index: _139, offset: 0B]+-3
]))) pr69038.C:647 155 {floatsidf2}
(expr_list:REG_DEAD (reg:SI 2027 [ MEM[base: in_140, index: _139, offset:
0B]+-3 ])
(nil)))
Spilling for insn 1237.
reload failure for reload 0
Reloads for insn # 1237
Reload 0: reload_in (SI) = (reg:SI 2027 [ MEM[base: in_140, index: _139,
offset: 0B]+-3 ])
FP_REGS, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (reg:SI 2027 [ MEM[base: in_140, index: _139, offset:
0B]+-3 ])
But AFAICS %f0 could be used as reload register here thanks to the REG_DEAD
note... It's probably too late to implement this in reload though.
[Bug lto/69119] More fun with LTO on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69119 --- Comment #8 from PeteVine --- There's going to be question #3 now that I've successfully built rustc on arm using -flto. The rust compiler passes all tests but an example binary (bfc) segfaults: (gdb) bt #0 0x7f642784 in thread_rng::h22bece718b8c83adkgf () #1 0x7f6422dc in util::tmpname::h63004644db7838bePja () #2 0x7f641a00 in named::NamedTempFile::new::hfa7543c1e647f61ecqa () #3 0x7f61c308 in compile_file::h04704d1240bcd17a3Fc () #4 0x7f62077c in main::h68a433d56cae34167Pc () #5 0x7f65ab4c in panic::recover::h13621087687085827578 () #6 0x7f65a68c in rt::lang_start::h5fc8517878d759f3Dky () #7 0xb6d61632 in __libc_start_main (main=0x7f621dbc , argc=2, argv=0xbeffef74, init=, fini=0x8004b0f9 <__libc_csu_fini>, rtld_fini=0xb6fea4c5 <_dl_fini>, stack_end=0xbeffef74) at libc-start.c:287 #8 0x7f61a8d8 in _start () Note line #6 - that's the C glue that's probably the victim of this optimization. Is it a bug in gcc deserving a separate issue? Needless to say, without -flto at rustc's build-time the binaries created by it don't segfault.
[Bug libstdc++/69081] forward_list::splice_after does not handle the case of first<=last properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69081 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-01-04 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to William Li from comment #0) > It supposes to transfer elements [first, last). If the last is before the > first, then [first, last) shall be empty set mathematically. The title of this report talks about first<=last, the text above talks about last
[Bug c++/69138] New: Woverflow not triggered for constexpr within class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69138
Bug ID: 69138
Summary: Woverflow not triggered for constexpr within class
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: krzysztof.wesolowski at rainlabs dot pl
Target Milestone: ---
When i have following code:
#include
static constexpr uint8_t small_global = 0x;
class A {
static constexpr uint8_t small_within_class = 0x;
};
template
class B {
static constexpr uint8_t small_within_templated_class = 0x;
};
B b;
It only produces warnings for first two cases.
Online compiler with test case: https://goo.gl/aGL0n4
[Bug tree-optimization/69097] [6 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69097 --- Comment #4 from Jakub Jelinek --- Created attachment 37219 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37219&action=edit gcc6-pr69097.patch Untested WIP patch. Looking for better name of the new function and better location. Furthermore, the optimization likely needs to be repeated somewhere in VRP, because only then it could apply to say x % -y being guarded with y != -1 or similar (where y is unmodified parameter, or something that doesn't get a new SSA_NAME). And to Mikael, yes, this is indeed related to PR50865, but that PR should have been marked as a 4+ regression (because it worked well in 3.4 and earlier; that way it wouldn't slip through for so many years), and the patch should have been posted to gcc-patches instead of only being added to the PR. That said, the conditionalizing on lang_hooks.name looks ugly, and the optimization is now in match.pd.
[Bug bootstrap/69123] [6 Regression] --with-build-config='bootstrap-O3 bootstrap-debug' miscompiled stage 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69123 Andrew Pinski changed: What|Removed |Added Status|NEW |UNCONFIRMED Ever confirmed|1 |0 --- Comment #2 from Andrew Pinski --- (In reply to H.J. Lu from comment #1) > It was caused by r231674. In this case I think exposed by is the correct term as this just changes the cost algorithm. Also do you have a short testcase of what is being miscompiled?
[Bug tree-optimization/69107] def does not dominate use ICE with -O2 -ftree-paralellize-loops=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69107 --- Comment #1 from vries at gcc dot gnu.org --- Created attachment 37220 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37220&action=edit reduced test-case
[Bug c++/60304] Including disables -Wconversion-null in C++ 98 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60304
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2014-10-06 00:00:00 |2016-1-4
CC||msebor at gcc dot gnu.org
Summary|Including disables |Including
|-Wconversion-null |disables -Wconversion-null
||in C++ 98 mode
Known to fail||4.9.3, 5.1.0, 6.0
--- Comment #23 from Martin Sebor ---
The original test case with works as expected with 4.9.3, 5.1.0, and
today's trunk (6.0).
What doesn't work correctly is including in the test case and
compiling it in C++ 98 mode. The test case below shows there's still no
warning there. This is because Jonathan's patch left false defined as a macro
in C++ 98 for compatibility, and the system header preprocessor bug still
hasn't been fixed.
I'm changing the Summary to reflect what still doesn't work and to make this
bug easier to find, though it could also probably be closed as a duplicate of
the underlying system header preprocessor bug (if only I could find it).
$ cat a.cpp && /home/msebor/build/gcc-trunk-svn/gcc/xgcc
-B/home/msebor/build/gcc-trunk-svn/gcc
-I/home/msebor/build/gcc-trunk-svn/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
-I/home/msebor/build/gcc-trunk-svn/x86_64-pc-linux-gnu/libstdc++-v3/include -S
-Wall -Werror -o/dev/null -std=c++98 a.cpp
#include
int* foo () { return false; }
[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848 --- Comment #28 from Jack Howarth --- (In reply to r...@cebitec.uni-bielefeld.de from comment #27) > > --- Comment #25 from Jack Howarth --- > [...] > > Did you remember to install the patched build before attempting to run the > > libjava test suite? System Integrity Protection on 10.11 will make any > > usage of > > No, I've never done that before and try to avoid it if at all possible > on any platform. > > > DYLD_LIBRARY_PATH by the test suite non-functional so any previously > > installed > > libraries will be used instead of those in the current build directory. > > I wasn't aware of that: what a pity this is an system-wide > all-or-nothing setting without any way to override it e.g. per session > with appropriate privilege: makes the system sort of useless for > combined development and desktop use ;-( > Iain suggested that the required changes for supporting SIP will be along the lines of... a) make all libs @rpath/xxx b) add @loader_path as an rpath to all libs with a local dep. c) add @executable_path/../lib; ../lib as rpaths to exes. > After disabling SIP, I get the same results as you do with your patch. > > Thanks. > Rainer
[Bug c/69104] invalid atomic memory order not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69104 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Known to fail||4.9.3, 5.1.0, 6.0 --- Comment #5 from Martin Sebor --- Thanks for looking into it! (I've changed the Status to NEW since you confirmed the absence of the warning.) After some searching and reading it seems like there are a couple of problems then: 1) the known system header/preprocessor bug is preventing the GCC from issuing the warning (it's enabled by default and doesn't require -Wall or -Wextra) 2) the -Winvalid-memory-model option that controls the warning is undocumented in the GCC manual Let me submit a patch for (2). Based on discussions in Bugzilla, fixing (1) sounds like it will be a tougher nut to crack. (I wonder how many other problems this bug masks.)
[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848 --- Comment #29 from Iain Sandoe --- (In reply to Jack Howarth from comment #28) > (In reply to r...@cebitec.uni-bielefeld.de from comment #27) > > > --- Comment #25 from Jack Howarth --- > Iain suggested that the required changes for supporting SIP will be along > the lines of... > > a) make all libs @rpath/xxx > b) add @loader_path as an rpath to all libs with a local dep. > c) add @executable_path/../lib; ../lib as > rpaths to exes. I have a draft for a patch to do this - will try and stick it somewhere useful soon.
[Bug tree-optimization/69107] [6 Regression] def does not dominate use ICE with -O2 -ftree-paralellize-loops=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69107 vries at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0 Summary|def does not dominate use |[6 Regression] def does not |ICE with -O2|dominate use ICE with -O2 |-ftree-paralellize-loops=2 |-ftree-paralellize-loops=2 --- Comment #2 from vries at gcc dot gnu.org --- In transform_to_exit_first_loop_alt, so a 6 regression.
[Bug tree-optimization/69107] [6 Regression] def does not dominate use ICE with -O2 -funswitch-loops -ftree-paralellize-loops=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69107 vries at gcc dot gnu.org changed: What|Removed |Added Summary|[6 Regression] def does not |[6 Regression] def does not |dominate use ICE with -O2 |dominate use ICE with -O2 |-ftree-paralellize-loops=2 |-funswitch-loops ||-ftree-paralellize-loops=2 --- Comment #3 from vries at gcc dot gnu.org --- Instead of -O3, we can use the more minimal -O2 -funswitch-loops to trigger the error.
[Bug tree-optimization/69109] [6 Regression] missing phi argument ICE in transform_to_exit_first_loop_alt with -ftree-parallelize-loops=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69109 vries at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |6.0 Summary|missing phi argument ICE in |[6 Regression] missing phi |transform_to_exit_first_loo |argument ICE in |p_alt with |transform_to_exit_first_loo |-ftree-parallelize-loops=2 |p_alt with ||-ftree-parallelize-loops=2 --- Comment #1 from vries at gcc dot gnu.org --- Error in transform_to_exit_first_loop_alt, 6 regression
[Bug tree-optimization/55936] [4.9/5 Regression] Missed VRP optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55936 Andrew Pinski changed: What|Removed |Added Summary|[4.9/5/6 Regression] Missed |[4.9/5 Regression] Missed |VRP optimization|VRP optimization --- Comment #10 from Andrew Pinski --- Fixed on the trunk at least: Folding statement: if (i_22 < 0) Folding predicate i_22 < 0 to 0 gimple_simplified to if (0 != 0) Folded into: if (0 != 0) ... Folding statement: if (j_31 > 0) Folding predicate j_31 > 0 to 1 gimple_simplified to if (1 != 0) Folded into: if (1 != 0) ...
[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66848 --- Comment #30 from Jack Howarth --- (In reply to Iain Sandoe from comment #29) > (In reply to Jack Howarth from comment #28) > > (In reply to r...@cebitec.uni-bielefeld.de from comment #27) > > > > --- Comment #25 from Jack Howarth --- > > > Iain suggested that the required changes for supporting SIP will be along > > the lines of... > > > > a) make all libs @rpath/xxx > > b) add @loader_path as an rpath to all libs with a local dep. > > c) add @executable_path/../lib; ../lib as > > rpaths to exes. > > I have a draft for a patch to do this - will try and stick it somewhere > useful soon. It certainly would be worthwhile getting some level of support for SIP in gcc 6 as we really don't want to encourage users to disable that feature.
[Bug middle-end/68542] [6 Regression] 10% 481.wrf performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68542 --- Comment #4 from Andrew Pinski --- (In reply to Yuri Rumyantsev from comment #3) > I enhanced a patch for masked stores movement by guard on zero mask - move > all possible producers for stored value and performance degradation > disappeared. > the patch will be re-designed and send for review next week. What happened to this patch?
[Bug rtl-optimization/64081] [5/6 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 --- Comment #19 from Andrew Pinski --- Any progress on the patch?
[Bug rtl-optimization/68991] -O3 generates misaligned xorv4si3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
H.J. Lu changed:
What|Removed |Added
CC||vmakarov at redhat dot com
--- Comment #9 from H.J. Lu ---
With Bm constraint on SSE *mov_internal, curr_insn_transform in
lra-constraints.c generates an extra
(insn 354 353 323 8 (set (reg:V4SF 192)
(reg:V4SF 202 [192])) 1226 {*movv4sf_internal}
(nil))
for input:
(insn 353 322 354 8 (set (reg:V4SF 202 [192])
(reg:V4SF 201 [192])) 1226 {*movv4sf_internal}
(nil))
[Bug rtl-optimization/68991] -O3 generates misaligned xorv4si3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991 --- Comment #10 from Jakub Jelinek --- But why should the *mov_internal use Bm or vector_operand? It can/should handle both aligned and unaligned memory operands.
[Bug c/69104] invalid atomic memory order not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69104 --- Comment #6 from Martin Sebor --- Patch documenting -Winvalid-memory-model posted for review: https://gcc.gnu.org/ml/gcc-patches/2016-01/msg00111.html
[Bug tree-optimization/68714] [6 Regression] less folding of vector comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68714 --- Comment #5 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #4) > I'd add this regressed with r229128, and indeed before that change reassoc > has been able to optimize the comparisons, but now it is not. So, either we > defer the creation of vec_cond_expr until later time, or need to teach at > least reassoc pass about COND_EXPRs and VEC_COND_EXPRs. More than that, vec_cond_expr for non x86_64 AVX targets here is useless and makes it harder to optimize otherwise. Why again do we need the vec_cond_expr for those expressions again?
[Bug tree-optimization/51492] vectorizer does not support saturated arithmetic patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51492 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Last reconfirmed|2011-12-12 00:00:00 |2016-1-4 Known to fail||6.0 Build|x86_64-linux|x86_64-linux ||aarch64-linux-gnu --- Comment #4 from Andrew Pinski --- AARCH64 could produce SQSUB instead of the following code: add v1.8h, v0.8h, v3.8h cmhiv0.8h, v0.8h, v2.8h and v0.16b, v1.16b, v0.16b
[Bug rtl-optimization/68991] -O3 generates misaligned xorv4si3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991 --- Comment #11 from H.J. Lu --- (In reply to Jakub Jelinek from comment #10) > But why should the *mov_internal use Bm or vector_operand? It > can/should handle both aligned and unaligned memory operands. Only for historical reason.
[Bug rtl-optimization/68991] -O3 generates misaligned xorv4si3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
--- Comment #12 from H.J. Lu ---
(In reply to H.J. Lu from comment #9)
> With Bm constraint on SSE *mov_internal, curr_insn_transform in
> lra-constraints.c generates an extra
>
> (insn 354 353 323 8 (set (reg:V4SF 192)
> (reg:V4SF 202 [192])) 1226 {*movv4sf_internal}
> (nil))
>
> for input:
>
> (insn 353 322 354 8 (set (reg:V4SF 202 [192])
> (reg:V4SF 201 [192])) 1226 {*movv4sf_internal}
> (nil))
LRA is OK when Bm is properly defined as
(define_memory_constraint "Bm"
"@internal Vector memory operand."
(match_operand 0 "vector_memory_operand"))
[Bug tree-optimization/54525] Recognize (vec_)cond_expr in mask operation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54525 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-04 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed also on aarch64-linux-gnu: f: uxtbw2, w2 eor w0, w0, w1 neg w2, w2 and w0, w0, w2 eor w0, w0, w1 ret g: uxtbw2, w2 cmp w2, wzr cselw0, w0, w1, ne ret h: cmgtv2.2d, v3.2d, v2.2d bif v0.16b, v1.16b, v2.16b ret Well actually h is detected correctly; though not on the tree level.
[Bug tree-optimization/55936] [4.9/5/6 Regression] Missed VRP optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55936 Jeffrey A. Law changed: What|Removed |Added Summary|[4.9/5 Regression] Missed |[4.9/5/6 Regression] Missed |VRP optimization|VRP optimization --- Comment #11 from Jeffrey A. Law --- No, this is no fixed on the trunk. You have to look at the .vrp1 dump more closely. There's 3 tests that should be folded by the end of vrp1, only 2 are currently getting folded away. vrp06.c actually tests for this and has an xfailed test for the missed optimization.
[Bug testsuite/68629] FAIL: c-c++-common/attr-simd-3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68629 mrs at gcc dot gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #7 from mrs at gcc dot gnu.org --- I changed cilk to turn off all tests on non-pthread targets by default. That change might fix this PR, feel free to test and let us know if the problem is fixed.
[Bug c++/69139] New: [4.9/5/6 Regression] deduction failure with trailing return type in function template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69139
Bug ID: 69139
Summary: [4.9/5/6 Regression] deduction failure with trailing
return type in function template argument
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
Test case (modified from http://stackoverflow.com/q/31229359/2756719):
auto get(int) -> int { return {}; }
template int f(auto (*)(int) -> R) { return {}; }
int i = f(get);
Compiles on 4.8.2, fails on 4.9 and later:
prog.cc:3:14: error: no matching function for call to 'f(int (&)(int))'
int i = f(get);
^
prog.cc:2:24: note: candidate: template int f(auto:1
(*)(int))
template int f(auto (*)(int) -> R) { return {}; }
^
prog.cc:2:24: note: template argument deduction/substitution failed:
prog.cc:3:14: note: couldn't deduce template parameter 'R'
int i = f(get);
^
It seems as if the 'auto' indicating the trailing return type is being treated
as introducing another template parameter, as if in abbreviated function
templates, and then the trailing return type is just ignored.
[Bug tree-optimization/54013] Loop with control flow not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54013 --- Comment #2 from Andrew Pinski --- Note the loop needs an alignment potion otherwise there could be undefined behavior if 45 is passed the tab array bounds and the one of the elements are greater than x.
[Bug target/69140] New: [5.3 regression] Stack alignment + O1 breaks on x86_64 [introduced by r230176 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69140 Bug ID: 69140 Summary: [5.3 regression] Stack alignment + O1 breaks on x86_64 [introduced by r230176 ] Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bucaneer at gmail dot com Target Milestone: --- Compilation of 64bit Wine with GCC 5.3 fails when using both stack realignment (-mincoming-stack-boundary=3) and optimization (-O1 or higher): --- ../../../wine/dlls/advapi32/crypt_md4.c:134:1: internal compiler error: in choose_baseaddr, at config/i386/i386.c:10412 --- which refers to this assert in choose_baseaddr: --- gcc_assert (base_reg != NULL); --- This worked fine in some pre-5.3 dev builds (as confirmed when testing bug 66697 fix). git bisect identifies r230176 as the cause of the regression: --- commit 6ca53fc513f4efdca56af52439ffc5a49b9e6e21 Author: ebotcazou Date: Wed Nov 11 14:56:17 2015 + PR target/67265 * ira.c (ira_setup_eliminable_regset): Do not necessarily create the frame pointer for stack checking if non-call exceptions aren't used. * config/i386/i386.c (ix86_finalize_stack_realign_flags): Likewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-5-branch@230176 138bc75d-0d04-0410-961f-82ee72b054a4 ---
[Bug tree-optimization/69141] [6 Regression] -O2 -fdump-tree-fre ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69141 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target Milestone|--- |6.0
[Bug tree-optimization/69141] New: [6 Regression] -O2 -fdump-tree-fre ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69141
Bug ID: 69141
Summary: [6 Regression] -O2 -fdump-tree-fre ICEs
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
While looking into PR66223, I found this.
Take this small undefined C++ code:
struct B {
B* self;
B();
virtual void f() = 0;
};
B::B() : self( this ) { self->f(); }
With -O2 -fdump-tree-fre we get the following ICE:
tt99.cc: In constructor ‘B::B()’:
tt99.cc:6:36: internal compiler error: Segmentation fault
B::B() : self( this ) { self->f(); }
^
0xcd2fc7 crash_signal
/home/apinski/src/local/gcc/gcc/toplev.c:334
0x90aef8 symtab_node::name() const
/home/apinski/src/local/gcc/gcc/symtab.c:516
0xe6658b eliminate_dom_walker::before_dom_children(basic_block_def*)
/home/apinski/src/local/gcc/gcc/tree-ssa-pre.c:4328
0x11c8b6b dom_walker::walk(basic_block_def*)
/home/apinski/src/local/gcc/gcc/domwalk.c:265
0xe64563 eliminate
/home/apinski/src/local/gcc/gcc/tree-ssa-pre.c:4464
0xe648af execute
/home/apinski/src/local/gcc/gcc/tree-ssa-pre.c:4900
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug target/69140] [5/6 regression] Stack alignment + O1 breaks on x86_64 [introduced by r230176 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69140 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Target||x86_64-linux-gnu Target Milestone|--- |5.4 Summary|[5 regression] Stack|[5/6 regression] Stack |alignment + O1 breaks on|alignment + O1 breaks on |x86_64 [introduced by |x86_64 [introduced by |r230176 ] |r230176 ] --- Comment #1 from Andrew Pinski --- Can you provide a preprocessed testcase and the exact options you used?
[Bug tree-optimization/67153] [5/6 Regression] integer optimizations 53% slower than std::bitset<>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153 --- Comment #19 from Andrew Pinski --- bitset<> version real0m1.073s user0m1.052s sys 0m0.021s unsigned int real0m0.903s user0m0.883s sys 0m0.019s bitset with container adapter: real0m1.519s user0m1.499s sys 0m0.019s
[Bug tree-optimization/67153] [5/6 Regression] integer optimizations 53% slower than std::bitset<>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67153 --- Comment #20 from Andrew Pinski --- (In reply to Andrew Pinski from comment #19) > bitset<> version > real0m1.073s > user0m1.052s > sys 0m0.021s > > unsigned int > real0m0.903s > user0m0.883s > sys 0m0.019s > > bitset with container adapter: > real0m1.519s > user0m1.499s > sys 0m0.019s I should say this is on a ThunderX T88 pass 2 running at 1.9GHz.
[Bug target/69140] [5/6 regression] Stack alignment + O1 breaks on x86_64 [introduced by r230176 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69140 --- Comment #2 from Justas L --- Created attachment 37221 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37221&action=edit testcase This testcase throws the error when compiled with: gcc -c -O2 -mincoming-stack-boundary=3 crypt_md4.i
[Bug target/69140] [5/6 regression] Stack alignment + O1 breaks on x86_64 [introduced by r230176 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69140 --- Comment #3 from Justas L --- Created attachment 37222 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37222&action=edit testcase2 The previous testcase fails only with -O2 or higher; this one fails with -O1: gcc -c -O1 -mincoming-stack-boundary=3 chain.i
[Bug target/69142] New: missing documentation for s/390 zvector builtin features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69142 Bug ID: 69142 Summary: missing documentation for s/390 zvector builtin features Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: sandra at gcc dot gnu.org CC: krebbel at gcc dot gnu.org Target Milestone: --- This patch https://gcc.gnu.org/ml/gcc-patches/2015-05/msg00935.html added a new "s390_vector_bool" function attribute and it looks like a whole bunch of new built-in functions, but no user documentation for these features. Somebody familiar with this target needs to write the missing documentation.
[Bug c/69122] -Wmisleading-indentation false positive with empty macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69122 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-01-05 Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Thanks; I'm working on a patch for this.
[Bug target/69140] [5/6 regression] Stack alignment + O1 breaks on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69140 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-01-05 Summary|[5/6 regression] Stack |[5/6 regression] Stack |alignment + O1 breaks on|alignment + O1 breaks on |x86_64 [introduced by |x86_64 |r230176 ] | Ever confirmed|0 |1 --- Comment #4 from Eric Botcazou --- > This worked fine in some pre-5.3 dev builds (as confirmed when testing bug > 66697 fix). git bisect identifies r230176 as the cause of the regression: > > --- > commit 6ca53fc513f4efdca56af52439ffc5a49b9e6e21 > Author: ebotcazou > Date: Wed Nov 11 14:56:17 2015 + > > PR target/67265 > * ira.c (ira_setup_eliminable_regset): Do not necessarily create the > frame pointer for stack checking if non-call exceptions aren't used. > * config/i386/i386.c (ix86_finalize_stack_realign_flags): Likewise. Really sure? This change is a no-op unless you use -fstack-check.
[Bug bootstrap/68361] [6 regression] Bootstrap failure with --enable-checking=release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68361 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- Fixed.
[Bug debug/69077] [6 Regression] omnetpp ICEs with -flto -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69077 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-01-05 Ever confirmed|0 |1 --- Comment #10 from Andrew Pinski --- So confirmed.
[Bug c/66970] Add __has_builtin() macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66970 Andy Lutomirski changed: What|Removed |Added CC||luto at mit dot edu --- Comment #2 from Andy Lutomirski --- I'd also like this feature. Not all standard open source projects use autoconf. For example, the Linux kernel doesn't. The Linux kernel *is* capable of probing for the existence of builtins, but it's a pain in the neck: it needs to write out a test .c file and try compiling it. This is slow, and it scales terribly: the configuration step wastes time proportional to the number of probed builtins probing for builtins, and the constant factor is pretty bad. It also means that the amount of work needed to use a new builtin is rather high: add a new config step and remember to use the result correctly in the code that uses the builtin. The name of the resulting macro can't really be standardized. Sure, with __has_builtin, users would still need to probe for __has_builtin itself, but that would be a single check. For builtins that are newer than __has_builtin, there would be no need to have a fallback and, for older builtins, a fallback could be added if needed. (Alternatively, the C code could simply not use the builtin on older gcc versions.)
[Bug target/69143] New: PowerPC64: aggregate results are badly handled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69143
Bug ID: 69143
Summary: PowerPC64: aggregate results are badly handled
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: anton at samba dot org
Target Milestone: ---
This testcase:
struct foo1 {
float x;
float y;
};
struct foo1 blah1(struct foo1 y)
{
struct foo1 x;
x.x = y.y;
x.y = y.x;
return x;
}
Compiled with:
gcc -fno-stack-protector -mcpu=power8 -O2
Results in the following code:
blah1:
xscvdpspn 12,2
stfs 1,-16(1)
ori 2,2,0
lwz 8,-16(1)
mfvsrd 10,12
mr 9,8
rldicl 9,9,0,32
srdi 10,10,32
sldi 10,10,32
or 9,9,10
rotldi 9,9,32
mr 10,9
srdi 9,9,32
sldi 8,10,32
sldi 10,9,32
mtvsrd 1,8
mtvsrd 2,10
xscvspdpn 1,1
xscvspdpn 2,2
blr
I was expecting a couple of FPR moves. Clang does what I expected:
blah1:
fmr 0, 1
fmr 1, 2
fmr 2, 0
blr
[Bug rtl-optimization/68991] -O3 generates misaligned xorv4si3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991
--- Comment #13 from H.J. Lu ---
(In reply to H.J. Lu from comment #12)
> (In reply to H.J. Lu from comment #9)
> > With Bm constraint on SSE *mov_internal, curr_insn_transform in
> > lra-constraints.c generates an extra
> >
> > (insn 354 353 323 8 (set (reg:V4SF 192)
> > (reg:V4SF 202 [192])) 1226 {*movv4sf_internal}
> > (nil))
> >
> > for input:
> >
> > (insn 353 322 354 8 (set (reg:V4SF 202 [192])
> > (reg:V4SF 201 [192])) 1226 {*movv4sf_internal}
> > (nil))
>
>
> LRA is OK when Bm is properly defined as
>
> (define_memory_constraint "Bm"
> "@internal Vector memory operand."
> (match_operand 0 "vector_memory_operand"))
It doesn't work since process_alt_operands in LRA will treat Bm as m:
case CT_MEMORY:
if (MEM_P (op)
&& satisfies_memory_constraint_p (op, cn))
win = true;
else if (spilled_pseudo_p (op))
win = true;
and ignores vector_memory_operand.
[Bug tree-optimization/67781] [5/6 Regression] wrong code generated on big-endian with -O1 -fexpensive-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67781 --- Comment #11 from Thomas Preud'homme --- Yes, sorry. I had finished bootstrap on x86_64-linux-gnu and regression testsuite on both that and arm-none-eabi but I wanted to do a bootstrap on a big endian system. I then got caught up by holidays. I'll post the patch for review and send an update once big endian bootstrap is over.
[Bug rtl-optimization/68991] -O3 generates misaligned xorv4si3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68991 --- Comment #14 from H.J. Lu --- (In reply to H.J. Lu from comment #13) > > LRA is OK when Bm is properly defined as > > > > (define_memory_constraint "Bm" > > "@internal Vector memory operand." > > (match_operand 0 "vector_memory_operand")) > > It doesn't work since process_alt_operands in LRA will treat Bm as m: > >case CT_MEMORY: > if (MEM_P (op) > && satisfies_memory_constraint_p (op, cn)) > win = true; > else if (spilled_pseudo_p (op)) > win = true; > > and ignores vector_memory_operand. It happens with case CT_MEMORY: if (MEM_P (op) && satisfies_memory_constraint_p (op, cn)) win = true; else if (spilled_pseudo_p (op)) win = true; /* If we didn't already win, we can reload constants via force_const_mem or put the pseudo value into memory, or make other memory by reloading the address like for 'o'. */ if (CONST_POOL_OK_P (mode, op) || MEM_P (op) || REG_P (op)) badop = false; /* If this operand accepts a register, and if the register class has at least one allocatable register, then this operand can be reloaded. */ if (winreg && !no_regs_p) badop = false;
[Bug target/69140] [5/6 regression] Stack alignment + O1 breaks on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69140 Eric Botcazou changed: What|Removed |Added Status|WAITING |NEW --- Comment #5 from Eric Botcazou --- > This worked fine in some pre-5.3 dev builds (as confirmed when testing bug > 66697 fix). git bisect identifies r230176 as the cause of the regression: > > --- > commit 6ca53fc513f4efdca56af52439ffc5a49b9e6e21 > Author: ebotcazou > Date: Wed Nov 11 14:56:17 2015 + > > PR target/67265 > * ira.c (ira_setup_eliminable_regset): Do not necessarily create the > frame pointer for stack checking if non-call exceptions aren't used. > * config/i386/i386.c (ix86_finalize_stack_realign_flags): Likewise. As expected, reverting the patch doesn't change anything on the 5 branch, so I'd suggest either filling a bug report for 'git bisect' or double checking its result next time.
[Bug target/69140] stack alignment + O1 breaks with Microsoft ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69140 Eric Botcazou changed: What|Removed |Added Target Milestone|5.4 |--- Summary|[5/6 regression] Stack |stack alignment + O1 breaks |alignment + O1 breaks on|with Microsoft ABI |x86_64 | --- Comment #6 from Eric Botcazou --- Remove categorization based on incorrect diagnostic.
