[Bug c++/95559] New: Compiling "{{}}" result is inconsistent in different versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95559
Bug ID: 95559
Summary: Compiling "{{}}" result is inconsistent in different
versions
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
This case test.cc
#include
int main() {
return {{}};
}
In the version of GCC 6.1 - 8.4, it's compiled ok.
But in GCC 6.1 lower and 8.4 higher version, for example, in GCC trunk
$g++-trunk test.cc
test.cc: In function 'int main()':
test.cc:3:15: error: too many braces around scalar initializer for type 'int'
3 | int var = {{}};
|
I also compiled test.cc in recent released Clang, and they all accept "{{}}".
Should GCC compile "{{}}" fine also? I think this is a supported feature
according to https://en.cppreference.com/w/cpp/language/return.
[Bug middle-end/95558] New: Invalid IPA optimizations based on weak definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558 Bug ID: 95558 Summary: Invalid IPA optimizations based on weak definition Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: bugdal at aerifal dot cx Target Milestone: --- Created attachment 48689 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48689=edit test case Here is a case that came up in WIP code on musl libc, where I wanted to provide a weak dummy definition for functionality that would optionally be replaced by a strong definition elsewhere at ld time. I've been looking for some plausible explanation aside from an IPA bug, like interaction with UB, but I can't find any. In the near-minimal test case here, the function reclaim() still has all of the logic it should, but reclaim_gaps gets optimized down to a nop. What seems to be happening is that the dummy weak definition does not leak into its direct caller via IPA optimizations, but does leak to the caller's caller.
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 95456, which changed state. Bug 95456 Summary: [11 Regression] gcc/gcc.c:6035:16: runtime error: null pointer passed as argument 2, which is declared to never be null https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95456 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug driver/95456] [11 Regression] gcc/gcc.c:6035:16: runtime error: null pointer passed as argument 2, which is declared to never be null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95456 Alexandre Oliva changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Alexandre Oliva --- fixed
[Bug c/95556] Not replacing __builtin___memcpy_chk() as documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556 --- Comment #3 from Jeff Davis --- Original larger case was discovered in PostgreSQL: https://www.postgresql.org/message-id/99b2eab335c1592c925d8143979c8e9e81e1575f.ca...@j-davis.com
[Bug middle-end/95556] Not replacing __builtin___memcpy_chk() as documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556 --- Comment #2 from Jeff Davis --- Created attachment 48688 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48688=edit Example 3 Another example that works (i.e. builtin is properly replaced by memcpy as described in the document). The only difference between this working example and the failing example2.c is that I replaced the sizeof() with a constant.
[Bug driver/95456] [11 Regression] gcc/gcc.c:6035:16: runtime error: null pointer passed as argument 2, which is declared to never be null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95456 --- Comment #2 from CVS Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:2e6a6644db0ef0f369df4e5b1b337122d84c1a39 commit r11-1014-g2e6a6644db0ef0f369df4e5b1b337122d84c1a39 Author: Alexandre Oliva Date: Fri Jun 5 22:31:19 2020 -0300 [PR95456] avoid memcpy (_, NULL, 0) in gcc.c Some newly-added code in gcc.c might call memcpy with a NULL source pointer and zero-length inputs. Avoid such calls by rearranging the code a little. for gcc/ChangeLog PR driver/95456 * gcc.c (do_spec_1): Don't call memcpy (_, NULL, 0).
[Bug c++/95557] New: __STDCPP_DEFAULT_NEW_ALIGNMENT__ is int instead of size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95557 Bug ID: 95557 Summary: __STDCPP_DEFAULT_NEW_ALIGNMENT__ is int instead of size_t Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bruck.michael at gmail dot com Target Milestone: --- [cpp.predefined] __STDCPP_DEFAULT_NEW_ALIGNMENT__ "An integer literal of type std::size_t whose value is the..." It currently fails with things like std::max when comparing to size_t values.
[Bug c/95556] Not replacing __builtin___memcpy_chk() as documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556 --- Comment #1 from Jeff Davis --- Created attachment 48687 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48687=edit Example 1
[Bug c/95556] New: Not replacing __builtin___memcpy_chk() as documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95556 Bug ID: 95556 Summary: Not replacing __builtin___memcpy_chk() as documented Product: gcc Version: 7.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: pg...@j-davis.com Target Milestone: --- Created attachment 48686 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48686=edit Example 2 GCC's Object Size Checking doc says: "There are built-in functions added for many common string operation functions, e.g., for memcpy __builtin___memcpy_chk built-in is provided. This built-in has an additional last argument, which is the number of bytes remaining in the object the dest argument points to or (size_t) -1 if the size is not known. The built-in functions are optimized into the normal string functions like memcpy if the last argument is (size_t) -1 or if it is known at compile time that the destination object will not be overflowed..." https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html In the attached example1.c, __builtin___memcpy_chk() is optimized into the normal memcpy(), as expected. But in a slightly different example2.c, it is not, despite an object size of -1. When the checked version is left in place (like example2.c), it causes a significant regression in my case. This is important because Ubuntu 18.04 uses _FORTIFY_SOURCE, which ends up using __builtin___memcpy_chk() for memcpy. If gcc is arbitrarily leaving it in place when it should be (according to the docs) optimized away, that affects a lot of code. I'm seeing this on Ubuntu 18.04 with both: gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 gcc-9 (Ubuntu 9.2.1-19ubuntu1~18.04.york0) 9.2.1 20191109 It happens with or without -fno-builtin-memcpy (which is not a surprise, since I am directly calling the builtin version anyway). Compiled using: gcc-9 -O2 -c -S -o example1.S example1.c gcc-9 -O2 -c -S -o example2.S example2.c example1.S:50: callmemcpy@PLT example2.S:75: rep movsq
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #23 from bouanto at zoho dot com --- Created attachment 48685 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48685=edit Example of global assembly See answers below. (In reply to David Malcolm from comment #22) > Created attachment 48684 [details] > Updated work-in-progress patch which adds "asm goto" support > > Here's an updated version of the patch which adds "asm goto" support. grep > for test_i386_basic_asm_3a to see an example. > > Also uploaded to: > https://dmalcolm.fedorapeople.org/gcc/2020-06-05/0001-FIXME-WIP-on-extended- > asm-support-v2.patch > > Does this API make sense? Yes, now I understand what you meant. The API looks good. > I could use a concrete example of what you might use in C. > An issue is ordering: in C, these top-level statements presumably are ordered > relative to each other and the function bodies, based on the order they're > seen > by the parser (though I'm guessing here). Would something similar happen > based > on the order of calls to gcc_jit_context_new_function? I attached an example of global assembly. I don't understand the ordering issue. I also don't understand how gcc_jit_context_new_function is used here.
[Bug bootstrap/95555] [11 regression] bootstrap build failure starting with r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #4 from Bill Seurer --- bootstrap works with that patch
[Bug fortran/95374] ICE: gfc_array_size failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95374 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords|ice-on-valid-code |accepts-invalid, ||ice-on-invalid-code Priority|P3 |P4 Ever confirmed|0 |1 Last reconfirmed||2020-06-05 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Example z2.f90 is actually invalid code that is not rejected, since the rhs takes element a(0) which is out-of-bounds, has size 1, whereas the lhs has size 0. For the same reason, z1.f90 is invalid code since it accesses a(0).
[Bug fortran/95512] gcc/fortran/trans-decl.c:1066: array sanity check after use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95512 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2020-06-05 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from anlauf at gcc dot gnu.org --- This looks like a false positive: dim is the index of the enclosing for loop. It is also funny that it warns about this statement and not the if preceeding this one.
[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from anlauf at gcc dot gnu.org --- Fixed on master for GCC-11, and backported to 10-branch and 9-branch. Thanks for the report!
[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373 --- Comment #14 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d82e9d37d843539127df59d7b8894e5e3baec9b9 commit r9-8657-gd82e9d37d843539127df59d7b8894e5e3baec9b9 Author: Harald Anlauf Date: Sat May 30 20:59:41 2020 +0200 PR fortran/95373 - ICE in build_reference_type, at tree.c:7942 The use of KIND, LEN, RE, and IM inquiry references for applicable intrinsic types is valid only for suffienctly new Fortran standards. Add appropriate checks in the appropriate place. 2020-05-30 Harald Anlauf gcc/fortran/ PR fortran/95373 * primary.c (is_inquiry_ref): Move validity check of inquiry references against selected Fortran standard from here... (gfc_match_varspec) ...to here. gcc/testsuite/ PR fortran/95373 * gfortran.dg/pr95373_1.f90: Adjust error messages. * gfortran.dg/pr95373_2.f90: Adjust error message. (cherry picked from commit dd38c765a04d06c775134a135f68b18c3b7c9c78)
[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373 --- Comment #13 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:2039ad0eb5261a2e7eb1d3c9da7576a5c370c073 commit r9-8656-g2039ad0eb5261a2e7eb1d3c9da7576a5c370c073 Author: Harald Anlauf Date: Thu May 28 22:28:08 2020 +0200 PR fortran/95373 - ICE in build_reference_type, at tree.c:7942 The use of KIND, LEN, RE, and IM inquiry references for applicable intrinsic types is valid only for suffienctly new Fortran standards. Add appropriate check. 2020-05-28 Harald Anlauf gcc/fortran/ PR fortran/95373 * primary.c (is_inquiry_ref): Check validity of inquiry references against selected Fortran standard. gcc/testsuite/ PR fortran/95373 * gfortran.dg/pr95373_1.f90: New test. * gfortran.dg/pr95373_2.f90: New test. (cherry picked from commit 5c715e6a2990cfb6c15acc1ee14219523534ec69)
[Bug bootstrap/95555] [11 regression] bootstrap build failure starting with r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #3 from Martin Sebor --- (In reply to Andreas Schwab from comment #2) > alternative_order[0] is guaranteed to be set, because alternative_reject[i] > <= alternative_reject[which_alternative] for i == which_alternative at > least. We know that which_alternative < recog_data.n_alternatives, > otherwise alternative_reject[which_alternative] would be undefined. That's another way of saying that the code must be correct because otherwise it would be undefined. (There is no obvious constraint that which_alternative is less than recog_data.n_alternatives.) But if clearing alternative_order[0] is safe and if avoids the warning it's fine with me. Bill, can you please confirm that the patch below suppresses it (I can't reproduce it on my end)? diff --git a/gcc/postreload.c b/gcc/postreload.c index f6258285022..9b4e2bd9efb 100644 --- a/gcc/postreload.c +++ b/gcc/postreload.c @@ -592,6 +592,10 @@ reload_cse_simplify_operands (rtx_insn *insn, rtx testreg) } } + /* The loop below sets alternative_order[0] but -Wmaybe-uninitialized + can't know that. Clear it here to avoid the warning. */ + alternative_order[0] = 0; + /* Record all alternatives which are better or equal to the currently matching one in the alternative_order array. */ for (i = j = 0; i < recog_data.n_alternatives; i++)
[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373 --- Comment #12 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:2927ec5bc1276188efae82301d8fcffe4a245d1e commit r10-8257-g2927ec5bc1276188efae82301d8fcffe4a245d1e Author: Harald Anlauf Date: Sat May 30 20:59:41 2020 +0200 PR fortran/95373 - ICE in build_reference_type, at tree.c:7942 The use of KIND, LEN, RE, and IM inquiry references for applicable intrinsic types is valid only for suffienctly new Fortran standards. Add appropriate checks in the appropriate place. 2020-05-30 Harald Anlauf gcc/fortran/ PR fortran/95373 * primary.c (is_inquiry_ref): Move validity check of inquiry references against selected Fortran standard from here... (gfc_match_varspec) ...to here. gcc/testsuite/ PR fortran/95373 * gfortran.dg/pr95373_1.f90: Adjust error messages. * gfortran.dg/pr95373_2.f90: Adjust error message. (cherry picked from commit dd38c765a04d06c775134a135f68b18c3b7c9c78)
[Bug fortran/95373] [9/10/11 Regression] ICE in build_reference_type, at tree.c:7942
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95373 --- Comment #11 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:d7760318305a0eab43d59d9884486569409c2d52 commit r10-8256-gd7760318305a0eab43d59d9884486569409c2d52 Author: Harald Anlauf Date: Thu May 28 22:28:08 2020 +0200 PR fortran/95373 - ICE in build_reference_type, at tree.c:7942 The use of KIND, LEN, RE, and IM inquiry references for applicable intrinsic types is valid only for suffienctly new Fortran standards. Add appropriate check. 2020-05-28 Harald Anlauf gcc/fortran/ PR fortran/95373 * primary.c (is_inquiry_ref): Check validity of inquiry references against selected Fortran standard. gcc/testsuite/ PR fortran/95373 * gfortran.dg/pr95373_1.f90: New test. * gfortran.dg/pr95373_2.f90: New test. (cherry picked from commit 5c715e6a2990cfb6c15acc1ee14219523534ec69)
[Bug fortran/95090] ICE: identifier overflow: 129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #17 from anlauf at gcc dot gnu.org --- Fixed on master for GCC-11 and 10-branch. A backport to 9-branch would need some manual work. As this is not a regression, not done. Thanks for the report!
[Bug middle-end/95552] [11 Regression] VLA ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95552
--- Comment #5 from Jason Merrill ---
This simplified testcase has been broken a lot longer (back to GCC 8, at
least); my patch just extended the breakage to templates that already affected
non-templates. The issue is that cloning the constructor doesn't handle the
VLA typedef properly, so the version in the clone ends up still referring to
the cloned function, which blows up.
struct ViewDom
{
ViewDom(int i) { char (*a)[i]; }
};
void element( )
{
ViewDom a(2);
}
[Bug fortran/95537] [11 regression] gfortran.dg/pr95090.f90 since r11-670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95537 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from anlauf at gcc dot gnu.org --- Fixed on master for GCC-11, and backported to 10-branch and 9-branch. Thanks for the report and assistance in pinpointing the origin of the problem!
[Bug fortran/95530] [11 regression] ICE in gfortran.dg/equiv_11.f90 after r11-594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95530 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from anlauf at gcc dot gnu.org --- Fixed on master for GCC-11, and backported to 10-branch and 9-branch. Thanks for the report and assistance in pinpointing the origin of the problem!
[Bug fortran/95106] Bogus warning from module with long name and an equivalence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95106 --- Comment #7 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:371739d01d00ae4c55902e0937b73ddee7d66391 commit r9-8655-g371739d01d00ae4c55902e0937b73ddee7d66391 Author: Harald Anlauf Date: Sun May 24 21:35:04 2020 +0200 PR fortran/95106 - truncation of long symbol names with EQUIVALENCE For long module names, the generated name-mangled symbol was truncated, leading to bogus warnings about COMMON block mismatches. Provide sufficiently large temporaries. gcc/fortran/ 2020-05-24 Harald Anlauf PR fortran/95106 * trans-common.c (gfc_sym_mangled_common_id): Enlarge temporaries for name-mangling. gcc/testsuite/ 2020-05-24 Harald Anlauf PR fortran/95106 * gfortran.dg/equiv_11.f90: New test. (cherry picked from commit d176184d98a00ab379ae5959aed1908a79995e6b)
[Bug fortran/95537] [11 regression] gfortran.dg/pr95090.f90 since r11-670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95537 --- Comment #11 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:075bec57a1c63a1b1de9d95909866a6548380390 commit r9-8654-g075bec57a1c63a1b1de9d95909866a6548380390 Author: Harald Anlauf Date: Fri Jun 5 20:30:34 2020 +0200 PR fortran/95530, PR fortran/95537 - Buffer overflows with long symbols The testcases for PR95090 and PR95106 trigger buffer overflows with long symbols that were found with an instrumented compiler. Enlarge the affected buffers, and add checks that the buffers will suffice. 2020-06-05 Harald Anlauf gcc/fortran/ PR fortran/95530 PR fortran/95537 * decl.c (gfc_match_decl_type_spec): Enlarge buffer, and enhance string copy to detect buffer overflow. * gfortran.h (gfc_common_head): Enlarge buffer. * trans-common.c (finish_equivalences): Enhance string copy to detect buffer overflow. (cherry picked from commit bcd96c9cce962ca5b2c6f8459597fb759f945ccf)
[Bug fortran/95530] [11 regression] ICE in gfortran.dg/equiv_11.f90 after r11-594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95530 --- Comment #14 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:075bec57a1c63a1b1de9d95909866a6548380390 commit r9-8654-g075bec57a1c63a1b1de9d95909866a6548380390 Author: Harald Anlauf Date: Fri Jun 5 20:30:34 2020 +0200 PR fortran/95530, PR fortran/95537 - Buffer overflows with long symbols The testcases for PR95090 and PR95106 trigger buffer overflows with long symbols that were found with an instrumented compiler. Enlarge the affected buffers, and add checks that the buffers will suffice. 2020-06-05 Harald Anlauf gcc/fortran/ PR fortran/95530 PR fortran/95537 * decl.c (gfc_match_decl_type_spec): Enlarge buffer, and enhance string copy to detect buffer overflow. * gfortran.h (gfc_common_head): Enlarge buffer. * trans-common.c (finish_equivalences): Enhance string copy to detect buffer overflow. (cherry picked from commit bcd96c9cce962ca5b2c6f8459597fb759f945ccf)
[Bug c++/95428] ABI breakage for "base object constructor" for final classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428 --- Comment #7 from Nathan Sidwell --- Richard Smith thinks the ABI is clear and compilers should always emit the as-base ctor. Even though that wording was written before final was a thing. Depends if Jason wants to argue the case?
[Bug fortran/95106] Bogus warning from module with long name and an equivalence
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95106 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:1e20cd1b583347cb2ea8591a45d99df143f7c41a commit r10-8255-g1e20cd1b583347cb2ea8591a45d99df143f7c41a Author: Harald Anlauf Date: Sun May 24 21:35:04 2020 +0200 PR fortran/95106 - truncation of long symbol names with EQUIVALENCE For long module names, the generated name-mangled symbol was truncated, leading to bogus warnings about COMMON block mismatches. Provide sufficiently large temporaries. gcc/fortran/ 2020-05-24 Harald Anlauf PR fortran/95106 * trans-common.c (gfc_sym_mangled_common_id): Enlarge temporaries for name-mangling. gcc/testsuite/ 2020-05-24 Harald Anlauf PR fortran/95106 * gfortran.dg/equiv_11.f90: New test.
[Bug c++/95369] braced-init-list with designated initializers as template-argument rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95369 --- Comment #5 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:cecc73af4980004502f4c327b6c639125defb379 commit r11-1010-gcecc73af4980004502f4c327b6c639125defb379 Author: Marek Polacek Date: Fri Jun 5 14:22:35 2020 -0400 c++: Make braced-init-list as template arg work with aggr init [PR95369] Barry pointed out to me that our braced-init-list as a template-argument extension doesn't work as expected when we aggregate-initialize. Since aggregate list-initialization is a user-defined conversion sequence, we allow it as part of a converted constant expression. Co-authored-by: Jason Merrill gcc/cp/ChangeLog: PR c++/95369 * call.c (build_converted_constant_expr_internal): Allow list-initialization. gcc/testsuite/ChangeLog: PR c++/95369 * g++.dg/cpp2a/nontype-class38.C: New test.
[Bug testsuite/95546] Random Fortran test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95546 --- Comment #6 from Dominique d'Humieres --- > I am curious, did this just start happening or is it a long time issue just > reported. The test is quite old: Feb 18 2018. I did not see any failure for it until now (one instance).
[Bug bootstrap/95555] [11 regression] bootstrap build failure starting with r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #2 from Andreas Schwab --- alternative_order[0] is guaranteed to be set, because alternative_reject[i] <= alternative_reject[which_alternative] for i == which_alternative at least. We know that which_alternative < recog_data.n_alternatives, otherwise alternative_reject[which_alternative] would be undefined.
[Bug c++/86568] -Wnonnull warnings should highlight the relevant argument not the closing parenthesis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86568 Martin Sebor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Status|NEW |ASSIGNED Keywords||patch --- Comment #2 from Martin Sebor --- Full patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547415.html
[Bug fortran/95530] [11 regression] ICE in gfortran.dg/equiv_11.f90 after r11-594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95530 --- Comment #13 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:36442ee216acbe9a345ae625be53efbde8626477 commit r10-8254-g36442ee216acbe9a345ae625be53efbde8626477 Author: Harald Anlauf Date: Fri Jun 5 20:30:34 2020 +0200 PR fortran/95530, PR fortran/95537 - Buffer overflows with long symbols The testcases for PR95090 and PR95106 trigger buffer overflows with long symbols that were found with an instrumented compiler. Enlarge the affected buffers, and add checks that the buffers will suffice. 2020-06-05 Harald Anlauf gcc/fortran/ PR fortran/95530 PR fortran/95537 * decl.c (gfc_match_decl_type_spec): Enlarge buffer, and enhance string copy to detect buffer overflow. * gfortran.h (gfc_common_head): Enlarge buffer. * trans-common.c (finish_equivalences): Enhance string copy to detect buffer overflow. (cherry picked from commit bcd96c9cce962ca5b2c6f8459597fb759f945ccf)
[Bug fortran/95090] ICE: identifier overflow: 129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090 --- Comment #14 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:2ee89130c278169b18b0123316ea4745120f commit r10-8251-g2ee89130c278169b18b0123316ea4745120f Author: Harald Anlauf Date: Wed May 27 21:20:24 2020 +0200 PR fortran/95090 - ICE: identifier overflow For long module name, derive type and component name, the generated name-mangled symbol did not fit into a buffer when coarrays were enabled. Provide sufficiently large temporary. 2020-05-27 Harald Anlauf gcc/fortran/ PR fortran/95090 * iresolve.c (gfc_get_string): Enlarge temporary for name-mangling. gcc/testsuite/ PR fortran/95090 * gfortran.dg/pr95090.f90: New test. (cherry picked from commit c949ec9c4e88d2ff6dbd5b179abddf3703129577)
[Bug fortran/95090] ICE: identifier overflow: 129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090 --- Comment #16 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:b3c17dfef86311a8b27b8e19854fd44cf8da29ee commit r10-8253-gb3c17dfef86311a8b27b8e19854fd44cf8da29ee Author: Harald Anlauf Date: Sat May 30 20:50:59 2020 +0200 PR fortran/95090 - ICE: identifier overflow Implement buffer overrun check for temporary that holds mangled names. 2020-05-30 Harald Anlauf gcc/fortran/ PR fortran/95090 * class.c (get_unique_type_string): Use buffer overrun check. (cherry picked from commit bf5fbbbd8c9a3385c1083cc80683bdb0195b1ffc)
[Bug fortran/95090] ICE: identifier overflow: 129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95090 --- Comment #15 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:78c4b06ac3df51c460de835917549c8555ee4eaf commit r10-8252-g78c4b06ac3df51c460de835917549c8555ee4eaf Author: Harald Anlauf Date: Fri May 29 21:19:31 2020 +0200 PR fortran/95090 - ICE: identifier overflow The initial fix for this PR uncovered several latent issues with further too small string buffers which showed up only when testing on i686. Provide sufficiently large temporaries. 2020-05-29 Harald Anlauf gcc/fortran/ PR fortran/95090 * class.c (get_unique_type_string): Enlarge temporary for name-mangling. Use strncpy to prevent buffer overrun. (get_unique_hashed_string): Enlarge temporary. (gfc_hash_value): Enlarge temporary for name-mangling. (cherry picked from commit 7deca8c0b3765787627b11387b56b97b01a8bf33)
[Bug fortran/95537] [11 regression] gfortran.dg/pr95090.f90 since r11-670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95537 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:36442ee216acbe9a345ae625be53efbde8626477 commit r10-8254-g36442ee216acbe9a345ae625be53efbde8626477 Author: Harald Anlauf Date: Fri Jun 5 20:30:34 2020 +0200 PR fortran/95530, PR fortran/95537 - Buffer overflows with long symbols The testcases for PR95090 and PR95106 trigger buffer overflows with long symbols that were found with an instrumented compiler. Enlarge the affected buffers, and add checks that the buffers will suffice. 2020-06-05 Harald Anlauf gcc/fortran/ PR fortran/95530 PR fortran/95537 * decl.c (gfc_match_decl_type_spec): Enlarge buffer, and enhance string copy to detect buffer overflow. * gfortran.h (gfc_common_head): Enlarge buffer. * trans-common.c (finish_equivalences): Enhance string copy to detect buffer overflow. (cherry picked from commit bcd96c9cce962ca5b2c6f8459597fb759f945ccf)
[Bug c++/95540] [coroutine] coroutine_traits<> lookup for lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95540
--- Comment #6 from Iain Sandoe ---
(In reply to Michael Bruck from comment #5)
> > Since the coroutine traits are global, and the closure type is unique,
> > that provides a way to disambiguate instantiations of the traits for
> > lambdas with otherwise identical signatures.
>
> But the closure type is generated in the same lambda expression where the
> coroutine generator looks up the coroutine_traits<>. How do I specialize on
> that?
I wasn't meaning to suggest you can specialise per lambda (but I was saying
that the traits instantiated will be unique per lambda) - perhaps the latter is
an implementation detail.
Providing the class/callable object type to the traits look does allow
specialisations like ...
template
struct std::coroutine_traits {
struct promise_type {
promise_type (CallOp op, T ...args) {}
Fake get_return_object() { return {}; }
std::suspend_always initial_suspend() { return {}; }
to be possible.
( I might be getting out of my depth with the long history of the design
evolution here - but this is my understanding of the rationale for the status
quo ).
[Bug bootstrap/95555] [11 regression] bootstrap build failure starting with r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 --- Comment #1 from Martin Sebor --- The reload_cse_simplify_operands() function allocates three arrays but resets only two: alternative_reject = XALLOCAVEC (int, recog_data.n_alternatives); alternative_nregs = XALLOCAVEC (int, recog_data.n_alternatives); alternative_order = XALLOCAVEC (int, recog_data.n_alternatives); memset (alternative_reject, 0, recog_data.n_alternatives * sizeof (int)); memset (alternative_nregs, 0, recog_data.n_alternatives * sizeof (int)); It then assigns to the alternative_order array in the loop below, but only conditionally: /* Record all alternatives which are better or equal to the currently matching one in the alternative_order array. */ for (i = j = 0; i < recog_data.n_alternatives; i++) if (alternative_reject[i] <= alternative_reject[which_alternative]) alternative_order[j++] = i; recog_data.n_alternatives = j; Finally, it unconditionally reads the first element: /* Substitute the operands as determined by op_alt_regno for the best alternative. */ j = alternative_order[0]; I don't know this part of the compiler to tell if the first element is guaranteed to be stored into by the loop, and it seems that GCC can't figure it out either, so it issues the warning. That's expected. If the element is guaranteed to be set by the loop then storing a zero into it before the loop should be safe and avoid the warning. If it isn't, someone familiar with the code should look into what the right initial value should be. The affected code hasn't changed since 2003 but Jakub and Richard Sandiford have made changes to the function since then so they might be able to help. In the meantime, I would suggest zeroing out the first element to see if that helps. Bill, can you give it a try?
[Bug fortran/95500] Segfault compiling extra interface on intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95500 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed on master for GCC-11, and backported to 10-branch and 9-branch. Closing. Thanks for the report!
[Bug c++/95540] [coroutine] coroutine_traits<> lookup for lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95540 --- Comment #5 from Michael Bruck --- > Since the coroutine traits are global, and the closure type is unique, > that provides a way to disambiguate instantiations of the traits for > lambdas with otherwise identical signatures. But the closure type is generated in the same lambda expression where the coroutine generator looks up the coroutine_traits<>. How do I specialize on that?
[Bug fortran/95500] Segfault compiling extra interface on intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95500 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:fa0d6c132c8fd7deb118f8309aa9dfe41a88e840 commit r9-8653-gfa0d6c132c8fd7deb118f8309aa9dfe41a88e840 Author: Harald Anlauf Date: Thu Jun 4 21:00:33 2020 +0200 PR fortran/95500 - Segfault compiling extra interface on intrinsic Converting an expression so that it can be passed by reference could result in a NULL pointer dereference. 2020-06-04 Steven G. Kargl Harald Anlauf gcc/fortran/ PR fortran/95500 * trans-expr.c (gfc_conv_expr_reference): Do not dereference NULL pointer. gcc/testsuite/ PR fortran/95500 * gfortran.dg/pr95500.f90: New test. (cherry picked from commit 8c727bdf4acf28c8315b119a1c8f6d6af745c2af)
[Bug fortran/95500] Segfault compiling extra interface on intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95500 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:4b3ea558da6479dabe5841bcb0f6bad3f7fea858 commit r10-8250-g4b3ea558da6479dabe5841bcb0f6bad3f7fea858 Author: Harald Anlauf Date: Thu Jun 4 21:00:33 2020 +0200 PR fortran/95500 - Segfault compiling extra interface on intrinsic Converting an expression so that it can be passed by reference could result in a NULL pointer dereference. 2020-06-04 Steven G. Kargl Harald Anlauf gcc/fortran/ PR fortran/95500 * trans-expr.c (gfc_conv_expr_reference): Do not dereference NULL pointer. gcc/testsuite/ PR fortran/95500 * gfortran.dg/pr95500.f90: New test. (cherry picked from commit 8c727bdf4acf28c8315b119a1c8f6d6af745c2af)
[Bug fortran/95537] [11 regression] gfortran.dg/pr95090.f90 since r11-670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95537 --- Comment #9 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:bcd96c9cce962ca5b2c6f8459597fb759f945ccf commit r11-1009-gbcd96c9cce962ca5b2c6f8459597fb759f945ccf Author: Harald Anlauf Date: Fri Jun 5 20:30:34 2020 +0200 PR fortran/95530, PR fortran/95537 - Buffer overflows with long symbols The testcases for PR95090 and PR95106 trigger buffer overflows with long symbols that were found with an instrumented compiler. Enlarge the affected buffers, and add checks that the buffers will suffice. 2020-06-05 Harald Anlauf gcc/fortran/ PR fortran/95530 PR fortran/95537 * decl.c (gfc_match_decl_type_spec): Enlarge buffer, and enhance string copy to detect buffer overflow. * gfortran.h (gfc_common_head): Enlarge buffer. * trans-common.c (finish_equivalences): Enhance string copy to detect buffer overflow.
[Bug fortran/95530] [11 regression] ICE in gfortran.dg/equiv_11.f90 after r11-594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95530 --- Comment #12 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:bcd96c9cce962ca5b2c6f8459597fb759f945ccf commit r11-1009-gbcd96c9cce962ca5b2c6f8459597fb759f945ccf Author: Harald Anlauf Date: Fri Jun 5 20:30:34 2020 +0200 PR fortran/95530, PR fortran/95537 - Buffer overflows with long symbols The testcases for PR95090 and PR95106 trigger buffer overflows with long symbols that were found with an instrumented compiler. Enlarge the affected buffers, and add checks that the buffers will suffice. 2020-06-05 Harald Anlauf gcc/fortran/ PR fortran/95530 PR fortran/95537 * decl.c (gfc_match_decl_type_spec): Enlarge buffer, and enhance string copy to detect buffer overflow. * gfortran.h (gfc_common_head): Enlarge buffer. * trans-common.c (finish_equivalences): Enhance string copy to detect buffer overflow.
[Bug bootstrap/95555] New: [11 regression] bootstrap build failure starting with r11-959
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9 Bug ID: 9 Summary: [11 regression] bootstrap build failure starting with r11-959 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: seurer at linux dot vnet.ibm.com Target Milestone: --- g:b825a22890740f341eae566af27e18e528cd29a7, r11-959 /home/seurer/gcc/git/build/gcc-trunk-bootstrap/./prev-gcc/xg++ -B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./prev-gcc/ -B/home/seurer/gcc/git/install/gcc-trunk-bootstrap/powerpc64-unknown-linux-gnu/bin/ -nostdinc++ -B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-trunk-bootstrap/libstdc++-v3/libsupc++ -L/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/seurer/gcc/git/build/gcc-trunk-bootstrap/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/. -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../include -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libcpp/include -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./gmp -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gmp -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./mpfr/src -I/home/seurer/gcc/git/gcc-trunk-bootstrap/mpfr/src -I/home/seurer/gcc/git/gcc-trunk-bootstrap/mpc/src -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libdecnumber -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libdecnumber/dpd -I../libdecnumber -I/home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/../libbacktrace -I/home/seurer/gcc/git/build/gcc-trunk-bootstrap/./isl/include -I/home/seurer/gcc/git/gcc-trunk-bootstrap/isl/include -o postreload.o -MT postreload.o -MMD -MP -MF ./.deps/postreload.TPo /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/postreload.c /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/postreload.c: In function 'int reload_cse_simplify_operands(rtx_insn*, rtx)': /home/seurer/gcc/git/gcc-trunk-bootstrap/gcc/postreload.c:629:5: error: '*alternative_order' may be used uninitialized [-Werror=maybe-uninitialized] 629 | j = alternative_order[0]; | ~~^~ cc1plus: all warnings being treated as errors make[3]: *** [postreload.o] Error 1
[Bug fortran/95509] [11 regression] gfortran.dg/spellcheck-operator.f90 fails after r11-875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95509 Tom Tromey changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Tom Tromey --- Fixed.
[Bug fortran/95509] [11 regression] gfortran.dg/spellcheck-operator.f90 fails after r11-875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95509 --- Comment #4 from CVS Commits --- The master branch has been updated by Tom Tromey : https://gcc.gnu.org/g:640e05e02b567fa5ccf4c207e6fc6c3e9a93b17c commit r11-1004-g640e05e02b567fa5ccf4c207e6fc6c3e9a93b17c Author: Tom Tromey Date: Fri Jun 5 06:40:14 2020 -0600 fortran/95509 - fix spellcheck-operator.f90 regression My earlier patch to add case handling to the spell checker caused a Fortran regression. I believe I must have misread the test results. This patch fixes the problem by changing the cutoff. I chose this value because the previous patch effectively multiplied the result of get_edit_distance by 2 (unless a case change is involved). gcc/fortran/ChangeLog: PR fortran/95509 * misc.c (gfc_closest_fuzzy_match): Update cutoff value computation.
[Bug c/95554] New: spurious -Wnonnull on a conditional call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95554
Bug ID: 95554
Summary: spurious -Wnonnull on a conditional call
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The C test case below was reduced from gcc/var-tracking.c which triggers the
-Wnonnull (in C++) when the this pointer in member functions is considered
implicitly declared nonnull (or, alternatively, when vec::is_empty() is
declared with attribute nonnull):
In file included from /ssd/test/src/gcc/86568/gcc/var-tracking.c:89:
/ssd/test/src/gcc/86568/gcc/var-tracking.c: In function ‘void
loc_exp_dep_alloc(variable*, int)’:
/ssd/test/src/gcc/86568/gcc/var-tracking.c:8109:46: error: ‘this’ pointer null
[-Werror=nonnull]
8109 | || VAR_LOC_DEP_VEC (var)->is_empty ());
| ^
/ssd/test/src/gcc/86568/gcc/system.h:748:14: note: in definition of macro
‘gcc_assert’
748 |((void)(!(EXPR) ? fancy_abort (__FILE__, __LINE__, __FUNCTION__), 0
: 0))
| ^~~~
/ssd/test/src/gcc/86568/gcc/var-tracking.c:8107:3: note: in expansion of macro
‘gcc_checking_assert’
8107 | gcc_checking_assert (!count
| ^~~
In the test case the P macro corresponds to the VAR_LOC_DEP_VEC() macro defined
in the file, function g() to loc_exp_dep_alloc (), and the return statement to
the gcc_checking_assert.
$ cat q.c && gcc -O2 -S -Wall -fdump-tree-original=/dev/stdout q.c
__attribute__ ((nonnull)) int f (void*);
struct A
{
int i;
};
struct B
{
struct A *p;
};
#define P(p) (p->p ? >p : 0)
int g (struct B *p)
{
return P (p) == 0 || f (P (p));
}
q.c: In function ‘g’:
q.c:17:24: warning: null argument where non-null required (argument 1)
[-Wnonnull]
17 | return P (p) == 0 || f (P (p));
|^
;; Function g (null)
;; enabled by -tree-original
{
return (p->p == 0B || >p == 0B) || f (p->p != 0B ? (void *) >p : 0B) !=
0;
}
[Bug testsuite/95546] Random Fortran test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95546 --- Comment #5 from Steve Kargl --- On Fri, Jun 05, 2020 at 03:46:18PM +, jvdelisle at charter dot net wrote: > > I am curious, did this just start happening or is it a long time issue just > reported. Locking mecahnisms were adjusted recently I believe. > What locking are you referring to? If it some recent changes to libgfortran's pthread locking, then I think that has nothing to do with the problem reported here. The code eof_4.f90 runs multiple tests. The looks like open(unit=99, file='test.dat', status='new') ! ! Test 1 ! close(99, status='delete') open(unit=99, file='test.dat', status='new') ! ! Test 2 ! close(99, status='delete') open(unit=99, file='test.dat', status='new') ! ! Test 3 ! close(99, status='delete') The above is actually testing Fortran feature. HJ Lu reported problems with 'make -jN', which suggests that eof_4.f90 is being compiled and executed in parallel. That is subject to races. Dejagnu needs to be told that eof_4.f90 cannot be run in parallel. If it is not possible to defeat dejagnu, then the test will need to changed to use a unique file name character(len=20) name write(name, '(A,I0,A)') 'tmp', getpid(), '.dat' open(unit=99, file=name, status='new') ! ! Test 1 ! close(99, status='delete') The test could also be adjusted to use inquire() and sleep() (need to check syntax) 1 inquire(file='test.dat', exists=stat) if (stat == 1) then call sleep(2) goto 1 end if
[Bug c++/65969] typename allowed in using declaration of non-types names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65969
Haoxin Tu changed:
What|Removed |Added
CC||haoxintu at gmail dot com
--- Comment #3 from Haoxin Tu ---
This case also reproduces the issue
namespace g_namespace {
int var = 1;
}
int main() {
using typename g_namespace::var; //should be compiled failed but succeeded
return 0;
}
[Bug c++/95553] Incorrect/misspelled designators not triggering compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95553 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- We warn with -Wpedantic and error with -pedantic-errors.
[Bug c++/95553] New: Incorrect/misspelled designators not triggering compilation error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95553
Bug ID: 95553
Summary: Incorrect/misspelled designators not triggering
compilation error
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: alex at weej dot com
Target Milestone: ---
The following code, I believe, should not compile in C++20 or otherwise (we use
it in gnu++17 mode).
#include
auto take_a_string(std::string const& wat) -> void;
auto test() {
take_a_string({.anything_goes_here = "banana"});
}
Tested this on GCC 7 and GCC trunk today on https://godbolt.org/z/ANNyL6
Note that Clang does treat this as an error.
Thanks
[Bug fortran/95530] [11 regression] ICE in gfortran.dg/equiv_11.f90 after r11-594
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95530 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 --- Comment #11 from anlauf at gcc dot gnu.org --- Patch submitted for review: https://gcc.gnu.org/pipermail/fortran/2020-June/054473.html
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 David Malcolm changed: What|Removed |Added Attachment #48677|0 |1 is obsolete|| --- Comment #22 from David Malcolm --- Created attachment 48684 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48684=edit Updated work-in-progress patch which adds "asm goto" support Here's an updated version of the patch which adds "asm goto" support. grep for test_i386_basic_asm_3a to see an example. Also uploaded to: https://dmalcolm.fedorapeople.org/gcc/2020-06-05/0001-FIXME-WIP-on-extended-asm-support-v2.patch Does this API make sense?
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #21 from David Malcolm --- (In reply to bouanto from comment #20) > Well, there's syntax for assembly at the top-level so the user can enter > anything he wants, like in C. > I can craft you an example if you need to, though. I could use a concrete example of what you might use in C. An issue is ordering: in C, these top-level statements presumably are ordered relative to each other and the function bodies, based on the order they're seen by the parser (though I'm guessing here). Would something similar happen based on the order of calls to gcc_jit_context_new_function?
[Bug fortran/95372] ICE in find_array_section, at fortran/expr.c:1687
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95372
kargl at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2020-06-05
CC||kargl at gcc dot gnu.org
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Priority|P3 |P4
--- Comment #1 from kargl at gcc dot gnu.org ---
This allows the code to compile and print 1.
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 280157)
+++ gcc/fortran/expr.c (working copy)
@@ -1684,7 +1684,13 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
}
cons = gfc_constructor_lookup (base, limit);
- gcc_assert (cons);
+
+ if (!cons)
+ {
+ t = false;
+ goto cleanup;
+ }
+
gfc_constructor_append_expr (>value.constructor,
gfc_copy_expr (cons->expr), NULL);
}
[Bug middle-end/95552] [11 Regression] VLA ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95552 Jason Merrill changed: What|Removed |Added Version|10.0|11.0 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug middle-end/95552] [11 Regression] VLA ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95552 David Edelsohn changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #4 from David Edelsohn --- Jason, this seems to be a regression introduced by your patch for C++ VLA PR 95232.
[Bug c++/95540] [coroutine] coroutine_traits<> lookup for lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95540 --- Comment #4 from Iain Sandoe --- (In reply to Michael Bruck from comment #3) > I think you misread, I was complaining about it passing the closure to the > traits/constructor/allocator. But if that is what was agreed upon... > > Can the closure object that is being passed to the constructor and allocator > be used for anything? I am asking because I got it to pass nullptr with the > code below. But if there is no legitimate use it might as well always pass a > nullptr. OK.. I think I did misread (I was under the impression you wanted better diagnostics for the case where the user had intentionally specialised the traits - but made an error). [FTR, I am not sure if that's feasible - but someone with more specialisation-fu can comment on that]. --- I think we need the closure object type in the traits lookup because: Since the coroutine traits are global, and the closure type is unique, that provides a way to disambiguate instantiations of the traits for lambdas with otherwise identical signatures. The callable is usable in the other positions - I don't think that was particularly in debate. The issue was about whether we should pass a reference to the closure or the pointer (and it was decided that symmetry with the class object that a reference was the intention). The fix is not yet in master (to make it a reference) - it's pending review (but you could apply it to test things out).
[Bug testsuite/95546] Random Fortran test failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95546 jvdelisle at charter dot net changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #4 from jvdelisle at charter dot net --- I am curious, did this just start happening or is it a long time issue just reported. Locking mecahnisms were adjusted recently I believe.
[Bug middle-end/95552] [11 Regression] VLA ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95552 --- Comment #3 from David Edelsohn --- Started between r11-878 and r11-896
[Bug c++/95540] [coroutine] coroutine_traits<> lookup for lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95540
--- Comment #3 from Michael Bruck ---
I think you misread, I was complaining about it passing the closure to the
traits/constructor/allocator. But if that is what was agreed upon...
Can the closure object that is being passed to the constructor and allocator be
used for anything? I am asking because I got it to pass nullptr with the code
below. But if there is no legitimate use it might as well always pass a
nullptr.
template
struct foo_t
{
static auto test()
{
return F();
}
};
using moo = foo_t<[]() -> pt::handle_t{ co_return; }>;
...
int main { moo::test(); }
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #20 from bouanto at zoho dot com --- Well, there's syntax for assembly at the top-level so the user can enter anything he wants, like in C. I can craft you an example if you need to, though. (In reply to David Malcolm from comment #19) > (In reply to bouanto from comment #18) > > (In reply to David Malcolm from comment #16) > > > Created attachment 48677 [details] > > This API looks good. > > Thanks. > > [...snip...] > > > > "Basic" asm > > > > > > Do we actually need "basic" asm (as opposed to extended asm)? > > > In particular I'm wary about asm code that's outside of any given > > > function. > > > Is that needed? > > > > That's something I use in my compiler, so that would be very appreciated if > > you could add this. > > Can you give concrete example(s) please? I'm having trouble thinking > through how this would work. > > [...snip...]
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #19 from David Malcolm --- (In reply to bouanto from comment #18) > (In reply to David Malcolm from comment #16) > > Created attachment 48677 [details] > This API looks good. Thanks. [...snip...] > > "Basic" asm > > > > Do we actually need "basic" asm (as opposed to extended asm)? > > In particular I'm wary about asm code that's outside of any given function. > > Is that needed? > > That's something I use in my compiler, so that would be very appreciated if > you could add this. Can you give concrete example(s) please? I'm having trouble thinking through how this would work. [...snip...]
[Bug tree-optimization/94589] Optimize (i<=>0)>0 to i>0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94589 Victor Khimenko changed: What|Removed |Added CC||khim at google dot com --- Comment #2 from Victor Khimenko --- Note that gcc looks bad even on the example from Microsoft's blog post: https://godbolt.org/z/Jc7TcN The fact that MSVC also looks bad on example from Microsoft is not really relevant, it's MSVC, after all. Blogpost itself is here: https://devblogs.microsoft.com/cppblog/simplify-your-code-with-rocket-science-c20s-spaceship-operator/
[Bug middle-end/95551] [OpenMP, OpenACC] -fopenmp/-fopenacc also with -foffload=disable fails with: (.gnu.offload_vars+0x0): undefined reference to `A.10.2'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95551 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Before IPA, we should be able to optimize away variables even if they are marked declare target to, as long as we optimize them away completely (i.e. neither the offloaded code nor host code will refer to them in any way), which suggests that perhaps we should be populating the variable and function tables for offloading later than we do now (basically immediately before IPA), but also once we enter something into the tables, we should mark those as being used such that e.g. IPA passes or anything later will not really optimize them away.
[Bug c++/95349] Using std::launder(p) produces unexpected behavior where (p) produces expected behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349 --- Comment #35 from Andrew Downing --- I agree that the new implicit object creation rules sound very difficult to implement correctly especially because the behavior in C is different. I'm curious to see how that will all play out. In this situation though, if we use the C rules for what memcpy does C17 6.5/6 https://web.archive.org/web/20181230041359if_/http://www.open-std.org/jtc1/sc22/wg14/www/abq/c17_updated_proposed_fdis.pdf#section.6.5, the effective type shouldn't be changed. The declared type of both objects is known to the compiler. In the first memcpy the declared type of the object is unsigned char[8], in the second memcpy the declared type of the object is double. Placement new changes the effective type to std::uint64_t, but that doesn't change the behavior of memcpy. Footnote 88 says "Allocated objects have no declared type.". I believe calling a function defined in another TU that returns a pointer also has to be considered to return a pointer to an object with no declared type, because the object's declaration isn't visible. In this situation though, the declared types are visible, and so a modifying access, or memcpy, or memmove shouldn't change the effective type. If gcc is changing the effective type with every memcpy no matter what, that would be the wrong thing to do right? Especially since you're saying that it's the reason that this example isn't being compiled correctly.
[Bug middle-end/95551] [OpenMP, OpenACC] -fopenmp/-fopenacc also with -foffload=disable fails with: (.gnu.offload_vars+0x0): undefined reference to `A.10.2'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95551
--- Comment #2 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #0)
> if (any (array /= [(-2*i, i = 1, 10)])) error stop 2
The A.10.2 is the array {-2,-4,...,-20} in static memory, which has been
removed with -O3 but there is still:
.offload_var_table:
.quad A.10.2
[Bug c++/95328] structured binding of template type inside template function is reported as "incomplete class type"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95328 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2020-06-05 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/95526] [11 Regression] aarch64: Wrong code accessing complex number from varargs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95526 Alex Coplan changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #8 from Alex Coplan --- *** Bug 95055 has been marked as a duplicate of this bug. ***
[Bug target/95055] [11 Regression] gcc.dg/compat/scalar-by-value-3 fails on aarch64 after r11-165-geb72dc663e9070b281be83a80f6f838a3a878822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95055 Alex Coplan changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #2 from Alex Coplan --- *** This bug has been marked as a duplicate of bug 95526 ***
[Bug target/95055] [11 Regression] gcc.dg/compat/scalar-by-value-3 fails on aarch64 after r11-165-geb72dc663e9070b281be83a80f6f838a3a878822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95055 Alex Coplan changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||acoplan at gcc dot gnu.org --- Comment #1 from Alex Coplan --- Hi Christophe, see PR95526: this should be fixed by ab56390384cd5168b548ff07e6f0c9c4d41420fb.
[Bug middle-end/95552] [11 Regression] VLA ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95552 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Summary|VLA ICE |[11 Regression] VLA ICE
[Bug middle-end/95552] VLA ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95552 David Edelsohn changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from David Edelsohn --- Confirmed.
[Bug middle-end/95552] VLA ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95552 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-06-05 Ever confirmed|0 |1 --- Comment #2 from David Edelsohn --- Confirmed.
[Bug middle-end/95552] New: VLA ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95552 Bug ID: 95552 Summary: VLA ICE Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org Target Milestone: --- Target: powerpc-ibm-aix* g++.dg/ext/vla3.C and g++.dg/cpp1y/vla8.C both now elicit during RTL pass: expand /nasfarm/edelsohn/src/src/gcc/testsuite/g++.dg/cpp1y/vla8.C:24:12: internal compiler error: in expand_expr_real_1, at expr.c:10160 ranges offset out of range
[Bug fortran/95509] [11 regression] gfortran.dg/spellcheck-operator.f90 fails after r11-875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95509 --- Comment #3 from Tom Tromey --- https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547388.html
[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95528 --- Comment #9 from rsandifo at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #8) > Created attachment 48683 [details] > gcc11-pr95528.patch > > Untested fix. The VECTOR_TYPE_P condition should be redundant. Looks good to me otherwise FWIW.
[Bug libstdc++/93542] std::future::wait_for should use monotonic clock
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93542 --- Comment #2 from Mike Crowe --- An updated version of the fix is available in https://gcc.gnu.org/pipermail/libstdc++/2020-May/050433.html which relies on https://gcc.gnu.org/pipermail/libstdc++/2020-May/050439.html .
[Bug libstdc++/91486] future::wait_for and shared_timed_mutex::wait_for do not work properly with float duration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91486 --- Comment #8 from Mike Crowe --- I think that https://gcc.gnu.org/pipermail/libstdc++/2020-May/050437.html fixes this for std::future::wait_for including the __chrono_detail part mentioned in comment 5.
[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95528 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Created attachment 48683 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48683=edit gcc11-pr95528.patch Untested fix.
[Bug middle-end/4210] should not warn in dead code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210 --- Comment #43 from Marc Glisse --- (In reply to Niels Möller from comment #42) > And what's the easiest way to run the the right compiler process (I guess > that's cc1) under gdb? gcc -c t.c -wrapper gdb,--args
[Bug lto/95548] ice in tree_to_shwi, at tree.c:7321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95548 --- Comment #4 from Jakub Jelinek --- On Fri, Jun 05, 2020 at 12:46:15PM +0200, Jan Hubicka wrote: > > I think Honza ran into this himself. > Yep, i converted code to use wide-ints. But it is nice to have short > testcase. For the testsuite perhaps also add another one with __int128_t and/or __uint128_t enumerators (guarded with #ifdef __SIZEOF_INT128__). Jakub
Re: [Bug lto/95548] ice in tree_to_shwi, at tree.c:7321
On Fri, Jun 05, 2020 at 12:46:15PM +0200, Jan Hubicka wrote: > > I think Honza ran into this himself. > Yep, i converted code to use wide-ints. But it is nice to have short > testcase. For the testsuite perhaps also add another one with __int128_t and/or __uint128_t enumerators (guarded with #ifdef __SIZEOF_INT128__). Jakub
Re: [Bug lto/95548] ice in tree_to_shwi, at tree.c:7321
> I think Honza ran into this himself. Yep, i converted code to use wide-ints. But it is nice to have short testcase. Honza
[Bug lto/95548] ice in tree_to_shwi, at tree.c:7321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95548 --- Comment #3 from Jan Hubicka --- > I think Honza ran into this himself. Yep, i converted code to use wide-ints. But it is nice to have short testcase. Honza
[Bug middle-end/95551] [OpenMP, OpenACC] -fopenmp/-fopenacc also with -foffload=disable fails with: (.gnu.offload_vars+0x0): undefined reference to `A.10.2'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95551 Tobias Burnus changed: What|Removed |Added Depends on||94848 --- Comment #1 from Tobias Burnus --- See also PR 94848 – the error is slightly different but similar enough that it might have the same cause. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94848 [Bug 94848] [Offloading][LTO] error due to only partially eliminated var / -ftree-pre causes link errors | libgomp.fortran/use_device_ptr-optional-3.f90 failures
[Bug middle-end/95551] New: [OpenMP, OpenACC] -fopenmp/-fopenacc also with -foffload=disable fails with: (.gnu.offload_vars+0x0): undefined reference to `A.10.2'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95551 Bug ID: 95551 Summary: [OpenMP, OpenACC] -fopenmp/-fopenacc also with -foffload=disable fails with: (.gnu.offload_vars+0x0): undefined reference to `A.10.2' Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: openacc, openmp, wrong-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- Loosely related to PR 95550 (for a variant of this test case, which fails with an ICE). The following test case fails to compile with -fopenmp or -fopenacc with: (.gnu.offload_vars+0x0): undefined reference to `A.10.2' at least when offloading to AMDGCN (for nvidia, one runs into PR 65181) and also with "-foffload=disable -O3". Note: In order to reproduce this issue, an offloading compiler has to be configured (configure-time set ENABLE_OFFLOADING has to evaluate to true) as otherwise no .gnu.offload_vars is generated. program main implicit none (type, external) integer :: j integer, allocatable :: A(:) A = [(3*j, j=1, 10)] call bar (A) deallocate (A) contains subroutine bar (array) integer :: i integer :: array(:) !$omp target map(from:array) !$acc parallel copyout(array) array = [(-2*i, i = 1, size(array))] !$omp do private(array) !$acc loop gang private(array) do i = 1, 10 array(i) = 9*i end do if (any (array /= [(-2*i, i = 1, 10)])) error stop 2 !$omp end target !$acc end parallel end subroutine bar end
[Bug middle-end/95550] New: [OpenACC] ICE in expand_oacc_for, at omp-expand.c:6075
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95550 Bug ID: 95550 Summary: [OpenACC] ICE in expand_oacc_for, at omp-expand.c:6075 Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: openacc Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- The following program gives an ICE with -fopenacc: 12 | !$acc loop private(A) | internal compiler error: in expand_oacc_for, at omp-expand.c:6075 0x6b9638 expand_oacc_for ../../repos/gcc-cs-og10-pre/gcc/omp-expand.c:6075 0xd6eadf expand_omp_for ../../repos/gcc-cs-og10-pre/gcc/omp-expand.c:6583 0xd6f5ea expand_omp ../../repos/gcc-cs-og10-pre/gcc/omp-expand.c:8912 program main implicit none (type, external) integer :: j, i integer, allocatable :: A(:) A = [(3*j, j=1, 10)] !$acc parallel create(A) A(:) = [(-2*i, i = 1, size(A))] !$acc loop private(A) do i = 1, 10 A(i) = 9*i end do !if (any (A /= [(-2*i, i = 1, 10)])) error stop 2 !$acc end parallel end
[Bug lto/95548] ice in tree_to_shwi, at tree.c:7321
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95548 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||marxin at gcc dot gnu.org Version|unknown |11.0 Component|c++ |lto --- Comment #2 from Richard Biener --- I think Honza ran into this himself.
[Bug ada/95549] [9/10/11 regression] gnat1 doesn't link on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95549 Richard Biener changed: What|Removed |Added Keywords||build Target Milestone|11.0|9.4
[Bug tree-optimization/95539] Vectorizer ICE in dr_misalignment, at tree-vectorizer.h:1433
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95539 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener --- Fixed.
[Bug tree-optimization/95539] Vectorizer ICE in dr_misalignment, at tree-vectorizer.h:1433
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95539 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:9758d196f57950ea89baa5cdf6ebd7125b5056e0 commit r11-967-g9758d196f57950ea89baa5cdf6ebd7125b5056e0 Author: Richard Biener Date: Fri Jun 5 10:13:27 2020 +0200 tree-optimization/95539 - fix SLP_TREE_REPRESENTATIVE vs. dr_info This fixes a disconnect between the stmt_info used for dr_info analysis and the one in SLP_TREE_REPRESENTATIVE with a temporary workaround. 2020-06-05 Richard Biener PR tree-optimization/95539 * tree-vect-data-refs.c (vect_slp_analyze_and_verify_instance_alignment): Use SLP_TREE_REPRESENTATIVE for the data-ref check. * tree-vect-stmts.c (vectorizable_load): Reset stmt_info back to the first scalar stmt rather than the SLP_TREE_REPRESENTATIVE to match previous behavior. * gcc.dg/vect/pr95539.c: New testcase.
[Bug target/95254] aarch64: gcc generate inefficient code with fixed sve vector length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95254 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED CC||rsandifo at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #3 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug target/95254] aarch64: gcc generate inefficient code with fixed sve vector length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95254 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:9a182ef9ee011935d827ab5c6c9a7cd8e22257d8 commit r11-966-g9a182ef9ee011935d827ab5c6c9a7cd8e22257d8 Author: Fei Yang Date: Fri Jun 5 10:34:59 2020 +0100 expand: Simplify removing subregs when expanding a copy [PR95254] In rtl expand, if we have a copy that matches one of the following patterns: (set (subreg:M1 (reg:M2 ...)) (subreg:M1 (reg:M2 ...))) (set (subreg:M1 (reg:M2 ...)) (mem:M1 ADDR)) (set (mem:M1 ADDR) (subreg:M1 (reg:M2 ...))) (set (subreg:M1 (reg:M2 ...)) (constant C)) where mode M1 is equal in size to M2, try to detect whether the mode change involves an implicit round trip through memory. If so, see if we can avoid that by removing the subregs and doing the move in mode M2 instead. 2020-06-05 Felix Yang gcc/ PR target/95254 * expr.c (emit_move_insn): Check src and dest of the copy to see if one or both of them are subregs, try to remove the subregs when innermode and outermode are equal in size and the mode change involves an implicit round trip through memory. gcc/testsuite/ PR target/95254 * gcc.target/aarch64/pr95254.c: New test. * gcc.target/i386/pr67609.c: Check "movq\t%xmm0" instead of "movdqa".
[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95528 --- Comment #7 from rsandifo at gcc dot gnu.org --- (In reply to rsand...@gcc.gnu.org from comment #6) > In summary: from an AArch64 perspective, it's probably fine to > check !VECTOR_MODE_P || VECTOR_BOOLEAN_TYPE_P. But given the V1 > thing, maybe it would be better to add || m == GET_MODE_INNER (m) > as well (unless that defeats the fix). Er, I mean: m == TYPE_MODE (TREE_TYPE (vectype)) or whatever. m == GET_MODE_INNER (m) is of course always true for scalars :-)
[Bug middle-end/95528] [10/11 Regression] internal compiler error: in emit_move_insn, at expr.c:3814
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95528 --- Comment #6 from rsandifo at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #4) > I'd say the vectorizer/simplify_vector_constructor just shouldn't attempt to > use these (e.g. vec_pack*, vec_unpack* optabs) for !VEC_MODE_P unless it is > VECTOR_BOOLEAN_TYPE_P type. > For i386 it would be the right thing as the patterns really assume that it > is vector booleans and have their properties. > Though, aarch64 seems to have vec_pack_trunc_di and vec_pack_trunc_df > expanders, it is unclear to me what they are for and if they are really used. > Other targets seem to only define these for vector modes. Yeah, I agree those look odd. The covering note for the patch that added them was: https://gcc.gnu.org/pipermail/gcc-patches/2013-April/361636.html which talks about fixing gcc.dg/vect failures. But as James says, only the 128-bit patterns should be needed for that. Maybe the the 64-bit patterns were just added for completeness. Perhaps one justification for _di is that there is no V1DI mode. Instead a vector of 1 DImode would itself have mode DImode. So in principle, vec_pack_trunc_di is probably the right name for a (V1)DI->V2SI truncate. The same doesn't apply to _df since we don't use scalar float modes for V1 vectors. And (unlike at the time of the patch) we now have V1DF. So I agree that the _df one looks dead. That said, for AArch64 we'd now try to mix 128-bit and 64-bit vectors instead of vectorising with 2 64-bit vectors. So the _di pattern probably isn't useful in practice either. In summary: from an AArch64 perspective, it's probably fine to check !VECTOR_MODE_P || VECTOR_BOOLEAN_TYPE_P. But given the V1 thing, maybe it would be better to add || m == GET_MODE_INNER (m) as well (unless that defeats the fix).
[Bug target/95535] Failure to optimize out cdqe after __bultin_ctz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95535 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:892b51cb73f24157391cd18c2215e8d703af97e7 commit r11-965-g892b51cb73f24157391cd18c2215e8d703af97e7 Author: Jakub Jelinek Date: Fri Jun 5 10:44:23 2020 +0200 ix86: Improve __builtin_c[lt]z followed by extension [PR95535] In January I've added patterns to optimize SImode -> DImode sign or zero extension of __builtin_popcount, this patch does the same for __builtin_c[lt]z. Like most other instructions, the [tl]zcntl instructions clear the upper 32 bits of the destination register and as the instructions only result in values 0 to 32 inclusive, both sign and zero extensions behave the same. 2020-06-05 Jakub Jelinek PR target/95535 * config/i386/i386.md (*ctzsi2_zext, *clzsi2_lzcnt_zext): New define_insn_and_split patterns. (*ctzsi2_zext_falsedep, *clzsi2_lzcnt_zext_falsedep): New define_insn patterns. * gcc.target/i386/pr95535-1.c: New test. * gcc.target/i386/pr95535-2.c: New test.
