[Bug debug/70578] internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70578 ishikawa,chiaki changed: What|Removed |Added CC||ishikawa at yk dot rim.or.jp --- Comment #2 from ishikawa,chiaki --- Created attachment 40633 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40633&action=edit preprocessed file that triggers the ICE. I have also seen this bug with gcc version 6.3.0 20170124 (Debian 6.3.0-5) I am attaching a preprocessed file uvectr64.ii gcc version (distributed under Debian GNU/Linux) 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='Debian 6.3.0-5' --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 --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --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.3.0 20170124 (Debian 6.3.0-5) ishikawa@debian-vbox-ci:/tmp$ I encountered a bug during a compilation of mozilla thunderbird. I used the following command to compile the attached .ii file, and I got the following ICE. COMMAND LINE: /usr/bin/g++-6 -std=gnu++11 -o uvectr64.o -c-gsplit-dwarf \ -DNDEBUG=1 -DTRIMMED=1 -DU_COMMON_IMPLEMENTATION -DLOCALE_SNAME=92 \ -DUCONFIG_NO_BREAK_ITERATION -DUCONFIG_NO_TRANSLITERATION \ -DUCONFIG_NO_REGULAR_EXPRESSIONS -DUCONFIG_NO_LEGACY_CONVERSION \ -DU_USING_ICU_NAMESPACE=0 -DU_NO_DEFAULT_INCLUDE_UTF_HEADERS=1 \ -DU_CHARSET_IS_UTF8 -MD -MP -MF -Wall -Wc++11-compat\ -fno-builtin-strlen -Wl,--gdb-index -Dfdatasync=fdatasync \ -DDEBUG_4GB_CHECK -DUSEHELGRIND=1 -fno-exceptions \ -fno-strict-aliasing -fno-rtti -fno-exceptions -fno-math-errno \ -pthread -g3 -Og -freorder-blocks \ -fno-omit-frame-pointer -frtti -fdiagnostics-color \ ./uvectr64.ii ICE error: new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/intl/icu/source/common/uvectr64.cpp:213:3: internal compiler error: in output_index_string, at dwarf2out.c:25635 U_NAMESPACE_END ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. However, if I remove "-gsplit-dwarf" from my command line, it seems to compile. TIA
[Bug debug/70578] internal compiler error: in output_index_string, at dwarf2out.c with -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70578
--- Comment #3 from ishikawa,chiaki ---
I noticed that in my case, it could be related to a name space issue since
U_NAMESPACE_END "}}" is to close the corresponding U_NAMESPACE_BEGIN "extern
"C++" "{ namespace U_ICU_NAMESPACE {".
[Bug target/79295] [7 regression] gcc.target/powerpc/bcd-3.c fails starting with r244942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79295 Richard Biener changed: What|Removed |Added Keywords||ice-on-valid-code Component|other |target Target Milestone|--- |7.0
[Bug c++/79294] [7 Regression] ICE in convert_nontype_argument, at cp/pt.c:6812
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79294 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/79290] [7 Regression] forming pointer to member function tries to access "__pfn"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79290 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |7.0
[Bug tree-optimization/79286] [7 Regression] wrong code at -O3 on x86_64-linux-gnu in 32-bit mode (but not in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79286 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|NEW |ASSIGNED Version|unknown |7.0 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Mine (looks like a latent issue though).
[Bug ipa/79285] [7 Regression] new valgrind error in build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79285 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/79284] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79284 Richard Biener changed: What|Removed |Added Target||x86_64-*-* Priority|P3 |P1 Version|unknown |7.0
[Bug target/79299] [7 Regression] Operand size mismatch for `vpgatherqd' w/ -O3 -masm=intel -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79299 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/79298] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79298 Richard Biener changed: What|Removed |Added Keywords||error-recovery Priority|P3 |P4 Version|unknown |7.0 Target Milestone|--- |7.0
[Bug c++/79296] [7 Regression] ICE in mangle_decl, at cp/mangle.c:3845
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79296 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/79297] [7 Regression] ICE (segfault) in main_block_label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79297 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Target Milestone|--- |7.0
[Bug c++/79267] [6/7 Regression] internal compiler error with -O3 or -O2 -finline-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79267 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Tue Jan 31 08:33:36 2017 New Revision: 245053 URL: https://gcc.gnu.org/viewcvs?rev=245053&root=gcc&view=rev Log: PR tree-optimization/79267 * value-prof.c (gimple_ic): Only drop lhs for noreturn calls if should_remove_lhs_p is true. * g++.dg/opt/pr79267.C: New test. Added: trunk/gcc/testsuite/g++.dg/opt/pr79267.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/value-prof.c
[Bug tree-optimization/79286] [7 Regression] wrong code at -O3 on x86_64-linux-gnu in 32-bit mode (but not in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79286 Martin Liška changed: What|Removed |Added CC||amodra at gcc dot gnu.org --- Comment #4 from Martin Liška --- My small test-case started to segfault with r235660.
[Bug middle-end/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #24 from Eric Botcazou --- The root cause of this mess is actually init_emit: REGNO_POINTER_ALIGN (VIRTUAL_INCOMING_ARGS_REGNUM) = STACK_BOUNDARY; REGNO_POINTER_ALIGN (VIRTUAL_STACK_VARS_REGNUM) = STACK_BOUNDARY; REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM) = STACK_BOUNDARY; REGNO_POINTER_ALIGN (VIRTUAL_OUTGOING_ARGS_REGNUM) = STACK_BOUNDARY; 3 out of 4 are wrong for 32-bit SPARC. VIRTUAL_STACK_DYNAMIC_REGNUM is fixable but not VIRTUAL_INCOMING_ARGS_REGNUM & VIRTUAL_OUTGOING_ARGS_REGNUM, whose offset is defined by the ABI. The code in init_emit looks wrong to me, as STACK_BOUNDARY is documented as: -- Macro: STACK_BOUNDARY Define this macro to the minimum alignment enforced by hardware for the stack pointer on this machine. The definition is a C expression for the desired alignment (measured in bits). This value is used as a default if `PREFERRED_STACK_BOUNDARY' is not defined. On most machines, this should be the same as `PARM_BOUNDARY'. but it goes back to 1995; I guess nobody cared about it until Dominik's patch.
[Bug middle-end/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #25 from Jakub Jelinek --- So do we want a target hook that can override these alignments, or new macros for each of the alignments that default to STACK_BOUNDARY?
[Bug c++/79300] New: Wrong diagnostics position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79300
Bug ID: 79300
Summary: Wrong diagnostics position
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Let's consider following test-case:
$ cat memtable.cc
#include
void
a ()
{
long val_size;
unsigned long encoded_len;
char *buf, *p;
assert ((p + val_size) - buf == encoded_len);
}
$ g++ memtable.cc -Wsign-compare -c
In file included from memtable.cc:1:0:
memtable.cc: In function ‘void a()’:
memtable.cc:8:32: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
assert ((p + val_size) - buf == encoded_len);
~^~~~
Tilda line ends after the first letter of 'encoded_len', which is wrong.
[Bug c++/70844] spurious -Wuseless-cast warning with inherited constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70844
TC changed:
What|Removed |Added
CC||rs2740 at gmail dot com
--- Comment #1 from TC ---
The attached test case doesn't reproduce in 6.2.0, presumably due to the fix
for 70972. The following (slightly modified) test case still produces a
-Wuseless-cast warning on trunk and 6.3.0:
struct base {
base (int const &);
};
struct derived : public base {
using base::base;
};
derived d(0);
What appears to be happening is that the inheriting constructor calls
forward_parm to perfectly forward the arguments, which in turn calls
build_static_cast to construct the equivalent of static_cast(p)
where p is of type const int &, which emits a -Wuseless-cast warning.
Consistent with this hypothesis, 6.1 emits a warning for the original test case
because it was emitting the equivalent of static_cast(p) where `p`'s type
is `int`; GCC >= 6.2, which has the 70972 fix, emits the equivalent of
static_cast(p), which doesn't trigger the warning. GCC < 6 doesn't have
forward_parm and doesn't unconditionally build a static_cast, so doesn't hit
this warning either.
[Bug c++/79300] Wrong diagnostics position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79300 Martin Liška changed: What|Removed |Added Target Milestone|--- |7.0 Known to fail||6.3.0, 7.0
[Bug middle-end/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #26 from Eric Botcazou --- > So do we want a target hook that can override these alignments, or new > macros for each of the alignments that default to STACK_BOUNDARY? No strong opinion, but IMO the main issue is to arrange for the default to be conservatively safe so that we don't have to go over the ~50 architectures.
[Bug testsuite/79272] FAIL: gcc.dg/ipa/pr77653.c scan-ipa-dump icf "Not unifying; alias cannot be created; target is discardable"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79272 --- Comment #5 from Martin Liška --- Created attachment 40634 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40634&action=edit Patch candidate Thanks for dumps. This patch should fix your problems. Can you please test that before I'll send that to ML?
[Bug middle-end/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #27 from Jakub Jelinek --- (In reply to Eric Botcazou from comment #26) > > So do we want a target hook that can override these alignments, or new > > macros for each of the alignments that default to STACK_BOUNDARY? > > No strong opinion, but IMO the main issue is to arrange for the default to > be conservatively safe so that we don't have to go over the ~50 > architectures. Well, at least at this point in GCC 7 development the fewer architectures we change the better.
[Bug tree-optimization/79286] [7 Regression] wrong code at -O3 on x86_64-linux-gnu in 32-bit mode (but not in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79286 Richard Biener changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #5 from Richard Biener --- Unassigning then.
[Bug tree-optimization/79291] r244897 introduces alias related performance issues for daxpy on MIPS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79291 Richard Biener changed: What|Removed |Added Target||mips32r2 Summary|r244397 introduces alias|r244897 introduces alias |related performance issues |related performance issues |for daxpy on MIPS |for daxpy on MIPS --- Comment #1 from Richard Biener --- Make sure to test after 2017-01-30 Richard Biener PR tree-optimization/79256 * targhooks.c (default_builtin_vector_alignment_reachable): Honor BIGGEST_FIELD_ALIGNMENT and ADJUST_FIELD_ALIGN to fix up bogus alignment on TYPE. * tree.c (build_aligned_type): Set TYPE_USER_ALIGN. I assume you are talking about mips32r2 in this bug. mips doesn't override ADJUST_FIELD_ALIGN or MAXIMUM_FIELD_ALIGNMENT or vector_alignment_reachable so it should benefit from the fixes in that types bigger than the pointer size can now be made properly aligned.
[Bug middle-end/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #28 from Eric Botcazou --- > Well, at least at this point in GCC 7 development the fewer architectures we > change the better. Sure, but by changing the middle-end, you change all the architectures at once and may break a fair number of them in the process. At this point I'd lean towards Bernd's position and revert again the get_dynamic_stack_size change, since it relies on the very questionable settings of init_emit.
[Bug middle-end/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #29 from Jakub Jelinek --- (In reply to Eric Botcazou from comment #28) > > Well, at least at this point in GCC 7 development the fewer architectures we > > change the better. > > Sure, but by changing the middle-end, you change all the architectures at > once and may break a fair number of them in the process. At this point I'd > lean towards Bernd's position and revert again the get_dynamic_stack_size > change, since it relies on the very questionable settings of init_emit. I have no problem with that for GCC 7 either.
[Bug middle-end/61677] False positive with -Wmaybe-uninitialized (predicate analysis, VRP)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61677 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #6 from Jeffrey A. Law --- The reduced testcase was fixed nearly two years ago. However, the full testcase still warns. I have not tried to re-reduce the testcase.
[Bug tree-optimization/79291] r244897 introduces IV related performance issues for daxpy on MIPS by enabling peeling for alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79291
--- Comment #2 from Richard Biener ---
It also looks like mips lacks implementation of any of the vectorizer cost
hooks and thus defaults to default_builtin_vectorization_cost which means that
unaligned loads/stores have double cost. And mips supports misaligned
loads/stores via movmisalign (for MSA). For daxpy:
for (i = 0;i < n; i++) {
dy[i] = dy[i] + da*dx[i];
}
the above makes peeling for alignment of dy[] profitable (and I'd generally
agree because esp. misaligned stores do have a real penalty - though likely
not when the store queue is not contended as likely in this case).
x86_64 peels for alignment as well and we get
.L6:
movups (%rax,%r8), %xmm1
addl$1, %r9d
mulps %xmm2, %xmm1
addps (%r11,%r8), %xmm1
movaps %xmm1, (%r11,%r8)
addq$16, %r8
cmpl%ebx, %r9d
jb .L6
and similar base+index addressing. IVO does see the indices are the same
though.
# i_46 = PHI
prolog_loop_adjusted_niters.6_48 = (sizetype) prolog_loop_niters.5_34;
niters.7_49 = niters.3_40 - prolog_loop_niters.5_34;
bnd.8_69 = niters.7_49 >> 2;
_75 = prolog_loop_adjusted_niters.6_48 * 4;
vectp_dy.12_74 = dy_15(D) + _75;
_80 = prolog_loop_adjusted_niters.6_48 * 4;
vectp_dx.15_79 = dx_16(D) + _80;
vect_cst__84 = {da_14(D), da_14(D), da_14(D), da_14(D)};
_88 = prolog_loop_adjusted_niters.6_48 * 4;
vectp_dy.20_87 = dy_15(D) + _88;
shows the missed CSE from the vectorizer (and a redundant IV).
During DR analysis we can in theory keep a list of stmts that share the
"same" DR (we have this for group reads already) and record the generated
IVs on the "master" DR.
A region-based CSE/DCE would still be my preference in the end.
[Bug c++/79300] Wrong diagnostics position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79300 Richard Biener changed: What|Removed |Added Version|unknown |7.0 Target Milestone|7.0 |---
[Bug middle-end/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664 --- Comment #13 from Richard Earnshaw --- (In reply to Segher Boessenkool from comment #12) > new_ready just adds insns to the ready list. High latency isn't > directly a problem: if we can schedule a high latency insn early > speculatively, that is a _good_ thing! Only if you're certain to need the result. If you aren't then you're blocking resources that might be used for other instructions to no useful purpose. Indeed, you might find that a tight loop now takes much longer because the speculative insn is never used but now dominates the critical path. If you're not certain to want the result you're probably better off letting the hardware speculation do the work, it will probably know how to abandon high latency operations if the path turns out to be false.
[Bug target/79282] [7 Regresion] FAIL: gcc.target/arm/neon-for-64bits-1.c scan-assembler-times vshr 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79282 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-31 CC||clyon at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from ktkachov at gcc dot gnu.org --- So the failure goes away if I change the arch attribute of the last two alternatives of the di3_neon pattern to neon_for_64bits from avoid_neon_for_64bits so that they are disabled when NEON is not preferred, but I see it was intentionally written this way, with many similar patterns in arm.md having the same structure (first two alternatives with neon_for_64bits, followed by the GPR alternatives, followed by two avoid_neon_for_64bits alternatives). Christophe, do you recall why it's structured that way?
[Bug tree-optimization/71691] [6/7 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (Floating point exception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71691 --- Comment #21 from Aldy Hernandez --- Author: aldyh Date: Tue Jan 31 10:30:47 2017 New Revision: 245057 URL: https://gcc.gnu.org/viewcvs?rev=245057&root=gcc&view=rev Log: PR tree-optimization/71691 * bitmap.h (class auto_bitmap): New. * tree-ssa-loop-unswitch.c (tree_may_unswitch_on): Call is_maybe_undefined instead of ssa_undefined_value_p. Added: trunk/gcc/testsuite/gcc.dg/loop-unswitch-5.c Modified: trunk/gcc/ChangeLog trunk/gcc/bitmap.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/loop-unswitch-1.c trunk/gcc/tree-ssa-loop-unswitch.c
[Bug tree-optimization/71691] [6 Regression] wrong code at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (Floating point exception)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71691 Aldy Hernandez changed: What|Removed |Added Summary|[6/7 Regression] wrong code |[6 Regression] wrong code |at -O3 in both 32-bit and |at -O3 in both 32-bit and |64-bit modes on |64-bit modes on |x86_64-linux-gnu (Floating |x86_64-linux-gnu (Floating |point exception)|point exception) --- Comment #22 from Aldy Hernandez --- Fixed in trunk. Removing GCC7 regression marker.
[Bug ipa/79285] [7 Regression] new valgrind error in build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79285 --- Comment #3 from Martin Liška --- Author: marxin Date: Tue Jan 31 10:54:41 2017 New Revision: 245058 URL: https://gcc.gnu.org/viewcvs?rev=245058&root=gcc&view=rev Log: Call symbol_summary<>::release instead of ~symbol_summary (PR ipa/79285). 2017-01-31 Martin Liska PR ipa/79285 * ipa-prop.c (ipa_free_all_node_params): Call release method instead of ~sumbol_summary to not to trigger double times dtor of hash_map. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c
[Bug c++/79301] New: With -Werror=pedantic outside C++17 mode, __has_cpp_attribute(fallthrough) is nonzero but [[fallthrough]] fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79301
Bug ID: 79301
Summary: With -Werror=pedantic outside C++17 mode,
__has_cpp_attribute(fallthrough) is nonzero but
[[fallthrough]] fails
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andersk at mit dot edu
Target Milestone: ---
One would expect code like this to silence the new -Wimplicit-fallthrough
warning that’s been added to -Wextra:
switch (x) {
case 0:
printf("zero\n");
#if __has_cpp_attribute(fallthrough)
[[fallthrough]];
#elif __has_cpp_attribute(gnu::fallthrough)
[[gnu::falthrough]];
#endif
case 1:
printf("zero or one\n");
}
However, this fails to compile with -Werror=pedantic in C++14 mode or earlier:
“error: ‘fallthrough’ is a C++17 feature; use ‘gnu::fallthrough’
[-Werror=pedantic]”.
__has_cpp_attribute(fallthrough) should evaluate to 0 if [[fallthrough]] is not
going to work.
[Bug tree-optimization/77318] [7 regression] FAIL: gfortran.dg/graphite/pr68279.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77318
--- Comment #10 from Richard Biener ---
Ok, so the issue is we have a region that is inside of loop 1 but does not
fully cover it and in
/* Returns a linear expression for tree T evaluated in PBB. */
static isl_pw_aff *
create_pw_aff_from_tree (poly_bb_p pbb, tree t)
{
scop_p scop = PBB_SCOP (pbb);
t = scalar_evolution_in_region (scop->scop_info->region, pbb_loop (pbb), t);
when analyzing _62 from a condition on a block inside the region (the blocks
loop father is loop 1) pbb_loop returns loop 3 (pbb->black_box->bb is its
loop header).
_62 is defined inside the region, but then
if (TREE_CODE (t) != SSA_NAME
|| loop_in_sese_p (loop, region))
/* FIXME: we would need instantiate SCEV to work on a region, and be more
flexible wrt. memory loads that may be invariant in the region. */
return instantiate_scev (before, loop,
analyze_scalar_evolution (loop, t));
here loop is loop 3 and thus we call analyze_scalar_evolution with bogus input
which just returns t, instantiate_scev then instantiates it to
(integer(kind=8)) (integer(kind=4)) {(unsigned int) pretmp_123 + 4294967295, +,
1}_1 but this has an evolution in a loop that is not in the region and boom.
Eventually that pbb is bogus from the start or rather that we are using pbb
when adding dominating conditions(?).
Index: gcc/graphite-sese-to-poly.c
===
--- gcc/graphite-sese-to-poly.c (revision 245052)
+++ gcc/graphite-sese-to-poly.c (working copy)
@@ -436,11 +436,11 @@ extract_affine (scop_p s, tree e, __isl_
/* Returns a linear expression for tree T evaluated in PBB. */
static isl_pw_aff *
-create_pw_aff_from_tree (poly_bb_p pbb, tree t)
+create_pw_aff_from_tree (poly_bb_p pbb, loop_p loop, tree t)
{
scop_p scop = PBB_SCOP (pbb);
- t = scalar_evolution_in_region (scop->scop_info->region, pbb_loop (pbb), t);
+ t = scalar_evolution_in_region (scop->scop_info->region, loop, t);
gcc_assert (!chrec_contains_undetermined (t));
gcc_assert (!automatically_generated_chrec_p (t));
@@ -455,8 +455,9 @@ create_pw_aff_from_tree (poly_bb_p pbb,
static void
add_condition_to_pbb (poly_bb_p pbb, gcond *stmt, enum tree_code code)
{
- isl_pw_aff *lhs = create_pw_aff_from_tree (pbb, gimple_cond_lhs (stmt));
- isl_pw_aff *rhs = create_pw_aff_from_tree (pbb, gimple_cond_rhs (stmt));
+ loop_p loop = gimple_bb (stmt)->loop_father;
+ isl_pw_aff *lhs = create_pw_aff_from_tree (pbb, loop, gimple_cond_lhs
(stmt));
+ isl_pw_aff *rhs = create_pw_aff_from_tree (pbb, loop, gimple_cond_rhs
(stmt));
isl_set *cond;
switch (code)
fixes that but then we ICE in
#1 0x019bfc12 in extract_affine (s=0x2ab42a0,
e=, space=0x2ae7790)
at /space/rguenther/src/svn/gcc-7-branch/gcc/graphite-sese-to-poly.c:409
408 case SSA_NAME:
409 gcc_assert (-1 != parameter_index_in_region_1 (e, s->scop_info)
410 || !invariant_in_sese_p_rec (e, s->scop_info->region,
NULL));
because the SSA name failed to register as parameter(?) - it is actually
defined inside! But we run into
tree
scalar_evolution_in_region (const sese_l ®ion, loop_p loop, tree t)
{
...
if (invariant_in_sese_p_rec (t, region, &has_vdefs))
return t;
which looks correct -- but it seems that extract_affine assumes we
"instantiate" an expression up to the regions params...
So maybe that assert is just another bogus one or scalar_evolution_in_region
is bogus (instantiating before the region entry returns a chrec with an
evolution in a loop not inside the region again...).
Well. Doing
Index: gcc/graphite-sese-to-poly.c
===
--- gcc/graphite-sese-to-poly.c (revision 245052)
+++ gcc/graphite-sese-to-poly.c (working copy)
@@ -407,7 +407,7 @@ extract_affine (scop_p s, tree e, __isl_
case SSA_NAME:
gcc_assert (-1 != parameter_index_in_region_1 (e, s->scop_info)
- || !invariant_in_sese_p_rec (e, s->scop_info->region, NULL));
+ || defined_in_sese_p (e, s->scop_info->region));
res = extract_affine_name (s, e, space);
break;
fixes the testcase and still passes graphite.exp for all languages w/ {,-m32}.
[Bug libgcc/79280] mbtowc converts only one byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79280 Jan Turoň changed: What|Removed |Added Resolution|INVALID |WORKSFORME
[Bug tree-optimization/77318] [7 regression] FAIL: gfortran.dg/graphite/pr68279.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77318 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #11 from Richard Biener --- Patch posted.
[Bug tree-optimization/71311] [7 Regression] spec2006 test case 416.gamess fails since r235817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71311 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Richard Biener --- Seems to be fixed again. Let's close this (reverting the pattern doesn't reproduce it either).
[Bug libgcc/79280] mbtowc converts only one byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79280
--- Comment #2 from Jan Turoň ---
setlocale does some change, but still not right:
My system locale is cs_CZ, the default codepage is 1250, console uses 852. I
Have these results, considering this code:
const char *str = "ř";
mbtowc(&(a.w), str, 6);
printf("\na = %hhx%hhx", a.bytes.b2, a.bytes.b1);
setlocale(LC_CTYPE,"C"); // gives 0c5
setlocale(LC_CTYPE,"Czech_Czech Republic.1250"); // (same as "") gives 139
setlocale(LC_CTYPE,"Czech_Czech Republic.852"); // (same as "") gives 253c
The expected result is 159 (Unicode number of "ř").
[Bug target/79282] [7 Regresion] FAIL: gcc.target/arm/neon-for-64bits-1.c scan-assembler-times vshr 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79282 --- Comment #3 from Christophe Lyon --- I don't remember well, but it could be related to Richard's comment about cleaning the onlya8 flag: https://gcc.gnu.org/ml/gcc-patches/2012-12/msg01063.html
[Bug tree-optimization/79286] [7 Regression] wrong code at -O3 on x86_64-linux-gnu in 32-bit mode (but not in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79286 Alan Modra changed: What|Removed |Added Status|NEW |ASSIGNED CC||amodra at gmail dot com Assignee|unassigned at gcc dot gnu.org |amodra at gcc dot gnu.org
[Bug ipa/79285] [7 Regression] new valgrind error in build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79285 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška --- Fixed.
[Bug tree-optimization/79302] New: ICE in add_loop_constraints, at graphite-sese-to-poly.c:933 building 445.gobmk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79302 Bug ID: 79302 Summary: ICE in add_loop_constraints, at graphite-sese-to-poly.c:933 building 445.gobmk Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- Target: x86_64-*-* On core-avx2 with -Ofast -march=native -floop-nest-optimize
[Bug tree-optimization/79303] New: ICE: Segmentation fault from apply_schedule_map_to_scop, graphite-optimize-isl.c:429 building 464.h264ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79303 Bug ID: 79303 Summary: ICE: Segmentation fault from apply_schedule_map_to_scop, graphite-optimize-isl.c:429 building 464.h264ref Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- Target: x86_64-*-* With -Ofast -march=native -floop-nest-optimize on core-avx2.
[Bug middle-end/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664 --- Comment #14 from Segher Boessenkool --- I'm not sure how to read your remark. An insn where the result is not used is not on the critical path by definition; and you seem to be arguing for -fno-sched-spec by default?
[Bug tree-optimization/79302] ICE in add_loop_constraints, at graphite-sese-to-poly.c:933 building 445.gobmk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79302 --- Comment #1 from Richard Biener --- > ./cc1 -quiet -fpreprocessed getopt.i -quiet -dumpbase getopt.c -auxbase-strip > utils/getopt.o -O2 -version -floop-nest-optimize -o getopt.s GNU C11 (GCC) version 7.0.1 20170131 (experimental) [trunk revision 245052] (x86_64-pc-linux-gnu) compiled by GNU C version 4.8.5, GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.2, isl version 0.15 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C11 (GCC) version 7.0.1 20170131 (experimental) [trunk revision 245052] (x86_64-pc-linux-gnu) compiled by GNU C version 4.8.5, GMP version 5.1.3, MPFR version 3.1.2, MPC version 1.0.2, isl version 0.15 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 678ed9022a271b5b37b7e377eb717846 utils/getopt.c: In function ‘exchange’: utils/getopt.c:300:1: internal compiler error: in add_loop_constraints, at graphite-sese-to-poly.c:934 0x191fe29 add_loop_constraints /space/rguenther/src/svn/gcc-7-branch/gcc/graphite-sese-to-poly.c:934 0x192022d build_iteration_domains /space/rguenther/src/svn/gcc-7-branch/gcc/graphite-sese-to-poly.c:1002 0x192038a build_iteration_domains /space/rguenther/src/svn/gcc-7-branch/gcc/graphite-sese-to-poly.c:1041 0x192106f build_poly_scop(scop*) /space/rguenther/src/svn/gcc-7-branch/gcc/graphite-sese-to-poly.c:1365 0x1904f06 graphite_transform_loops() /space/rguenther/src/svn/gcc-7-branch/gcc/graphite.c:319 0x1904fb8 graphite_transforms /space/rguenther/src/svn/gcc-7-branch/gcc/graphite.c:356 0x19050db execute /space/rguenther/src/svn/gcc-7-branch/gcc/graphite.c:433 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. reducing testcase.
[Bug middle-end/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #30 from Dominik Vogt --- (In reply to Eric Botcazou from comment #24) > The root cause of this mess is actually init_emit: > > REGNO_POINTER_ALIGN (VIRTUAL_INCOMING_ARGS_REGNUM) = STACK_BOUNDARY; > REGNO_POINTER_ALIGN (VIRTUAL_STACK_VARS_REGNUM) = STACK_BOUNDARY; > REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM) = STACK_BOUNDARY; > REGNO_POINTER_ALIGN (VIRTUAL_OUTGOING_ARGS_REGNUM) = STACK_BOUNDARY; > > 3 out of 4 are wrong for 32-bit SPARC. VIRTUAL_STACK_DYNAMIC_REGNUM is > fixable but not VIRTUAL_INCOMING_ARGS_REGNUM & VIRTUAL_OUTGOING_ARGS_REGNUM, > whose offset is defined by the ABI. So there's a fundamental mismatch between the middleend's stack layout and target ABIs (Sparc, maybe others)? Looks like this never showed up because the values are not used anyway. Grepping through the sources and a regression test with bogus values (255) instead of STACK_BOUNDARY shows no uses of the other three, and only the one use of REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM) in explow.c. > The code in init_emit looks wrong to me, as STACK_BOUNDARY is documented as: > > -- Macro: STACK_BOUNDARY > Define this macro to the minimum alignment enforced by hardware > for the stack pointer on this machine. The definition is a C > expression for the desired alignment (measured in bits). This > value is used as a default if `PREFERRED_STACK_BOUNDARY' is not > defined. On most machines, this should be the same as > `PARM_BOUNDARY'. > > but it goes back to 1995; I guess nobody cared about it until Dominik's > patch. There are more potentially questionable uses of STACK_BOUNDARY that may not match its documentation. Hard to tell without analysing the individual uses in detail. So, this should be fixable by a simple target macro VIRTUAL_STACK_DYNAMIC_ALIGN or something like that (not adressing the INCOMING/OUTGOING_ARGS alignment thing.)
[Bug tree-optimization/79302] ICE in add_loop_constraints, at graphite-sese-to-poly.c:933 building 445.gobmk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79302 --- Comment #2 from Richard Biener --- Created attachment 40635 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40635&action=edit autoreduced testcase This one is probably because the region has an entry loop-header -> loop-block and an exit loop-latch -> loop-header. So its a loop without its header. I suppose a backedge as region exit isn't very well handled...
[Bug c++/79304] New: [7 Regression] diagnostic shows bogus expression ((X*)this)->.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79304
Bug ID: 79304
Summary: [7 Regression] diagnostic shows bogus expression
((X*)this)->.c
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
struct C { };
template
struct X
{
C* c;
void f() {
this->c.s();
}
};
int main()
{
X x;
x.f();
}
x.cc: In member function 'void X::f()':
x.cc:9:13: error: request for member 's' in '((X*)this)->.c', which is of
pointer type 'C*' (maybe you meant to use '->' ?)
this->c.s();
^
The ->.c part is bogus, that doesn't appear in the source, and isn't valid C++.
GCC 6 is correct:
x.cc: In instantiation of 'void X::f() [with T = int]':
x.cc:16:7: required from here
x.cc:9:13: error: request for member 's' in '((X*)this)->X::c', which
is of pointer type 'C*' (maybe you meant to use '->' ?)
this->c.s();
^
If it's not a template we get ((X*)this)->X::c which is also correct.
[Bug c++/79304] [7 Regression] diagnostic shows bogus expression ((X*)this)->.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79304 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-01-31 Known to work||5.4.0, 6.3.0 Ever confirmed|0 |1
[Bug tree-optimization/79302] ICE in add_loop_constraints, at graphite-sese-to-poly.c:933 building 445.gobmk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79302
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-01-31
CC||marxin at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from Martin Liška ---
Reduced test-case:
*a;
b;
f ()
{
int c;
while (b)
if (-b > c)
{
int d, e;
for (; e < d; e++)
a[e] = d;
}
else
{
int d, e;
for (; e < d; e++)
a[e] = a;
}
}
[Bug tree-optimization/79302] [6/7 Regression] ICE in add_loop_constraints, at graphite-sese-to-poly.c:933 building 445.gobmk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79302 Martin Liška changed: What|Removed |Added CC||spop at gcc dot gnu.org --- Comment #4 from Martin Liška --- Started to ICE with r232812.
[Bug tree-optimization/79291] r244897 introduces IV related performance issues for daxpy on MIPS by enabling peeling for alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79291
--- Comment #3 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #2)
> It also looks like mips lacks implementation of any of the vectorizer cost
> hooks and thus defaults to default_builtin_vectorization_cost which means
> that
> unaligned loads/stores have double cost. And mips supports misaligned
> loads/stores via movmisalign (for MSA). For daxpy:
>
>for (i = 0;i < n; i++) {
> dy[i] = dy[i] + da*dx[i];
> }
>
> the above makes peeling for alignment of dy[] profitable (and I'd generally
> agree because esp. misaligned stores do have a real penalty - though likely
> not when the store queue is not contended as likely in this case).
>
> x86_64 peels for alignment as well and we get
>
> .L6:
> movups (%rax,%r8), %xmm1
> addl$1, %r9d
> mulps %xmm2, %xmm1
> addps (%r11,%r8), %xmm1
> movaps %xmm1, (%r11,%r8)
> addq$16, %r8
> cmpl%ebx, %r9d
> jb .L6
>
> and similar base+index addressing. IVO does see the indices are the same
> though.
>
> # i_46 = PHI
> prolog_loop_adjusted_niters.6_48 = (sizetype) prolog_loop_niters.5_34;
> niters.7_49 = niters.3_40 - prolog_loop_niters.5_34;
> bnd.8_69 = niters.7_49 >> 2;
> _75 = prolog_loop_adjusted_niters.6_48 * 4;
> vectp_dy.12_74 = dy_15(D) + _75;
> _80 = prolog_loop_adjusted_niters.6_48 * 4;
> vectp_dx.15_79 = dx_16(D) + _80;
> vect_cst__84 = {da_14(D), da_14(D), da_14(D), da_14(D)};
> _88 = prolog_loop_adjusted_niters.6_48 * 4;
> vectp_dy.20_87 = dy_15(D) + _88;
>
> shows the missed CSE from the vectorizer (and a redundant IV).
Do you mean the IV for exit comparison? Yes, iv_elimination could be improved,
especially we know there must be no wrapping in address from vectorization
analyzer.
>
> During DR analysis we can in theory keep a list of stmts that share the
> "same" DR (we have this for group reads already) and record the generated
> IVs on the "master" DR.
Grouping DRs is helpful, but not optimal. For case like PR68030, we have
starting addresses for vectors as below:
base1 + offset + init1;
base1 + offset + init2;
base1 + offset + init3;
base1 + offset + init4;
base2 + offset + init5;
We may still need to reassociate constant part (init) out of offset. Simply
grouping/reassociation DRs of the same memory object still has problem with the
last one.
I will send patches both for vectroizer and IVOPT as next stage1 opens.
>
> A region-based CSE/DCE would still be my preference in the end.
[Bug tree-optimization/71824] [6/7 Regression] ICE when compiling libiberty with Graphite loop optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71824 --- Comment #8 from Martin Liška --- Full back-trace: 0x1307b83 add_loop_constraints ../../gcc/graphite-sese-to-poly.c:933 0x1307c7b build_iteration_domains ../../gcc/graphite-sese-to-poly.c:1001 0x1307d0a build_iteration_domains ../../gcc/graphite-sese-to-poly.c:1040 0x13084ef build_poly_scop(scop*) ../../gcc/graphite-sese-to-poly.c:1364 0x12f2758 graphite_transform_loops() ../../gcc/graphite.c:319 0x12f2d00 graphite_transforms ../../gcc/graphite.c:356 0x12f2d00 execute ../../gcc/graphite.c:433
[Bug tree-optimization/79302] [6/7 Regression] ICE in add_loop_constraints, at graphite-sese-to-poly.c:933 building 445.gobmk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79302 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška --- Dup.
[Bug target/77687] frame access after release without redzone on powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77687 --- Comment #4 from hainque at adacore dot com --- Thanks again for your help on this Segher! > On Jan 27, 2017, at 01:54 , segher at gcc dot gnu.org > wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77687 > > Segher Boessenkool changed: > > What|Removed |Added > > Known to work||7.0 > > -- > You are receiving this mail because: > You reported the bug.
[Bug tree-optimization/79302] [6/7 Regression] ICE in add_loop_constraints, at graphite-sese-to-poly.c:933 building 445.gobmk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79302
--- Comment #6 from Richard Biener ---
But it smells similar to PR77318.
gcc_assert (!chrec_contains_undetermined (nb_iters));
nb_iters = scalar_evolution_in_region (region, loop, nb_iters);
gcc_assert (!chrec_contains_undetermined (nb_iters));
nb_iters is (unsigned int) _2 + 4294967295, defined outside of loop,
loops outer loop is not fully contained within the region.
scalar_evolution_in_region goes
if (TREE_CODE (t) != SSA_NAME
|| loop_in_sese_p (loop, region))
/* FIXME: we would need instantiate SCEV to work on a region, and be more
flexible wrt. memory loads that may be invariant in the region. */
return instantiate_scev (before, loop,
analyze_scalar_evolution (loop, t));
where analyze_scalar_evolution just does nothing (obviously) but
instantiate_scev returns scev_not_known because in 'before' we have
_2 = middle_39 - bottom_30 and that's not analyzable (but graphite
expects instantiation to stop there, evaluating to this symbolically).
But we do
static tree
instantiate_scev_name (basic_block instantiate_below,
struct loop *evolution_loop, struct loop *inner_loop,
tree chrec,
bool *fold_conversions,
int size_expr)
{
...
/* If the analysis yields a parametric chrec, instantiate the
result again. */
res = analyze_scalar_evolution (def_loop, chrec);
and that fails and we run in circles via
else if (res != chrec_dont_know)
{
if (inner_loop
&& def_bb->loop_father != inner_loop
&& !flow_loop_nested_p (def_bb->loop_father, inner_loop))
/* ??? We could try to compute the overall effect of the loop here.
*/
res = chrec_dont_know;
else
res = instantiate_scev_r (instantiate_below, evolution_loop,
inner_loop, res,
fold_conversions, size_expr);
with the same SSA name again and again until we give up due to the recursion
limit. So the expectation of GRAPHITE is sth like
Index: gcc/tree-scalar-evolution.c
===
--- gcc/tree-scalar-evolution.c (revision 245058)
+++ gcc/tree-scalar-evolution.c (working copy)
@@ -280,6 +280,7 @@ along with GCC; see the file COPYING3.
#include "params.h"
#include "tree-ssa-propagate.h"
#include "gimple-fold.h"
+#include "cfgexpand.h"
static tree analyze_scalar_evolution_1 (struct loop *, tree, tree);
static tree analyze_scalar_evolution_for_address_of (struct loop *loop,
@@ -2460,9 +2461,14 @@ instantiate_scev_name (basic_block insta
/* ??? We could try to compute the overall effect of the loop here.
*/
res = chrec_dont_know;
else
- res = instantiate_scev_r (instantiate_below, evolution_loop,
- inner_loop, res,
- fold_conversions, size_expr);
+ {
+ if (res == chrec
+ && is_gimple_assign (SSA_NAME_DEF_STMT (res)))
+ res = gimple_assign_rhs_to_tree (SSA_NAME_DEF_STMT (res));
+ res = instantiate_scev_r (instantiate_below, evolution_loop,
+ inner_loop, res,
+ fold_conversions, size_expr);
+ }
}
/* Store the correct value to the cache. */
which fixes the ICE. But we can probably simply deal with this case in
add_loop_constraints with
Index: gcc/graphite-sese-to-poly.c
===
--- gcc/graphite-sese-to-poly.c (revision 245058)
+++ gcc/graphite-sese-to-poly.c (working copy)
@@ -930,7 +931,11 @@ add_loop_constraints (scop_p scop, __isl
/* loop_i <= expr_nb_iters */
gcc_assert (!chrec_contains_undetermined (nb_iters));
nb_iters = scalar_evolution_in_region (region, loop, nb_iters);
- gcc_assert (!chrec_contains_undetermined (nb_iters));
+ if (chrec_contains_undetermined (nb_iters))
+{
+ isl_space_free (space);
+ return domain;
+}
isl_pw_aff *aff_nb_iters = extract_affine (scop, nb_iters,
isl_space_copy (space));
[Bug tree-optimization/79302] [6/7 Regression] ICE in add_loop_constraints, at graphite-sese-to-poly.c:933 building 445.gobmk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79302 Martin Liška changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #7 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 71824 ***
[Bug tree-optimization/71824] [6/7 Regression] ICE when compiling libiberty with Graphite loop optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71824 Martin Liška changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #9 from Martin Liška --- *** Bug 79302 has been marked as a duplicate of this bug. ***
[Bug target/79299] [7 Regression] Operand size mismatch for `vpgatherqd' w/ -O3 -masm=intel -mavx512bw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79299 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 40636 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40636&action=edit gcc7-pr79299.patch Untested patch that makes gcc emit what gas expects, though it isn't clear if that is the right thing.
[Bug target/79038] Improve PowerPC ISA 3.0 conversion between integers and hardware _Float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79038 --- Comment #2 from Michael Meissner --- Author: meissner Date: Tue Jan 31 13:38:35 2017 New Revision: 245059 URL: https://gcc.gnu.org/viewcvs?rev=245059&root=gcc&view=rev Log: 2017-01-31 Michael Meissner PR target/78597 PR target/79038 * config/rs6000/rs6000-protos.h (convert_float128_to_int): Delete, no longer used. (convert_int_to_float128): Likewise. * config/rs6000/rs6000.c (convert_float128_to_int): Likewise. (convert_int_to_float128): Likewise. * config/rs6000/rs6000.md (UNSPEC_IEEE128_MOVE): Likewise. (UNSPEC_IEEE128_CONVERT): Likewise. (floatsi2, FLOAT128 iterator): Bypass calling rs6000_expand_float128_convert if we have IEEE 128-bit hardware. Use local variables for IBM extended format. (fix_truncsi2, FLOAT128 iterator): Likewise. (fix_truncsi2_fprs): Likewise. (fixuns_trunc2): Likewise. (floatuns2, IEEE128 iterator): Likewise. (fix_si2_hw): Rework the IEEE 128-bt hardware support to know that we can now have integers of all sizes in vector registers. (fix_di2_hw): Likewise. (float_si2_hw): Likewise. (fix_si2_hw): Likewise. (fixuns_si2_hw): Likewise. (float_di2_hw): Likewise. (float_di2_hw): Likewise. (float_si2_hw): Likewise. (floatuns_di2_hw): Likewise. (floatuns_si2_hw): Likewise. (xscvqpwz_): Delete, no longer used. (xscvqpdz_): Likewise. (xscvdqp_): Likewise. (ieee128_mfvsrd_64bit): Likewise. (ieee128_mfvsrd_32bit): Likewise. (ieee128_mfvsrwz): Likewise. (ieee128_mtvsrw): Likewise. (ieee128_mtvsrd_64bit): Likewise. (ieee128_mtvsrd_32bit): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000-protos.h trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.md
[Bug target/78597] test case gcc.dg/torture/fp-int-convert-float128-ieee.c (and others) fail starting with r242780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78597 --- Comment #3 from Michael Meissner --- Author: meissner Date: Tue Jan 31 13:38:35 2017 New Revision: 245059 URL: https://gcc.gnu.org/viewcvs?rev=245059&root=gcc&view=rev Log: 2017-01-31 Michael Meissner PR target/78597 PR target/79038 * config/rs6000/rs6000-protos.h (convert_float128_to_int): Delete, no longer used. (convert_int_to_float128): Likewise. * config/rs6000/rs6000.c (convert_float128_to_int): Likewise. (convert_int_to_float128): Likewise. * config/rs6000/rs6000.md (UNSPEC_IEEE128_MOVE): Likewise. (UNSPEC_IEEE128_CONVERT): Likewise. (floatsi2, FLOAT128 iterator): Bypass calling rs6000_expand_float128_convert if we have IEEE 128-bit hardware. Use local variables for IBM extended format. (fix_truncsi2, FLOAT128 iterator): Likewise. (fix_truncsi2_fprs): Likewise. (fixuns_trunc2): Likewise. (floatuns2, IEEE128 iterator): Likewise. (fix_si2_hw): Rework the IEEE 128-bt hardware support to know that we can now have integers of all sizes in vector registers. (fix_di2_hw): Likewise. (float_si2_hw): Likewise. (fix_si2_hw): Likewise. (fixuns_si2_hw): Likewise. (float_di2_hw): Likewise. (float_di2_hw): Likewise. (float_si2_hw): Likewise. (floatuns_di2_hw): Likewise. (floatuns_si2_hw): Likewise. (xscvqpwz_): Delete, no longer used. (xscvqpdz_): Likewise. (xscvdqp_): Likewise. (ieee128_mfvsrd_64bit): Likewise. (ieee128_mfvsrd_32bit): Likewise. (ieee128_mfvsrwz): Likewise. (ieee128_mtvsrw): Likewise. (ieee128_mtvsrd_64bit): Likewise. (ieee128_mtvsrd_32bit): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000-protos.h trunk/gcc/config/rs6000/rs6000.c trunk/gcc/config/rs6000/rs6000.md
[Bug target/79170] [7 regression] memcmp builtin expansion sequence can overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79170 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- So fixed?
[Bug tree-optimization/79302] [6/7 Regression] ICE in add_loop_constraints, at graphite-sese-to-poly.c:933 building 445.gobmk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79302 --- Comment #8 from Martin Liška --- ICEs with: ./cc1 -fpreprocessed pr79302.i -march=haswell -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mno-sgx -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -mtune=haswell -quiet -dumpbase pr79302.c -auxbase pr79302 -Ofast -version -floop-nest-optimize -o pr79302.s
[Bug c++/78689] [7 Regression] ICE (segfault) within cleanup_dead_labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78689 --- Comment #5 from Jakub Jelinek --- *** Bug 79297 has been marked as a duplicate of this bug. ***
[Bug middle-end/79297] [7 Regression] ICE (segfault) in main_block_label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79297 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Jakub Jelinek --- This is a clear dup. *** This bug has been marked as a duplicate of bug 78689 ***
[Bug target/79038] Improve PowerPC ISA 3.0 conversion between integers and hardware _Float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79038 --- Comment #3 from Michael Meissner --- Subversion id 245059 fixes the majority of the issues. However, there are some enhancements that should be added for GCC 8: 1) Add support for converting IEEE 128-bit floating point to/from char/short data types that is similar to the support that when in for normal 32-bit and 64-bit floating point types. 2) Add a combiner pattern for converting IEEE 128-bit floating point to 32-bit integer and storing it in memory so that the register allocator can do the store directly from the Altivec register instead of using direct move to save it as a GPR (since the GPR side allows more address forms for int). 3) Similarly, add a combiner pattern when converting from a 32-bit integer in memory to IEEE 128-bit floating point to avoid having to move it through a GPR.
[Bug middle-end/79297] [7 Regression] ICE (segfault) in main_block_label
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79297 --- Comment #4 from Jakub Jelinek --- Even from the same package...
[Bug tree-optimization/71824] [6/7 Regression] ICE when compiling libiberty with Graphite loop optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71824 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #10 from Richard Biener --- I have a patch.
[Bug tree-optimization/79303] ICE: Segmentation fault from apply_schedule_map_to_scop, graphite-optimize-isl.c:429 building 464.h264ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79303 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Richard Biener --- Works with new ISL -> ISL bug.
[Bug tree-optimization/79303] ICE: Segmentation fault from apply_schedule_map_to_scop, graphite-optimize-isl.c:429 building 464.h264ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79303 --- Comment #1 from Richard Biener --- segfault occurs within ISL with isl 0.14 but not with isl 0.16.1 so not sure if worth pursuing (well, I guess not).
[Bug c++/79304] [7 Regression] diagnostic shows bogus expression ((X*)this)->.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79304 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug middle-end/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664 --- Comment #15 from James Greenhalgh --- (In reply to Segher Boessenkool from comment #14) > I'm not sure how to read your remark. An insn where the result is > not used is not on the critical path by definition; and you seem to > be arguing for -fno-sched-spec by default? For cores with in-order execution, a long-running instruction like a square-root stalls execution until it completes. Even as you move to partially out-of-order and fully out-of-order execution the cost of executing a useless instruction is increased demand for limited system resources. For example, even an insn with an unused result can prevent retire of subsequent instructions until it completes, and at the very least it holds sqrt/divide resource. Modelling this resource usage in terms of unit reservations increases the size of the automaton in a way that quickly makes it unfeasible (see pr70473 and pr60743 for recent ARM examples). "Latency" may not be a great name for the cost we're looking for, but it is a reasonable approximation. If an instruction causes significant resource usage we ought not to make it speculative. That isn't an argument for -fno-sched-spec, it is an argument for a cost model which better matches the cost of the transformation, using the information available, without bloating the automaton.
[Bug middle-end/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664 --- Comment #16 from David Edelsohn --- > That isn't an argument for -fno-sched-spec, it is an argument for a cost > model which better matches the cost of the transformation, using the > information available, without bloating the automaton. And that's what Segher proposed with the patch for the hook on the mailing list.
[Bug middle-end/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664 --- Comment #17 from James Greenhalgh --- (In reply to David Edelsohn from comment #16) > > That isn't an argument for -fno-sched-spec, it is an argument for a cost > > model which better matches the cost of the transformation, using the > > information available, without bloating the automaton. > > And that's what Segher proposed with the patch for the hook on the mailing > list. I totally missed the proposal! https://gcc.gnu.org/ml/gcc-patches/2017-01/msg02101.html for others following this thread.
[Bug tree-optimization/79284] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79284 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- So, the problem seems to be that useless_type_conversion_p considers conversions between BOOLEAN_TYPE and INTEGER_TYPE with precision 1 as useless, but the vectorizer handles BOOLEAN_TYPE and INTEGER_TYPE with precision 1 very differently. When some propagation propagates e.g. INTEGER_TYPE with precision 1 into one operand of a stmt and the other operand is still BOOLEAN_TYPE, we'll use VECTOR_BOOLEAN_TYPE_P vectype for one of the operands, but a V*QI mode vectype for the other operand and obviously very bad things happen. So, shall we change all the places in the vectorizer that check for BOOLEAN_TYPE to also allow INTEGRAL_TYPE_P that is TYPE_PRECISION == 1 and TYPE_UNSIGNED? grep -w BOOLEAN_TYPE tree-vect-[lps]*.c tree-vect-loop.c: if (TREE_CODE (scalar_type) == BOOLEAN_TYPE tree-vect-loop.c:!= BOOLEAN_TYPE) tree-vect-loop.c: && TREE_CODE (TREE_TYPE (gimple_assign_rhs1 (stmt))) != BOOLEAN_TYPE) tree-vect-patterns.c: && TREE_CODE (TREE_TYPE (rhs1)) != BOOLEAN_TYPE) tree-vect-patterns.c: && TREE_CODE (TREE_TYPE (var)) != BOOLEAN_TYPE) tree-vect-patterns.c: if (TREE_CODE (TREE_TYPE (rhs1)) == BOOLEAN_TYPE) tree-vect-patterns.c: && TREE_CODE (TREE_TYPE (var)) != BOOLEAN_TYPE) tree-vect-patterns.c: if (TREE_CODE (TREE_TYPE (lhs)) != BOOLEAN_TYPE) tree-vect-slp.c: if (TREE_CODE (TREE_TYPE (op)) == BOOLEAN_TYPE tree-vect-stmts.c: else if (TREE_CODE (TREE_TYPE (op)) == BOOLEAN_TYPE tree-vect-stmts.c: if (TREE_CODE (TREE_TYPE (mask)) != BOOLEAN_TYPE) tree-vect-stmts.c: if (TREE_CODE (TREE_TYPE (op0)) == BOOLEAN_TYPE) tree-vect-stmts.c:if (TREE_CODE (TREE_TYPE (scalar_dest)) != BOOLEAN_TYPE) tree-vect-stmts.c: && TREE_CODE (TREE_TYPE (cond)) == BOOLEAN_TYPE) tree-vect-stmts.c: if (TREE_CODE (scalar_type) == BOOLEAN_TYPE)
[Bug c++/79304] [7 Regression] diagnostic shows bogus expression ((X*)this)->.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79304 Jonathan Wakely changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #1 from Jonathan Wakely --- bisection suggests r236221
[Bug tree-optimization/77318] [7 regression] FAIL: gfortran.dg/graphite/pr68279.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77318 --- Comment #12 from Richard Biener --- Author: rguenth Date: Tue Jan 31 14:44:37 2017 New Revision: 245064 URL: https://gcc.gnu.org/viewcvs?rev=245064&root=gcc&view=rev Log: 2017-01-31 Richard Biener PR tree-optimization/77318 * graphite-sese-to-poly.c (extract_affine): Fix assert. (create_pw_aff_from_tree): Take loop parameter. (add_condition_to_pbb): Pass loop of the condition to create_pw_aff_from_tree. Modified: trunk/gcc/ChangeLog trunk/gcc/graphite-sese-to-poly.c
[Bug tree-optimization/77362] [6/7 Regression] [graphite] ICE in sese_build_liveouts_use w/ -O2 -floop-nest-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77362 --- Comment #7 from Sebastian Pop --- The fix looks good. Thanks!
[Bug tree-optimization/77362] [6/7 Regression] [graphite] ICE in sese_build_liveouts_use w/ -O2 -floop-nest-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77362 --- Comment #8 from Sebastian Pop --- LIM in general is bad for loop transforms: it introduces loop carried dependences. If we can move graphite before LIM that would solve some problems.
[Bug c++/79264] [7 Regression] ICE verify_type failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79264 --- Comment #3 from Nathan Sidwell --- Author: nathan Date: Tue Jan 31 15:10:41 2017 New Revision: 245065 URL: https://gcc.gnu.org/viewcvs?rev=245065&root=gcc&view=rev Log: PR c++/79264 * lambda.c (maybe_generic_this_capture): Deal with template-id-exprs. * semantics.c (finish_member_declaration): Assert class is being defined. PR c++/79264 * g++.dg/cpp1y/pr61636-1.C: Augment. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/lambda.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp1y/pr61636-1.C
[Bug tree-optimization/79284] [7 Regression] ICE on valid code at -O3 on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79284 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 40637 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40637&action=edit gcc7-pr79284.patch Untested fix.
[Bug c++/79264] [7 Regression] ICE verify_type failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79264 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Nathan Sidwell --- Fixed r245065.
[Bug tree-optimization/77318] [7 regression] FAIL: gfortran.dg/graphite/pr68279.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77318 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Richard Biener --- Fixed.
[Bug tree-optimization/77362] [6/7 Regression] [graphite] ICE in sese_build_liveouts_use w/ -O2 -floop-nest-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77362 --- Comment #9 from Richard Biener --- (In reply to Sebastian Pop from comment #8) > LIM in general is bad for loop transforms: it introduces loop carried > dependences. If we can move graphite before LIM that would solve some > problems. Yeah, but the user can write such dependences himself so ideally we have a way to undo them, like by using local scratch memory? So x_0 = 1; loop: # x_1 = PHI ... x_2 = ...; goto loop; turns into mem = 1; loop: x_1 = mem; x_2 = ...; mem = x_2; goto loop; plus replacement of exit PHIs with loads. Would that help? Or does the new (non-aliased, loop invariant) memory location complicate things as well?
[Bug tree-optimization/70729] Loop marked with omp simd pragma is not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70729 Bug 70729 depends on bug 77318, which changed state. Bug 77318 Summary: [7 regression] FAIL: gfortran.dg/graphite/pr68279.f90 -O (internal compiler error) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77318 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 Bug 59859 depends on bug 77318, which changed state. Bug 77318 Summary: [7 regression] FAIL: gfortran.dg/graphite/pr68279.f90 -O (internal compiler error) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77318 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/79298] [7 Regression] ICE on invalid C++ code on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79298 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |dmalcolm at gcc dot gnu.org --- Comment #2 from David Malcolm --- My bad, sorry. Working on a fix.
[Bug fortran/79305] New: real128 - undefined reference to cexpl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79305 Bug ID: 79305 Summary: real128 - undefined reference to cexpl Product: gcc Version: 6.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mexas at bristol dot ac.uk Target Milestone: --- FreeBSD 11.0-RELEASE-p2 use, intrinsic :: iso_fortran_env, only: real128 integer, parameter :: fk = real128 complex( kind=fk ) :: z z = cmplx( 1.0_fk, -1.0_fk, kind=fk ) write (*,*) exp( z ) end $ gfortran49 z.f90 /tmp//ccIF7kVE.o: In function `MAIN__': z.f90:(.text+0x79): undefined reference to `cexpl' collect2: error: ld returned 1 exit status $ gfortran6 z.f90 /tmp//ccq1EOKO.o: In function `MAIN__': z.f90:(.text+0x62): undefined reference to `cexpl' collect2: error: ld returned 1 exit status $ gfortran7 z.f90 /tmp//ccgH1sQM.o: In function `MAIN__': z.f90:(.text+0x62): undefined reference to `cexpl' collect2: error: ld returned 1 exit status Have I missed something? Thanks Anton
[Bug tree-optimization/77362] [6/7 Regression] [graphite] ICE in sese_build_liveouts_use w/ -O2 -floop-nest-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77362 --- Comment #10 from Sebastian Pop --- (In reply to Richard Biener from comment #9) > Yeah, but the user can write such dependences himself so ideally we have > a way to undo them, like by using local scratch memory? So You are right. LLVM-Polly has a pass that undoes LIM, it is non trivial, and furthermore we'd better catch the LIM once the loop transforms are done! > > x_0 = 1; > > loop: > # x_1 = PHI > ... > x_2 = ...; > goto loop; > > turns into > > mem = 1; > > loop: > x_1 = mem; > x_2 = ...; > mem = x_2; > goto loop; > > plus replacement of exit PHIs with loads. Would that help? That's how we were handling reductions and end of loop values in the dependence graph. Today we can reason about scalars themselves and add the scalars to the dependence graph instead of generating the loads that would need to be cleaned up after graphite.
[Bug tree-optimization/54810] VRP doesn't handle comparison of narrowing cast like comparison of BIT_AND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54810 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #3 from Jeffrey A. Law --- This was fixed long ago (2013) by improving VRP's ASSERT_EXPR insertion for loop latches.
[Bug pch/79306] New: ICE on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79306 Bug ID: 79306 Summary: ICE on valid code Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch Assignee: unassigned at gcc dot gnu.org Reporter: vi0oss at gmail dot com Target Milestone: --- I noticed this message on some build log: (command line approximate) cd .../WebRTC/webrtc && /usr/bin/c++ -D... -fPIC -msse2 -msse3 -m64 -std=c++11 -g -O0 -fno-inline -D_DEBUG -I... -I.../WebRTC/webrtc/video_coding_pch -Winvalid-pch -include .../WebRTC/webrtc/video_coding_pch/stdafx.h -o o -c .../WebRTC/webrtc/modules/video_coding/main/source/codec_database.cc c++: internal compiler error: Segmentation fault (program cc1plus) Please submit a full bug report, with preprocessed source if appropriate. See for instructions. Version is 4.8.x. If needed I may try to reproduce and minimize it, but it is not simple. Turning off precompiled headers makes it build successfully.
[Bug c++/79304] [7 Regression] diagnostic shows bogus expression ((X*)this)->.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79304 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 40638 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40638&action=edit gcc7-pr79304.patch Untested fix.
[Bug c++/79267] [6 Regression] internal compiler error with -O3 or -O2 -finline-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79267 Jakub Jelinek changed: What|Removed |Added Summary|[6/7 Regression] internal |[6 Regression] internal |compiler error with -O3 or |compiler error with -O3 or |-O2 -finline-functions |-O2 -finline-functions --- Comment #7 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/67273] Incorrect -Wshadow warning with generic lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67273 Nathan Sidwell changed: What|Removed |Added CC||jens.auer at cgi dot com --- Comment #3 from Nathan Sidwell --- *** Bug 67951 has been marked as a duplicate of this bug. ***
[Bug c++/67951] Wshadow for variable with same name as generic (auto) lambda parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67951 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Nathan Sidwell --- Essentially same as 67273, to which I added a clearer testcase *** This bug has been marked as a duplicate of bug 67273 ***
[Bug c++/78771] [5/6/7 Regression] ICE when using inherited constructors (instantiate_template_1 in gcc/cp/pt.c:17391)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78771 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Nathan Sidwell --- jason fixed it
[Bug target/79170] [7 regression] memcmp builtin expansion sequence can overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79170 acsawdey at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from acsawdey at gcc dot gnu.org --- Fixed in 245041.
[Bug target/79170] [7 regression] memcmp builtin expansion sequence can overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79170 --- Comment #4 from acsawdey at gcc dot gnu.org --- Yes, should be fixed with 245041 -- different instruction sequence and a better memcmp/strncmp regtest to catch this and other things.
