[Bug rtl-optimization/91860] [10 Regression] ICE: in decompose, at rtl.h:2279 with -Og -fipa-cp -g --param=max-combine-insns=3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91860 --- Comment #11 from Zdenek Sojka --- (In reply to Jim Wilson from comment #9) > Created attachment 47008 [details] > second untested fix Thank you for taking care about this bugreport. I've been testing this patch for several days, and found no problems. I will now switch back to clean trunk.
[Bug target/92083] -mlong-double-64 strange results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92083 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- There is only one ABI normally. If you use -mlong-double-64, you change the ABI, there are no two ABIs for the glibc. You need to recompile all of glibc (or your libc) with that option too. The documentation is clear here too: Warning: if you override the default value for your target ABI, this changes the size of structures and arrays containing long double variables, as well as modifying the function calling convention for functions taking long double. Hence they are not binary-compatible with code compiled without that switch.
[Bug c/92083] New: -mlong-double-64 strange results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92083 Bug ID: 92083 Summary: -mlong-double-64 strange results Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tydeman at tybor dot com Target Milestone: --- On an Intel 64-bit CPU (Core i5 7th gen), running Linux, gcc using -mlong-double-64 gets strange results for long doubles in (at least) isnan() and scanf(). For example, scanf() using "%Lg" to read into a long double, stores 10 bytes (80-bit x87 format) instead of the expected 8 bytes (64-bit double format). isnan() of a long double that is a NaN returns false. Similar issues may also exists for functions, printf(), , and . Is there documentation on exactly what -mlong-double-64/80/128 are supposed to do? Are they supposed to link in different libraries?
[Bug debug/59319] gcc does not emit DW_AT_friend or DW_TAG_friend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59319 --- Comment #4 from Eric Gallager --- Now that I've closed bug 49348, this is the last bug left open blocking bug 63243
[Bug debug/63243] [meta-bug] RH GDB project tracker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63243 Bug 63243 depends on bug 49348, which changed state. Bug 49348 Summary: DW_TAG_template_* DIEs missing from template specializations https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49348 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX
[Bug debug/49348] DW_TAG_template_* DIEs missing from template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49348 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from Eric Gallager --- (In reply to Eric Gallager from comment #5) > (In reply to Alexandre Oliva from comment #4) > > From Jason's feedback in response to the proposed patch, it looks like this > > is not a bug, after all, and GCC is working as intended. Is there any > > reason for this bug to remain open? > > WAITING on a reply to this No reply; closing
[Bug rtl-optimization/58036] [meta-bug] alias.c:base_alias_check says stack accesses with different base registers don't alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58036 Eric Gallager changed: What|Removed |Added Blocks|53705, 58029, 50063, 54921 | Depends on||53705, 58029, 50063, 54921 --- Comment #2 from Eric Gallager --- (In reply to Eric Gallager from comment #1) > I think the "Blocks" field might need to be swapped into the "Depends on" > field; normally meta-bugs depend on more bugs than they block. Thus, re-arranging Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50063 [Bug 50063] [4.6/4.7/4.8 Regression] DSE: wrong code for gcc.dg/torture/pta-ptrarith-3.c https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53705 [Bug 53705] wrong code with custom flags - stores to memory are lost https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54921 [Bug 54921] [4.8 Regression] wrong code with -Os -fno-omit-frame-pointer -fsched2-use-superblocks -fstack-protector -ftree-slp-vectorize https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58029 [Bug 58029] base_alias_check says pretend-args saves and varargs accesses don't alias
[Bug c++/92082] New: ICE with concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92082
Bug ID: 92082
Summary: ICE with concepts
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bruno.manga95 at gmail dot com
Target Milestone: ---
The compiler ICEs with a segmentation fault with the following code:
#include
#include
template class ttp, class c>
struct resolve {static constexpr bool value = false; };
template class ttp, class ... ts>
struct resolve>{static constexpr bool value = true; };
template < class c, template class ttp>
concept instanceof = resolve::value;
int main()
{
instanceof auto x = std::array{1, 2, 3};
}
godbolt: https://gcc.godbolt.org/z/99WWSW
[Bug libgomp/92081] FAIL: libgomp.fortran/target-simd.f90 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92081 --- Comment #1 from John David Anglin --- Revision 276732 was okay.
[Bug libgomp/92081] New: FAIL: libgomp.fortran/target-simd.f90 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92081 Bug ID: 92081 Summary: FAIL: libgomp.fortran/target-simd.f90 execution test Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Host: hppa-unknown-linux-gnu Target: hppa-unknown-linux-gnu Build: hppa-unknown-linux-gnu This is with trunk revision 276929. spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/obj dir/gcc/ ../../../../gcc/libgomp/testsuite/libgomp.fortran/target-simd.f90 -B/ho me/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgomp/ -B/home/dave/gnu/gcc/objdir/hpp a-linux-gnu/./libgomp/.libs -I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgomp -I../../../../gcc/libgomp/testsuite/../../include -I../../../../gcc/libgomp/tes tsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -Wno-hsa -fdiagnostics- color=never -fopenmp -O0 -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgomp/.. /libgfortran/.libs -fintrinsic-modules-path=/home/dave/gnu/gcc/objdir/hppa-linux -gnu/./libgomp -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgomp/.libs -L/hom e/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgomp/../libgfortran/.libs -lgfortran - foffload=-lgfortran -lm -o ./target-simd.exe PASS: libgomp.fortran/target-simd.f90 -O0 (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgomp/ .libs:/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./l ibgomp/../libgfortran/.libs:.:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgomp /.libs:/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./ libgomp/../libgfortran/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc Execution timeout is: 300 spawn [open ...] corrupted size vs. prev_size Program received signal SIGABRT: Process abort signal. Backtrace for this error: FAIL: libgomp.fortran/target-simd.f90 -O0 execution test Test fails at all optimizations.
[Bug debug/91929] missing inline subroutine information in build using sin/cos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91929 --- Comment #5 from Milian Wolff --- > Note the line number program should have picked up a location from the surrounding code, at least the surrounding function, so the ?? in the backtraces look like a consumer (perf) issue to me. All major DWARF consumers get it wrong, no? addr2line from binutils / libbfd, elfutils / libdwfl and also GDB - none of them find any information for __cos_fma.
[Bug target/87243] FSF GCC needs to do something special (like using xcrun) on darwin18 to find system headers in SDK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87243 --- Comment #10 from Jack Howarth --- (In reply to Iain Sandoe from comment #8) Why can't maybe_get_sysroot_from_sdkroot() be expanded so that it attempts to execute 'xcrun --show-sdk-path' to obtain SDKROOT when unset? IMHO, this would mitigate the overhead for the compiler as xrcun would only be called when absolutely needed. The overall overhead in that case shouldn't be much worst than Apple's compiler wrapper approach to calling their compiler through xcrun itself.
template auto deduction ICE in the latest gcc master version.
https://github.com/euloanty/fast_io/blob/master/examples/0036.concepts_check/iostrm.cc
cqwrteur@DESKTOP-7H7UHQ9:/mnt/d/hg/fast_io/examples/build$ ninja
[1/2] Building CXX object CMakeFiles/iostrm.dir/0036.concepts_check/iostrm.cc.o
FAILED: CMakeFiles/iostrm.dir/0036.concepts_check/iostrm.cc.o
/usr/local/bin/c++-O3 -DNDEBUG -fconcepts -ffast-math -Wall -Wextra
-std=gnu++2a -MD -MT CMakeFiles/iostrm.dir/0036.concepts_check/iostrm.cc.o -MF
CMakeFiles/iostrm.dir/0036.concepts_check/iostrm.cc.o.d -o
CMakeFiles/iostrm.dir/0036.concepts_check/iostrm.cc.o -c
../0036.concepts_check/iostrm.cc
../0036.concepts_check/iostrm.cc: In function ‘int main()’:
../0036.concepts_check/iostrm.cc:8:51: error: deduced initializer does not
satisfy placeholder constraints
8 | fast_io::stream auto fin(std::ifstream("abc.txt"));
| ^
../0036.concepts_check/iostrm.cc:8:51: note: constraints not satisfied
c++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See for Windows 10
[Bug fortran/92072] [10 Regression] ICE on include from other directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92072 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- Bisection points to the possible 'culprit': r276567 | burnus | 2019-10-04 11:29:31 +0200 (Fr, 04. Okt 2019) | 9 Zeilen [Fortran] Fix column of %C diagnostic location gcc/fortran/ * error (error_print, gfc_format_decoder): Fix off-by one issue with %C. Adding Tobias to CC.
[Bug fortran/91513] Non-standard terminology in error message for pointer component assignment in pure procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91513 --- Comment #5 from Damian Rouson --- Thanks, Steve!
[Bug fortran/91513] Non-standard terminology in error message for pointer component assignment in pure procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91513 kargl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #4 from kargl at gcc dot gnu.org --- Fixed on trunk. Closing. Thanks for bug report.
[Bug fortran/91513] Non-standard terminology in error message for pointer component assignment in pure procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91513 --- Comment #3 from kargl at gcc dot gnu.org --- Author: kargl Date: Sun Oct 13 17:16:40 2019 New Revision: 276941 URL: https://gcc.gnu.org/viewcvs?rev=276941=gcc=rev Log: 2019-10-13 Damian Rouson PR fortran/91513 * resolve.c (resolve_ordinary_assign): Improved error message. 2019-10-13 Damian Rouson PR fortran/91513 * gfortran.dg/impure_assignment_2.f90: Update dg-error regex. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/impure_assignment_2.f90
[Bug other/89863] [meta-bug] Issues that static analyzers (cppcheck, clang-static-analyzer) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 90297, which changed state. Bug 90297 Summary: gcc/fortran/resolve.c: 2 * possibly redundant code ? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90297 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/90297] gcc/fortran/resolve.c: 2 * possibly redundant code ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90297 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |kargl at gcc dot gnu.org Target Milestone|--- |10.0 --- Comment #9 from kargl at gcc dot gnu.org --- Fixed on trunk. Thanks for bug report.
[Bug fortran/90297] gcc/fortran/resolve.c: 2 * possibly redundant code ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90297 --- Comment #8 from kargl at gcc dot gnu.org --- Author: kargl Date: Sun Oct 13 16:51:33 2019 New Revision: 276940 URL: https://gcc.gnu.org/viewcvs?rev=276940=gcc=rev Log: 2019-10-13 Steven G. Kargl PR fortran/90297 * resolve.c (resolve_typebound_function): Remove code with no functional effect. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c
[Bug libstdc++/92059] Crash on tr2::dynamic_bitset::operator=() with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92059 --- Comment #11 from John Harris --- Great. Thanks for the quick and thorough response.
[Bug target/92051] Many aarch64 SVE tests fail with ICE (expected integer_cst, have poly_int_cst in to_wide)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92051 Aldy Hernandez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Aldy Hernandez --- This is likely a duplicate and Richard Sandiford has posted a patch to fix it. *** This bug has been marked as a duplicate of bug 92033 ***
[Bug tree-optimization/92033] ICE during dom with -march=armv8.2-a+sve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92033 Aldy Hernandez changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #3 from Aldy Hernandez --- *** Bug 92051 has been marked as a duplicate of this bug. ***
[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374 --- Comment #2 from Jerry DeLisle --- Almost have this one. I am working out some details related to -std= specifier and also the exponent length business.
[Bug target/82887] ICE: in extract_insn, at recog.c:2287 (unrecognizable insn) with _mm512_extracti64x4_epi64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82887 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Jakub Jelinek --- Fixed. *** This bug has been marked as a duplicate of bug 80206 ***
[Bug target/80206] ICE in extract_insn, at recog.c:2327
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80206 Jakub Jelinek changed: What|Removed |Added CC||marcin.slusarz at intel dot com --- Comment #7 from Jakub Jelinek --- *** Bug 82887 has been marked as a duplicate of this bug. ***
[Bug c++/86403] Deduction guides not supported in local classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86403
Jonathan Poelen changed:
What|Removed |Added
CC||jonathan.poelen at gmail dot
com
--- Comment #2 from Jonathan Poelen ---
$ g++ --version
g++ (GCC) 9.2.0
$ cat test.cpp
struct A
{
template
struct B
{
B(T) {}
};
template
B(T) -> B;
};
$ g++ -std=c++17 test.cpp
test.cpp:10:3: error: deduction guide ‘A::B(T) -> A::B’ must be declared at
namespace scope
10 | B(T) -> B;
| ^
This works with Clang and MSVC.
https://en.cppreference.com/w/cpp/language/class_template_argument_deduction#User-defined_deduction_guides
User-defined deduction guides must name a class template and must be introduced
within the same semantic scope of the class template (which could be namespace
or enclosing class)
[Bug target/82887] ICE: in extract_insn, at recog.c:2287 (unrecognizable insn) with _mm512_extracti64x4_epi64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82887 --- Comment #5 from Peter Cordes --- Reported bug 92080 for the missed CSE
[Bug tree-optimization/92080] New: Missed CSE of _mm512_set1_epi8(c) with _mm256_set1_epi8(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92080
Bug ID: 92080
Summary: Missed CSE of _mm512_set1_epi8(c) with
_mm256_set1_epi8(c)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: peter at cordes dot ca
Target Milestone: ---
Target: x86_64-*-*, i?86-*-*
As a workaround for PR 82887 some code (e.g. a memset) uses
__m512i zmm = _mm512_set1_epi8((char)c);
__m256i ymm = _mm256_set1_epi8((char)c);
instead of
ymm = _mm512_castsi512_si256(zmm);
(found in the persistent-memory library
https://github.com/pmem/pmdk/blob/a6031710f7c102c6b8b6b19dc9708a3b7d43e87b/src/libpmem/x86_64/memset/memset_nt_avx512f.h#L193
)
Obviously we'd like to CSE that instead of actually broadcasting twice. MVCE:
#include
__m512i sinkz;
__m256i sinky;
void foo(char c) {
sinkz = _mm512_set1_epi8(c);
sinky = _mm256_set1_epi8(c);
}
https://godbolt.org/z/CeXhi8 g++ (Compiler-Explorer-Build) 10.0.0 20191012
# g++ -O3 -march=skylake-avx512 (AVX512BW + AVX512VL are the relevant ones)
foo(char):
vpbroadcastb%edi, %zmm0
vmovdqa64 %zmm0, sinkz(%rip)
vpbroadcastb%edi, %ymm0 # wasted insn
vmovdqa64 %ymm0, sinky(%rip) # wasted EVEX prefix
vzeroupper
ret
Without AVX512VL it wastes even more instructions (vmovd + AVX2 vpbroadcastb
xmm,ymm), even though AVX512BW vpbroadcastb zmm does set the YMM register.
(There are no CPUs with AVX512BW but not AVX512VL; if people compile that way
it's their own fault. But this might be relevant for set1_epi32() on KNL).
Clang finds this optimization, and uses a shorter vmovdqa for the YMM store
saving another 2 bytes of code size:
vpbroadcastb%edi, %zmm0
vmovdqa64 %zmm0, sinkz(%rip)
vmovdqa %ymm0, sinky(%rip)
vzeroupper
ret
[Bug fortran/92017] ICE in gfc_expr_attr, at fortran/primary.c:2674
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92017 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Thomas Koenig --- Fixed on trunk, can be backported upon request.
[Bug target/82887] ICE: in extract_insn, at recog.c:2287 (unrecognizable insn) with _mm512_extracti64x4_epi64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82887 Peter Cordes changed: What|Removed |Added CC||peter at cordes dot ca --- Comment #4 from Peter Cordes --- Since some code is apparently still avoiding this because of old broken GCC (e.g. https://github.com/pmem/pmdk/blob/a6031710f7c102c6b8b6b19dc9708a3b7d43e87b/src/libpmem/x86_64/memset/memset_nt_avx512f.h#L193 ) Perhaps a workaround of _mm512_castsi512_si256 would be useful? Or does that ICE as well? I can't repro the bug on Godbolt so IDK. Doing _mm512_set1_epi8(c) and a separate _mm256_set1_epi8(c) doesn't CSE with GCC, only clang. https://godbolt.org/z/uZ4lv- And if you leave out -march=skylake-avx512 you get even worse asm from GCC.
[Bug fortran/92017] ICE in gfc_expr_attr, at fortran/primary.c:2674
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92017 --- Comment #2 from Thomas Koenig --- Author: tkoenig Date: Sun Oct 13 13:42:30 2019 New Revision: 276938 URL: https://gcc.gnu.org/viewcvs?rev=276938=gcc=rev Log: 2019-10-13 Thomas Koenig PR fortran/92017 * expr.c (simplify_parameter_variable): Set the character length of the result expression from the original expression if necessary. 2019-10-13 Thomas Koenig PR fortran/92017 * gfortran.dg/minmaxloc_14.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/minmaxloc_14.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/92017] ICE in gfc_expr_attr, at fortran/primary.c:2674
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92017 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED CC||tkoenig at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org
[Bug libstdc++/92057] variant converting constructor fails for primitives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92057
--- Comment #5 from pj at patrickjohnston dot org ---
So then why does `std::variant{600}` work just fine? (Where `Double` is
defined by `struct Double { double x; Double(int){} };`)
[Bug fortran/92065] [7/8/9/10 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 Thomas Koenig changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Last reconfirmed||2019-10-13 CC||tkoenig at gcc dot gnu.org Ever confirmed|0 |1 Summary|internal compiler error: in |[7/8/9/10 Regression] |expand_expr_real_1 |internal compiler error: in ||expand_expr_real_1 Target Milestone|--- |7.5
[Bug web/89964] Remove the "First, you must pick a product on which to enter a bug:" page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89964 Frédéric Buclin changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Frédéric Buclin --- Done!
[Bug tree-optimization/92066] [10 regression] Many vectorization tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92066 Rainer Orth changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from Rainer Orth --- (In reply to Richard Biener from comment #2) > Mine. Can you see if the commit fixed the testcases? It did: with your patch and the one for PR c++/92049, Solaris/SPARC testresults are back to normal. Thanks. Rainer
[Bug middle-end/92063] [10 Regression] ICE in operation_could_trap_p, at tree-eh.c:2528 when compiling Python's Python/_warnings.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92063 Andrew Pinski changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #13 from Andrew Pinski --- *** Bug 92079 has been marked as a duplicate of this bug. ***
[Bug c/92079] ice in operation_could_trap_p, at tree-eh.c:2528
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92079 Andrew Pinski changed: What|Removed |Added Keywords|ice-on-valid-code | Status|WAITING |RESOLVED Component|tree-optimization |c Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- Yes this was already fixed and yes it is a dup of bug 92063. *** This bug has been marked as a duplicate of bug 92063 ***
[Bug c/92079] ice in operation_could_trap_p, at tree-eh.c:2528
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92079 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-10-13 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Are you sure it has not been fixed already? See PR 92063.
[Bug c/92079] ice in operation_could_trap_p, at tree-eh.c:2528
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92079 --- Comment #1 from David Binderman --- The bug seems to start someplace between revision 276650 and 276700. I will have my usual go at reducing the code.
[Bug c/92079] New: ice in operation_could_trap_p, at tree-eh.c:2528
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92079 Bug ID: 92079 Summary: ice in operation_could_trap_p, at tree-eh.c:2528 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 47028 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47028=edit C source code For the attached C code, compiled by recent trunk and compiler flag -O2, does this: Python/_warnings.c: In function ‘setup_context’: Python/_warnings.c:753:13: internal compiler error: in operation_could_trap_p, at tree-eh.c:2528 753 | ascii_lower(PyUnicode_READ(kind, data, len-1)) == 'c') | ^~~ gcc -g -O3 -Wall -Wextra -pthread -c -fno-strict-aliasing -Wno-unused-result -Wsign-compare -DNDEBUG -g -O3 -Wall-std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Wno-cast-function-type -Werror=implicit-function-declaration -I. -I./Include-DPy_BUILD_CORE -o Python/Python-ast.o Python/Python-ast.c 0x6af319 operation_could_trap_p(tree_code, bool, bool, tree_node*) ../../trunk/gcc/tree-eh.c:2528 0x6af319 operation_could_trap_p(tree_code, bool, bool, tree_node*) ../../trunk/gcc/tree-eh.c:2518 0x6af319 tree_could_trap_p(tree_node*) ../../trunk/gcc/tree-eh.c:2635
