[Bug preprocessor/93419] __has_attribute(ifunc) false positive on hurd and kfreebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93419 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-25 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Martin Sebor --- If the error is issued by GCC then that would make it a bug in the implementation of __has_attribute. Let me look into it.
[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 #121 from Peter Bisroev --- > > I think it would be good to test 4.7.4 build with make check. > I will try to get that done. Unfortunately I remember trying to get guile > (required for "make check" based on the errors) to work on HPUX and not > getting anywhere. Will try getting it running over the weekend. Hi Dave, after a bit of trial and error, I was able to get Tcl, expect and DejaGnu to run from what I can tell. It also looks like that this is all that is needed to run "make check-c" and "make check-c++". Would these two checks be good enough to start? I am currently running them both for 4.7.4 bootstrapped by aCC. Thanks, --peter
[Bug c++/93400] [10 Regression] ICE: in tsubst, at cp/pt.c:15142 on friends with concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93400 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jason Merrill --- Fixed.
[Bug c++/93400] [10 Regression] ICE: in tsubst, at cp/pt.c:15142 on friends with concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93400 --- Comment #1 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:9c1179c339e050e2ce7c545f648b684d38dec69d commit r10-6220-g9c1179c339e050e2ce7c545f648b684d38dec69d Author: Jason Merrill Date: Fri Jan 24 14:58:56 2020 -0500 c++: Fix ICE with constrained friend (PR93400). Here, the problem was that tsubst_friend_function was modifying the CONSTRAINT_INFO for the friend template to have the constraints for one instantiation, which fell down when we went to adjust it for another instantiation. Fixed by deferring substitution of trailing requirements until we try to check declaration matching. PR c++/93400 - ICE with constrained friend. * constraint.cc (maybe_substitute_reqs_for): New. * decl.c (function_requirements_equivalent_p): Call it. * pt.c (tsubst_friend_function): Only substitute TEMPLATE_PARMS_CONSTRAINTS. (tsubst_template_parms): Copy constraints.
[Bug fortran/93427] New: Rejects valid with pointer result from recursive function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93427 Bug ID: 93427 Summary: Rejects valid with pointer result from recursive function Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com Target Milestone: --- The following code fails to compile (using git commit 472dc648ce3e7661762931d584d239611ddca964): module a type :: t end type t contains recursive function b() class(t), pointer :: b type(t) :: c allocate(t :: b) select type (b) type is (t) b=c end select end function b end module a $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.0.1 20200124 (experimental) (GCC) $ gfortran -c p.F90 -o p.o p.F90:12:15: 12 | select type (b) | 1 Error: Associating entity 'b' at (1) is a procedure name p.F90:14:5: 14 | b=c | 1 Error: 'b' at (1) associated to vector-indexed target cannot be used in a variable definition context (assignment) The code compiles successfully using ifort 18.0.1. Removing the "recursive" attribute, or specifying a "result()" variable makes the errors go away.
[Bug c/90036] [8/9/10 Regression] false positive: directive argument is null [-Werror=format-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90036 Jeffrey A. Law changed: What|Removed |Added Target Milestone|10.0|11.0 --- Comment #9 from Jeffrey A. Law --- I still think extracting the predicate analysis bits out of tree-ssa-uninit.c is the way to go. Essentially we'd build the predicate guarding the problematical sprintf call and realize it can never be true. There's a slight chance the new VRP code could help here as it does have a backwards substitution/solver engine. I think we'd want to raise the query what's the range of ownvptr_15 in bb4 and work backwards. Aldy, want to take a looksie and see if your work could help here. In either case, I don't see this being resolved in gcc-10.
[Bug target/92665] [AArch64] low lanes select not optimized out for vmlal intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92665 --- Comment #5 from Andrew Pinski --- Note some of the moves were removed with g:8c8952918b75f4fa6adbbe44cd641d5fd0bb55e3 But it is not a general solution, it just "splits" the case where dst and source have the same register. my patch (which I have a few improvements to it and fixing it for GCC 10) handles the case where the dst and the source registers are different which is what is happening in this case.
[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 #120 from Peter Bisroev --- (In reply to EML from comment #117) > I do appreciate someone else taking a look at this; I've had a lot of > changes at work, so this really took a back seat. And I don't have access to > the HP compiler to try things. I think this is an important step is in > comment 112: > > --- > Unfortunately, the above won't work directly because of the function name > encoding used on pa. Maybe you can look at aCC to see the assembly output > it generates to a call to a weak function. > --- > > > If we can figure out how aCC generates such weak and linkonce sections, we > should be able to make gcc do the same. > > As an aside, I have maxtsiz set to 1073741824 (per kctune) Thank you EML. Also increasing maxtsiz did help the self bootstrap of 4.7.4 with itself without needing to use "-Os" with STAGE1_CFLAGS. As far as compiling with aCC, is there anything specific that you would like to test out now? I can definitely compile that for you. Thanks, --peter
[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 #119 from Peter Bisroev --- (In reply to dave.anglin from comment #116) > It's the stage1 compile flags, "-O0 -g", which generate the large binaries. > Later stages > are compiled with -O2. You could reduce the size of stage1 using "-Os" in > STAGE1_CFLAGS > and STAGE1_CXXFLAGS. Got it, that makes sense. However what I am still not sure about is why there is such as drastic difference between aCC being used as a host compiler to compiler 4.7.4 and using compiler 4.7.4 as a host compiler to bootstrap itself again. In the meantime, as per your suggestion, I have used the size tool to check the size of the text section, and it was much larger than maxtsiz. By making it larger, I was successfully able do a 3-stage self bootstrap of 4.7.4 with 4.7.4 that was initially compiled with aCC. I did not have to use "-Os" with STAGE1_CFLAGS. > I think it would be good to test 4.7.4 build with make check. I will try to get that done. Unfortunately I remember trying to get guile (required for "make check" based on the errors) to work on HPUX and not getting anywhere. Will try getting it running over the weekend. > Think your aCC build was probably fine apart from the maxtsiz issue. I > would focus on it > first. Got it, will stick to 4.7.4 bootstrapped with aCC as a host compiler. Thanks, --peter
[Bug c++/93279] [9/10 Regression] C++ Template substitution ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93279 --- Comment #7 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:8b91e848130e45b427599ad30e99f96e447ea9aa commit r10-6219-g8b91e848130e45b427599ad30e99f96e447ea9aa Author: Jason Merrill Date: Fri Jan 24 18:20:56 2020 -0500 c++: Fix ICE with lambda in member operator (PR93279) Here the problem was that we were remembering the lookup in template scope, and then trying to reuse that lookup in the instantiation without substituting into it at all. The simplest solution is to not try to remember a lookup that finds a class-scope declaration, as in that case doing the normal lookup again at instantiation time will always find the right declarations. PR c++/93279 - ICE with lambda in member operator. * name-lookup.c (maybe_save_operator_binding): Don't remember class-scope bindings.
[Bug libstdc++/93426] New: fix typo in span
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93426 Bug ID: 93426 Summary: fix typo in span Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: merukun1125 at docomo dot ne.jp Target Milestone: --- https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/span#L419 line 419 of gcc/libstdc++-v3/include/std/span: span>> ↓ span>> reference: http://eel.is/c++draft/views#span.overview-2
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 Devin Hussey changed: What|Removed |Added Build||2020-01-24 0:00 --- Comment #5 from Devin Hussey --- Finally got GCC to build after it was throwing a fit. I can confirm that the regression is in that commit. g:28a8a768ebef5e31f950013f1b48b14c008b4b3b works correctly, g:6a03477e85e1b097ed6c0b86c76436de575aef04 does not.
[Bug analyzer/93276] Build error of current trunk indicating "#pragma GCC diagnostic not allowed inside functions"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93276 David Malcolm changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01688.html
[Bug c/93410] [9 only] can't use _Decimal64 in C99/C11/C17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93410 --- Comment #3 from Vincent Lefèvre --- (In reply to jos...@codesourcery.com from comment #2) > But that's not the sort of change we make on past release branches. OK, but note that the GCC manual does not mention any limitation of this kind. This is rather confusing.
[Bug c++/93345] [10 Regression] ICE in nothrow_spec_p, at cp/except.c:1247
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93345
gcc-bugs at marehr dot dialup.fu-berlin.de changed:
What|Removed |Added
CC||gcc-bugs at marehr dot
dialup.fu-b
||erlin.de
--- Comment #7 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Hi Jason Merrill,
I have the following gcc-9 code:
```
template concept bool a = true;
template struct b {};
template using c = b>;
struct h {
template auto operator()(g) noexcept(noexcept(c{})) {}
};
template concept bool e = requires(d f) { h{}(f); };
static_assert(e);
```
that ICEs at the same location:
```
> g++ -std=c++17 -fconcepts -c ice.cpp
ice.cpp:7:59: internal compiler error: in nothrow_spec_p, at cp/except.c:1247
7 | template concept bool e = requires(d f) { h{}(f); };
|~~~^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug tree-optimization/92788] [10 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92788 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jeffrey A. Law --- Should be fixed on the trunk.
[Bug tree-optimization/92788] [10 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92788 --- Comment #7 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:98181563dc4c65c9d23eaa99134e18876b6ec671 commit r10-6217-g98181563dc4c65c9d23eaa99134e18876b6ec671 Author: Jeff Law Date: Fri Jan 24 17:44:10 2020 -0500 Fix ICE due to invalid jump threading request PR tree-optimization/92788 * tree-ssa-threadedge.c (thread_across_edge): Check EDGE_COMPLEX not EDGE_ABNORMAL. PR tree-optimization/92788 * g++.dg/pr92788.C: New test.
[Bug c++/93377] [10 Regression] ICE in tsubst_pack_expansion, at cp/pt.c:12852
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93377 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Fixed.
[Bug libfortran/92836] segfault with inquire()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836 Janne Blomqvist changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org --- Comment #18 from Janne Blomqvist --- Assigning to myself, looking into the locking errors.
[Bug testsuite/93058] FAIL: g++.dg/asan/asan_test.C -O2 (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93058 Sergei Trofimovich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #5 from Sergei Trofimovich --- In https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01682.html Jakub pointed out that was a fixable glibc bug. I assume it was fixed in https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=768c83b7f60d82db6677e19dc51be9f341e0f3fc closing this bug as INVALID. Apologies for the noise.
[Bug c++/93377] [10 Regression] ICE in tsubst_pack_expansion, at cp/pt.c:12852
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93377 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:55dd44535d2e4e5703c0103c26e7c51ab8c502c4 commit r10-6216-g55dd44535d2e4e5703c0103c26e7c51ab8c502c4 Author: Jason Merrill Date: Thu Jan 23 16:59:54 2020 -0500 c++: Fix parameter map handling of member typedef. any_template_parm_r was looking at the args of an alias template-id, but we need to look at all args of a member alias/typedef, including implicit ones from the enclosing class. PR c++/93377 - ICE with member alias in constraint. * pt.c (any_template_parm_r): Look at template arguments for all aliases, not only alias templates.
[Bug tree-optimization/93411] variable reference to constant array with same elements not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93411 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Looks like https://gcc.gnu.org/ml/gcc-patches/2017-04/msg01559.html , but Richi didn't like that. Would need to dig up IRC log what were the issues; that said, nothing has been done about it since then.
[Bug target/93412] [10 Regression] ICE: in extract_insn, at recog.c:2294 with __builtin_add_overflow() at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93412 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-24 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- I'll have a look.
[Bug c++/93413] Destructor definition not found during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93413 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-24 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Seems to be dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92695#c12 I'm afraid I don't know how to resolve this.
[Bug target/93395] AVX2 missed optimization : _mm256_permute_pd() is unfortunately translated into the more expensive VPERMPD instead of the cheap VPERMILPD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93395 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed for 10+.
[Bug target/93376] [10 Regression] ICE: in immed_wide_int_const_1, at emit-rtl.c:660 with -Og -finline-functions-called-once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93376 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jakub Jelinek --- Fixed.
[Bug c/38308] -Wformat does not work for wide strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38308 --- Comment #6 from Joseph S. Myers --- *** Bug 93406 has been marked as a duplicate of this bug. ***
[Bug analyzer/93276] Build error of current trunk indicating "#pragma GCC diagnostic not allowed inside functions"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93276 --- Comment #2 from David Malcolm --- Created attachment 47705 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47705=edit Patch that fixes the build with gcc 4.4
[Bug c++/93406] No argument checking for wchar_t variants of print-like functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93406 Joseph S. Myers changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Joseph S. Myers --- As a duplicate, if you have questions they should be raised in the main bug report; don't reopen a duplicate one unless you have an argument for it not being a duplicate. The question is how best to *cleanly* support format checking for wide string formats, when narrow format strings can be tricky mixtures of bytes and multibyte characters. I think the answer involves implementing some general set of accessors (not accessors restricted to the case of format checking) for accessing bytes / multibyte characters / wide characters in string constants (nowadays, that would probably be a fairly simple C++ class abstracting access to target strings in some way). Such accessors could then incrementally be used elsewhere in the compiler when elements of strings need to be accessed. *** This bug has been marked as a duplicate of bug 38308 ***
[Bug target/93395] AVX2 missed optimization : _mm256_permute_pd() is unfortunately translated into the more expensive VPERMPD instead of the cheap VPERMILPD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93395 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5d782a8d909c5cc472c911c0ab4de0b890aad868 commit r10-6215-g5d782a8d909c5cc472c911c0ab4de0b890aad868 Author: Jakub Jelinek Date: Fri Jan 24 22:49:51 2020 +0100 i386: prefer vpermilpd over vpermpd [PR93395] In Agner Fog's tables, vpermilp[sd] with immediates seem to be much faster than vpermpd with immediate, for a good reason, the former only permute something within the lanes and don't do anything intra-lane, while vpermpd can. So, functionality-wise, vpermilpd is more efficient subset of vpermpd. We use the same RTL for those though (and also for certain broadcast). Now, the problem was that the vpermpd pattern appeared first in sse.md, followed by the broadcast patterns, followed by the vpermilp[sd]. Which means unless -mavx -mno-avx2, we'd emit vpermpd instead of the more efficient alternatives. The following patch reorders them, so that vpermpd comes last, if we can match a broadcast, we do, if we can match a vpermilp[sd] that is not a broadcast, we will, otherwise fall back (of course only if -mavx2) to vpermpd. 2020-01-24 Jakub Jelinek PR target/93395 * config/i386/sse.md (*avx_vperm_broadcast_v4sf, *avx_vperm_broadcast_, _vpermil, *_vpermilp): Move before avx2_perm/avx512f_perm. * gcc.target/i386/pr93395.c: New test. * gcc.target/i386/avx512vl-vpermilpdi-1.c: Remove xfail.
[Bug target/93376] [10 Regression] ICE: in immed_wide_int_const_1, at emit-rtl.c:660 with -Og -finline-functions-called-once
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93376 --- Comment #9 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:14e5881e37771f1f58123e77c558adb3b90c8764 commit r10-6214-g14e5881e37771f1f58123e77c558adb3b90c8764 Author: Jakub Jelinek Date: Fri Jan 24 22:47:23 2020 +0100 simplify-rtx: Punt for modes with precision above MAX_BITSIZE_MODE_ANY_INT [PR93376] The following patch makes sure we punt in the 3 spots if precision is above MAX_BITSIZE_MODE_ANY_INT. 2020-01-24 Jakub Jelinek PR target/93376 * simplify-rtx.c (simplify_const_unary_operation, simplify_const_binary_operation): Punt for mode precision above MAX_BITSIZE_MODE_ANY_INT.
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 Andrew Pinski changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- (In reply to Devin Hussey from comment #3) > I think I found the culprit commit. > > Haven't set up a GCC build tree yet, though. > > https://github.com/gcc-mirror/gcc/commit/ > a51c4926712307787d133ba50af8c61393a9229b g:6a03477e85e1b097ed6c0b86c76436de575aef04 for the new git.
[Bug c/93410] [9 only] can't use _Decimal64 in C99/C11/C17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93410 --- Comment #2 from joseph at codesourcery dot com --- On Fri, 24 Jan 2020, pinskia at gcc dot gnu.org wrote: > I doubt GCC 9 is going to change. Indeed. The old approach was inconsistent with normal practice, as I said in commit fe2bc27cdb6d572da0163d77e787ba644b400753 (r276896, "Support _Decimal* keywords for C2x."): The _Decimal* keywords are marked with D_EXT, meaning they are not considered keywords at all in strict conformance modes. This is contrary to the normal practice for most implementation-namespace keywords, which are accepted in all standards modes but with appropriate pedwarns for older standards. This patch removes D_EXT from those keywords so they are accepted as keywords for all standards, consequently removing the gcc.dg/dfp/keywords-ignored-c99.c test that is no longer valid. But that's not the sort of change we make on past release branches.
[Bug target/91838] [8/9 Regression] incorrect use of shr and shrx to shift by 64, missed optimization of vector shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838 --- Comment #8 from Andrew Pinski --- (In reply to Tamar Christina from comment #7) > In file included from > /data/tamchr01/write-access/gcc-git/libgcc/unwind-dw2.c:403:0: > ./md-unwind-support.h: In function 'x86_64_fallback_frame_state': > ./md-unwind-support.h:65:47: error: dereferencing pointer to incomplete type > 'struct ucontext' >sc = (struct sigcontext *) (void *) _->uc_mcontext; > > and disabling libgcc doesn't get me very far because of the dependencies of > things on it. You must be using a too new glibc, g:883312dc79806f513275b72502231c751c14ff72 is what fixed libgcc to support newer glibc.
[Bug tree-optimization/93131] ((a&8) == 8) && ((a&2) == 2) is not optimized to (a&(8|2)) == (8|2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93131 --- Comment #20 from CVS Commits --- The master branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:6ccc19bd4d12379a0d9fce486ceba3207749424a commit r10-6213-g6ccc19bd4d12379a0d9fce486ceba3207749424a Author: Andrew Pinski Date: Sat Jan 11 20:34:24 2020 + Decrease cortexa57_extra_costs's alu.shift_reg Like I mentioned in https://gcc.gnu.org/ml/gcc/2020-01/msg00157.html, The shift by a register should be just COSTS_N_INSNS (1) rather than COSTS_N_INSNS (2). This allows lshift_cheap_p to return true now and converting switches to be using shift and other like structures. I noticed this difference when I was working through PR 93131 and understanding what reassoc could handle. ChangeLog: * config/arm/aarch-cost-tables.h (cortexa57_extra_costs): Change alu.shift_reg to 0.
[Bug fortran/93422] Bogus POINTER attribute mismatch with submodule MODULE PROCEDURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93422 --- Comment #1 from Andrew Benson --- Using a "result()" for the return value of the function allows this to compile successfully: module t type :: a contains procedure :: p => ap end type a type, extends(a) :: b contains procedure :: p => bp end type b type :: c end type c type, extends(c) :: d end type d interface module function bp(s) result(ss) class(b), intent(inout) :: s class(d), pointer :: ss end function end interface contains function ap(s) result(ss) class(d), pointer :: ss class(a), intent(inout) :: s end function ap end module t submodule (t) ts contains function bp(s) result(ss) class(d), pointer :: ss class(b), intent(inout) :: s end function bp end submodule ts
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 --- Comment #3 from Devin Hussey --- I think I found the culprit commit. Haven't set up a GCC build tree yet, though. https://github.com/gcc-mirror/gcc/commit/a51c4926712307787d133ba50af8c61393a9229b
[Bug c++/93299] [9 Regression] ICE in tsubst_copy, at cp/pt.c:15779
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93299 Marek Polacek changed: What|Removed |Added Summary|[9/10 Regression] ICE in|[9 Regression] ICE in |tsubst_copy, at |tsubst_copy, at |cp/pt.c:15779 |cp/pt.c:15779 --- Comment #7 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/93299] [9/10 Regression] ICE in tsubst_copy, at cp/pt.c:15779
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93299 --- Comment #6 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:d54a86cd92860e1108f43fae9329ccb0897f3e1d commit r10-6212-gd54a86cd92860e1108f43fae9329ccb0897f3e1d Author: Marek Polacek Date: Fri Jan 17 15:17:42 2020 -0500 c++: Fix ICE in tsubst_copy with parenthesized expression [PR93299] Since e4511ca2e9ecdb51d41b64452398f8e2df575668 force_paren_expr can create a VIEW_CONVERT_EXPR so that we have something to set REF_PARENTHESIZED_P on, while not making the expression dependent. But tsubst_copy can't cope with such a VIEW_CONVERT_EXPR, because it's not location_wrapper_p, or a TEMPLATE_PARM_INDEX wrapped in a VIEW_CONVERT_EXPR. I think we need to teach tsubst_copy how to handle it. Setting EXPR_LOCATION_WRAPPER_P in force_paren_expr would make the ICE go away too, but tsubst_copy would lose the REF_PARENTHESIZED_P flag. 2020-01-24 Marek Polacek PR c++/93299 - ICE in tsubst_copy with parenthesized expression. * pt.c (tsubst_copy): Handle a REF_PARENTHESIZED_P VIEW_CONVERT_EXPR. * g++.dg/cpp1y/paren5.C: New test.
[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316 --- Comment #16 from Iain Sandoe --- (In reply to Iain Sandoe from comment #15) > (In reply to David Edelsohn from comment #14) > > Compiler version: 10.0.1 20200124 (experimental) [src revision > > 96f7f2867f2:1b708f12f4b:5026cbde65e724347cc2d2797026bb7bb12578f1] (GCC) > > > > You can see https://gcc.gnu.org/ml/gcc-testresults/2020-01/msg01180.html > > Likewise on powerpc-darwin9 (32b host, PIC by default) I see the setjmp > case r10-6194 (but I will retest with all your changes in place). Oops, that was somewhat incoherent. https://gcc.gnu.org/ml/gcc-testresults/2020-01/msg01190.html in addition to the cases mentioned above (and which I will open new PRs for after re-running with all your current changes). on powerpc-darwin9 only, I still see the setjmp fails that David (E) is seeing on AIX.
[Bug lto/93166] [10 Regression] ICE in get_info_about_necessary_edges, at ipa-cp.c:4137 since r278893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93166 Jeffrey A. Law changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #6 from Jeffrey A. Law --- I've got state, so I'll take this as well.
[Bug c++/93279] [9/10 Regression] C++ Template substitution ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93279
--- Comment #6 from Marek Polacek ---
This passes dg.exp but I haven't convinced it's the right solution so haven't
posted it...
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -21849,8 +21849,12 @@ type_unification_real (tree tparms,
NULL_TREE);
if (!uses_template_parms (substed))
- arg = convert_template_argument (parm, substed, full_targs,
-complain, i, NULL_TREE);
+ {
+ ++processing_template_decl;
+ arg = convert_template_argument (parm, substed, full_targs,
+ complain, i, NULL_TREE);
+ --processing_template_decl;
+ }
else if (saw_undeduced == 1)
arg = NULL_TREE;
else
[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316 --- Comment #15 from Iain Sandoe --- (In reply to David Edelsohn from comment #14) > Compiler version: 10.0.1 20200124 (experimental) [src revision > 96f7f2867f2:1b708f12f4b:5026cbde65e724347cc2d2797026bb7bb12578f1] (GCC) > > You can see https://gcc.gnu.org/ml/gcc-testresults/2020-01/msg01180.html Likewise on powerpc-darwin9 (32b host, PIC by default) I see the setjmp case r10-6194 (but I will retest with all your changes in place).
[Bug tree-optimization/92788] [10 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92788 --- Comment #6 from Jeffrey A. Law --- We shouldn't have threaded this to begin with. I think I see what went wrong here.
[Bug c++/93279] [9/10 Regression] C++ Template substitution ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93279 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/93400] [10 Regression] ICE: in tsubst, at cp/pt.c:15142 on friends with concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93400 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-24 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug preprocessor/93419] __has_attribute(ifunc) false positive on hurd and kfreebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93419
--- Comment #5 from kloetzl ---
Sorry for missing out the details, here goes:
I work in a Debian Hurd 20290705 image using qemu. The example file is given
above. Compiling with `gcc -Wall -Wextra ifunc.c` produces the following error.
error: ifunc is not supported on this target
int fn(void) __attribute((ifunc("fn_select")));
The output of gcc -v is (may contain typos)
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-gnu/8/lto-wrapper
Target: i686-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-7'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8 --program-prefix=i686-gnu-
--enable-shared --enable-linker-build-id --libexecdir=/usr/lib
--without-include-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --disable-libitm --disable-libsanitizer
--enable-plugin --enable-default-pie --with-system-zlib --disable-libphobos
--enable-multiarch --disable-werror --with-arch=i586 --with-tune=generic
--enable-checking=release --build=i686-gnu --host-i686-gnu --target=i686-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-7)
So it is not 9.0 as I first thought.
Hope this helps.
[Bug tree-optimization/92788] [10 Regression] ICE in redirect_eh_edge_1, at tree-eh.c:2313
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92788 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #5 from Jeffrey A. Law --- Given this mess is my code, I'll take it.
[Bug c++/93425] Template parameter deduction failure when template parameters have template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93425 --- Comment #1 from andysem at mail dot ru --- Also, the compilation succeeds if I explicitly specify the NumberT template parameter at the call site.
[Bug c++/93377] [10 Regression] ICE in tsubst_pack_expansion, at cp/pt.c:12852
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93377 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/92852] [8/9/10 Regression] location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92852 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jason Merrill --- Fixed for 8.4/9.3/10.
[Bug c++/93425] New: Template parameter deduction failure when template parameters have template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93425
Bug ID: 93425
Summary: Template parameter deduction failure when template
parameters have template template parameter
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andysem at mail dot ru
Target Milestone: ---
The following code fails to compile:
template< typename T >
struct plus {};
template< typename Q >
struct test
{
template< template< typename > class BinaryFunT, typename NumberT >
static void test_impl(NumberT n)
{
}
static void test_arith()
{
test_impl< plus >(10);
}
};
$ g++ -O3 -c -o test.o test.cpp
test.cpp: In static member function ‘static void test::test_arith()’:
test.cpp:14:29: error: no matching function for call to
‘test::test_impl(int)’
14 | test_impl< plus >(10);
| ^
test.cpp:8:17: note: candidate: ‘template
template class BinaryFunT, class NumberT>
template template class BinaryFunT, class NumberT> static void
test::test_impl(NumberT)’
8 | static void test_impl(NumberT n)
| ^
test.cpp:8:17: note: template argument deduction/substitution failed:
test.cpp:14:29: note: mismatched types ‘NumberT’ and ‘int’
14 | test_impl< plus >(10);
| ^
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.2.1-9ubuntu2'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--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 --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.2.1 20191008 (Ubuntu 9.2.1-9ubuntu2)
The same code compiles fine with gcc 8.3.0 and clang 9. Compilation succeeds if
I remove the template template parameter from test_impl definition and
invokation.
Note also how gcc 9 messes up the template parameters lists in the error
message. If this is an unrelated problem, let me know if I should file a
separate bug to fix this.
[Bug c++/92852] [8/9/10 Regression] location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92852 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a4b7cf5865823df4b4df1d840d692dfc83fd0672 commit r9-8175-ga4b7cf5865823df4b4df1d840d692dfc83fd0672 Author: Jason Merrill Date: Thu Jan 23 15:45:36 2020 -0500 c++: Unshare expressions from constexpr cache. Another place we need to unshare cached expressions. PR c++/92852 - ICE with generic lambda and reference var. * constexpr.c (maybe_constant_value): Likewise.
[Bug c++/92778] [8/9 regression] ICE: Illegal instruction signal terminated program cc1plus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92778 --- Comment #6 from Hannes Hauswedell --- Ok, the ICE on Linux is a different one. This particular ICE happens only on FreeBSD. I have rebuilt GCC9 from source with fullbootstrap and without any -march settings. The problem remains. What can I do to further narrow this down?
[Bug c++/92852] [8/9/10 Regression] location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92852 --- Comment #8 from CVS Commits --- The releases/gcc-8 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:7175893ad8010df1270af884a1810476e51a8cd9 commit r8-9953-g7175893ad8010df1270af884a1810476e51a8cd9 Author: Jason Merrill Date: Thu Jan 23 15:45:36 2020 -0500 c++: Unshare expressions from constexpr cache. Another place we need to unshare cached expressions. PR c++/92852 - ICE with generic lambda and reference var. * constexpr.c (maybe_constant_value): Likewise.
[Bug rtl-optimization/90275] [8/9/10 Regression] ICE: in insert_regs, at cse.c:1128 with -O2 -fno-dce -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90275 --- Comment #6 from David Binderman --- I can confirm this is still going wrong in a raspberry pi cross compiler dated 20200123.
[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316 --- Comment #14 from David Edelsohn --- Compiler version: 10.0.1 20200124 (experimental) [src revision 96f7f2867f2:1b708f12f4b:5026cbde65e724347cc2d2797026bb7bb12578f1] (GCC) You can see https://gcc.gnu.org/ml/gcc-testresults/2020-01/msg01180.html
[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316 --- Comment #13 from David Malcolm --- (In reply to David Malcolm from comment #12) > (In reply to David Edelsohn from comment #11) > > I continue to see setjmp failures on AIX. > > > [...] > > FAIL: gcc.dg/analyzer/setjmp-8.c (internal compiler error) > > during IPA pass: analyzer > > /nasfarm/edelsohn/src/src/gcc/testsuite/gcc.dg/analyzer/setjmp-8.c:15:3: > > interna > > l compiler error: in as_a, at is-a.h:197 > >NN | longjmp (env, 0); > > | ^~~~ > > ranges offset out of range > > David, which version are you testing? This looks reminiscent of PR 93378, > which I fixed in r10-6154-g597e403d6dbb44315f33fb2b5bb0ca4946a4a1e1. Well, r10-6153-gfd9982bb0051d1a678191b684bb907d1ac177991 (that other commit is a fix for me messing up the testcase)
[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316 --- Comment #12 from David Malcolm --- (In reply to David Edelsohn from comment #11) > I continue to see setjmp failures on AIX. > [...] > FAIL: gcc.dg/analyzer/setjmp-8.c (internal compiler error) > during IPA pass: analyzer > /nasfarm/edelsohn/src/src/gcc/testsuite/gcc.dg/analyzer/setjmp-8.c:15:3: > interna > l compiler error: in as_a, at is-a.h:197 >NN | longjmp (env, 0); > | ^~~~ > ranges offset out of range David, which version are you testing? This looks reminiscent of PR 93378, which I fixed in r10-6154-g597e403d6dbb44315f33fb2b5bb0ca4946a4a1e1.
[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316
--- Comment #11 from David Edelsohn ---
I continue to see setjmp failures on AIX.
FAIL: gcc.dg/analyzer/setjmp-7a.c expected multiline pattern lines 41-110 not
found:
FAIL: gcc.dg/analyzer/setjmp-7a.c (test for excess errors)
Excess errors:
NN | longjmp (env, 1); /* { dg-warning "leak of 'ptr'" } */
FAIL: gcc.dg/analyzer/setjmp-8.c (internal compiler error)
FAIL: gcc.dg/analyzer/setjmp-8.c (test for warnings, line 29)
FAIL: gcc.dg/analyzer/setjmp-8.c expected multiline pattern lines 40-108 not
found:
FAIL: gcc.dg/analyzer/setjmp-8.c (test for excess errors)
Excess errors:
during IPA pass: analyzer
/nasfarm/edelsohn/src/src/gcc/testsuite/gcc.dg/analyzer/setjmp-8.c:15:3:
interna
l compiler error: in as_a, at is-a.h:197
NN | longjmp (env, 0);
| ^~~~
ranges offset out of range
FAIL: gcc.dg/analyzer/setjmp-9.c (internal compiler error)
FAIL: gcc.dg/analyzer/setjmp-9.c (test for warnings, line 31)
FAIL: gcc.dg/analyzer/setjmp-9.c expected multiline pattern lines 42-110 not
found:
FAIL: gcc.dg/analyzer/setjmp-9.c (test for excess errors)
Excess errors:
during IPA pass: analyzer
/nasfarm/edelsohn/src/src/gcc/testsuite/gcc.dg/analyzer/setjmp-9.c:17:3:
interna
l compiler error: in as_a, at is-a.h:197
NN | longjmp (env, unknown_val);
| ^~
ranges offset out of range
FAIL: gcc.dg/analyzer/setjmp-3.c (internal compiler error)
FAIL: gcc.dg/analyzer/setjmp-3.c (test for warnings, line 28)
FAIL: gcc.dg/analyzer/setjmp-3.c expected multiline pattern lines 39-107 not
found:
FAIL: gcc.dg/analyzer/setjmp-3.c (test for excess errors)
Excess errors:
during IPA pass: analyzer
/nasfarm/edelsohn/src/src/gcc/testsuite/gcc.dg/analyzer/setjmp-3.c:14:3:
interna
l compiler error: in as_a, at is-a.h:197
NN | longjmp (env, 1);
| ^~~~
ranges offset out of range
FAIL: gcc.dg/analyzer/setjmp-4.c (internal compiler error)
FAIL: gcc.dg/analyzer/setjmp-4.c (test for warnings, line 29)
FAIL: gcc.dg/analyzer/setjmp-4.c expected multiline pattern lines 34-107 not
found:
FAIL: gcc.dg/analyzer/setjmp-4.c (test for excess errors)
Excess errors:
during IPA pass: analyzer
/nasfarm/edelsohn/src/src/gcc/testsuite/gcc.dg/analyzer/setjmp-4.c:12:3:
interna
l compiler error: in as_a, at is-a.h:197
NN | foo (x);
| ^~~
ranges offset out of range
[Bug fortran/93424] ICE on valid with pointer result from submodule function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93424 --- Comment #1 from Andrew Benson --- Correction: The above code is valid (not invalid as I stated in the description) as far as I can tell.
[Bug fortran/93424] New: ICE on valid with pointer result from submodule function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93424 Bug ID: 93424 Summary: ICE on valid with pointer result from submodule function Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com Target Milestone: --- The following invalid code results in an ICE (using git commit 472dc648ce3e7661762931d584d239611ddca964): module t type :: a contains procedure :: p => ap end type a type, extends(a) :: b contains procedure :: p => bp end type b type :: c end type c interface module function bp(s) class(b), intent(inout) :: s class(c), pointer :: bp end function end interface contains function ap(s) class(a), intent(inout) :: s class(c), pointer :: ap end function ap end module t submodule (t) ts contains function bp(s) class(b), intent(inout) :: s class(c), pointer :: bp end function bp end submodule ts $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.0.1 20200124 (experimental) (GCC) $ gfortran -c test3.mod.F90 -o test3.mod.o f951: internal compiler error: Segmentation fault 0xe1b2bf crash_signal ../../gcc-git/gcc/toplev.c:328 0x7fc2247331ef ??? /data001/abenson/Galacticus/Tools/glibc-2.12.1/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0 0x80cc31 compare_rank ../../gcc-git/gcc/fortran/interface.c:776 0x80cc31 compare_rank ../../gcc-git/gcc/fortran/interface.c:766 0x80ef55 gfc_check_result_characteristics(gfc_symbol*, gfc_symbol*, char*, int) ../../gcc-git/gcc/fortran/interface.c:1556 0x814ae2 gfc_check_typebound_override(gfc_symtree*, gfc_symtree*) ../../gcc-git/gcc/fortran/interface.c:4799 0x86fd0d resolve_typebound_procedure ../../gcc-git/gcc/fortran/resolve.c:14002 0x8a0769 do_traverse_symtree ../../gcc-git/gcc/fortran/symbol.c:4178 0x8785bc resolve_typebound_procedures ../../gcc-git/gcc/fortran/resolve.c:14053 0x8785bc resolve_fl_derived ../../gcc-git/gcc/fortran/resolve.c:14829 0x8751a7 resolve_symbol ../../gcc-git/gcc/fortran/resolve.c:15199 0x8a0722 do_traverse_symtree ../../gcc-git/gcc/fortran/symbol.c:4172 0x882893 resolve_types ../../gcc-git/gcc/fortran/resolve.c:17123 0x8741fc gfc_resolve(gfc_namespace*) ../../gcc-git/gcc/fortran/resolve.c:17238 0x8741fc gfc_resolve(gfc_namespace*) ../../gcc-git/gcc/fortran/resolve.c:17219 0x8670b7 gfc_parse_file() ../../gcc-git/gcc/fortran/parse.c:6446 0x8b756f gfc_be_parse_file ../../gcc-git/gcc/fortran/f95-lang.c:210 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions.
[Bug fortran/93423] New: ICE on invalid with argument list for module procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93423 Bug ID: 93423 Summary: ICE on invalid with argument list for module procedure Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com Target Milestone: --- The following invalid code results in an ICE (using git commit 472dc648ce3e7661762931d584d239611ddca964): module t type :: b contains procedure :: p => bp end type b interface module function bp(s) class(b), intent(inout) :: s integer, pointer :: bp end function end interface end module t submodule (t) ts contains module procedure bp(s) end procedure bp end submodule ts $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.0.1 20200124 (experimental) (GCC) $ gfortran -c test2.mod.F90 -o test2.mod.o test2.mod.F90:21:19: 21 | module procedure bp(s) | 1 Error: MODULE PROCEDURE at (1) must be in a generic module interface test2.mod.F90:22:5: 22 | end procedure bp | 1 Error: Expecting END SUBMODULE statement at (1) *** glibc detected *** /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951: free(): invalid pointer: 0x03e2fa70 *** === Backtrace: = /home/abenson/Galacticus/Tools/lib/libc.so.6(+0x71776)[0x7fe72592a776] /home/abenson/Galacticus/Tools/lib/libc.so.6(cfree+0x6c)[0x7fe72592f49c] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x8a6b4e] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x8a6c59] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x8a6276] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x8a6630] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951(_Z17gfc_symbol_done_2v+0x54)[0x8a8314] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951(_Z10gfc_done_2v+0x9)[0x83e559] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x85a9a4] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951(_Z14gfc_parse_filev+0xa14)[0x8675d4] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x8b7570] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0xe1b484] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951(_ZN6toplev4mainEiPPc+0x7ad)[0xe1db0d] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951(main+0x2f)[0x183b47f] /home/abenson/Galacticus/Tools/lib/libc.so.6(__libc_start_main+0xfd)[0x7fe7258d7d0d] /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951[0x7c5f21] === Memory map: 0040-025c3000 r-xp 09:06 39587037 /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951 027c3000-027d3000 rw-p 021c3000 09:06 39587037 /home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/f951 027d3000-0292d000 rw-p 00:00 0 03d87000-03e4a000 rw-p 00:00 0 [heap] 3c4540-3c4542 r-xp 09:01 1703950 /lib64/ld-2.12.so 3c4561f000-3c4562 r--p 0001f000 09:01 1703950 /lib64/ld-2.12.so 3c4562-3c45621000 rw-p 0002 09:01 1703950 /lib64/ld-2.12.so 3c45621000-3c45622000 rw-p 00:00 0 7fe72000-7fe720021000 rw-p 00:00 0 7fe720021000-7fe72400 ---p 00:00 0 7fe725347000-7fe72535e000 r-xp 09:06 38928531 /home/abenson/Galacticus/Tools/lib64/libgcc_s.so.1 7fe72535e000-7fe72555d000 ---p 00017000 09:06 38928531 /home/abenson/Galacticus/Tools/lib64/libgcc_s.so.1 7fe72555d000-7fe72555e000 rw-p 00016000 09:06 38928531 /home/abenson/Galacticus/Tools/lib64/libgcc_s.so.1 7fe72555e000-7fe7258b9000 rw-p 00:00 0 7fe7258b9000-7fe725a18000 r-xp 09:06 36448328 /home/abenson/Galacticus/Tools/lib/libc-2.12.1.so 7fe725a18000-7fe725c18000 ---p 0015f000 09:06 36448328 /home/abenson/Galacticus/Tools/lib/libc-2.12.1.so 7fe725c18000-7fe725c1c000 r--p 0015f000 09:06 36448328 /home/abenson/Galacticus/Tools/lib/libc-2.12.1.so 7fe725c1c000-7fe725c1d000 rw-p 00163000 09:06 36448328 /home/abenson/Galacticus/Tools/lib/libc-2.1
[Bug fortran/93422] New: Bogus POINTER attribute mismatch with submodule MODULE PROCEDURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93422 Bug ID: 93422 Summary: Bogus POINTER attribute mismatch with submodule MODULE PROCEDURE Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abensonca at gmail dot com Target Milestone: --- The following code results in a bogus error (using git commit 472dc648ce3e7661762931d584d239611ddca964) claiming a pointer attribute mismatch between the function result as defined in the module and submodule: module t type :: a contains procedure :: p => ap end type a type, extends(a) :: b contains procedure :: p => bp end type b type :: c end type c type, extends(c) :: d end type d interface module function bp(s) class(b), intent(inout) :: s class(d), pointer :: bp end function end interface contains function ap(s) class(a), intent(inout) :: s class(d), pointer :: ap end function ap end module t submodule (t) ts contains function bp(s) class(d), pointer :: bp class(b), intent(inout) :: s end function bp end submodule ts $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-git/configure --prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --disable-multilib Thread model: posix Supported LTO compression algorithms: zlib gcc version 10.0.1 20200124 (experimental) (GCC) $ gfortran -c test4.mod.F90 -o test4.mod.o test4.mod.F90:35:12: 35 | submodule (t) ts |1 Error: Result mismatch for the overriding procedure 'p' at (1): POINTER attribute mismatch in function result test4.mod.F90:39:2: 39 | function bp(s) | 1 Error: POINTER attribute mismatch in function result between the MODULE PROCEDURE declaration in MODULE 't' and the declaration at (1) in (SUB)MODULE 'ts' The code compiles successfully if the "pointer" attribute is removed, or if the function in the submodule is declared using the "module procedure" approach instead of explicitly (re)defining its interface. It also compiles successfully using ifort 18.0.1.
[Bug c++/92852] [8/9/10 Regression] location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92852 --- Comment #7 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:28a5d5c365044710ba32510b9bec67dd40562154 commit r10-6210-g28a5d5c365044710ba32510b9bec67dd40562154 Author: Jason Merrill Date: Thu Jan 23 15:45:36 2020 -0500 c++: Unshare expressions from constexpr cache. Another place we need to unshare cached expressions. PR c++/92852 - ICE with generic lambda and reference var. * constexpr.c (maybe_constant_value): Likewise.
[Bug libstdc++/93421] futex.cc use of futex syscall is not time64-compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93421 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-24 Ever confirmed|0 |1
[Bug tree-optimization/91470] [10 Regression] bogus uninitialized warning in trans-intrinsic.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91470 Jeffrey A. Law changed: What|Removed |Added Target Milestone|10.0|11.0 --- Comment #4 from Jeffrey A. Law --- Yes, the loop PHI is where things start, but the PHI in the latch block is just as problematical it not more. It's the use in the latch PHI that uninit.c considers unguarded. We could duplicate the latch block (thus creating two backedges to the top of the loop). Of course this mucks up the loop structures to some degree, so it's not a great solution. We could unroll the loop which ought to untangle things enough, but that's a codesize regression and just twiddling the loop bounds would be enough to bring the warning back, so I consider this a non-starter. Peeling the first iteration has the same effect as unrolling on this specific test and I think would resolve it. Peeling the first iteration would also work if the loop bounds were different. Jump threading often has the same effect as peeling off an iteration. DOM3 discovers the opportunity, but doesn't actually thread the jump presumably because doing so will muck up the loop structure. I looked at Bin's recent work hoping it might be enough to help uninit.c realize the use is guarded, but it isn't. It may be extendable to handle this case though. Unsure. Given we don't really have a viable path forward yet, I'm going to punt this to 11.
[Bug libstdc++/93421] New: futex.cc use of futex syscall is not time64-compatible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93421 Bug ID: 93421 Summary: futex.cc use of futex syscall is not time64-compatible Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: bugdal at aerifal dot cx Target Milestone: --- Created attachment 47704 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47704=edit simple fix, not necessarily right for upstream This code directly passes a userspace timespec struct to the SYS_futex syscall, which does not work if the userspace type is 64-bit but the syscall expects legacy 32-bit timespec. I'm attaching the patch we're using in musl-cross-make to fix this. It does not attempt to use the SYS_futex_time64 syscall, since that would require fallback logic with cost tradeoffs for which to try first, and since the timeout is relative and therefore doesn't even need to be 64-bit. Instead it just uses the existence of SYS_futex_time64 to infer that the plain SYS_futex uses a pair of longs, and converts the relative timestamp into that. This assumes that any system where the libc timespec type has been changed for time64 will also have had its headers updated to define SYS_futex_time64. Error handling for extreme out-of-bound values should probably be added.
[Bug preprocessor/93419] __has_attribute(ifunc) false positive on hurd and kfreebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93419 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #4 from Martin Sebor --- What does the build failure look like? Quoting from What we need in https://gcc.gnu.org/bugs: Please include all of the following items, the first three of which can be obtained from the output of gcc -v: ... the compiler output (error messages, warnings, etc.); and
[Bug c++/93279] [9/10 Regression] C++ Template substitution ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93279 --- Comment #5 from Marek Polacek --- Since r9-6405-gbddee796d0b4800b5ac3d7e7e9e315c23799424d, when we see in a lambda a use of an operator that might be overloaded, we do name lookup and save it away in an internal attribute on the lambda call operator. Here we have a (generic) lambda and the * operator, so we stash operator* -> OVERLOAD [template_decl] into the attribute. Then push_operator_bindings pushes it to the function parameter binding level using push_local_binding. When we instantiate_decl the function operator* we end up substituting the m * l expr. Then build_x_binary_op builds it, it calls build_new_op_1 which will invoke add_operator_candidates. That will add the operator* TEMPLATE_DECL stashed above into the candidate set. It's a template and we try to deduce the template arguments in fn_type_unification. We have a template parameter of type B::f, and we will tsubst its template arguments = E. This will wind up lookup_template_class (E, ) which calls coerce_template_parms. So we convert_template_argument: #3 0x009a0fdf in maybe_constant_value (t=, decl=, manifestly_const_eval=true) at /home/mpolacek/src/gcc/gcc/cp/constexpr.c:6596 #4 0x00bad57a in convert_nontype_argument (type=, expr=, complain=0) at /home/mpolacek/src/gcc/gcc/cp/pt.c:7116 #5 0x00bb1cc8 in convert_template_argument (parm=, arg=, args=, complain=0, i=1, in_decl=) at /home/mpolacek/src/gcc/gcc/cp/pt.c:8350 And so maybe_constant_value gets a template_parm_index. But processing_template_decl is 0 so this check if (!is_nondependent_constant_expression (t)) in maybe_constant_value won't work: value_dependent_expression_p always returns false when !processing_template_decl. So the template_parm_index winds up going to the constexpr machinery and that ICEs. I would think we need ++processing_template_decl; ... --processing_template_decl; somewhere, but can't find the right spot.
[Bug analyzer/93349] ICE: verify_gimple failed (error: location references block not in block tree)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93349 --- Comment #3 from David Malcolm --- Candidate patch: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01673.html
[Bug c++/93420] New: Deducing "T C::* const&" from a non-const pointer-to-member-function fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93420
Bug ID: 93420
Summary: Deducing "T C::* const&" from a non-const
pointer-to-member-function fails
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
struct S {};
template
void check(T C::* const&);
int (S::*f)();
using t = decltype(check(f));
Rejected by GCC:
:8:27: error: no matching function for call to 'check(int (S::*&)())'
8 | using t = decltype(check(f));
| ^
:4:6: note: candidate: 'template void check(T C::*
const&)'
4 | void check(T C::* const&);
| ^
:4:6: note: template argument deduction/substitution failed:
:8:27: note: types 'T C::* const' and 'int (S::*)()' have
incompatible cv-qualifiers
8 | using t = decltype(check(f));
| ^
This appears to be the cause of PR69243, which was worked around in the
library.
[Bug preprocessor/93419] __has_attribute(ifunc) false positive on hurd and kfreebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93419 --- Comment #3 from kloetzl --- Hm, I feared that this would be the answer I would get. This makes GCCs __has_attribute much less useful than Clangs version where the docs state: “This function-like macro takes a single identifier argument that is the name of a GNU-style attribute. It evaluates to 1 if the attribute is supported by the current compilation target, or 0 if not.”
[Bug target/13721] SEGV on inline-asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13721 Jeffrey A. Law changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #13 from Jeffrey A. Law --- Yes, using output_operand_lossage was the right thing to do here. I've done that in the most obvious places where we called byte_reg.
[Bug preprocessor/93419] __has_attribute(ifunc) false positive on hurd and kfreebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93419 --- Comment #2 from Andrew Pinski --- I think the docs are clear here too: The special operator __has_attribute (operand) may be used in ‘#if’ and ‘#elif’ expressions to test whether the attribute referenced by its operand is recognized by GCC. CUT --- __has_attribute just says GCC recognizes the attribute which is true, ifunc is recognized and is basically supported inside gcc until the very end of the compiler. So I want to say this is an invalid bug report ...
[Bug target/13721] SEGV on inline-asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13721 --- Comment #12 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:64c9f2d9972ad359a32f0a97ee0a806c2532db15 commit r10-6207-g64c9f2d9972ad359a32f0a97ee0a806c2532db15 Author: Jeff Law Date: Fri Jan 24 08:57:46 2020 -0700 Emit reasonable diagnostic rather than ICE on invalid ASM on H8 port PR target/13721 * config/h8300/h8300.c (h8300_print_operand): Only call byte_reg for REGs. Call output_operand_lossage to get more reasonable diagnostics. PR target/13721 * gcc.target/h8300/pr13721.c: New test.
[Bug preprocessor/93419] __has_attribute(ifunc) false positive on hurd and kfreebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93419 --- Comment #1 from Andrew Pinski --- __has_attribute(ifunc) is true as the attribute is supported all the way through the compiler up to the point where it gets emitted. Really __has_attribute is a bad execuse for not doing proper feature testing in my mine.
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 --- Comment #2 from Andrew Pinski --- The bug is most likely inside ix86_fold_builtin.
[Bug preprocessor/93419] New: __has_attribute(ifunc) false positive on hurd and kfreebsd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93419
Bug ID: 93419
Summary: __has_attribute(ifunc) false positive on hurd and
kfreebsd
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: fabian-gcc at kloetzl dot info
Target Milestone: ---
Hi all,
Hereby I am forwarding a bug I filed against Debian [1]. One of my packages
there failed to build on hurd-i386 and kfreebsd-* due to unsupported ifuncs.
However, I had that code guarded by __has_attribute(ifunc) which,
unfortunately, evaluates to 1 on said platforms. A minimal testcase is given
below.
Best,
Fabian
1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945133
-
#include
int main() {
return 0;
}
#if __has_attribute(ifunc)
typedef void (fntype)(void);
fntype* fn_select(void) {
return NULL;
}
void fn(void) __attribute__((ifunc("fn_select")));
#endif
[Bug target/93418] [9/10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-01-24
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
From .ccp1:
Visiting statement:
_17 = VIEW_CONVERT_EXPR(shifts_13);
which is likely CONSTANT
Match-and-simplified VIEW_CONVERT_EXPR(shifts_13) to { 16, 31,
-34, 3 }
Lattice value changed to CONSTANT { 16, 31, -34, 3 }. Adding SSA edges to
worklist.
marking stmt to be not simulated again
Visiting statement:
_18 = VIEW_CONVERT_EXPR(vals_11);
which is likely CONSTANT
Match-and-simplified VIEW_CONVERT_EXPR(vals_11) to { -1, -1, -1,
-1 }
Lattice value changed to CONSTANT { -1, -1, -1, -1 }. Adding SSA edges to
worklist.
marking stmt to be not simulated again
Visiting statement:
_19 = __builtin_ia32_psllv4si (_18, _17);
which is likely CONSTANT
Lattice value changed to CONSTANT { -65536, -65536, -65536, -65536 }. Adding
SSA edges to worklist.
marking stmt to be not simulated again
[Bug fortran/93365] ICE in match_data_constant, at fortran/decl.c:426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93365 --- Comment #6 from Steve Kargl --- On Fri, Jan 24, 2020 at 12:36:45PM +, markeggleston at gcc dot gnu.org wrote: > gfc_simplify_expr calls simplify_parameter_variable which for zero size > arrays it creates a new gfc_expr structure with the expr_type set to > EXPR_ARRAY > and replaces primary. When primary is replaced its chain of ref structures is > deleted so tmp->u.i is invalid causing the ICE the following lines are never > reached: The lines are reached in my debugging sessions. :-) I bootstrap with --enable-checking, which might prevent the ICE issue. > > then enters the switch statement and get to lines 2384-2385 > > > >primary->ts.type = BT_INTEGER; > >primary->ts.kind = gfc_default_integer_kind; > > > > This just resets a part of primary, but it does not fix up > > it up correctly. Likely, need to check for zero size > > arrays do extra work. > > I have modified gfc_simplify_expr: I'm beginning to think that calling gfc_simplify_expr may not be correct, here. But, don't have time to investigate more.
[Bug target/93418] [10 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418 Andrew Pinski changed: What|Removed |Added Component|regression |target Target Milestone|--- |10.0 Summary|GCC incorrectly constant|[10 Regression] GCC |propagates |incorrectly constant |_mm_sllv/srlv/srav |propagates ||_mm_sllv/srlv/srav
[Bug regression/93418] New: GCC incorrectly constant propagates _mm_sllv/srlv/srav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418
Bug ID: 93418
Summary: GCC incorrectly constant propagates _mm_sllv/srlv/srav
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: husseydevin at gmail dot com
Target Milestone: ---
Regression starting in GCC 9
Currently, GCC constant propagates the AVX2 _mm_sllv family with constant
amounts to only shift by the first element instead of all elements
individually.
#include
#include
// force -O0
__attribute__((__optimize__("-O0")))
void unoptimized() {
__m128i vals = _mm_set1_epi32(0x);
__m128i shifts = _mm_setr_epi32(16, 31, -34, 3);
__m128i shifted = _mm_sllv_epi32(vals, shifts);
printf("%08x %08x %08x %08x\n", _mm_extract_epi32(shifted, 0),
_mm_extract_epi32(shifted, 1), _mm_extract_epi32(shifted, 2),
_mm_extract_epi32(shifted, 3));
}
// force -O3
__attribute__((__optimize__("-O3")))
void optimized() {
__m128i vals = _mm_set1_epi32(0x);
__m128i shifts = _mm_setr_epi32(16, 31, -34, 3);
__m128i shifted = _mm_sllv_epi32(vals, shifts);
printf("%08x %08x %08x %08x\n", _mm_extract_epi32(shifted, 0),
_mm_extract_epi32(shifted, 1), _mm_extract_epi32(shifted, 2),
_mm_extract_epi32(shifted, 3));
}
int main() {
printf("Without optimizations (correct result):\t");
unoptimized();
printf("With optimizations (incorrect result):\t");
optimized();
}
I would expect this code to emit the following:
Without optimizations (correct result): 8000 fff8
With optimizations (incorrect result): 8000 fff8
Clang and GCC < 9 exhibit the first output, but 9.1 and later
However, I get this output on GCC 9 and later:
Without optimizations (correct result): 8000 fff8
With optimizations (incorrect result):
Godbolt link: https://gcc.godbolt.org/z/oC3Psp
[Bug target/93177] PPC: Missing many useful platform intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177 --- Comment #14 from Matt Emmerton --- I'd like to thank everyone for the great discussion so far. Here's a summary of where we are at this point. 1) sync intrinsics Useful, but with caveats. 2) cache prefetch intrinsics Implemented via __builtin_prefetch() 3) larx/stcx intrinsics Useful, but with caveats. Improvements to stcx CR handling, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93417 4) streaming cache prefetch intrinsics See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93408
[Bug target/93417] New: PPC: Support the "Flag Output Operands" so inline-asm can avoid having to copy CRx to GPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93417 Bug ID: 93417 Summary: PPC: Support the "Flag Output Operands" so inline-asm can avoid having to copy CRx to GPR Product: gcc Version: 8.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: memmerto at ca dot ibm.com Target Milestone: --- From https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93177 > If PowerPC back-end supported the "Flag Output Operands" part > if GCC's inline-asm, you could use that to do the correct thing. > But sadly PowerPC does not currently. > > https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Flag-Output-Operands
[Bug bootstrap/93416] New: [10 Regression] ICE in in tree_cmp, at analyzer/region-model.cc:1851 on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93416 Bug ID: 93416 Summary: [10 Regression] ICE in in tree_cmp, at analyzer/region-model.cc:1851 on s390x-linux-gnu Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: doko at ubuntu dot com Target Milestone: --- seen with 20200124 on s390x-linux-gnu. It tells it cannot be reproduced, but I see it repeatedly. gcc configured with Configured with: -v --enable-languages=c,c++,go,d,fortran,objc,obj-c++ --prefix=/usr/lib/gcc-snapshot --with-gcc-major-version-only --program-prefix= --enable-shared --enable-linker-build-id --disable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch=z196 --with-long-double-128 --enable-multilib --enable-checking=yes --build=s390x-linux-gnu --host=s390x-linux-gnu --target=s390x-linux-gnu [...] echo timestamp > s-macro_list /<>/build/./gcc/xgcc -B/<>/build/./gcc/ -xc -nostdinc /dev/null -S -o /dev/null -fself-test=../../src/gcc/testsuite/selftests cc1: internal compiler error: in tree_cmp, at analyzer/region-model.cc:1851 /<>/build/./gcc/xgcc -B/<>/build/./gcc/ -xc++ -nostdinc /dev/null -S -o /dev/null -fself-test=../../src/gcc/testsuite/selftests 0x3ffa06ab3a5 __libc_start_main /build/glibc-MXXdq1/glibc-2.29/csu/libc-start.c:308 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. cc1plus: internal compiler error: in tree_cmp, at analyzer/region-model.cc:1851 0x3ff848ab3a5 __libc_start_main /build/glibc-MXXdq1/glibc-2.29/csu/libc-start.c:308 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. The bug is not reproducible, so it is likely a hardware or OS problem. make[5]: *** [../../src/gcc/c/Make-lang.in:124: s-selftest-c] Error 1 make[5]: *** Waiting for unfinished jobs The bug is not reproducible, so it is likely a hardware or OS problem. make[5]: *** [../../src/gcc/cp/Make-lang.in:178: s-selftest-c++] Error 1 rm gcov.pod fsf-funding.pod lto-dump.pod gfdl.pod gpl.pod cpp.pod gccgo.pod gcc.pod gdc.pod gcov-dump.pod gfortran.pod gcov-tool.pod make[5]: Leaving directory '/<>/build/gcc' make[4]: *** [Makefile:4746: all-stage2-gcc] Error 2 make[4]: Leaving directory '/<>/build' make[3]: *** [Makefile:24566: stage2-bubble] Error 2 make[3]: Leaving directory '/<>/build' make[2]: *** [Makefile:24770: bootstrap] Error 2 make[2]: Leaving directory '/<>/build'
[Bug c/91113] add declare_simd_variant attribute support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91113 nsz at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from nsz at gcc dot gnu.org --- i think this will have to be done differently (the attribute syntax).
[Bug c++/93414] Bad diagnostics for dynamic_cast during constant evaluation: implementation details leak out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93414 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-01-24 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Mine. Users weren't supposed to see that message.
[Bug bootstrap/93409] [10 Regression] gcn libgomp plugin fails to build for x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93409 --- Comment #3 from Matthias Klose --- this is needed for the bootstrap, you have to build the plugin for all multilibs, although it's discarded on install.
[Bug c++/93415] New: Previous declaration of template without default arguments leads to incorrect overload resolution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93415
Bug ID: 93415
Summary: Previous declaration of template without default
arguments leads to incorrect overload resolution
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Predelnik at gmail dot com
Target Milestone: ---
#include
template
void f (int);
template
void f (int)
{
std::cout << "correct - int\n";
}
template
void f (char)
{
std::cout << "wrong - char\n";
}
int main ()
{
f (0);
return 0;
}
The above program prints "wrong - char" with gcc, however just removing
declartion of `f` without default arguments leads to expected result. It is
very annoying issue because do-nothing forward declarations may lead to
unexpected hard to find bugs. Other compilers seem to handle this case
properly.
[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316 --- Comment #10 from David Malcolm --- (In reply to David Malcolm from comment #9) > (In reply to Iain Sandoe from comment #8) [...] > I haven't seen failures before. ^ "these failures", I meant to say [...] > > > > Do you want me to re-open this or open one or more new ones? > > Please open a new one for the malloc-1.c issue. ..."and for any other new ones", I meant to say Thanks
[Bug c++/93414] New: Bad diagnostics for dynamic_cast during constant evaluation: implementation details leak out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93414
Bug ID: 93414
Summary: Bad diagnostics for dynamic_cast during constant
evaluation: implementation details leak out
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the example that attempts to throw a std::bad_cast:
struct Base {
constexpr virtual ~Base(){}
};
struct Derived: Base {
constexpr ~Derived(){}
};
constexpr const Derived& cast(const Base& b) {
return dynamic_cast(b); // error!
}
auto test() {
static constexpr Base b;
constexpr auto res = cast(b);
return res;
}
The error message is following:
: In function 'constexpr const Derived& cast(const Base&)':
:10:42: error: call to non-'constexpr' function 'void*
__cxa_bad_cast()'
10 | return dynamic_cast(b); // error: call to
non-'constexpr' function 'void* __cxa_bad_cast()'
That's not informative: users usually know nothing about __cxa_bad_cast
Please change the error message to something more informative, for example
"During constexpr evaluation attempt to cast a variable `b` with typeid(b) ==
typeid(Base) to `Derived` was detected"
[Bug analyzer/93316] Several gcc.dg/analyzer tests FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93316 --- Comment #9 from David Malcolm --- (In reply to Iain Sandoe from comment #8) > (In reply to David Malcolm from comment #7) > > (In reply to r...@cebitec.uni-bielefeld.de from comment #6) > > [...] > > > On Solaris (both sparc and x86), all analyzer testsuite failures are > > > gone. > > > > Thanks. > > > > I'll go ahead and mark this as resolved. Please reopen if there are any > > other failures (apart from the pattern-test-2.c issue, which is PR > > analyzer/93291). > > Hi David, > Things are much improved on Darwin, but certainly not (yet) all fixed (see > https://gcc.gnu.org/ml/gcc-testresults/2020-01/msg01146.html and the next > few entries). Thanks for the update. > * analyzer/abort.c fails everywhere on Darwin with: > > /src-local/gcc-master/gcc/testsuite/gcc.dg/analyzer/abort.c:71:3: warning: > UNKNOWN > PASS: gcc.dg/analyzer/abort.c (test for warnings, line 14) > PASS: gcc.dg/analyzer/abort.c (test for warnings, line 31) > PASS: gcc.dg/analyzer/abort.c (test for warnings, line 47) > PASS: gcc.dg/analyzer/abort.c (test for warnings, line 60) > FAIL: gcc.dg/analyzer/abort.c (test for warnings, line 71) > FAIL: gcc.dg/analyzer/abort.c (test for excess errors) > Excess errors: > /src-local/gcc-master/gcc/testsuite/gcc.dg/analyzer/abort.c:71:3: warning: > UNKNOWN Looks like PR 93367, which should be fixed by r10-6195-ga0b935ac66bc9804b0864151e5f1bfde5ac1ddeb. > * analyzer/dot-output.c: fails on 32bit HOSTs (x86 and PPC) with: > > Warning: dot-output.c.state-purge.dot:11: string ran past end of line > Error: dot-output.c.state-purge.dot:12: syntax error near line 12 > context: >>> ' <<< _5' not needed here > Warning: dot-output.c.state-purge.dot:34: string ran past end of line > Warning: dot-output.c.state-purge.dot:45: string ran past end of line > Looks like PR 93293. What version of GraphViz do you have installed? > * analyzer/malloc-1.c: fails on x86_64 HOSTs with: > > PASS: gcc.dg/analyzer/malloc-1.c (test for warnings, line 393) > FAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 417) > FAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 418) > FAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 425) > FAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 429) > XFAIL: gcc.dg/analyzer/malloc-1.c (test for warnings, line 445) > PASS: gcc.dg/analyzer/malloc-1.c (test for warnings, line 453) I haven't seen failures before. It looks like memset in your hasn't been marked with __attribute__ ((__nonnull__)) on its first param, which the tests are implicitly assuming. > powerpc-darwin9 (32b host) has a couple of additional fails, including the > pattern-test-2.c case. > > Do you want me to re-open this or open one or more new ones? Please open a new one for the malloc-1.c issue.
[Bug analyzer/93375] ICE in gimple_call_arg, at gimple.h:3258
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93375 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #4 from Christophe Lyon --- (In reply to Rainer Orth from comment #3) > The new test FAILs on Solaris/SPARC, both 32 and 64-bit: > > +FAIL: gcc.dg/analyzer/pr93375.c (test for warnings, line 14) > +FAIL: gcc.dg/analyzer/pr93375.c (test for excess errors) > > Excess errors: > /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/analyzer/pr93375.c:14:3: > warning: use of NULL 'rl' where non-null expected [CWE-690] > [-Wanalyzer-null-argument] Same thing on arm-linux-gnueabi[hf] when forcing eg. -march=armv5t
[Bug c++/93413] New: Destructor definition not found during constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93413
Bug ID: 93413
Summary: Destructor definition not found during constant
evaluation
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: antoshkka at gmail dot com
Target Milestone: ---
Consider the example:
struct Base {
constexpr virtual ~Base(){}
};
struct Derived: Base {};
constexpr Derived d;
Destructor for the `Derived` should be implicitly defined. However the above
snippet produces error message on GCC-10 with -std=c++2a flag: `error: 'virtual
constexpr Derived::~Derived()' used before its definition`.
[Bug bootstrap/93409] [10 Regression] gcn libgomp plugin fails to build for x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93409
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #2 from Tobias Burnus ---
Untested:
diff --git a/libgomp/configure b/libgomp/configure
index 04a6fd96610..ee1bbe6a0a8 100755
--- a/libgomp/configure
+++ b/libgomp/configure
@@ -15322,3 +15322,3 @@ rm -f core conftest.err conftest.$ac_objext \
case " ${CC} ${CFLAGS} " in
- *" -m32 "*)
+ *" -m32 "*|*" -mx32 "*)
PLUGIN_HSA=0
@@ -15362,3 +15362,3 @@ rm -f core conftest.err conftest.$ac_objext \
case " ${CC} ${CFLAGS} " in
- *" -m32 "*)
+ *" -m32 "*|*" -mx32 "*)
PLUGIN_GCN=0
diff --git a/libgomp/plugin/configfrag.ac b/libgomp/plugin/configfrag.ac
index 9a424aa1c9c..fc91702a434 100644
--- a/libgomp/plugin/configfrag.ac
+++ b/libgomp/plugin/configfrag.ac
@@ -213,3 +213,3 @@ if test x"$enable_offload_targets" != x; then
case " ${CC} ${CFLAGS} " in
- *" -m32 "*)
+ *" -m32 "*|*" -mx32 "*)
PLUGIN_HSA=0
@@ -253,3 +253,3 @@ if test x"$enable_offload_targets" != x; then
case " ${CC} ${CFLAGS} " in
- *" -m32 "*)
+ *" -m32 "*|*" -mx32 "*)
PLUGIN_GCN=0
[Bug rtl-optimization/92294] alias attribute generates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||rsandifo at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #3 from rsandifo at gcc dot gnu.org --- About to post a patch.
[Bug fortran/93365] ICE in match_data_constant, at fortran/decl.c:426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93365 markeggleston at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |markeggleston at gcc dot gnu.org --- Comment #5 from markeggleston at gcc dot gnu.org --- (In reply to Steve Kargl from comment #4) > On Thu, Jan 23, 2020 at 03:37:04PM +, markeggleston at gcc dot gnu.org > wrote: > > > > If the parameter attribute is removed or a non zero sized array is used, the > > ICE does not occur. > > > > The ICE occurs in gfc_match_varspec (primary.c) a temporary gfc_ref > > structure > > has been created and has the type REF_INQUIRY. If the primary expression has > > been passed in is EXPR_CONSTANT the check is done. When the ICE occurs the > > type > > is EXPR_STRUCTURE, so the value of the REF_INQUIRY taken from u.i is used > > for > > the inquiry type instead of being 2 (INQUIRY_KIND) it is random > > e.g.73176720. > > > > Not quite, right. If you have > >complex, parameter :: a(1) = 0 >integer b >data b/a%kind% > > then at line 2337 in primary.c > >gfc_simplify_expr (primary, 0); > > collapses primary to an EXPR_CONSTANT, and then things seem to work. > > If you have > >complex, parameter :: a(0) = 0 >integer b >data b/a%kind% > > then "gfc_simplify_expr (primary, 0)" does not collapse primary > to EXPR_CONSTANT as it seems gfc_simplify_expr does not handle > zero size arrays (as there is nothing to simplify!). gfortran gfc_simplify_expr calls simplify_parameter_variable which for zero size arrays it creates a new gfc_expr structure with the expr_type set to EXPR_ARRAY and replaces primary. When primary is replaced its chain of ref structures is deleted so tmp->u.i is invalid causing the ICE the following lines are never reached: > then enters the switch statement and get to lines 2384-2385 > >primary->ts.type = BT_INTEGER; >primary->ts.kind = gfc_default_integer_kind; > > This just resets a part of primary, but it does not fix up > it up correctly. Likely, need to check for zero size > arrays do extra work. I have modified gfc_simplify_expr: --- a/gcc/fortran/expr.c +++ b/gcc/fortran/expr.c @@ -2069,8 +2069,13 @@ simplify_parameter_variable (gfc_expr *p, int type) e->value.constructor = NULL; e->shape = gfc_copy_shape (p->shape, p->rank); e->where = p->where; - gfc_replace_expr (p, e); - return true; + e->ref = gfc_copy_ref (p->ref); + t = gfc_simplify_expr (e, type); + if (t && !e->ref) + gfc_replace_expr (p, e); + else + gfc_free_expr (e); + return t; } e = gfc_copy_expr (p->symtree->n.sym->value); This results in primary being reduced to a EXPR_CONSTANT just like it is for non-zero length arrays. I've checked the 8 and 9 branches, 8 does not support this syntax and 9.2 behaves differently: program p real, parameter :: a(0) = 0.5 write(*,*) a%kind end compiles but the output is: 0.5 and program p real, parameter :: a(1) = 0.5 write(*,*) a%kind end fails to compile with an ICE. I'll investigate these further and ad either 1 or 2 new PRs. I'm now getting failures for several test cases in gfortran.dg, more work to do...
[Bug bootstrap/93409] [10 Regression] gcn libgomp plugin fails to build for x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93409 Andrew Stubbs changed: What|Removed |Added CC||ams at gcc dot gnu.org --- Comment #1 from Andrew Stubbs --- Please don't try x32. It might have previously built, but it does not work. In order for offloading to work it is necessary that both CPU and GPU use the exact same type layout. Since the GPU compiler is using x86_64 compatible types it is incompatible with x86_32. We should probably find a nicer way to not build. :-(
[Bug libstdc++/91947] std::filesystem::file_size will return wrong value on 32bit platforms with large files support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91947 --- Comment #19 from Eric Botcazou --- > Fixed for gcc-9 as well, please let me know if you see any more build issues > here. Sure, thanks for the quick resolution!
