[Bug tree-optimization/103761] [12 Regression] ICE in exact_div, at poly-int.h:2239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103761 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug fortran/55214] Program fail to evaluate where clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55214 Andrew Pinski changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #4 from Andrew Pinski --- *** Bug 64097 has been marked as a duplicate of this bug. ***
[Bug fortran/64097] Bug with nested WHERE constructs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64097 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Andrew Pinski --- Dup of bug 55214. *** This bug has been marked as a duplicate of bug 55214 ***
[Bug tree-optimization/103744] [12 Regression] ICE in operator[], at vec.h:889 since r12-5612-g10833849b55401a52f2334eb032a70beb688e9fc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103744 --- Comment #8 from Arseny Solokha --- (In reply to rsand...@gcc.gnu.org from comment #5) > (In reply to Arseny Solokha from comment #4) > > The apparently related case: > I think this is actually a separate bug. Could you open a new PR for it? I've just filed PR103761 for that.
[Bug tree-optimization/103761] New: [12 Regression] ICE in exact_div, at poly-int.h:2239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103761
Bug ID: 103761
Summary: [12 Regression] ICE in exact_div, at poly-int.h:2239
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64-linux-gnu
+++ This bug was initially created as a clone of Bug #103744 +++
gcc 12.0.0 alpha20211212 snapshot (g:0b52083ea2c2dd9897031fdc3802a68fd4aa45ef)
ICEs when compiling the following testcase w/ -mcpu=a64fx -O2
-fno-tree-scev-cprop:
short int *s;
int
foo (int r, int z)
{
int *a;
while (z < 1)
{
int i;
i = *s;
s += 2;
r += a[i];
r += a[i];
z += 1;
}
return r;
}
% aarch64-linux-gnu-gcc-12.0.0 -mcpu=a64fx -O2 -fno-tree-scev-cprop -c
egbadqtv.c
during GIMPLE pass: vect
egbadqtv.c: In function 'foo':
egbadqtv.c:4:1: internal compiler error: in exact_div, at poly-int.h:2239
4 | foo (int r, int z)
| ^~~
0x7dd13e poly_int<2u, poly_result::result_kind>::type>
exact_div<2u, unsigned long, unsigned long>(poly_int_pod<2u, unsigned long>
const&, poly_int_pod<2u, unsigned long> const&)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/poly-int.h:2239
0x7defbe poly_int<2u, poly_result::result_kind>::type>
exact_div<2u, unsigned long, unsigned long>(poly_int_pod<2u, unsigned long>
const&, poly_int_pod<2u, unsigned long> const&)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/poly-int.h:2242
0x7defbe vect_record_loop_mask(_loop_vec_info*, auto_vec*, unsigned int, tree_node*, tree_node*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vect-loop.c:9060
0x1c978ba vectorizable_load
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vect-stmts.c:8875
0x1c9fe6a vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*,
_slp_instance*, vec*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vect-stmts.c:11086
0x120b698 vect_slp_analyze_node_operations_1
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vect-slp.c:4481
0x120b698 vect_slp_analyze_node_operations
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vect-slp.c:4640
0x120b578 vect_slp_analyze_node_operations
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vect-slp.c:4620
0x120df26 vect_slp_analyze_operations(vec_info*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vect-slp.c:4879
0x11e609e vect_analyze_loop_2
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vect-loop.c:2412
0x11e7f32 vect_analyze_loop_1
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vect-loop.c:2830
0x11e84d1 vect_analyze_loop(loop*, vec_info_shared*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vect-loop.c:2952
0x121e227 try_vectorize_loop_1
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vectorizer.c:1047
0x121e227 try_vectorize_loop
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vectorizer.c:1162
0x121ef74 execute
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_p20211212/work/gcc-12-20211212/gcc/tree-vectorizer.c:1278
It was originally reported in PR103744 comment 4.
[Bug fortran/69695] slice of an array retains pointer attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69695 Andrew Pinski changed: What|Removed |Added Known to fail||10.3.0 Known to work||11.1.0 Keywords||needs-bisection --- Comment #4 from Andrew Pinski --- With -fsanitize=address,undefined I only get a leak detection starting in GCC 11. In GCC 10.3.0 I did get: = ==1==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60400038 at pc 0x00401891 bp 0x7ffd65e9dc40 sp 0x7ffd65e9dc38 READ of size 4 at 0x60400038 thread T0 #0 0x401890 in __point_MOD_ptest /app/example.f90:10 #1 0x4020cf in test /app/example.f90:23 #2 0x4020cf in main /app/example.f90:14 #3 0x7fdbefdea0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2) #4 0x4011fd in _start (/app/output.s+0x4011fd)
[Bug fortran/68101] Provide a way to allocate arrays aligned to 32 bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68101 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=55916, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=24261 Severity|normal |enhancement Keywords||missed-optimization
[Bug fortran/58002] [IR tracking] Pointer function results in non pointer context: Shall use a temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58002 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > Ifort also produces: > > 420 420 I should say using -stand f03 and -stand f95.
[Bug fortran/58002] [IR tracking] Pointer function results in non pointer context: Shall use a temporary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58002 --- Comment #2 from Andrew Pinski --- Ifort also produces: 420 420
[Bug fortran/56156] Reject calls to external procedures using non-module declared TYPEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56156 Andrew Pinski changed: What|Removed |Added Known to work||4.9.4 --- Comment #4 from Andrew Pinski --- Looks to be fixed before GCC 4.9.x.
[Bug driver/66765] gfortran passing fortran-specific options to ld and collect2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66765 Andrew Pinski changed: What|Removed |Added Keywords||rejects-valid Component|fortran |driver --- Comment #10 from Andrew Pinski --- This is definitely a driver issue. I don't know if we have fixed this one yet or not. I suspect it is still there. I think the driver should get rid of the non-C front-end acceptable options when passing them down to collect2.
[Bug fortran/45396] Apply front-end pass also for arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45396 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug fortran/49331] Accepts invalid specification expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49331 --- Comment #3 from Andrew Pinski --- (In reply to Tobias Burnus from comment #0) > gfortran currently compiles http://www.fortran.com/iso_varying_string.f95 > with -std=f2003 without any error. File does not exist any more :(. (In reply to Dominique d'Humieres from comment #2) > For the second test in comment 1, I get the following errors (r208766) Same behavior with the trunk. Also ifort has the same behavior as GCC including accepting the first test in comment #1.
[Bug fortran/57079] [Fortran-dev] version/type/attribute fields not set with CLASS components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57079
--- Comment #3 from Andrew Pinski ---
Something changed in GCC 8 and we get:
:
x_22 = __builtin_malloc (144);
if (x_22 == 0B)
goto ; [INV]
else
goto ; [INV]
:
_gfortran_os_error (&"Allocation would exceed memory limit"[1]{lb: 1 sz: 1});
...
And no more __builtin_calloc either.
[Bug fortran/57611] [Fortran-Dev Regression] Too much memory allocated (gfortran.dg/coarray_lib_alloc_2.f90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57611 --- Comment #2 from Andrew Pinski --- I can't reproduce this even in GCC 4.9.4.
[Bug fortran/49592] [OOP] Non-polymorphic ALLOCATE with polymorphic SOURCE= rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49592 Andrew Pinski changed: What|Removed |Added Known to fail||5.5.0 Known to work||6.3.0 --- Comment #2 from Andrew Pinski --- Seems to be fixed in GCC 6+.
[Bug fortran/45425] Bounds check applied before MASK of WHERE construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45425 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Last reconfirmed|2010-08-28 19:51:18 |2021-12-17 Known to fail|| --- Comment #4 from Andrew Pinski --- We also now get a warning since GCC 8 too: /app/example.f90:10:10: 8 | do i = 2, 2 | 2 9 | where (mask) 10 | A = b(i) | 1 Warning: Array reference at (1) out of bounds (2 > 1) in loop beginning at (2) /app/example.f90:10:10: 8 | do i = 2, 2 | 2 9 | where (mask) 10 | A = b(i) | 1 Warning: Array reference at (1) out of bounds (2 > 1) in loop beginning at (2)
[Bug fortran/43837] Set TREE_NOTHROW also on libgfortran library calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43837 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug fortran/43172] Unnecessary array temporary - non-pointer/non-target does not alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43172 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2010-02-25 12:42:15 |2021-12-17
[Bug fortran/41911] Unnecessary copying of array descriptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41911 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed|2009-11-02 19:29:47 |2021-12-17
[Bug fortran/88404] ICE (tree check) with -fsanitize=thread on Fortran2003 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88404 Andrew Pinski changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #4 from Andrew Pinski --- *** Bug 77390 has been marked as a duplicate of this bug. ***
[Bug fortran/77390] generates INDIRECT_REF of void type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77390 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|WAITING |RESOLVED --- Comment #3 from Andrew Pinski --- Even though this bug report is older, PR 88404 has more information and even a testcase of where an indirect reference of a void can cause issues. *** This bug has been marked as a duplicate of bug 88404 ***
[Bug c/103649] -Wno-attribute=foo::bar implies no arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103649 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Marek Polacek --- Fixed.
[Bug c/103649] -Wno-attribute=foo::bar implies no arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103649
--- Comment #1 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:6afb8a68a9113897ccf39e40983e042ed90d7aed
commit r12-6052-g6afb8a68a9113897ccf39e40983e042ed90d7aed
Author: Marek Polacek
Date: Thu Dec 16 16:29:41 2021 -0500
attribs: Fix wrong error with -Wno-attribute=A::b [PR103649]
My patch to implement -Wno-attribute=A::b caused a bogus error when
parsing
[[foo::bar(1, 2)]];
when -Wno-attributes=foo::bar was specified on the command line, because
when we create a fake foo::bar attribute and insert it into our attribute
table, it is created with max_length == 0 which doesn't allow any args.
That is wrong -- we know nothing about the attribute, so we shouldn't
require any specific number of arguments. And since unknown attributes
can be rather complex (see for example omp::{directive,sequence}), we
must skip parsing their arguments. To that end, I'm using max_length
with value -2.
Also let's not warn about things like
[[vendor::assume(true)]];
because they may have some meaning (this is reminiscent of C++ Portable
Assumptions).
PR c/103649
gcc/ChangeLog:
* attribs.c (handle_ignored_attributes_option): Create the fake
attribute with max_length == -2.
(attribute_ignored_p): New overloads.
* attribs.h (attribute_ignored_p): Declare them.
* tree-core.h (struct attribute_spec): Document that max_length
can be -2.
gcc/c/ChangeLog:
* c-decl.c (c_warn_unused_attributes): Don't warn for
attribute_ignored_p.
* c-parser.c (c_parser_std_attribute): Skip parsing of the
attribute
arguments when the attribute is ignored.
gcc/cp/ChangeLog:
* parser.c (cp_parser_declaration): Don't warn for
attribute_ignored_p.
(cp_parser_std_attribute): Skip parsing of the attribute
arguments when the attribute is ignored.
gcc/testsuite/ChangeLog:
* c-c++-common/Wno-attributes-6.c: New test.
[Bug fortran/103412] [10/11/12 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103412 --- Comment #5 from Steve Kargl --- On Fri, Dec 17, 2021 at 09:07:44PM +, anlauf at gcc dot gnu.org wrote: > > --- Comment #4 from anlauf at gcc dot gnu.org --- > Alternative patch: > Either patch fixes the problem and I'll offer that they both fall under the "obvious" label. Pick one and commit.:wq
[Bug fortran/77415] ICE: tree check: expected function_type or method_type, have pointer_type in create_function_arglist, at fortran/trans-decl.c:2263
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77415 Andrew Pinski changed: What|Removed |Added Known to work||10.1.0 --- Comment #3 from Andrew Pinski --- Seems to have been fixed in GCC 9.3.0, 10+.
[Bug fortran/66907] Correct code produces "Segmentation fault - invalid memory reference"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66907 Andrew Pinski changed: What|Removed |Added Known to work||11.1.0 Known to fail||10.3.0 --- Comment #3 from Andrew Pinski --- Seems to be fixed in GCC 11+.
[Bug fortran/55824] [OOP] ICE with ALLOCATE and SOURCE= TRANSPOSE/RESHAPE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55824 Andrew Pinski changed: What|Removed |Added Known to work||7.1.0 Known to fail||5.5.0, 6.3.0 --- Comment #7 from Andrew Pinski --- Seems to be working in GCC 7+.
[Bug fortran/103590] ICE: find_array_spec(): Missing spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103590 Andrew Pinski changed: What|Removed |Added Known to fail||4.9.4 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-12-17 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug fortran/103610] ICE in gfc_convert_mpz_to_signed, at fortran/simplify.c:193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103610 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/103610] ICE in gfc_convert_mpz_to_signed, at fortran/simplify.c:193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103610 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:1062d2b022575e2ab942236478029cd637f937a5 commit r9-9875-g1062d2b022575e2ab942236478029cd637f937a5 Author: Harald Anlauf Date: Tue Dec 7 23:06:41 2021 +0100 Fortran: dimensions of an array have to be non-negative gcc/fortran/ChangeLog: PR fortran/103610 * array.c (spec_dimen_size): Fix simplification of SHAPE: dimensions must be non-negative. gcc/testsuite/ChangeLog: PR fortran/103610 * gfortran.dg/shape_11.f90: New test. (cherry picked from commit 5f7cdea34e118776d0ccd2ff3dda0f5acab18a94)
[Bug fortran/103610] ICE in gfc_convert_mpz_to_signed, at fortran/simplify.c:193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103610 --- Comment #8 from anlauf at gcc dot gnu.org --- *** Bug 103260 has been marked as a duplicate of this bug. ***
[Bug fortran/103260] ICE in gfc_simplify_reshape, at fortran/simplify.c:6857 since r6-4614-g57e596204fceef2e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103260 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from anlauf at gcc dot gnu.org --- It is actually a duplicate of PR103610. *** This bug has been marked as a duplicate of bug 103610 ***
[Bug fortran/103610] ICE in gfc_convert_mpz_to_signed, at fortran/simplify.c:193
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103610 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:a28d6903677629c23bac53ff061eb80f22d51006 commit r10-10346-ga28d6903677629c23bac53ff061eb80f22d51006 Author: Harald Anlauf Date: Tue Dec 7 23:06:41 2021 +0100 Fortran: dimensions of an array have to be non-negative gcc/fortran/ChangeLog: PR fortran/103610 * array.c (spec_dimen_size): Fix simplification of SHAPE: dimensions must be non-negative. gcc/testsuite/ChangeLog: PR fortran/103610 * gfortran.dg/shape_11.f90: New test. (cherry picked from commit 5f7cdea34e118776d0ccd2ff3dda0f5acab18a94)
[Bug fortran/103260] ICE in gfc_simplify_reshape, at fortran/simplify.c:6857 since r6-4614-g57e596204fceef2e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103260 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Status|NEW |WAITING --- Comment #3 from anlauf at gcc dot gnu.org --- Does no longer appear on trunk at r12-6050.
[Bug tree-optimization/103759] [12 Regression] memcpy-chk failure for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103759 --- Comment #2 from Siddhesh Poyarekar --- I've posted a candidate fix: https://patchwork.sourceware.org/project/gcc/patch/20211217212347.72617-1-siddh...@gotplt.org/
[Bug c++/103760] Invalid expression inside lambda inside compound requirement causes an error instead of concept satisfaction failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103760 Andrew Pinski changed: What|Removed |Added Keywords||rejects-valid --- Comment #1 from Andrew Pinski --- MSVC also rejects this code for the same reason as GCC ...
[Bug fortran/103412] [10/11/12 Regression] ICE: Invalid expression in gfc_element_size since r10-2083-g8dc63166e0b85954
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103412 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- Alternative patch: diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c index 3934336df2e..625473c90d1 100644 --- a/gcc/fortran/check.c +++ b/gcc/fortran/check.c @@ -5135,6 +5135,9 @@ gfc_check_sizeof (gfc_expr *arg) return false; } + if (illegal_boz_arg (arg)) +return false; + /* TYPE(*) is acceptable if and only if it uses an array descriptor. */ if (arg->ts.type == BT_ASSUMED && (arg->symtree->n.sym->as == NULL
[Bug libstdc++/103755] {has,use}_facet() and iostream constructor performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755 --- Comment #4 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #3) > Created attachment 52025 [details] > Alternative implementation v2 > > The diagnostic regression is easy to fix with a static assertion before > calling __try_use_facet. Although that causes errors for certain uses of streams without including , specifically when building the library. Also I forgot to say that I can still reproduce approx. 3x speedup using my patch. Before: BM_sstream_construct288 ns 287 ns 2525913 BM_fstream_construct319 ns 318 ns 2204065 After: BM_sstream_construct 99.5 ns 99.1 ns 6512679 BM_fstream_construct108 ns 107 ns 6536463
[Bug c++/103760] New: Invalid expression inside lambda inside compound requirement causes an error instead of concept satisfaction failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103760
Bug ID: 103760
Summary: Invalid expression inside lambda inside compound
requirement causes an error instead of concept
satisfaction failure
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jacek.olczyk98 at gmail dot com
Target Milestone: ---
When using a lambda expression in a requires clause compound requirement,
placing an expression invalid for some type T inside the lambda causes a
compile error during instantiation, instead of the expected behavior of causing
the concept to not be satisfied.
On clang, the behavior is as expected.
This happens on 10.2, where I discovered it, as well as on trunk.
Here is the code: https://godbolt.org/z/EnK5G8Yjf
To save a click, the example code is:
template
concept Concept = requires (T x) {
{[](){ return T::foo; }()};
};
static_assert(!Concept);
The expected behavior is to pass the static_assert.
The actual error is:
: In lambda function:
:3:22: error: 'foo' is not a member of 'int'
3 | {[](){ return T::foo; }()};
| ^~~
[Bug c++/92944] [concepts] redefinition error when using constrained structure template inside namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92944 --- Comment #2 from Ed Catmur --- Sorry, meant to link this: https://quuxplusone.github.io/blog/2021/10/27/dont-reopen-namespace-std/
[Bug c++/103681] [9/10/11 Regression] Unusual behavior for tail padding with different c++ standards and NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103681 Jason Merrill changed: What|Removed |Added Summary|[9/10/11/12 Regression] |[9/10/11 Regression] |Unusual behavior for tail |Unusual behavior for tail |padding with different c++ |padding with different c++ |standards and NSDMI |standards and NSDMI Known to fail|12.0| Known to work||12.0 Severity|blocker |major --- Comment #4 from Jason Merrill --- Fixed for GCC 12 so far.
[Bug c++/83264] std::initializer_list with a single element selects the wrong overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83264
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|1 |0
Resolution|INVALID |---
Status|RESOLVED|UNCONFIRMED
--- Comment #7 from Andrew Pinski ---
The example at the end of the change of DR 1467:
Example:
void f1(int); // #1
void f1(std::initializer_list); // #2
void g1() { f1({42}); } // chooses #2
void f2(std::pair); // #3
void f2(std::initializer_list); // #4
void g2() { f2({"foo","bar"}); } // chooses #4
—end example]
http://www.open-std.org/cwg1589 is also this one too.
Plus http://www.open-std.org/cwg2076
Note I don't think constructor of A matter, it could be a function instead,
e.g.:
#include
#include
using namespace std;
struct UdfInt {
UdfInt(int) {}
};
void f(int)
{
cout << "f(int)\n";
}
void f(UdfInt)
{
cout << "f(initializer_list)\n";
}
void f(std::initializer_list)
{
cout << "f(initializer_list)\n";
}
int main() {
f({10});
return 0;
}
GCC prints f(initializer_list) while all the rest of the compilers print
A(int).
The big question initializer_list a better conversion from
initializer_list than int.
I think the answer is yes.
The example in DR 1467 shows that the conversion from initializer_list to
initializer_list is better than the conversion from initializer_list
to int (clang implements that, ICC and MSVC do not).
I think the language change in end of DR 1467 is what applies here the most:
even if one of the other rules in this paragraph would otherwise apply.
Also if we take:
#include
#include
#include
using namespace std;
#if 0
static void f(const char*)
{
cout << "f(const char*)\n";
}
#endif
static void f(std::string)
{
cout << "f(std::string)\n";
}
static void f(std::initializer_list)
{
cout << "f(initializer_list)\n";
}
int main() {
f({"10"});
return 0;
}
Right now all compilers agree f(initializer_list) but once we add in f(const
char*), GCC still selects f(initializer_list) while ICC/MSVC/clang select
f(const char*). That seems a bit odd.
[Bug tree-optimization/26854] Inordinate compile times on large routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 --- Comment #141 from lucier at math dot purdue.edu --- Created attachment 52027 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52027=edit CPU and Memorty usage reports for compilling all.i, _num.i, and compiler.i
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #17 from lucier at math dot purdue.edu --- (In reply to lucier from comment #16) > Created attachment 52026 [details] > CPU and Memorty usage reports for compilling all.i, _num.i, and compiler.i Sorry, added comment to wrong PR.
[Bug middle-end/51446] -fno-trapping-math generates NaN constant with different sign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51446 --- Comment #16 from lucier at math dot purdue.edu --- Created attachment 52026 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52026=edit CPU and Memorty usage reports for compilling all.i, _num.i, and compiler.i
[Bug tree-optimization/26854] Inordinate compile times on large routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 --- Comment #140 from lucier at math dot purdue.edu --- (In reply to Andrew Pinski from comment #139) > Does anyone have recent #s on this testcase? I downloaded all.i.gz from https://www.math.purdue.edu/~lucier/gcc/test-files/bugzilla/1/ and _num.i.gz and compiler.i.gz from https://www.math.purdue.edu/~lucier/bugzilla/8/ (For some reason I had to gunzip them twice to get the .i files.) I then compiled them with, e.g., heine:~/Downloads/gcc-tests> /pkgs/gcc-mainline/bin/gcc -v -c -O2 -fmem-report -ftime-report compiler.i -save-temps > & ! report-compiler3 with today's github head: heine:~/Downloads/gcc-tests> /pkgs/gcc-mainline/bin/gcc -v Using built-in specs. COLLECT_GCC=/pkgs/gcc-mainline/bin/gcc COLLECT_LTO_WRAPPER=/pkgs/gcc-mainline/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../../gcc-mainline/configure --prefix=/pkgs/gcc-mainline --enable-checking=release --enable-languages=c --disable-multilib --enable-gather-detailed-mem-stats Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.0 20211217 (experimental) (GCC) I'll attach a tar file that contains the time and space results. Brad
[Bug c++/95949] mame build succeeds with -O3 but fails with -O2 and all -O3 flags added manually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95949 --- Comment #11 from Julian Sikorski --- I can still reproduce this with mame master (0b418d65bae66baa9f334c6daa6dcb4148909f7f) and mingw-w64-x86_64-gcc 11.2.0-5.
[Bug tree-optimization/103759] [12 Regression] memcpy-chk failure for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103759 Siddhesh Poyarekar changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |siddhesh at gcc dot gnu.org
[Bug c++/103758] bogus warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug tree-optimization/103759] [12 Regression] memcpy-chk failure for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103759 David Edelsohn changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-12-17 Status|UNCONFIRMED |NEW --- Comment #1 from David Edelsohn --- Confirmed
[Bug tree-optimization/103759] New: [12 Regression] memcpy-chk failure for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103759 Bug ID: 103759 Summary: [12 Regression] memcpy-chk failure for 32 bits Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org Target Milestone: --- Target: powerpc-*-* i386-*-* memcpy-chk, memmove-chk, mempcpy-chk, memset-chk, stpcpy-chk test cases now all fail in 32 bit mode. https://gcc.gnu.org/pipermail/gcc-testresults/2021-December/742567.html https://gcc.gnu.org/pipermail/gcc-testresults/2021-December/742553.html https://gcc.gnu.org/pipermail/gcc-testresults/2021-December/742564.html https://gcc.gnu.org/pipermail/gcc-testresults/2021-December/742535.html between r12-6029 and r12-6031
[Bug c++/103749] Misleading error message on template/non-template conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103749 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Marek Polacek --- Fixed.
[Bug c++/103749] Misleading error message on template/non-template conflict
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103749
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:fae016862631da70e6482fe3173a111248f8b9bc
commit r12-6049-gfae016862631da70e6482fe3173a111248f8b9bc
Author: Marek Polacek
Date: Thu Dec 16 14:57:07 2021 -0500
c++: Improve diagnostic for class tmpl/class redecl [PR103749]
For code like
template
struct bar;
struct bar {
int baz;
};
bar var;
we emit a fairly misleading and unwieldy diagnostic:
~
$ g++ -c u.cc
u.cc:6:8: error: template argument required for 'struct bar'
6 | struct bar {
|^~~
u.cc:10:5: error: class template argument deduction failed:
10 | bar var;
| ^~~
u.cc:10:5: error: no matching function for call to 'bar()'
u.cc:3:17: note: candidate: 'template bar()-> bar<
>'
3 | friend struct bar;
| ^~~
u.cc:3:17: note: template argument deduction/substitution failed:
u.cc:10:5: note: couldn't deduce template parameter
''
10 | bar var;
| ^~~
u.cc:3:17: note: candidate: 'template bar(bar<
>)-> bar< >'
3 | friend struct bar;
| ^~~
u.cc:3:17: note: template argument deduction/substitution failed:
u.cc:10:5: note: candidate expects 1 argument, 0 provided
10 | bar var;
| ^~~
~
but with this patch we get:
~
z.C:4:10: error: class template 'bar' redeclared as non-template
4 | struct bar {
| ^~~
z.C:2:10: note: previous declaration here
2 | struct bar;
| ^~~
z.C:8:7: error: 'bar<...auto...> var' has incomplete type
8 | bar var;
| ^~~
~
which is clearer about what the problem is.
I thought it'd be nice to avoid printing the messages about failed CTAD,
too. To that end, I'm using CLASSTYPE_ERRONEOUS to suppress CTAD. Not
sure if that's entirely kosher.
The other direction (first a non-template class declaration followed by
a class template definition) we handle quite well:
~
z.C:11:8: error: 'bar' is not a template
11 | struct bar {};
|^~~
z.C:8:8: note: previous declaration here
8 | struct bar;
|^~~
~
PR c++/103749
gcc/cp/ChangeLog:
* decl.c (lookup_and_check_tag): Give an error when a class was
declared as template but no template header has been provided.
* pt.c (do_class_deduction): Don't deduce CLASSTYPE_ERRONEOUS
types.
gcc/testsuite/ChangeLog:
* g++.dg/template/redecl4.C: Adjust dg-error.
* g++.dg/diagnostic/redeclaration-2.C: New test.
[Bug c++/102051] [coroutines] ICE in gimplify_var_or_parm_decl, at gimplify.c:2848
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102051 Iain Sandoe changed: What|Removed |Added Last reconfirmed||2021-12-17 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1
[Bug libstdc++/103755] {has,use}_facet() and iostream constructor performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755 Jonathan Wakely changed: What|Removed |Added Attachment #52024|0 |1 is obsolete|| --- Comment #3 from Jonathan Wakely --- Created attachment 52025 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52025=edit Alternative implementation v2 The diagnostic regression is easy to fix with a static assertion before calling __try_use_facet.
[Bug target/103624] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624 Segher Boessenkool changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #12 from Segher Boessenkool --- Fixed on trunk. No backports planned.
[Bug target/103624] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624 --- Comment #11 from CVS Commits --- The master branch has been updated by Segher Boessenkool : https://gcc.gnu.org/g:87ae8d7613a8b15d0d729b38ffd49153f1314799 commit r12-6048-g87ae8d7613a8b15d0d729b38ffd49153f1314799 Author: Segher Boessenkool Date: Fri Dec 17 17:01:16 2021 + rs6000: Update darn testcases Make the darn testcases work (and be tested) in 32-bit mode as well. They used to ICE, but they no longer do. 2021-12-17 Segher Boessenkool gcc/testsuite/ PR target/103624 * gcc.target/powerpc/darn-0.c: Remove target clause. * gcc.target/powerpc/darn-1.c: Remove target clause. Remove lp64 requirement. Change return type to long. * gcc.target/powerpc/darn-2.c: Ditto. * gcc.target/powerpc/darn-3.c: Remove target clause.
[Bug target/103624] ICE: in extract_insn, at recog.c:2769 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103624
--- Comment #10 from CVS Commits ---
The master branch has been updated by Segher Boessenkool :
https://gcc.gnu.org/g:7194397966e6a007cee42360f96834377c3121a4
commit r12-6047-g7194397966e6a007cee42360f96834377c3121a4
Author: Segher Boessenkool
Date: Fri Dec 17 16:59:55 2021 +
rs6000: Redo darn (PR103624)
The builtins now all return "long". The patterns have :GPR as the
output mode, so they can be 32-bit as well (the instruction makes sense
in 32 bit just fine). The builtins expand to the DImode version
normally, but to the SImode if {32bit} is true.
2021-12-17 Segher Boessenkool
PR target/103624
* config/rs6000/rs6000-builtins.def (__builtin_darn): Expand to
darn_64_di. Add {32bit} attribute. Return long.
(__builtin_darn_32): Expand to darn_32_di. Add {32bit} attribute.
Return long.
(__builtin_darn_raw): Expand to darn_raw_di. Add {32bit}
attribute.
Return long.
* config/rs6000/rs6000-call.c (rs6000_expand_builtin): Expand the
darn
builtins to the _si variants for -m32.
* config/rs6000/rs6000.md (UNSPECV_DARN_32, UNSPECV_DARN_RAW):
Delete.
(UNSPECV_DARN): Update comment.
(darn_32, darn_raw, darn): Delete.
(darn_32_, darn_64_, darn_raw_ for GPR): New.
(@darn for GPR): New.
[Bug c++/103758] bogus warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758
--- Comment #2 from Marek Polacek ---
Incidentally, this
error ("% invalid in condition");
in cp_parser_decl_specifier_seq should be adjusted as well.
[Bug c++/103758] bogus warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-12-17 Ever confirmed|0 |1 --- Comment #1 from Jason Merrill --- Agreed.
[Bug c++/103758] New: bogus warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758 Bug ID: 103758 Summary: bogus warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag] Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org CC: jason at gcc dot gnu.org Target Milestone: --- Every time I compile GCC I see: gcc/cp/parser.c: In function ‘void cp_parser_decl_specifier_seq(cp_parser*, cp_parser_flags, cp_decl_specifier_seq*, int*)’: /home/mpolacek/src/gcc/gcc/cp/parser.c:15923:55: warning: misspelled term ‘decl’ in format; use ‘declaration’ instead [-Wformat-diag] 15923 | "standard attributes in middle of decl-specifiers"); | ^~~~ /home/mpolacek/src/gcc/gcc/cp/parser.c:15925:57: warning: misspelled term ‘decl’ in format; use ‘declaration’ instead [-Wformat-diag] 15925 | "standard attributes must precede the decl-specifiers to " | ^~~~ but I don't want to, "decl-specifiers" is a grammar production. It is not code, so should not be wrapped inside of %< %>. I'd like my compilation to be free of warnings, otherwise I'm going to miss some important ones. The warning should not warn on "decl-specifier*".
[Bug c++/103754] [11,12][ice][modules] import bits/stdc++.h and map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103754 --- Comment #5 from Egor Pugin --- (In reply to Andrew Pinski from comment #3) > Sadly it looks like modules are no where near prime time. Seems so. I set up my tooling and trying to play with them, but there are a lot of issues. Does someone working on fixing those items from meta-ticket? Maybe I'll try to study the code and fix something.
[Bug ipa/103734] IPA-CP opportunity for imagick in SPECCPU 2017
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103734 pthaugen at gcc dot gnu.org changed: What|Removed |Added CC||pthaugen at gcc dot gnu.org --- Comment #3 from pthaugen at gcc dot gnu.org --- (In reply to Hongtao.liu from comment #2) > (In reply to Tamar Christina from comment #0) > > When using --param ipa-cp-eval-threshold=1 --param ipa-cp-unit-growth=20 on > > imagick the hot functions MorphologyApply and GetVirtualPixelsFromNexus get > > replaced by specialized versions that are much smaller and faster. > > > > Some other benchmarks like leela also get very small uplifts but the imagick > > one is worth 14%. Both flags seem to be needed. > > Observe similar thing on ICX with -param=inline-min-speedup=3 I tested on a Power9 system and see the following improvements: --param ipa-cp-eval-threshold=1 --param ipa-cp-unit-growth=20 : +5% -param=inline-min-speedup=3 : +30%
[Bug libstdc++/103755] {has,use}_facet() and iostream constructor performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103755 --- Comment #2 from Jonathan Wakely --- Created attachment 52024 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52024=edit Alternative implementation This seems like a much simpler approach. This causes 22_locale/ctype/is/string/89728_neg.cc to fail for C++98/11/14 modes, because without 'if constexpr' the body of __try_use_facet creates dozens of errors, rather than just one from the current definition of use_facet. That isn't the end of the world, but it's a regression in diagnostic quality.
[Bug c++/103358] what is the first constructor argument of lambda coroutine promise_type?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103358 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #1 from Iain Sandoe --- There was a long discussion about this between the various WG21 paper authors. The stated intend was that 'this' pointer and the 'lambda object pointer' were intended to be cast to references (to the same type as their pointers). This behaviour should be the same between MSVC, clang and GCC (but I fear that the amendment did not make C++20 timescale - so we might need a coordinated change to remove it from the compilers). Does that explain what you are seeing?
[Bug c++/83264] std::initializer_list with a single element selects the wrong overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83264 --- Comment #6 from Jonathan Wakely --- I don't know what the "right" behaviour is. I don't think any compiler except GCC actually implements 2137, as it causes problems. I'm not even sure if this is a case where 2137 applies!
[Bug c++/100772] Templated coroutine new function's arguments have incorrect value categories/overload selection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100772 Iain Sandoe changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED CC||iains at gcc dot gnu.org Last reconfirmed||2021-12-17 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org --- Comment #3 from Iain Sandoe --- fixed on master so far
[Bug c++/100127] [coroutines] internal compiler error compiling promise with custom awaiter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100127 --- Comment #5 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:2466a8d0dd40d05cb4a239d7d4a21bbd9ffab698 commit r12-6046-g2466a8d0dd40d05cb4a239d7d4a21bbd9ffab698 Author: Iain Sandoe Date: Sat Oct 2 17:20:08 2021 +0100 coroutines: Handle initial awaiters with non-void returns [PR 100127]. The way in which a C++20 coroutine is specified discards any value that might be returned from the initial or final await expressions. This ICE was caused by an initial await expression with an await_resume () returning a reference, the function rewrite code was not set up to expect this. Fixed by looking through any indirection present and by explicitly discarding the value, if any, returned by await_resume(). It does not seem useful to make a diagnostic for this, since the user could define a generic awaiter that usefully returns values when used in a different position from the initial (or final) await expressions. Signed-off-by: Iain Sandoe PR c++/100127 gcc/cp/ChangeLog: * coroutines.cc (coro_rewrite_function_body): Handle initial await expressions that try to produce a reference value. gcc/testsuite/ChangeLog: * g++.dg/coroutines/pr100127.C: New test.
[Bug c++/100772] Templated coroutine new function's arguments have incorrect value categories/overload selection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100772 --- Comment #2 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:921942a8a106cb53994c21162922e4934eb3a3e0 commit r12-6045-g921942a8a106cb53994c21162922e4934eb3a3e0 Author: Iain Sandoe Date: Sun Oct 3 19:46:09 2021 +0100 coroutines: Pass lvalues to user-defined operator new [PR 100772]. The wording of the standard has been clarified to be explicit that the the parameters to any user-defined operator-new in the promise class should be lvalues. Signed-off-by: Iain Sandoe PR c++/100772 gcc/cp/ChangeLog: * coroutines.cc (morph_fn_to_coro): Convert function parms from reference before constructing any operator-new args list. gcc/testsuite/ChangeLog: * g++.dg/coroutines/pr100772-a.C: New test. * g++.dg/coroutines/pr100772-b.C: New test.
[Bug c++/96517] ICE in is_this_parameter when accessing constexpr method of a field inside coroutine lambda (with optimization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96517 --- Comment #3 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:39d2ec41509e3b0d130215a65d7aacbd064b5532 commit r12-6044-g39d2ec41509e3b0d130215a65d7aacbd064b5532 Author: Iain Sandoe Date: Fri Oct 15 09:42:25 2021 +0100 coroutines, c++: Add test for PR 96517. This PR was fixed by r12-5255-gdaa9c6b015, this adds the testcase. Signed-off-by: Iain Sandoe gcc/testsuite/ChangeLog: PR c++/96517 * g++.dg/coroutines/pr96517.C: New test.
[Bug fortran/103757] [F18] compiler rejects import, {none, all, only}, does not recognize the keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103757
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords||rejects-valid
Summary|compiler rejects import,|[F18] compiler rejects
|{none,all,only}, does not |import, {none,all,only},
|recognize the keyword |does not recognize the
||keyword
Ever confirmed|0 |1
Last reconfirmed||2021-12-17
Priority|P3 |P4
--- Comment #2 from anlauf at gcc dot gnu.org ---
Confirmed. New in F2018.
[Bug c++/83264] std::initializer_list with a single element selects the wrong overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83264 --- Comment #5 from Ruslan Altynbaev --- Actually DR 2137 describes that: https://wg21.link/cwg2137
[Bug middle-end/102080] [12 Regression] avx512vl related ICE, on firefox-92 gcc ICEs: in expand_insn, at optabs.c:7946 by r12-2679
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #17 from H.J. Lu --- Fixed.
[Bug middle-end/102080] [12 Regression] avx512vl related ICE, on firefox-92 gcc ICEs: in expand_insn, at optabs.c:7946 by r12-2679
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102080 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #16 from Jakub Jelinek --- So fixed?
[Bug c++/84573] missing warning on an uninstantiated function template returning T with no return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84573
Martin Sebor changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #4 from Martin Sebor ---
I believe the warning would be helpful because as I mentioned in comment #0:
...the only valid specialization of such a template is one where T = void
it's likely that the missing return statement is a mistake...
A function template that returns a template argument should be defined that way
even if it's meant to be instantiated on void:
template
T g () { return T (); } // valid for any default-constructible type, even
void
void h () { return g(); } // valid
Warning for a missing return statement would be helpful in template libraries
that rarely instantiate all their code either during a build or in their tests.
[Bug target/103750] [i386] GCC schedules KMOV instructions that destroys performance in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103750 --- Comment #9 from Uroš Bizjak --- (In reply to Thiago Macieira from comment #0) > Testcase: ... > The assembly for this produces: > > vmovdqu16 (%rdi), %ymm1 > vmovdqu16 32(%rdi), %ymm2 > vpcmpuw $0, %ymm0, %ymm1, %k0 > vpcmpuw $0, %ymm0, %ymm2, %k1 > kmovw %k0, %edx > kmovw %k1, %eax > kortestw%k1, %k0 > je .L10 > > Those two KMOVW instructions aren't required for the check that follows. > They're also dispatched on port 0, same as the KORTESTW, meaning the KORTEST > can't be dispatched until those two have executed, thus introducing a > 2-cycle delay in this loop. These are not NOP moves but zero-extensions. vmovdqu16 (%rdi), %ymm1 # 93[c=17 l=6] movv16hi_internal/2 vmovdqu16 32(%rdi), %ymm2 # 94[c=21 l=7] movv16hi_internal/2 vpcmpuw $0, %ymm0, %ymm1, %k0 # 21[c=4 l=7] avx512vl_ucmpv16hi3 vpcmpuw $0, %ymm0, %ymm2, %k1 # 27[c=4 l=7] avx512vl_ucmpv16hi3 kmovw %k0, %edx # 30[c=4 l=4] *zero_extendhisi2/1 kmovw %k1, %eax # 29[c=4 l=4] *zero_extendhisi2/1 kortestw%k1, %k0# 31[c=4 l=4] kortesthi since for some reason tree optimizers give us: _28 = VIEW_CONVERT_EXPR<__v16hi>(_31); _29 = __builtin_ia32_ucmpw256_mask (_28, _20, 0, 65535); _26 = VIEW_CONVERT_EXPR<__v16hi>(_30); _27 = __builtin_ia32_ucmpw256_mask (_26, _20, 0, 65535); _2 = (int) _27; _3 = (int) _29; _15 = __builtin_ia32_kortestzhi (_3, _2); > Clang generates: > > .LBB0_2:# =>This Inner Loop Header: Depth=1 > vpcmpeqw(%rdi), %ymm0, %k0 > vpcmpeqw32(%rdi), %ymm0, %k1 > kortestw%k0, %k1 > jne .LBB0_3 > > ICC inserts one KMOVW, but not the other. > > Godbolt build link: https://gcc.godbolt.org/z/cc3heo48M > > LLVM-MCA analysis: https://analysis.godbolt.org/z/dGvY1Wj78 > It shows the Clang loop runs on average 2.0 cycles per loop, whereas the GCC > code is 3 cycles/loop. > > LLVM-MCA says the ICC loop with one of the two KMOV also runs at 2.0 cycles > per loop, because it can run in parallel with the second load, given that > the loads are ports 2 and 3.
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 102944, which changed state. Bug 102944 Summary: Many gcc.dg/Wstringop-overflow-*.c failures https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102944 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug testsuite/102944] Many gcc.dg/Wstringop-overflow-*.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102944 Martin Sebor changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Sebor --- Thanks. Resolving as fixed then.
[Bug tree-optimization/103744] [12 Regression] ICE in operator[], at vec.h:889 since r12-5612-g10833849b55401a52f2334eb032a70beb688e9fc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103744 rsandifo at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from rsandifo at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/103744] [12 Regression] ICE in operator[], at vec.h:889 since r12-5612-g10833849b55401a52f2334eb032a70beb688e9fc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103744 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Sandiford : https://gcc.gnu.org/g:e781cb93d7d908f1f4f1611d0034eccbd1478e91 commit r12-6041-ge781cb93d7d908f1f4f1611d0034eccbd1478e91 Author: Richard Sandiford Date: Fri Dec 17 14:18:39 2021 + vect: Fix multi-vector SLP gather loads [PR103744] This PR shows that I didn't properly test the multi-vector case when adding support for SLP gather loads. The patch fixes that case using the same approach as we do for non-SLP cases: keep the scalar base the same, but iterate through the (also multi-vector) vector offsets. âvec_num * j + iâ is already used elsewhere as a way of handling both the multi-vector SLP case and the multi-vector non-SLP case. gcc/ PR tree-optimization/103744 * tree-vect-stmts.c (vectorizable_load): Handle multi-vector SLP gather loads. gcc/testsuite/ PR tree-optimization/103744 * gcc.dg/vect/pr103744-1.c: New test. * gcc.dg/vect/pr103744-2.c: Likewise.
[Bug tree-optimization/103744] [12 Regression] ICE in operator[], at vec.h:889 since r12-5612-g10833849b55401a52f2334eb032a70beb688e9fc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103744 --- Comment #5 from rsandifo at gcc dot gnu.org --- (In reply to Arseny Solokha from comment #4) > The apparently related case: I think this is actually a separate bug. Could you open a new PR for it?
[Bug c++/84573] missing warning on an uninstantiated function template returning T with no return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84573 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- I personally think we should not add such a warning.
[Bug sanitizer/84250] Symbol collision when using both Address and Undefined Behavior sanitizers (-fsanitize=address,undefined)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84250 --- Comment #11 from Marek Polacek --- (In reply to chefmax from comment #10) > Hi Marek, sorry, I'm not really tracking this anymore :(. Hi, understood. > I don't remember exactly why option 1) from > https://github.com/google/sanitizers/issues/912#issuecomment-363525012 > doesn't work for GCC so I'm not sure whether I can give any new valuable > input for this issue. Should I unassign/reassign this to someone else? If you're not planning to get back to this then I think it'd be good to unassign. I don't know whom we would reassign this to at this point.
[Bug target/103750] [i386] GCC schedules KMOV instructions that destroys performance in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103750 --- Comment #8 from Thiago Macieira --- Update again: looks like the issue was the next line I didn't paste, which was performing _kortestz_mask32_u8 on an __mmask16. The type mismatch was causing this problem. If I Use the correct _kortestz_maskXX_u8, I'm getting: vmovdqu8(%rsi), %ymm2 vmovdqu832(%rsi), %ymm3 vpcmpub $6, %ymm0, %ymm2, %k0 vpcmpub $6, %ymm0, %ymm3, %k1 kortestd%k1, %k0 je .L794 vmovdqu16 (%rsi), %ymm2 vmovdqu16 32(%rsi), %ymm3 vpcmpuw $6, %ymm0, %ymm2, %k0 vpcmpuw $6, %ymm0, %ymm3, %k1 kortestw%k1, %k0 je .L807 So it looks like GCC is not completely wrong, but it could be more lenient (Clang is). You can lower the severity of this issue.
[Bug c++/83264] std::initializer_list with a single element selects the wrong overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83264 --- Comment #4 from Andrew Pinski --- https://wg21.link/cwg1467
[Bug c++/83264] std::initializer_list with a single element selects the wrong overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83264 Andrew Pinski changed: What|Removed |Added Alias||Cwg1467 Resolution|--- |INVALID Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- DR 1467 describes that gcc is correct.
[Bug target/103750] [i386] GCC schedules KMOV instructions that destroys performance in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103750 --- Comment #7 from Thiago Macieira --- I should add the same is not happening for Char == char, meaning the returned type is an __mmask32 (unsigned) vmovdqu8(%rsi), %ymm2 vmovdqu832(%rsi), %ymm3 vpcmpub $6, %ymm0, %ymm2, %k0 vpcmpub $6, %ymm0, %ymm3, %k1 kortestd%k1, %k0 je .L792
[Bug c++/83264] std::initializer_list with a single element selects the wrong overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83264 --- Comment #2 from Jonathan Wakely --- Maybe another case of DR 2137 (PR 85577)
[Bug target/103750] [i386] GCC schedules KMOV instructions that destroys performance in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103750
--- Comment #6 from Thiago Macieira ---
It got worse. Now I'm seeing:
.L807:
vmovdqu16 (%rsi), %ymm2
vmovdqu16 32(%rsi), %ymm3
vpcmpuw $6, %ymm0, %ymm2, %k2
vpcmpuw $6, %ymm0, %ymm3, %k3
kmovw %k2, %eax
kmovw %k3, %edx
kmovd %eax, %k4
kmovd %edx, %k5
kortestd%k5, %k4
je .L814
Code snippet:
auto loadAndCompare = [maxval](const Char *ptr, unsigned mask = ~0U) {
if constexpr (sizeof(Char) == 1) {
__m256i mval = _mm256_set1_epi8(maxval);
__m256i data = _mm256_maskz_loadu_epi8(mask, ptr);
return _mm256_cmpgt_epu8_mask(data, mval);
} else if constexpr (sizeof(Char) == 2) {
__m256i mval = _mm256_set1_epi16(maxval);
__m256i data = _mm256_maskz_loadu_epi16(mask, ptr);
return _mm256_cmpgt_epu16_mask(data, mval);
} else if constexpr (sizeof(Char) == 4) {
__m256i mval = _mm256_set1_epi32(maxval);
__m256i data = _mm256_maskz_loadu_epi32(mask, ptr);
return _mm256_cmpgt_epu32_mask(data, mval);
}
};
/*...*/
auto mask1 = loadAndCompare(n1);
auto mask2 = loadAndCompare(n2);
I can make a compilable version if you need me to
[Bug target/103750] [i386] GCC schedules KMOV instructions that destroys performance in loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103750
--- Comment #5 from Thiago Macieira ---
Maybe this is running afoul of GCC's thinking that a simple register-register
move is free? I've seen it save a constant in an opmask register, but kmov{d,q}
is not free like mov{l,q} is.
[Bug testsuite/102944] Many gcc.dg/Wstringop-overflow-*.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102944 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from Martin Sebor --- > I don't see any of the FAILs or XFAILs listed in comment #0 with cross > compilers for any of the Targets. Can this report be resolved? The failures last occured on sparc*-sun-solaris2.11 on 20211101 and on i386-pc-solaris2.11 on 20210716, so for my targets the issue is fixed indeed.
[Bug c++/83264] std::initializer_list with a single element selects the wrong overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83264 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-12-17 Known to fail||11.2.0, 4.4.7, 4.7.4, 4.9.4 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c++/35835] Compiler fails to recognize match of local "extern" declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35835 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.0 Resolution|--- |FIXED Status|NEW |RESOLVED Known to fail||10.3.0 Keywords||needs-bisection Known to work||11.1.0 --- Comment #6 from Andrew Pinski --- Fixed for GCC 11 by r11-3699-g4e62aca0e0520e4ed2532f2d815358.
[Bug c++/14769] [DR 426] Block extern incorrectly resolved to file-scope internal linkage object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14769 Andrew Pinski changed: What|Removed |Added CC||tabloid.adroit at gmail dot com --- Comment #7 from Andrew Pinski --- *** Bug 94764 has been marked as a duplicate of this bug. ***
[Bug c++/94764] block extern incorrectly resolved to external linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94764 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- DR 426 is clear here, the code is illformed. Anyways this is a dup of bug var. *** This bug has been marked as a duplicate of bug 14769 ***
[Bug c++/14769] [DR 426] Block extern incorrectly resolved to file-scope internal linkage object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14769 Andrew Pinski changed: What|Removed |Added Keywords|wrong-code |accepts-invalid Blocks||94404 Alias||cwg426 Status|SUSPENDED |NEW --- Comment #6 from Andrew Pinski --- > [Adopted at the February/March, 2017 meeting.] The defect report has now been adopted for C++20, and the code is illformed (invalid). I don't know if this is illformed with no diagnostic required or not but I suspect it requires a diagnostic. So now this is an accepts invalid. Also note clang rejects the example program in comment #0 as illformed already as the types are different const int vs int. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404 [Bug 94404] [meta-bug] C++ core issues
[Bug c++/57533] When throwing local variable, it's being move-constructed even if not going out of scope.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57533 Andrew Pinski changed: What|Removed |Added Known to work||11.1.0 Known to fail||10.3.0 --- Comment #8 from Andrew Pinski --- I think we should just add the testcase and be done with it.
[Bug c++/40225] Mishandled throw/catch with throw in constructor and rethrow in set_terminate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40225 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=44127 --- Comment #3 from Andrew Pinski --- Fixed, I suspect PR 44127 was the fix.
[Bug tree-optimization/103741] [12 Regression] ICE in prepare_vec_mask, at tree-vect-stmts.c:1808 since r12-5772-g06f2e7d49fc6341ea0128ccd83fd13705dd2c523
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103741 Tamar Christina changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Tamar Christina --- fixed on trunk, thanks for the report!
