[Bug ipa/93621] [10 Regression] ICE in redirect_call_stmt_to_callee, at cgraph.c:1443
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-02-07
CC||hubicka at gcc dot gnu.org
Target Milestone|--- |10.0
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed.
1440 if (flag_checking && decl)
1441{
1442 cgraph_node *node = cgraph_node::get (decl);
1443 gcc_assert (!node || !node->clone.param_adjustments);
1444}
(gdb) p node
$1 =
[Bug c++/93618] [10 Regression] : unknown array size in delete when using C++20 standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93618 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug tree-optimization/93616] Missed chance to use alias checks to vectorise invariant indirection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93616 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- I think the issue is (*dest_ptr)[i] overlapping (*dest_ptr), 'src' doesn't even come into play here.
[Bug c++/93614] C++ compile error with struct in template class and < operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93614 Richard Biener changed: What|Removed |Added Keywords||rejects-valid --- Comment #2 from Richard Biener --- EDG accepts it (ICC 2020).
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 --- Comment #213 from Eric Gallager --- (In reply to Eric Gallager from comment #212) > (In reply to Rich Felker from comment #211) > > If new reports are going to be marked as duplicates of this, then can it > > please be moved from SUSPENDED status to REOPENED? The situation is far > > worse than what seems to have been realized last this was worked on, as > > evidenced by pr 85957. These issues just came up again breaking real-world > > software in https://github.com/OSGeo/PROJ/issues/1906 > > Uh... I'm not seeing "REOPENED" on the menu for possible statuses? Maybe a > bug can only have the REOPENED status if it's actually been closed in the > past, and this might not have actually been closed before? I thought this > had been closed at one point, but it looks like I was wrong... Hold on, let > me check the (very long) history for this bug... OK, never mind, it looks like this bug has actually been closed before like I thought originally; whether or not a bug can have its status changed to REOPENED or not must depend on its current status, rather than any past status it might have had... So, I guess I can either close it temporarily and then immediately reopen it, or give it some other status. Which would you prefer?
[Bug ipa/93621] New: [10 Regression] ICE in redirect_call_stmt_to_callee, at cgraph.c:1443
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93621 Bug ID: 93621 Summary: [10 Regression] ICE in redirect_call_stmt_to_callee, at cgraph.c:1443 Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com CC: marxin at gcc dot gnu.org Target Milestone: --- g++-10.0.1-alpha20200202 snapshot (g:b817be038d94c987e02c26ed2d81b6f2ebb5f97a) ICEs when compiling gcc/testsuite/g++.dg/ipa/pr79776.C w/ -O3 --param ipa-cp-eval-threshold=100 --param large-function-growth=60 --param large-function-insns=10 --param uninlined-thunk-insns=1000: % g++-10.0.1 -O3 --param ipa-cp-eval-threshold=100 --param large-function-growth=60 --param large-function-insns=10 --param uninlined-thunk-insns=1000 -c gcc/testsuite/g++.dg/ipa/pr79776.C during IPA pass: inline gcc/testsuite/g++.dg/ipa/pr79776.C: In function '_ZThn8_N1C2fnEPKciPi.artificial_thunk.0': gcc/testsuite/g++.dg/ipa/pr79776.C:13:5: internal compiler error: in redirect_call_stmt_to_callee, at cgraph.c:1443 13 | E fn (const char *, int, int *); | ^~ 0x6c01f7 cgraph_edge::redirect_call_stmt_to_callee(cgraph_edge*) /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/cgraph.c:1443 0x1954ea4 inline_transform(cgraph_node*) /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/ipa-inline-transform.c:715 0xf0530d execute_one_ipa_transform_pass /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/passes.c:2231 0xf0530d execute_all_ipa_transforms(bool) /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/passes.c:2270 0xb857c3 cgraph_node::expand() /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/cgraphunit.c:2276 0xb869ad expand_all_functions /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/cgraphunit.c:2454 0xb869ad symbol_table::compile() /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/cgraphunit.c:2804 0xb88c8c symbol_table::compile() /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/cgraphunit.c:2717 0xb88c8c symbol_table::finalize_compilation_unit() /var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200202/work/gcc-10-20200202/gcc/cgraphunit.c:2984
[Bug fortran/93599] [9/10 regression] Bug in fortran asynchronous I/O wait function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93599 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- The fact that it worked in the previous version is sort of irrelevent because it was simply syntax checking brfore the patch and not actually doing anything useful. So it appears to be a some sort of difficult to trigger bug o this specific platform. I am going to see if I can reproduce this on x86 with a big repeting loop or soething. It could be a bug in thread locking or gomp related on the powerpc.
[Bug c/92875] GCC ignores the floating-point 'f' suffix in C11 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84717 --- Comment #9 from Eric Gallager --- due to the part about floating/double constant suffixes, I think bug 84717 is related
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 --- Comment #212 from Eric Gallager --- (In reply to Rich Felker from comment #211) > If new reports are going to be marked as duplicates of this, then can it > please be moved from SUSPENDED status to REOPENED? The situation is far > worse than what seems to have been realized last this was worked on, as > evidenced by pr 85957. These issues just came up again breaking real-world > software in https://github.com/OSGeo/PROJ/issues/1906 Uh... I'm not seeing "REOPENED" on the menu for possible statuses? Maybe a bug can only have the REOPENED status if it's actually been closed in the past, and this might not have actually been closed before? I thought this had been closed at one point, but it looks like I was wrong... Hold on, let me check the (very long) history for this bug...
[Bug middle-end/93195] -fpatchable-function-entries : __patchable_function_entries should consider comdat groups
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93195 Bug 93195 depends on bug 93536, which changed state. Bug 93536 Summary: -fpatchable-function-entries -ffunction-sections doesn't work with --gc-sections https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93536 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/93195] -fpatchable-function-entries : __patchable_function_entries should consider comdat groups
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93195 --- Comment #4 from H.J. Lu --- *** Bug 93536 has been marked as a duplicate of this bug. ***
[Bug middle-end/93536] -fpatchable-function-entries -ffunction-sections doesn't work with --gc-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93536 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from H.J. Lu --- Dup. *** This bug has been marked as a duplicate of bug 93195 ***
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 --- Comment #211 from Rich Felker --- If new reports are going to be marked as duplicates of this, then can it please be moved from SUSPENDED status to REOPENED? The situation is far worse than what seems to have been realized last this was worked on, as evidenced by pr 85957. These issues just came up again breaking real-world software in https://github.com/OSGeo/PROJ/issues/1906
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 --- Comment #210 from Rich Felker --- If new reports are going to be marked as duplicates of this, then can it please be moved from SUSPENDED status to REOPENED? The situation is far worse than what seems to have been realized last this was worked on, as evidenced by pr 85957. These issues just came up again breaking real-world software in https://github.com/OSGeo/PROJ/issues/1906
[Bug middle-end/323] optimized code gives strange floating point results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 Andrew Pinski changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #209 from Andrew Pinski --- *** Bug 93620 has been marked as a duplicate of this bug. ***
[Bug c++/93620] Floating point is broken in C++ on targets with excess precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93620 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Yes this is known. See PR 323. Where even this is mentioned that C++ is not enabled yet. *** This bug has been marked as a duplicate of bug 323 ***
[Bug c++/93620] New: Floating point is broken in C++ on targets with excess precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93620 Bug ID: 93620 Summary: Floating point is broken in C++ on targets with excess precision Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bugdal at aerifal dot cx Target Milestone: --- Attempting to use -fexcess-precision=standard with g++ produces: cc1plus: sorry, unimplemented: '-fexcess-precision=standard' for C++ In light of eldritch horrors like pr 85957 this means floating point is essentially catastrophically broken on i386 and m68k. This came to my attention while analyzing https://github.com/OSGeo/PROJ/issues/1906. Most of the problems are g++ incorrectly handling excess precision, and they're having to put awful hacks with volatile objects in place to work around it.
[Bug c/82318] -fexcess-precision=standard has no effect on a libm function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82318 Rich Felker changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #5 from Rich Felker --- My understanding is that C2x is fixing this underspecification and will require the library functions to drop excess precision as if they used a return statement. So this really should be fixed in glibc if it's still an issue; if they accept fixing that I don't think GCC needs any action on this. I just fixed it in musl.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #137 from dave.anglin at bell dot net --- On 2020-02-05 10:18 p.m., peter.bisroev at groundlabs dot com wrote: > I just had a chance to do some testing tonight. So attempting to bootstrap > 8.3.0 in stock configuration gives PCREL21B style errors in stage1 as have > been > shown before. If I compile stage1 with '-O2' only, stage1 compiles, but > straight away we get > -- > /home/pbisroev/src/build/./gcc/xgcc -B/home/pbisroev/src/build/./gcc/ -xc > -nostdinc /dev/null -S -o /dev/null > -fself-test=/home/pbisroev/src/gcc-8.3.0/gcc/testsuite/selftests > cc1: internal compiler error: Segmentation fault > -- You need to at least apply patch from comment#72. This fixes regression from 4.7.x. You should also consider the last patch set from The Written Word. It was stated that it's possible to get a full bootstrap with it although there are issues.
[Bug rtl-optimization/93561] [bounds checking] memory overflow for spill_for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93561 --- Comment #3 from vfdff --- thanks very much!
[Bug analyzer/93375] ICE in gimple_call_arg, at gimple.h:3258
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93375 David Malcolm changed: What|Removed |Added Status|ASSIGNED|WAITING
[Bug analyzer/93288] ICE in supergraph.cc:180
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93288 David Malcolm changed: What|Removed |Added Status|ASSIGNED|WAITING
[Bug analyzer/93405] Passing constant arguments to subroutines in Fortran ... and the analyzer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93405 David Malcolm changed: What|Removed |Added Status|ASSIGNED|WAITING
[Bug analyzer/93375] ICE in gimple_call_arg, at gimple.h:3258
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93375 --- Comment #7 from David Malcolm --- Does the patch in comment #6 fix the remaining test failures for everyone?
[Bug analyzer/93375] ICE in gimple_call_arg, at gimple.h:3258
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93375
--- Comment #6 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:13f5b93e6453d121abc15c718dfcc588aca976c3
commit r10-6496-g13f5b93e6453d121abc15c718dfcc588aca976c3
Author: David Malcolm
Date: Thu Feb 6 14:17:48 2020 -0500
analyzer: fix reproducer for PR 93375
Reproducing the ICE in PR analyzer/93375 required some kind of
analyzer diagnostic occurring after a call with fewer arguments
than required by the callee.
The testcase used __builtin_memcpy with a NULL argument for this.
On x86_64-pc-linux-gnu this happened to be already optimized into:
_4 = MEM [(char * {ref-all})0B];
MEM [(char * {ref-all})rl_1] = _4;
by the time of the analyzer pass, leading to the diagnostic in question
being:
warning: dereference of NULL ‘rl’ [CWE-690] [-Wanalyzer-null-dereference]
On other targets e.g. arm-unknown-linux-gnueabi, the builtin isn't
optimized at the time of the analyzer pass, leading to this diagnostic
instead:
warning: use of NULL ‘rl’ where non-null expected [CWE-690]
[-Wanalyzer-null-argument]
: note: argument 1 of ‘__builtin_memcpy’ must be non-null
This patch fixes the test case by using a custom function marked as
nonnull. I manually verified that it still reproduces the ICE if the
patch for the PR is reverted.
gcc/testsuite/ChangeLog:
PR analyzer/93375
* gcc.dg/analyzer/pr93375.c: Rework test case to avoid per-target
differences in how __builtin_memcpy has been optimized at the time
the analyzer runs.
[Bug c++/91465] [9/10 Regression] unexpected expression of kind overload (ICE)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91465 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #6 from Marek Polacek --- https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00407.html
[Bug rtl-optimization/93565] Combine duplicates count trailing zero instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565 --- Comment #7 from Segher Boessenkool --- What makes that move redundant? I don't see it.
[Bug target/93569] [10 regression] r10-6419 causes ICE in gcc.target/powerpc/vsx-builtin-15d.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93569 Michael Meissner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Michael Meissner --- Fixed on February 6th, 2020. commit r10-6494-ga66219dce7fcba068a0998dd926e2ffc6857f149
[Bug target/93569] [10 regression] r10-6419 causes ICE in gcc.target/powerpc/vsx-builtin-15d.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93569 --- Comment #2 from CVS Commits --- The master branch has been updated by Michael Meissner : https://gcc.gnu.org/g:a66219dce7fcba068a0998dd926e2ffc6857f149 commit r10-6494-ga66219dce7fcba068a0998dd926e2ffc6857f149 Author: Michael Meissner Date: Thu Feb 6 18:39:48 2020 -0500 Fix PR 93569. 2020-02-06 Michael Meissner PR target/93569 * config/rs6000/rs6000.c (reg_to_non_prefixed): Before ISA 3.0 we only had X-FORM (reg+reg) addressing for vectors. Also before ISA 3.0, we only had X-FORM addressing for scalars in the traditional Altivec registers.
[Bug rtl-optimization/93565] Combine duplicates count trailing zero instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565 Wilco changed: What|Removed |Added CC||wdijkstr at arm dot com --- Comment #6 from Wilco --- (In reply to Segher Boessenkool from comment #4) > Why would that be unlikely? It lengthens the lifetime of that pseudo, > potentially significantly. The move should be easy to remove since it is already known to be redundant. I don't understand how you can say that the lifetime is increased when duplicating the instruction is actually what increases the lifetime. Also it requires extra registers to hold the two identical results.
[Bug rtl-optimization/93561] [bounds checking] memory overflow for spill_for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93561 --- Comment #2 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:d26f37a16e3ed3d75a93ffb1da10c44c36a8a36d commit r10-6493-gd26f37a16e3ed3d75a93ffb1da10c44c36a8a36d Author: Vladimir N. Makarov Date: Thu Feb 6 17:10:58 2020 -0500 PR93561 -- [bounds checking] memory overflow for spill_for 2020-02-06 Vladimir Makarov PR rtl-optimization/93561 * lra-assigns.c (spill_for): Check that tested hard regno is not out of hard register range.
[Bug rtl-optimization/93565] Combine duplicates count trailing zero instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565 --- Comment #5 from Segher Boessenkool --- IOW, we need hard numbers, not guesstimates :-)
[Bug rtl-optimization/93565] Combine duplicates count trailing zero instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565 --- Comment #4 from Segher Boessenkool --- Why would that be unlikely? It lengthens the lifetime of that pseudo, potentially significantly.
[Bug tree-optimization/93616] Missed chance to use alias checks to vectorise invariant indirection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93616 Andrew Pinski changed: What|Removed |Added Keywords||alias Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-06 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/93616] Missed chance to use alias checks to vectorise invariant indirection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93616 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #1 from Martin Sebor --- For the cases when the overlap is exceedingly unlikely it would be helpful to issue a warning suggesting to qualify the function arguments with the restrict keyword. That would make it possible to avoid the runtime check.
[Bug middle-end/93512] Introduce rotate_truncation_mask
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93512 --- Comment #4 from Segher Boessenkool --- I said (or I meant, at least) that as far as I see and know, all rotate instructions on all machines do this truncation. It is of course possible for targets to write it in RTL that only works for a limited range of inputs )with shifts and an ior, or similar).
[Bug target/87612] Bad diagnostic for conflicting mcpu and march options on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87612 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-06 Version|unknown |10.0 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Confirmed, I was just about to file this bug too.
[Bug testsuite/93619] New: aarch64 target testsuite is so broken with -mcpu=*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93619
Bug ID: 93619
Summary: aarch64 target testsuite is so broken with -mcpu=*
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
The aarch64 target testsuite does not like at any -mcpu=* options supplied as a
MULTILIB option.
Take atomic-store.c and running {,-mcpu=octeontx,-mcpu=octeontx2}
FAIL: gcc.target/aarch64/atomic-store.c (test for excess errors)
=== gcc Summary for
aarch64-marvell-linux-gnu-qemu/-mcpu=octeontx ===
# of expected passes21
# of unexpected failures1
Executing on host: aarch64-marvell-linux-gnu-gcc
/home/apinski/src/toolchain-10/src/gcc/testsuite/gcc.target/aarch64/atomic-store.c
-mcpu=octeontx -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never
-fdiagnostics-urls=never -march=armv8.4-a -O2 -ffat-lto-objects -fno-ident -S
-o atomic-store.s(timeout = 300)
spawn -ignore SIGHUP aarch64-marvell-linux-gnu-gcc
/home/apinski/src/toolchain-10/src/gcc/testsuite/gcc.target/aarch64/atomic-store.c
-mcpu=octeontx -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -march=armv8.4-a -O2
-ffat-lto-objects -fno-ident -S -o atomic-store.s^M
cc1: warning: switch '-mcpu=armv8-a' conflicts with '-march=armv8.4-a' switch^M
Executing on host: aarch64-marvell-linux-gnu-gcc exceptions_enabled963.c
-mcpu=octeontx -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -S -o
exceptions_enabled963.s(timeout = 300)
spawn -ignore SIGHUP aarch64-marvell-linux-gnu-gcc exceptions_enabled963.c
-mcpu=octeontx -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -S -o
exceptions_enabled963.s^M
exceptions_enabled963.c: In function 'foo':^M
exceptions_enabled963.c:4:7: error: 'throw' undeclared (first use in this
function)^M
exceptions_enabled963.c:4:7: note: each undeclared identifier is reported only
once for each function it appears in^M
exceptions_enabled963.c:4:12: error: expected ';' before numeric constant^M
compiler exited with status 1
FAIL: gcc.target/aarch64/atomic-store.c (test for excess errors)
Excess errors:
cc1: warning: switch '-mcpu=armv8-a' conflicts with '-march=armv8.4-a' switch
[Bug c++/92517] [10 Regression] ICE on incorrect syntax involving requires and decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92517 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug fortran/70070] ICE on initializing character data beyond min/max bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70070 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 --- Comment #10 from kargl at gcc dot gnu.org --- (In reply to kargl from comment #9) > Programs z1.f90, z2.f90, z3.f90, z5.f90 now give the error > > troutmask:sgk[271] gfcx -o z z3.f90 && ./z > a.f90:4:9: > > 4 |data (c(i:i), i=1,999) /999*'c'/ > | 1 > Error: Invalid substring in data-implied-do at (1) in DATA statement > > Oddly, za.f90 compiles because the variable is implicitly defined > to be of type integer. If 'integer i' is added to this case, then > an error is issued. This was actually fixed by r257962 | kargl | 2018-02-24 09:22:10 -0800 (Sat, 24 Feb 2018) | 11 lines 2018-02-24 Steven G. Kargl PR fortran/30792 * decl.c (gfc_match_data): Check for invalid substring in data-implied-do 2018-02-24 Steven G. Kargl PR fortran/30792 * gfortran.dg/data_substring.f90: New test. but the check for issuing the error message enforced that the implied-do index must be integer. For za.f90 testcase, the basic type for the implicitly typed 'i' is BT_UNKNOWN. Checking for BT_INTEGER is tto strict. Here a patch against svn r 280157. Whoever decides to commit the patch should probably convert za.f90 to a testcase. Index: gcc/fortran/decl.c === --- gcc/fortran/decl.c (revision 280157) +++ gcc/fortran/decl.c (working copy) @@ -657,7 +657,6 @@ gfc_match_data (void) goto cleanup; if (new_data->var->iter.var - && new_data->var->iter.var->ts.type == BT_INTEGER && new_data->var->iter.var->symtree->n.sym->attr.implied_index == 1 && new_data->var->list && new_data->var->list->expr
[Bug fortran/70070] ICE on initializing character data beyond min/max bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70070 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #9 from kargl at gcc dot gnu.org --- Programs z1.f90, z2.f90, z3.f90, z5.f90 now give the error troutmask:sgk[271] gfcx -o z z3.f90 && ./z a.f90:4:9: 4 |data (c(i:i), i=1,999) /999*'c'/ | 1 Error: Invalid substring in data-implied-do at (1) in DATA statement Oddly, za.f90 compiles because the variable is implicitly defined to be of type integer. If 'integer i' is added to this case, then an error is issued.
[Bug analyzer/93288] ICE in supergraph.cc:180
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93288 David Malcolm changed: What|Removed |Added Keywords||patch --- Comment #7 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00398.html
[Bug fortran/70913] ICE in gfc_encode_character, at fortran/target-memory.c:227
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70913 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #6 from kargl at gcc dot gnu.org --- The code in comment #1 compiles and gives the expected result. The programs z1.f90, z2.f90, and z3.f90 should be converted to "dg-do run" tests. The code in comment #3 still gives and ICE.
[Bug analyzer/93405] Passing constant arguments to subroutines in Fortran ... and the analyzer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93405 David Malcolm changed: What|Removed |Added Keywords||patch --- Comment #2 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00394.html
[Bug lto/93609] gcc -flto -fno-comon places symbols into ".text" section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93609 --- Comment #3 from Martin Liška --- (In reply to Sergei Trofimovich from comment #2) > (In reply to Martin Liška from comment #1) > > Hello, it's a known and reported issue: > > https://lists.gnu.org/archive/html/libtool/2020-01/msg00022.html > > https://sourceware.org/bugzilla/show_bug.cgi?id=25355 > > Aha, makes sense. A lot more complicated than I thought. Thank you! Yes! It seems to me that the discussion is stuck and it blocks testing of GCC 10 with for me in openSUSE. There's quite some -fno-common fallout and this hides part of the issues.
[Bug target/90763] PowerPC vec_xl_len should take const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90763 --- Comment #3 from Martin Liška --- (In reply to Bill Schmidt from comment #2) > Whoops, that was not supposed to go to bz. Sorry about that. Hehe. Sure, I'll do it next time.
[Bug c++/86269] [concepts] ICE with intermediate concepts notation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86269 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Patrick Palka --- Fixed in trunk by r276764, which also adds a test.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 86269, which changed state. Bug 86269 Summary: [concepts] ICE with intermediate concepts notation https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86269 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 87441, which changed state. Bug 87441 Summary: [concepts] Found compiler internal error: in tsubst at cp/pt.c:13657 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87441 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/87441] [concepts] Found compiler internal error: in tsubst at cp/pt.c:13657
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87441 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #5 from Patrick Palka --- Fixed in trunk by r276764, which also adds a test.
[Bug c++/79759] [concepts] ICE in tsubst, at cp/pt.c:13509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79759 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #4 from Patrick Palka --- Fixed in trunk by r276764, which also adds a test.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 79759, which changed state. Bug 79759 Summary: [concepts] ICE in tsubst, at cp/pt.c:13509 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79759 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/80746] [concepts] ICE evaluating constraints for concepts with dependent template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80746 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Patrick Palka --- Fixed in trunk by r276764, which also adds a test.
[Bug c++/80746] [concepts] ICE evaluating constraints for concepts with dependent template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80746 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Target Milestone|--- |10.0 --- Comment #5 from Patrick Palka --- Fixed in trunk by r276764, which also adds a test.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 80746, which changed state. Bug 80746 Summary: [concepts] ICE evaluating constraints for concepts with dependent template parameters https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80746 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/80773] [Concepts] Internal Compiler error on template parameter pack expansion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80773 Patrick Palka changed: What|Removed |Added Status|NEW |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #3 from Patrick Palka --- Fixed in trunk by r276764, which also adds a test.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 80773, which changed state. Bug 80773 Summary: [Concepts] Internal Compiler error on template parameter pack expansion https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80773 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/82740] [concepts] requires clause evaluated early
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82740 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |10.0 --- Comment #2 from Patrick Palka --- Fixed in trunk by r276764, which also adds the test.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 82740, which changed state. Bug 82740 Summary: [concepts] requires clause evaluated early https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82740 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug analyzer/93375] ICE in gimple_call_arg, at gimple.h:3258
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93375 David Malcolm changed: What|Removed |Added Status|REOPENED|ASSIGNED --- Comment #5 from David Malcolm --- Thanks; am testing a fix.
[Bug target/93532] RISCV g++ hangs with optimization >= -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532 Jim Wilson changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |wilson at gcc dot gnu.org --- Comment #13 from Jim Wilson --- Created attachment 47794 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47794&action=edit untested patch to fix the problem
[Bug target/93532] RISCV g++ hangs with optimization >= -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532 --- Comment #12 from Jim Wilson --- A bisection on mainline between the gcc-8 and gcc-9 releases shows that this testcase was fixed by a combine patch for PR87600 that stops combining hard regs with pseudos to reduce register pressure. The commentary refers to ira and lra problems. A combine patch won't be as safe as a RISC-V backend patch though. I tried testing the riscv HARD_REGNO_CALLER_SAVE_MODE patch with buildroot but it turns out that it is downloading a pre-built compiler instead of building one. So dropping in the patch doesn't do anything. I will have to figure out what is going on there. Trying the riscv patch with mainline on the testcase, I see that I get better rematerialization without the confusing subregs, and I also get smaller stack frames since we are saving SFmode now to the stack instead of DFmode now. Otherwise, I don't see any significant changes to the code. I tried a make check with the riscv patch on mainline, and got an unexpected g++ testsuite failure, so I will have to look into that.
[Bug lto/93609] gcc -flto -fno-comon places symbols into ".text" section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93609 --- Comment #2 from Sergei Trofimovich --- (In reply to Martin Liška from comment #1) > Hello, it's a known and reported issue: > https://lists.gnu.org/archive/html/libtool/2020-01/msg00022.html > https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Aha, makes sense. A lot more complicated than I thought. Thank you!
[Bug c++/93618] [10 Regression] : unknown array size in delete when using C++20 standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93618 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Please follow https://gcc.gnu.org/bugs/ instructions and attach preprocessed source.
[Bug c++/91212] [8/9/10 Regression] const ignored for ctor arguments within return since r8-2493-g4ce8c5dea53d8073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91212 --- Comment #7 from Jason Merrill --- Created attachment 47793 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47793&action=edit Fix This patch fixes the pre-P1825 bug, but breaks the PR58051 test which is not actually allowed by DR 1579 (but is by P1825), and some of your -Wredundant-move tests for the same reason. I think let's wait to see what the committee thinks before deciding how to resolve this.
[Bug target/91638] powerpc -mlong-double-NN (documentation) issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91638 --- Comment #2 from Segher Boessenkool --- That isn't documentation.
[Bug fortran/93497] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93497
--- Comment #5 from Steve Kargl ---
On Thu, Feb 06, 2020 at 03:38:05AM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> --- Comment #4 from Steve Kargl ---
> On Thu, Feb 06, 2020 at 02:06:01AM +, sgk at troutmask dot
> apl.washington.edu wrote:
(old patch deleted)
> >
> > Another possibility to fix the bug is to use gfc_expr_walker
> > from frontend-passes.c to check if the expression has an array
> > result. Don't know how to do that.
> >
>
> Another possibility is to find where in resolve.c that the
> charlen is reduced and issue an appropriate error when
> an array-valued length is found.
>
Here you go. Still need to adjust error message in gfortran.dg/pr88025.f90.
Whoever decides to push the change can fix it.
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 280157)
+++ gcc/fortran/decl.c (working copy)
@@ -1056,6 +1072,11 @@ char_len_param_value (gfc_expr **expr, bool *deferred)
if (!gfc_expr_check_typed (*expr, gfc_current_ns, false))
return MATCH_ERROR;
+
+ /* If gfortran gets an EXPR_OP, try to simplifiy it. This catches things
+ like CHARACTER(([1])). */
+ if ((*expr)->expr_type == EXPR_OP)
+gfc_simplify_expr (*expr, 1);
if ((*expr)->expr_type == EXPR_FUNCTION)
{
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 280157)
+++ gcc/fortran/resolve.c (working copy)
@@ -12297,7 +12300,7 @@ resolve_charlen (gfc_charlen *cl)
}
/* cl->length has been resolved. It should have an integer type. */
- if (cl->length->ts.type != BT_INTEGER)
+ if (cl->length->ts.type != BT_INTEGER || cl->length->rank != 0)
{
gfc_error ("Scalar INTEGER expression expected at %L",
&cl->length->where);
[Bug c++/91212] [8/9/10 Regression] const ignored for ctor arguments within return since r8-2493-g4ce8c5dea53d8073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91212 --- Comment #6 from Marek Polacek --- (In reply to Jason Merrill from comment #5) > I think this is a bug in pre-P1825R0 handling of the restriction that the > first overload resolution fails "if the type of the first parameter of the > selected constructor is not an rvalue reference to the object's type > (possibly cv-qualified)". > > But that restriction was removed by P1825R0, and I think this demonstrates a > problem with that. > > Testing a patch. Will this resolve bug 91427 too? Sorry, still assigned to me...
[Bug c++/93618] New: [10 Regression] : unknown array size in delete when using C++20 standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93618
Bug ID: 93618
Summary: [10 Regression] : unknown array size in delete when
using C++20 standard
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: laurent.stacul at gmail dot com
Target Milestone: ---
Hello,
I tried to compile Re2 (https://github.com/google/re2) with a close to HEAD
gcc:
g++ (GCC) 10.0.1 20200124 (experimental)
And I got the error described here: https://github.com/google/re2/issues/102.
This one was fixed several years ago for gcc 6.1 & 6,2 through
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71147.
Now with gcc 10 it works fine except when I add the flag -std=gnu++2a as you
can see below:
$ make CXXFLAGS="-std=gnu++2a" -j8
...
g++ -c -o obj/re2/dfa.o -std=c++11 -pthread -Wall -Wextra
-Wno-unused-parameter -Wno-missing-field-initializers -I. -std=gnu++2a
-DNDEBUG re2/dfa.cc
re2/dfa.cc: In constructor ‘constexpr re2::DFA::State::State()’:
re2/dfa.cc:120:10: error: unknown array size in delete
120 | struct State {
| ^
re2/dfa.cc: In member function ‘re2::DFA::State* re2::DFA::CachedState(int*,
int, uint32_t)’:
re2/dfa.cc:753:9: note: synthesized method ‘constexpr re2::DFA::State::State()’
first required here
753 | State state;
| ^
Thanks in advance for you help,
Stac
[Bug c++/91212] [8/9/10 Regression] const ignored for ctor arguments within return since r8-2493-g4ce8c5dea53d8073
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91212 --- Comment #5 from Jason Merrill --- I think this is a bug in pre-P1825R0 handling of the restriction that the first overload resolution fails "if the type of the first parameter of the selected constructor is not an rvalue reference to the object's type (possibly cv-qualified)". But that restriction was removed by P1825R0, and I think this demonstrates a problem with that. Testing a patch.
[Bug c++/93617] Ternary operator calling a noreturn function should not cause type errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93617 --- Comment #4 from Jonathan Wakely --- Definitely invalid, even with the standard [[noreturn]] attribute.
[Bug rtl-optimization/87763] [9/10 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #66 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:bba0c624c8b1d6e54dc58091dd21b0c2ab000434 commit r10-6485-gbba0c624c8b1d6e54dc58091dd21b0c2ab000434 Author: Richard Sandiford Date: Mon Feb 3 21:43:44 2020 + aarch64: Add an and/ior-based movk pattern [PR87763] This patch adds a second movk pattern that models the instruction as a "normal" and/ior operation rather than an insertion. It fixes the third insv_1.c failure in PR87763, which was a regression from GCC 8. 2020-02-06 Richard Sandiford gcc/ PR target/87763 * config/aarch64/aarch64-protos.h (aarch64_movk_shift): Declare. * config/aarch64/aarch64.c (aarch64_movk_shift): New function. * config/aarch64/aarch64.md (aarch64_movk): New pattern. gcc/testsuite/ PR target/87763 * gcc.target/aarch64/movk_2.c: New test.
[Bug rtl-optimization/87763] [9/10 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #66 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:bba0c624c8b1d6e54dc58091dd21b0c2ab000434 commit r10-6485-gbba0c624c8b1d6e54dc58091dd21b0c2ab000434 Author: Richard Sandiford Date: Mon Feb 3 21:43:44 2020 + aarch64: Add an and/ior-based movk pattern [PR87763] This patch adds a second movk pattern that models the instruction as a "normal" and/ior operation rather than an insertion. It fixes the third insv_1.c failure in PR87763, which was a regression from GCC 8. 2020-02-06 Richard Sandiford gcc/ PR target/87763 * config/aarch64/aarch64-protos.h (aarch64_movk_shift): Declare. * config/aarch64/aarch64.c (aarch64_movk_shift): New function. * config/aarch64/aarch64.md (aarch64_movk): New pattern. gcc/testsuite/ PR target/87763 * gcc.target/aarch64/movk_2.c: New test.
[Bug rtl-optimization/87763] [9/10 Regression] aarch64 target testcases fail after r265398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763 --- Comment #65 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:b65a1eb3fae53f2e1ea1ef8c1164f490d55855a1 commit r10-6484-gb65a1eb3fae53f2e1ea1ef8c1164f490d55855a1 Author: Richard Sandiford Date: Mon Feb 3 21:12:35 2020 + aarch64: Add an extra sbfiz pattern [PR87763] This patch matches another form of sbfiz, in which the input has DImode and the output has SImode. It fixes a regression in gcc.target/aarch64/lsl_asr_sbfiz.c from GCC 8. 2020-02-06 Richard Sandiford gcc/ PR rtl-optimization/87763 * config/aarch64/aarch64.md (*ashiftsi_extvdi_bfiz): New pattern.
[Bug c++/93614] C++ compile error with struct in template class and < operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93614 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- clang++ rejects this too.
[Bug c++/93617] Ternary operator calling a noreturn function should not cause type errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93617 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from Jakub Jelinek --- Yeah, the type of the ternary operator operand is one thing and noreturn attribute is another. You can use (throwError(), 0) or something similar.
[Bug c++/93597] [10 Regression] ICE in get_fns since r10-6219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93597 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed.
[Bug c++/93617] Ternary operator calling a noreturn function should not cause type errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93617 --- Comment #2 from Andrew Pinski --- I doubt we are going to accept an extension here.
[Bug c++/93617] Ternary operator calling a noreturn function should not cause type errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93617 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- I'm not sure that should be accepted, icc/clang++ reject it too.
[Bug c++/93597] [10 Regression] ICE in get_fns since r10-6219
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93597 --- Comment #2 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:4a136a214ede91ef05caac017814b142883dc80d commit r10-6482-g4a136a214ede91ef05caac017814b142883dc80d Author: Marek Polacek Date: Wed Feb 5 12:53:06 2020 -0500 c++: Fix ICE with lambda in operator function [PR93597] If we are going to use get_first_fn let's make sure we operate on is_overloaded_fn, as the rest of the codebase does, and if lookup finds any class-scope declaration, return early too. PR c++/93597 - ICE with lambda in operator function. * name-lookup.c (maybe_save_operator_binding): Check is_overloaded_fn. * g++.dg/cpp0x/lambda/lambda-93597.C: New test.
[Bug c++/93617] New: Ternary operator calling a noreturn function should not cause type errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93617 Bug ID: 93617 Summary: Ternary operator calling a noreturn function should not cause type errors Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: whoffman at de dot ibm.com Target Milestone: --- Created attachment 47792 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47792&action=edit sample program Given a ternary operator that calls a function annotated with __attribute__((noreturn)) in one branch should not lead to type errors. At the moment, compiling the attached sample program fails with $ gcc foo.cpp foo.cpp: In function 'void foo()': foo.cpp:12:21: error: third operand to the conditional operator is of type 'void', but the second operand is neither a throw-expression nor of type 'void' 12 | int a = b ? 2 : throwError(); | ^
[Bug fortran/93578] [10 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:1949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93578 markeggleston at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||markeggleston at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #1 from markeggleston at gcc dot gnu.org --- Built with bootstrap, master at https://gcc.gnu.org/g:c940105cc17 Get the same output as gfortran-10-20200105 in the original report.
[Bug target/90763] PowerPC vec_xl_len should take const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90763 --- Comment #2 from Bill Schmidt --- Whoops, that was not supposed to go to bz. Sorry about that.
[Bug target/90763] PowerPC vec_xl_len should take const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90763 --- Comment #1 from wschmidt at linux dot ibm.com --- Hi Martin, Could you please CC me on all ppc bugs as well as Segher? I do all of the "project management" activities for the IBM GCC team. Thanks! Bill On 2/6/20 8:28 AM, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90763 > > Martin Liška changed: > > What|Removed |Added > > Status|UNCONFIRMED |NEW > Last reconfirmed||2020-02-06 > CC||marxin at gcc dot gnu.org, > ||segher at gcc dot gnu.org > Ever confirmed|0 |1 >
[Bug tree-optimization/93616] New: Missed chance to use alias checks to vectorise invariant indirection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93616
Bug ID: 93616
Summary: Missed chance to use alias checks to vectorise
invariant indirection
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Blocks: 53947
Target Milestone: ---
For:
void
foo (char **dest_ptr, char *src)
{
for (int i = 0; i < 100; ++i)
(*dest_ptr)[i] = src[i];
}
we should be able to emit a runtime alias check that [src, src+99]
doesn't overlap *dest_ptr and then vectorise the loop normally.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug rtl-optimization/93561] [bounds checking] memory overflow for spill_for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93561 --- Comment #1 from Vladimir Makarov --- Thank you for reporting this. It seems the bug did not manifested itself before as the most targets have virtual hard registers as the last hard regs. I'll commit your patch today. Thank you again.
[Bug target/93611] [10 Regression] ICE in extract_constrain_insn_cached, at recog.c:2207 since r10-6451-gb7b3378f91c0641f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93611 Jakub Jelinek changed: What|Removed |Added Attachment #47788|0 |1 is obsolete|| --- Comment #5 from Jakub Jelinek --- Created attachment 47791 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47791&action=edit gcc10-pr93611.patch Updated patch that moves it one function down and thus handles *lea too.
[Bug target/93615] [10 Regression] unwind.h on arm can't be compiled with -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93615
--- Comment #1 from Jakub Jelinek ---
Untested fix:
2020-02-06 Jakub Jelinek
PR target/93615
* config/arm/unwind-arm.h (gnu_Unwind_Find_got): Rename to ...
(_Unwind_gnu_Find_got): ... this. Use __asm instead of asm. Remove
trailing :s in asm. Formatting fixes.
(_Unwind_decode_typeinfo_ptr): Adjust caller.
--- libgcc/config/arm/unwind-arm.h.jj 2020-01-12 11:54:38.616380172 +0100
+++ libgcc/config/arm/unwind-arm.h 2020-02-06 16:16:54.244624408 +0100
@@ -43,19 +43,15 @@ extern "C" {
#endif
_Unwind_Ptr __attribute__((weak)) __gnu_Unwind_Find_got (_Unwind_Ptr);
-static inline _Unwind_Ptr gnu_Unwind_Find_got (_Unwind_Ptr ptr)
+static inline _Unwind_Ptr _Unwind_gnu_Find_got (_Unwind_Ptr ptr)
{
_Unwind_Ptr res;
if (__gnu_Unwind_Find_got)
- res = __gnu_Unwind_Find_got (ptr);
+ res = __gnu_Unwind_Find_got (ptr);
else
- {
- asm volatile ("mov %[result], r" XSTR(FDPIC_REGNUM)
- : [result]"=r" (res)
- :
- :);
- }
+ __asm volatile ("mov %[result], r" XSTR(FDPIC_REGNUM)
+ : [result] "=r" (res));
return res;
}
@@ -75,7 +71,7 @@ static inline _Unwind_Ptr gnu_Unwind_Fin
#if __FDPIC__
/* For FDPIC, we store the offset of the GOT entry. */
/* So, first get GOT from dynamic linker and then use indirect access.
*/
- tmp += gnu_Unwind_Find_got (ptr);
+ tmp += _Unwind_gnu_Find_got (ptr);
tmp = *(_Unwind_Word *) tmp;
#elif (defined(linux) && !defined(__uClinux__)) || defined(__NetBSD__) \
|| defined(__FreeBSD__) || defined(__fuchsia__)
[Bug target/93615] [10 Regression] unwind.h on arm can't be compiled with -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93615 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-02-06 Version|9.2.1 |10.0 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1
[Bug target/93615] New: [10 Regression] unwind.h on arm can't be compiled with -std=c11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93615
Bug ID: 93615
Summary: [10 Regression] unwind.h on arm can't be compiled with
-std=c11
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
In file included from
/builddir/build/BUILD/compiler-rt-10.0.0rc1.src/lib/builtins/gcc_personality_v0.c:11:
/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/10/include/unwind.h: In function
'gnu_Unwind_Find_got':
/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/10/include/unwind.h:54:2: error:
'asm' undeclared (first use in this function)
54 | asm volatile ("mov %[result], r" XSTR(FDPIC_REGNUM)
| ^~~
/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/10/include/unwind.h:54:2: note: each
undeclared identifier is reported only once for each function it appears in
/usr/lib/gcc/armv7hl-redhat-linux-gnueabi/10/include/unwind.h:54:5: error:
expected ';' before 'volatile'
54 | asm volatile ("mov %[result], r" XSTR(FDPIC_REGNUM)
| ^
| ;
[Bug fortran/93581] [9/10 Regression] ICE in gfc_get_dataptr_offset, at fortran/trans-array.c:6951
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93581 Jeffrey A. Law changed: What|Removed |Added Priority|P3 |P4 CC||law at redhat dot com
[Bug c++/93614] New: C++ compile error with struct in template class and < operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93614
Bug ID: 93614
Summary: C++ compile error with struct in template class and <
operator
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: thilo.voert...@coseda-tech.com
Target Milestone: ---
The following code does not compile. which I consider a compiler bug:
template
class foo{};
template
class template_class_with_struct
{
void my_method() {
if(this->b.foo < 1);
};
struct bar
{
long foo;
} b;
};
It returns the following error message is returned:
error: type/value mismatch at argument 1 in template parameter list for
'template class foo'
8 | if(this->b.foo < 1);
| ^
The creation of template class foo leads to this error, it can be worked around
by writing b.bar::foo or parenthesis ((this->b.foo) < 1) in the error line,
however it should not be neccessary.
Note: MSVC accepts this this code without complaining
[Bug fortran/93498] [9/10 Regression] ICE in gfc_resolve_findloc, at fortran/iresolve.c:1844 since r9-3688-g01ce9e31a02c8039
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93498 --- Comment #5 from Steve Kargl --- On Thu, Feb 06, 2020 at 07:24:36AM +, tkoenig at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93498 > > --- Comment #4 from Thomas Koenig --- > (In reply to kargl from comment #3) > > Patch is against svn r280157. > > > > Index: gcc/fortran/check.c > > === > > --- gcc/fortran/check.c (revision 280157) > > +++ gcc/fortran/check.c (working copy) > > @@ -3942,6 +3942,10 @@ gfc_check_findloc (gfc_actual_arglist *ap) > >v1 = v->ts.type == BT_CHARACTER; > >if ((a1 && !v1) || (!a1 && v1)) > > goto incompat; > > + > > + /* Check the kind of the characters argument match. */ > > + if (a1 && v1 && a->ts.kind != v->ts.kind) > > +goto incompat; > > > >d = ap->next->next->expr; > >m = ap->next->next->next->expr; > > This avoids the ICE. > > What I have not yet have had time to figure out if the test case > is legal or not, if we need to convert or to reject. > It's not valid. F2018, 10.1.5.1, p. 154. The kind type parameters of the operands of a character relational intrinsic operation shall be the same. F2018, 16.9.78 VALUE shall be scalar and in type conformance with ARRAY, as specified in Table 10.2 for the operator == or the operator .EQV..
[Bug target/93594] Missed optimization with _mm256_set/setr_m128i intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93594 --- Comment #9 from Marc Glisse --- (In reply to Jakub Jelinek from comment #6) > if we change the cast patterns so that they are a > vec_concat of the operand and UNSPEC_CAST that then represents just the > uninitialized higher part, simplify-rtx.c is able to deal with it on its own. Yes, I like that better as well. The name UNSPEC_CAST looks a bit strange though, it could be renamed UNSPEC_UNDEF for instance? If someone tries to extract the high part of such a vector, I expect simplification yields just the unspec, which doesn't have a matching pattern, so the simplification is cancelled? Any connection with _mm_undefined_si128? (random dump of thoughts, ignore most of it)
[Bug target/93613] Missed optimization with _mm256_permute2x128_si256 intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93613
--- Comment #1 from Jakub Jelinek ---
I've tried:
--- gcc/config/i386/sse.md.jj 2020-02-06 13:40:27.485007762 +0100
+++ gcc/config/i386/sse.md 2020-02-06 15:24:35.097743017 +0100
@@ -81,7 +81,6 @@ (define_c_enum "unspec" [
;; For AVX2 support
UNSPEC_VPERMVAR
- UNSPEC_VPERMTI
UNSPEC_GATHER
UNSPEC_VSIBADDR
@@ -20224,15 +20223,55 @@ (define_insn "avx512f_perm_1")
(set_attr "mode" "")])
-(define_insn "avx2_permv2ti"
- [(set (match_operand:V4DI 0 "register_operand" "=x")
- (unspec:V4DI
- [(match_operand:V4DI 1 "register_operand" "x")
- (match_operand:V4DI 2 "nonimmediate_operand" "xm")
- (match_operand:SI 3 "const_0_to_255_operand" "n")]
- UNSPEC_VPERMTI))]
+(define_expand "avx2_permv2ti"
+ [(match_operand:V4DI 0 "register_operand")
+ (match_operand:V4DI 1 "register_operand")
+ (match_operand:V4DI 2 "nonimmediate_operand")
+ (match_operand:SI 3 "const_0_to_255_operand")]
"TARGET_AVX2"
- "vperm2i128\t{%3, %2, %1, %0|%0, %1, %2, %3}"
+{
+ int mask = INTVAL (operands[3]);
+ int first = (mask & 0x08) ? 8 : (mask & 0x03) * 2;
+ int second = (mask & 0x80) ? 8 : (mask & 0x30) / 8;
+ emit_insn (gen_avx2_permv2ti_1 (operands[0], operands[1],
+ operands[2], CONST0_RTX (V8DImode),
+ GEN_INT (first),
+ GEN_INT (first + 1),
+ GEN_INT (second),
+ GEN_INT (second + 1)));
+ DONE;
+})
+
+(define_insn "avx2_permv2ti_1"
+ [(set (match_operand:V4DI 0 "register_operand" "=x")
+ (vec_select:V4DI
+ (vec_concat:V16DI
+ (vec_concat:V8DI
+ (match_operand:V4DI 1 "register_operand" "x")
+ (match_operand:V4DI 2 "nonimmediate_operand" "xm"))
+ (match_operand:V8DI 3 "const0_operand" "C"))
+ (parallel [(match_operand 4 "const_0_to_15_operand")
+(match_operand 5 "const_0_to_15_operand")
+(match_operand 6 "const_0_to_15_operand")
+(match_operand 7 "const_0_to_15_operand")])))]
+ "TARGET_AVX2
+ && (INTVAL (operands[4]) & 2) == 0
+ && INTVAL (operands[5]) == INTVAL (operands[4]) + 1
+ && (INTVAL (operands[6]) & 2) == 0
+ && INTVAL (operands[7]) == INTVAL (operands[6]) + 1"
+{
+ int mask = 0;
+ if (INTVAL (operands[4]) >= 8)
+mask |= 0x08;
+ else
+mask |= INTVAL (operands[4]) / 2;
+ if (INTVAL (operands[6]) >= 8)
+mask |= 0x80;
+ else
+mask |= INTVAL (operands[6]) * 8;
+ operands[4] = GEN_INT (mask);
+ return "vperm2i128\t{%4, %2, %1, %0|%0, %1, %2, %4}";
+}
[(set_attr "type" "sselog")
(set_attr "prefix" "vex")
(set_attr "mode" "OI")])
but unfortunately it doesn't help, guess we'll need to improve simplify-rtx.c
to deal with that (and for the last 3 functions it even makes things worse, as
combine then simplifies those patterns to vector constants but we don't have an
instruction that would force the const_vector into memory that combine could
match and could be split before reload). For those I guess we want gimple
folding of the builtin. Of course, people really should use __builtin_shuffle
instead of this mess... ;)
[Bug target/93594] Missed optimization with _mm256_set/setr_m128i intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93594 --- Comment #8 from Jakub Jelinek --- _mm256_permute2x128_si256 issue moved to separate PR93613.
[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid CC||mpolacek at gcc dot gnu.org --- Comment #7 from Marek Polacek --- An even simpler test: #define MY_RAW_STRING R"(My raw string multiline)" We still don't handle it right.
[Bug target/93613] New: Missed optimization with _mm256_permute2x128_si256 intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93613
Bug ID: 93613
Summary: Missed optimization with _mm256_permute2x128_si256
intrinsic
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: andysem at mail dot ru
Depends on: 93594
Target Milestone: ---
+++ This bug was initially created as a clone of Bug #93594 +++
#include
__m256i
foo (__m128i x)
{
return _mm256_permute2x128_si256 (_mm256_castsi128_si256 (x),
_mm256_castsi128_si256 (x), 0x80);
}
__m256i
bar (__m128i x)
{
return _mm256_permute2x128_si256 (_mm256_setzero_si256 (),
_mm256_castsi128_si256 (x), 0x02);
}
__m256i
baz (__m128i x)
{
return _mm256_permute2x128_si256 (_mm256_castsi128_si256 (x),
_mm256_setzero_si256 (), 0x20);
}
__m256i
qux (__m128i x)
{
return _mm256_permute2x128_si256 (_mm256_set_epi64x (1, 2, 3, 4),
_mm256_set_epi64x (5, 6, 7, 8), 0x80);
}
__m256i
corge (__m128i x)
{
return _mm256_permute2x128_si256 (_mm256_set_epi64x (1, 2, 3, 4),
_mm256_set_epi64x (5, 6, 7, 8), 0x02);
}
__m256i
quux (__m128i x)
{
return _mm256_permute2x128_si256 (_mm256_set_epi64x (1, 2, 3, 4),
_mm256_set_epi64x (5, 6, 7, 8), 0x20);
}
The _mm256_permute2x128_si256 issues are similar, but really unrelated and IMHO
should be tracked in a separate PR. The problem there is that the pattern we
use doesn't really describe what the instruction does, uses an UNSPEC_VPERMTI,
which obviously can't be simplified by the generic code. The reason is mainly
that the instruction isn't just a two source permutation, but essentially 3
source permutation, with the third source of 0.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93594
[Bug 93594] Missed optimization with _mm256_set/setr_m128i intrinsics
[Bug sanitizer/90746] __sanitizer_cov_trace_pc should not be tail called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90746 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-06 Ever confirmed|0 |1
[Bug tree-optimization/90753] missing -Warray-bounds with an extern index in out-of-bounds range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90753 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-02-06 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1
