[Bug c++/98801] Request for a conditional move built-in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98801 --- Comment #1 from Andrew Pinski --- I don't think we need a builtin. Because we could just improve the code generation instead.
[Bug c++/97399] [9/10 Regression] g++ 9.3 cannot compile SFINAE code with separated declaration and definition, g++ 7.3 compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97399 Patrick Palka changed: What|Removed |Added Summary|[9/10/11 Regression] g++|[9/10 Regression] g++ 9.3 |9.3 cannot compile SFINAE |cannot compile SFINAE code |code with separated |with separated declaration |declaration and definition, |and definition, g++ 7.3 |g++ 7.3 compiles|compiles --- Comment #6 from Patrick Palka --- Fixed for GCC 11 so far.
[Bug c++/97399] [9/10/11 Regression] g++ 9.3 cannot compile SFINAE code with separated declaration and definition, g++ 7.3 compiles
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97399 --- Comment #5 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:a8cef3cba6945730c69e15dcdad726e74b50fe58 commit r11-6878-ga8cef3cba6945730c69e15dcdad726e74b50fe58 Author: Patrick Palka Date: Sat Jan 23 00:24:17 2021 -0500 c++: 'this' injection and static member functions [PR97399] In the testcase pr97399.C below, finish_qualified_id_expr at parse time adds an implicit 'this->' to the expression tmp::integral (because it's type-dependent, and also current_class_ptr is set at this point) within the trailing return type. Later when substituting into this trailing return type we crash because we can't resolve the 'this', since tsubst_function_type does inject_this_parm only for non-static member functions, which tmp::func is not. This patch fixes this issue by removing the type-dependence check in finish_qualified_id_expr added by r9-5972, and instead relaxes shared_member_p to handle dependent USING_DECLs: > I think I was wrong in my assertion around Alex's patch that > shared_member_p should abort on a dependent USING_DECL; it now seems > appropriate for it to return false if we don't know, we just need to > adjust the comment to say that. And when parsing a friend function declaration, we shouldn't be setting current_class_ptr at all, so this patch additionally suppresses inject_this_parm in this case. Finally, the self-contained change to cp_parser_init_declarator is so that we properly communicate static-ness to cp_parser_direct_declarator when parsing a member function template. This lets us reject the explicit use of 'this' in the testcase this2.C below. gcc/cp/ChangeLog: PR c++/97399 * cp-tree.h (shared_member_p): Adjust declaration. * parser.c (cp_parser_init_declarator): If the storage class specifier is sc_static, pass true for static_p to cp_parser_declarator. (cp_parser_direct_declarator): Don't do inject_this_parm when the declarator is a friend. * search.c (shared_member_p): Change return type to bool and adjust function body accordingly. Return false for a dependent USING_DECL instead of aborting. * semantics.c (finish_qualified_id_expr): Rely on shared_member_p even when type-dependent. gcc/testsuite/ChangeLog: PR c++/88548 PR c++/97399 * g++.dg/cpp0x/this2.C: New test. * g++.dg/template/pr97399.C: New test.
[Bug c++/88548] [9 Regression] this accepted in static member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88548 --- Comment #6 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:a8cef3cba6945730c69e15dcdad726e74b50fe58 commit r11-6878-ga8cef3cba6945730c69e15dcdad726e74b50fe58 Author: Patrick Palka Date: Sat Jan 23 00:24:17 2021 -0500 c++: 'this' injection and static member functions [PR97399] In the testcase pr97399.C below, finish_qualified_id_expr at parse time adds an implicit 'this->' to the expression tmp::integral (because it's type-dependent, and also current_class_ptr is set at this point) within the trailing return type. Later when substituting into this trailing return type we crash because we can't resolve the 'this', since tsubst_function_type does inject_this_parm only for non-static member functions, which tmp::func is not. This patch fixes this issue by removing the type-dependence check in finish_qualified_id_expr added by r9-5972, and instead relaxes shared_member_p to handle dependent USING_DECLs: > I think I was wrong in my assertion around Alex's patch that > shared_member_p should abort on a dependent USING_DECL; it now seems > appropriate for it to return false if we don't know, we just need to > adjust the comment to say that. And when parsing a friend function declaration, we shouldn't be setting current_class_ptr at all, so this patch additionally suppresses inject_this_parm in this case. Finally, the self-contained change to cp_parser_init_declarator is so that we properly communicate static-ness to cp_parser_direct_declarator when parsing a member function template. This lets us reject the explicit use of 'this' in the testcase this2.C below. gcc/cp/ChangeLog: PR c++/97399 * cp-tree.h (shared_member_p): Adjust declaration. * parser.c (cp_parser_init_declarator): If the storage class specifier is sc_static, pass true for static_p to cp_parser_declarator. (cp_parser_direct_declarator): Don't do inject_this_parm when the declarator is a friend. * search.c (shared_member_p): Change return type to bool and adjust function body accordingly. Return false for a dependent USING_DECL instead of aborting. * semantics.c (finish_qualified_id_expr): Rely on shared_member_p even when type-dependent. gcc/testsuite/ChangeLog: PR c++/88548 PR c++/97399 * g++.dg/cpp0x/this2.C: New test. * g++.dg/template/pr97399.C: New test.
[Bug target/97683] [11 Regression] nios2 assembler branch offset errors building glibc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97683 --- Comment #2 from sandra at gcc dot gnu.org --- I'm pretty sure this is a gas bug. I used git bisect to track it down to binutils commit ae9d2233e61a98ff8dba56be10219aa5306ffc9a which caused gcc to start passing --gdwarf-5 on the gas command line. The DWARF-5 support was present in gas before that and I think it's likely that's disagreeing with something nios2-specific, perhaps mistakenly adding the size of the dwarf directive data to the code length or something like that. The differences in the .s file generated by GCC for the test case between that binutils revision with --gdwarf-5 and the one before it without that option don't seem to be significant. While working on this, I ran into another issue that is independently preventing glibc from building: In function '__rawmemchr', inlined from '__rawmemchr' at rawmemchr.c:27:1: rawmemchr.c:40:12: error: 'memchr' specified bound 4294967295 exceeds maximum object size 2147483647 [-Werror=stringop-overread] 40 | return memchr (s, c, (size_t)-1); |^ cc1: all warnings being treated as errors I apologize that this is all in such bad shape -- the last time I tried doing any testing on this target I ran into the glibc breakage Joseph mentioned, and since then I've been assigned to a different project where my focus has been on the gfortran front end instead. :-S I'll see if I can get some traction on the gas bug, though.
[Bug c++/98801] New: Request for a conditional move built-in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98801 Bug ID: 98801 Summary: Request for a conditional move built-in function Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jeffhurchalla at gmail dot com Target Milestone: --- There are a number of idiomatic ways to hint to gcc to generate a conditional move, but there is no way that is documented/guaranteed. In practice, they do not always result in a conditional move. I would like to request a builtin function that generates a conditional move. The current situation: Perhaps the most common hint is to write a = (cond) ? x : y Another way is to bit-hack, and hope the compiler transforms it to cmov. E.g. a = ((-cond) & x) | ((cond-1) & y) There are more ways still, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93165 . None can be relied on for the purpose. Certainly a conditional move can be accomplished via inline asm, but this is non-portable across ISAs, it's bug-prone, and it seems to hinder the optimizer. The existing function __builtin_expect_with_probability is interesting: in theory it seems like it might allow a user to get conditional moves via a probability of 0.5. I'm unsure if this works as desired in practice; its documentation does not mention anything about conditional moves or unpredictable branches. (Also note that a probability of 0.5 does not necessarily mean a condition is unpredictable - e.g. a condition could alternate between true and false each time it's executed.) Perhaps also interesting is clang's __builtin_unpredictable, which is documented as a way to indicate to the compiler that a branch condition is unpredictable. I'm unsure here too if this affects conditional moves; their docs don't mention it. Personally, I'd like conditional moves for performance in situations where I know a branch is completely unpredictable. However, cmovs appear to also be useful for security, to avoid timing attacks.
[Bug fortran/95644] [F2018] IEEE_FMA is missing from the IEEE_ARITHMETIC module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at charter dot net --- Comment #6 from Jerry DeLisle --- Hi Bill, per our operational security procedure we can't talk about ieee_arithmetic, especially when we dont get paid. However, I can go look at the code and see if Steve's patch got in or not.
[Bug libbacktrace/98732] libbacktrace could not find executable to open
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98732 郑之为 changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from 郑之为 --- fixed.
[Bug target/98092] [11 Regression] ICE in extract_insn, at recog.c:2315 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98092 --- Comment #3 from Segher Boessenkool --- Created attachment 50040 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50040=edit Patch Patch in testing.
[Bug other/63792] libcc1 doesn't built i386 multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63792 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #1 from Tom Tromey --- libcc1 is a host library, not a target library. So, I suspect nothing needs to be done here.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED CC|ebotcazou at gcc dot gnu.org | --- Comment #16 from Eric Botcazou --- > # High-level flow of the resulting crashes: > > - the procedure sem_type__get_next_interp has an output parameter of > record type sem_type__interp and overwrites that completely. > - in locations that call sem_type__get_next_interp, local variables of > type sem_type__interp get wrapped by maybe_pad_type in an outer > padding record for proper alignment. the padding record has a single > field "F" for the inner record. > - on s390x, that field gets falsely flagged as nonaddressable (see > zoom-in below). > - as a consequence of that flag, type based alias analysis does not > relate the padded record to the alias set of the inner record. > - modref_may_conflict disambiguates references to the local variables > (padded record) from sem_type__get_next_interp actually overwriting > the (inner) record -- "correct" decision based on the data, but > clearly the wrong result. > - as a result, loops that iterate via sem_type__get_next_interp are > "optimized" into endless loops, because their abort condition is > never checked against the updated data. > - these loops overrun All_Interp.Table and trigger assertions or > segfault (i've seen both). Thanks for the detailed investigation. The effect of nonaddressability on alias sets is as expected, but it is invalid to take the address of a nonaddressable field of course.
[Bug c/94669] libcc1: 4 * minor performance problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94669 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tromey at gcc dot gnu.org --- Comment #5 from Tom Tromey --- I have a patch for these.
[Bug c++/96623] [11 Regression] ICE in inject_parm_decls, at cp/parser.c:23893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96623 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Marek Polacek --- Fixed.
[Bug c++/96623] [11 Regression] ICE in inject_parm_decls, at cp/parser.c:23893
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96623
--- Comment #5 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:89100826acec92dfaa6ab8f2646b8053e7dbc67c
commit r11-6874-g89100826acec92dfaa6ab8f2646b8053e7dbc67c
Author: Marek Polacek
Date: Thu Jan 21 16:12:28 2021 -0500
c++: ICE with noexcept in class in member function [PR96623]
I discovered very strange code in inject_parm_decls:
if (args && is_this_parameter (args))
{
gcc_checking_assert (current_class_ptr == NULL_TREE);
current_class_ptr = NULL_TREE;
We are tripping up on the assert because when we call inject_parm_decls,
current_class_ptr is set to 'A'. It was set by inject_this_parameter
after we've parsed the parameter-declaration-clause of the member
function foo. It seems correct to set ccp/ccr to A::B when we're
late parsing the noexcept-specifiers of bar* functions in B, so that
this-> does the right thing. Since inject_parm_decls doesn't expect
to see non-null ccp/ccr, reset it before calling inject_parm_decls.
gcc/cp/ChangeLog:
PR c++/96623
* parser.c (inject_parm_decls): Remove a redundant assignment.
(cp_parser_class_specifier_1): Clear current_class_{ptr,ref}
before calling inject_parm_decls.
gcc/testsuite/ChangeLog:
PR c++/96623
* g++.dg/cpp0x/noexcept64.C: New test.
[Bug testsuite/98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125 --- Comment #12 from Alan Modra --- Created attachment 50039 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50039=edit ELFv1 support Revised patches. I wasn't happy with the use of a ".text" symbol in the previous patch since some targets don't call their text section ".text". These are really stage1 material. Usable -fpatchable-funtion-entry on powerpc64 is a new feature. I'm inclined to think the new test should just be skipped on powerpc64*-*. Bill, could you handle the testsuite fixes please?
[Bug testsuite/98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125 Alan Modra changed: What|Removed |Added Attachment #49701|0 |1 is obsolete|| --- Comment #11 from Alan Modra --- Created attachment 50038 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50038=edit ELFv2 support
[Bug c++/98800] [8/9/10/11 Regression] ICE on invalid use of non-static member function in trailing return type since r8-2724
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98800 Patrick Palka changed: What|Removed |Added Target Milestone|--- |8.5
[Bug c++/98800] [8/9/10/11 Regression] ICE on invalid use of non-static member function in trailing return type since r8-2724
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98800
Patrick Palka changed:
What|Removed |Added
Summary|ICE on invalid use of |[8/9/10/11 Regression] ICE
|non-static member function |on invalid use of
|in trailing return type |non-static member function
|since r251438 |in trailing return type
||since r8-2724
Keywords||ice-on-invalid-code
CC||jason at gcc dot gnu.org
Known to fail||10.2.0, 11.0, 8.4.0, 9.3.0
Known to work||7.5.0
--- Comment #1 from Patrick Palka ---
GCC 7.5 rejects with:
: In function 'int main()':
:7:29: error: no matching function for call to 'tmp::func()'
int main() { tmp::func(); }
^
:4:34: note: candidate: template static
enable_if_t()> tmp::func()
template static auto func() -> enable_if_t()>;
^~~~
:4:34: note: template argument deduction/substitution failed:
: In substitution of 'template static
enable_if_t()> tmp::func() [with E = int]':
:7:29: required from here
:4:70: error: cannot call member function 'constexpr bool
tmp::is_integral() [with = int]' without object
template static auto func() -> enable_if_t()>;
~~^~
[Bug c++/98800] New: ICE on invalid use of non-static member function in trailing return type since r251438
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98800
Bug ID: 98800
Summary: ICE on invalid use of non-static member function in
trailing return type since r251438
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
This invalid testcase is just a minor variant of PR97399#c4 where the member
function is_integral has been made non-static.
$ cat testcase.C
template struct enable_if_t {};
struct tmp {
templateconstexpr bool is_integral();
template static auto func() -> enable_if_t()>;
};
template constexpr bool tmp::is_integral() { return true; }
int main() { tmp::func(); }
$ g++ testcase.C
testcase.C: In substitution of ‘template static
enable_if_t<((tmp*)this)->is_integral()> tmp::f() [with T = int]’:
testcase.C:21:15: required from here
testcase.C:9:39: internal compiler error: in tsubst_copy, at cp/pt.c:16393
9 | -> enable_if_t()>; // { dg-message "in template
argument" }
|~~~^~
[Bug debug/98796] Incorrect .debug_line emitted for DWARF5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98796 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jakub Jelinek --- Fixed.
[Bug debug/98796] Incorrect .debug_line emitted for DWARF5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98796 --- Comment #2 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:b485fa167ef35c8facbd7c21cb86fd1abc77efcf commit r11-6868-gb485fa167ef35c8facbd7c21cb86fd1abc77efcf Author: Jakub Jelinek Date: Fri Jan 22 22:37:36 2021 +0100 dwarf2out: Always emit required 0 entries for DWARF 5 in *.debug_line [PR98796] When GCC is emitting .debug_line or .gnu.debuglto_.debug_line section by itself (happens either with too old or non-GNU assembler, with -gno-as-loc-support or with -flto) on empty translation units, it violates the DWARF 5 requirements. The standard says: "The first entry is the current directory of the compilation." and a few lines later: "The first entry in the sequence is the primary source file whose file name exactly matches that given in the DW_AT_name attribute in the compilation unit debugging information entry." GCC emits 4 zeros (directory entry format count, directories count, filename entry format count and filename count), which would be ok if the spec said The first entry may be rather than is. I had a brief look at whether I could just fall through into the rest of the function, but there are too many assumptions that there is at least one normal file that it can't be done that way easily. So this patch instead extends the early out code to emit the required minimum, which is 15 bytes more than we used to emit before. 2021-01-22 Jakub Jelinek PR debug/98796 * dwarf2out.c (output_file_names): For -gdwarf-5, if there are no filenames to emit, still emit the required 0 index directory and filename entries that match DW_AT_comp_dir and DW_AT_name of the compilation unit.
[Bug fortran/97272] Wrong answer from MAXLOC with character arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272 --- Comment #11 from anlauf at gcc dot gnu.org --- (In reply to Bill Long from comment #10) > Still fails with 10.2.0. Can you say which release version will include the > fix? According to https://gcc.gnu.org/, gcc 10.2 was released in July 2020. Extrapolating previous schedules, I'd expect 10.3 one year after 9.3, which was released in March 2020. You could check the 10-branch that the fix works for you.
[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228 --- Comment #15 from Marius Hillenbrand --- tl;dr: I found the root cause and a way to repro on x86. When the gnat/gcc interface converts gnat entities into tree decls, maybe_pad_type() pads some record types. maybe_pad_type() calls make_packable_type() to potentially pad a record into an integral type. On s390x, we hit that case for sem_type__interp, which is padded from 12 bytes in BLKmode to a TImode. That results in the wrapped record to be flagged as nonaddressable, which causes mayhem in tbaa (one way this blows up below). On x86-64 in contrast, maybe_pad_type() rejects the padding to TI in that specific case, because TI requires 128-bit or larger alignment on x86-64, while a 64-bit alignment is enough to get TI chosen on s390x). When removing that condition, the issue reproduces on x86-64. When I force that rejection on s390x, bootstrapping is successful (tested with bootstrap-lto-lean, which extensively reproduces; not yet with a full profiledbootstrap). tree packable_type = make_packable_type (type, true, align); if (TYPE_MODE (packable_type) != BLKmode) && align >= TYPE_ALIGN (packable_type)) // <- false on x86 type = packable_type; (I also have tweaked the calling convention for sem_type__get_next_interp to mimic that on s390x, with a pointer for the output parameter It) procedure Get_Next_Interp (I : in out Interp_Index; It : out Interp); pragma Export (C, Get_Next_Interp); pragma Export_Procedure (Get_Next_Interp, External => "sem_type__get_next_interp", Mechanism => (I => Value, It => Reference)); pragma No_Inline (Get_Next_Interp); -- causes repro in more places # High-level flow of the resulting crashes: - the procedure sem_type__get_next_interp has an output parameter of record type sem_type__interp and overwrites that completely. - in locations that call sem_type__get_next_interp, local variables of type sem_type__interp get wrapped by maybe_pad_type in an outer padding record for proper alignment. the padding record has a single field "F" for the inner record. - on s390x, that field gets falsely flagged as nonaddressable (see zoom-in below). - as a consequence of that flag, type based alias analysis does not relate the padded record to the alias set of the inner record. - modref_may_conflict disambiguates references to the local variables (padded record) from sem_type__get_next_interp actually overwriting the (inner) record -- "correct" decision based on the data, but clearly the wrong result. - as a result, loops that iterate via sem_type__get_next_interp are "optimized" into endless loops, because their abort condition is never checked against the updated data. - these loops overrun All_Interp.Table and trigger assertions or segfault (i've seen both). # How does the field get marked nonaddressable? maybe_pad_type calls make_packable_type, which attempts to find an integral type that fits the record to be padded; in our case it chooses TI.
[Bug fortran/86470] [8/9/10/11 Regression] [OOP] ICE with OMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470
--- Comment #7 from anlauf at gcc dot gnu.org ---
Untested patch:
diff --git a/gcc/fortran/trans.c b/gcc/fortran/trans.c
index a2376917635..7699e98f6ea 100644
--- a/gcc/fortran/trans.c
+++ b/gcc/fortran/trans.c
@@ -689,9 +689,14 @@ gfc_call_malloc (stmtblock_t * block, tree type, tree
size)
/* Call malloc. */
gfc_start_block ();
- size = fold_convert (size_type_node, size);
- size = fold_build2_loc (input_location, MAX_EXPR, size_type_node, size,
- build_int_cst (size_type_node, 1));
+ if (size)
+{
+ size = fold_convert (size_type_node, size);
+ size = fold_build2_loc (input_location, MAX_EXPR, size_type_node, size,
+ build_int_cst (size_type_node, 1));
+}
+ else
+size = build_int_cst (size_type_node, 1);
malloc_tree = builtin_decl_explicit (BUILT_IN_MALLOC);
gfc_add_modify (, res,
Not sure if this is correct, but it makes gfc_call_malloc match the comment
preceeding that function.
I'll leave the interpretation to the experts.
[Bug fortran/97272] Wrong answer from MAXLOC with character arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272 --- Comment #10 from Bill Long --- Still fails with 10.2.0. Can you say which release version will include the fix?
[Bug testsuite/98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125 --- Comment #10 from seurer at gcc dot gnu.org --- It is still failing for me so I'd guess that Alan's patch is not submitted yet.
[Bug target/98092] [11 Regression] ICE in extract_insn, at recog.c:2315 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98092 --- Comment #2 from Carl Love --- Segher: Yup, I saw the buzilla. Will take a look at it. Carl On Fri, 2021-01-22 at 18:49 +, segher at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98092 > > Segher Boessenkool changed: > >What|Removed |Added > --- > - >Assignee|unassigned at gcc dot gnu.org |segher at gcc > dot gnu.org >
[Bug target/98799] [10 Regression] vector_set_var ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98799 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |11.0 Ever confirmed|0 |1 Priority|P3 |P2 Last reconfirmed||2021-01-22 CC||bergner at gcc dot gnu.org, ||luoxhu at cn dot ibm.com, ||segher at gcc dot gnu.org --- Comment #1 from David Edelsohn --- Confirmed.
[Bug target/98799] New: [10 Regression] vector_set_var ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98799 Bug ID: 98799 Summary: [10 Regression] vector_set_var ICE Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org Target Milestone: --- Target: powerpc-ibm-aix7.2.3.0 gcc.target/powerpc/pr79251.p8.c gcc.target/powerpc/fold-vec-insert-float-p8.c now ICE: error: unrecognizable insn: (insn 16 15 17 2 (parallel [ (set (reg:SI 132) (unspec:SI [ (reg/v:SF 122 [ f ]) ] UNSPEC_SI_FROM_SF)) (clobber (scratch:V4SF)) ]) "/nasfarm/edelsohn/src/src/gcc/testsuite/gcc.target/powerpc/fold-vec- insert-float-p8.c":13:10 -1 (nil)) during RTL pass: vregs internal compiler error: in extract_insn, at recog.c:2769 ranges offset out of range
[Bug tree-optimization/97588] Overzealous SRA of boolean bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97588
Martin Jambor changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-01-22
--- Comment #2 from Martin Jambor ---
SRA only decides to create replacements for the single-bit flags, we
don't do total scalarization when there are bit-fields. Part of the
problem, is that SRA sees some accesses to the flags directly:
flags.flag1 = 1;
but others it does not really see because they are quite indirect:
_13 = BIT_FIELD_REF ;
_14 = _13 & 8;
if (_14 != 0)
...and it still decides to scalarize (more on that below), which means
that it has to store the flag back to flags before the BIT_FIELD_REF,
which leads to impression of the access being split into four parts.
Having said that, scalarizing bit-fields, and even more so 1-bit
flags, when there are not multiple reads from the bit-field itself, is
probably not useful (in the case of non-bit fields it can lead to
disappearance of the aggregate).
So, would the following help the real code that you derived the
testcase from?
diff --git a/gcc/tree-sra.c b/gcc/tree-sra.c
index d177f1ba11c..d3c3a4584a0 100644
--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -2519,7 +2519,8 @@ analyze_access_subtree (struct access *root, struct
access *parent,
&& (totally || !root->grp_total_scalarization)
&& (totally
|| root->grp_hint
- || ((root->grp_scalar_read || root->grp_assignment_read)
+ || (root->size > 1
+ && (root->grp_scalar_read || root->grp_assignment_read)
&& (root->grp_scalar_write || root->grp_assignment_write
{
/* Always create access replacements that cover the whole access.
@@ -2562,11 +2563,10 @@ analyze_access_subtree (struct access *root, struct
access *parent,
&& scalar && !root->first_child
&& !root->grp_total_scalarization
&& (root->grp_scalar_write || root->grp_assignment_write)
+ && (!root->grp_scalar_read && !root->grp_assignment_read)
&& !bitmap_bit_p (cannot_scalarize_away_bitmap,
DECL_UID (root->base)))
{
- gcc_checking_assert (!root->grp_scalar_read
- && !root->grp_assignment_read);
sth_created = true;
if (MAY_HAVE_DEBUG_BIND_STMTS)
{
[Bug c++/98744] [11 Regression] ICE in gimple_call_arg, at gimple.h:3246 since r11-6735-g424deca72b63e644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98744 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jason Merrill --- Fixed.
[Bug c++/98744] [11 Regression] ICE in gimple_call_arg, at gimple.h:3246 since r11-6735-g424deca72b63e644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98744 --- Comment #9 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:90cbc769006a43ed17d2384b3a0a4634f315d3fd commit r11-6866-g90cbc769006a43ed17d2384b3a0a4634f315d3fd Author: Jason Merrill Date: Fri Jan 22 11:57:27 2021 -0500 c++: Fix base copy elision thinko [PR98744] As Jakub points out in the PR, I was mixing up DECL_HAS_IN_CHARGE_PARM_P (which is true for the abstract maybe-in-charge constructor) and DECL_HAS_VTT_PARM_P (which is true for a base constructor that needs to handle virtual bases). gcc/cp/ChangeLog: PR c++/98744 * call.c (make_base_init_ok): Use DECL_HAS_VTT_PARM_P. gcc/testsuite/ChangeLog: PR c++/98744 * g++.dg/init/elide7.C: New test.
[Bug target/98519] rs6000: @pcrel unsupported on this instruction error in pveclib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98519 --- Comment #19 from Segher Boessenkool --- We cannot allow "m" to allow pcrel memory accesses, because most existing inline assembler code will break then. So we then need some way to tell the compiler that some instruction *does* allow pcrel memory (or even *requires* it).
[Bug c++/98545] [11 Regression] ICE in write_expression, at cp/mangle.c:3352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98545 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Marek Polacek --- Fixed.
[Bug sanitizer/95693] [8/9/10 Regression] Incorrect error from undefined behavior sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95693 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10/11 Regression] |[8/9/10 Regression] |Incorrect error from|Incorrect error from |undefined behavior |undefined behavior |sanitizer |sanitizer --- Comment #7 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug sanitizer/95693] [8/9/10/11 Regression] Incorrect error from undefined behavior sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95693
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:a9ed18295bfc6d69d40af197e059e16622cd94c6
commit r11-6865-ga9ed18295bfc6d69d40af197e059e16622cd94c6
Author: Jakub Jelinek
Date: Fri Jan 22 19:03:23 2021 +0100
c++: Fix up ubsan false positives on references [PR95693]
Alex' 2 years old change to build_zero_init_1 to return NULL pointer with
reference type for references breaks the sanitizers, the assignment of NULL
to a reference typed member is then instrumented before it is overwritten
with a non-NULL address later on.
That change has been done to fix error recovery ICE during
process_init_constructor_record, where we:
if (TYPE_REF_P (fldtype))
{
if (complain & tf_error)
error ("member %qD is uninitialized reference", field);
else
return PICFLAG_ERRONEOUS;
}
a few lines earlier, but then continue and ICE when build_zero_init returns
NULL.
The following patch reverts the build_zero_init_1 change and instead
creates
the NULL with reference type constants during the error recovery.
The pr84593.C testcase Alex' change was fixing still works as before.
2021-01-22 Jakub Jelinek
PR sanitizer/95693
* init.c (build_zero_init_1): Revert the 2018-03-06 change to
return build_zero_cst for reference types.
* typeck2.c (process_init_constructor_record): Instead call
build_zero_cst here during error recovery instead of
build_zero_init.
* g++.dg/ubsan/pr95693.C: New test.
[Bug c++/98545] [11 Regression] ICE in write_expression, at cp/mangle.c:3352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98545 --- Comment #4 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:25fc4d01a8ed1888e6a65597a3387349eb3c950c commit r11-6864-g25fc4d01a8ed1888e6a65597a3387349eb3c950c Author: Marek Polacek Date: Wed Jan 13 16:33:39 2021 -0500 c++: ICE when mangling operator name [PR98545] r11-6301 added some asserts in mangle.c, and now we trip over one of them. In particular, it's the one asserting that we didn't get IDENTIFIER_ANY_OP_P when mangling an expression with a dependent name. As this testcase shows, it's possible to get that, so turn the assert into an if and write "on". That changes the mangling in the following way: With this patch: $ c++filt _ZN1i1hIJ1adS1_EEEDTcldtdefpTonclspcvT__EEEDpS2_ decltype (((*this).(operator()))((a)(), (double)(), (a)())) i::h(a, double, a) G++10: $ c++filt _ZN1i1hIJ1adS1_EEEDTcldtdefpTclspcvT__EEEDpS2_ decltype (((*this).(operator()))((a)(), (double)(), (a)())) i::h(a, double, a) clang++/icc: $ c++filt _ZN1i1hIJ1adS1_EEEDTclonclspcvT__EEEDpS2_ decltype ((operator())((a)(), (double)(), (a)())) i::h(a, double, a) This is now tracked in PR98756. gcc/cp/ChangeLog: PR c++/98545 * mangle.c (write_member_name): Emit abi_warn_or_compat_version_crosses warnings regardless of abi_version_at_least. (write_expression): When the expression is a dependent name and an operator name, write "on" before writing its name. gcc/ChangeLog: PR c++/98545 * doc/invoke.texi: Update C++ ABI Version 15 description. gcc/testsuite/ChangeLog: PR c++/98545 * g++.dg/abi/mangle76.C: New test.
[Bug fortran/95644] [F2018] IEEE_FMA is missing from the IEEE_ARITHMETIC module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644 --- Comment #5 from Bill Long --- Original customer is asking again...
[Bug other/98790] [10/11 Regression] ICE in append_to_statement_list_1 (Segmentation Fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98790 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from Marek Polacek --- The original unreduced test now compiles with gcc10 & 11.
[Bug target/98681] [8/9/10/11 Regression] aarch64: Invalid ubfiz instruction rejected by assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98681 --- Comment #8 from Jakub Jelinek --- Created attachment 50037 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50037=edit gcc11-pr98681.patch Therefore, if you want to use UINTVAL in that function wherever possible, we can, but we need to add INTVAL (mask) > 0 check to catch the problems with negative mask %P printing. I'm already bootstrapping/regtesting the earlier patch, but can throw this one in too.
[Bug other/98790] [10/11 Regression] ICE in append_to_statement_list_1 (Segmentation Fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98790 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:c806314b32987096d79de21e72dc0cf783e51d57 commit r10-9288-gc806314b32987096d79de21e72dc0cf783e51d57 Author: Marek Polacek Date: Fri Jan 22 12:50:53 2021 -0500 c++: Crash when deducing template arguments [PR98790] maybe_instantiate_noexcept doesn't expect to see error_mark_node, but the new callsite I introduced in r11-6476 can pass error_mark_node to it. So cope. gcc/cp/ChangeLog: PR c++/98790 * pt.c (maybe_instantiate_noexcept): Return false if FN is error_mark_node. gcc/testsuite/ChangeLog: PR c++/98790 * g++.dg/template/deduce8.C: New test.
[Bug fortran/95647] operator(.eq.) and operator(==) treated differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 --- Comment #5 from Bill Long --- Is this fixed in a release version of GCC?
[Bug target/98681] [8/9/10/11 Regression] aarch64: Invalid ubfiz instruction rejected by assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98681
--- Comment #7 from Jakub Jelinek ---
So, for the mask, the question is if we should or shouldn't handle e.g.
unsigned
foo (unsigned int x)
{
return (x << 13) & (-1U << 13);
}
or
unsigned
bar (unsigned int x)
{
return (x << 0) & -1U;
}
I think the instruction in theory can handle those corner-cases,
as lsb is [0, 31] and width [1, 32-lsb], but the optimizers (both GIMPLE and
simplify-rtx during combine) will optimize that away (the useless masking in
both cases and useless shift in the second case).
So the case where mask is negative is only theoretical whether it should or
shouldn't match, that
exact_log2 ((INTVAL (mask) >> INTVAL (shft_amnt)) + 1)
for negative INTVAL (mask) will result in -1 + 1 for the masks with bits
starting with shft_amnt set and smaller clear and exact_log2 (0) is -1, thus it
fail, while if UINTVAL it could succeed. E.g. that hypothetical -1U << 13 mask
is in CONST_INT_P -1 << 13 so in UINTVAL (0xe000 >> 13) + 1 is a
power of two. But e.g. for shift count 0, -1 mask would be (0x
>> 0) + 1,
so 0 and fail anyway.
On the other side, I'm not sure if the define_insn will work correctly when
mask is negative - consider again the (x << 13) & (-1U << 13).
The instruction uses %P3 which uses
case 'P':
if (!CONST_INT_P (x))
{
output_operand_lossage ("invalid operand for '%%%c'", code);
return;
}
asm_fprintf (f, "%u", popcount_hwi (INTVAL (x)));
but the constant is not -1U << 13, but -1 << 13 and so %P3 will not print
ubfiz w1, w0, 13, 19
that should be printed, but
ubfiz w1, w0, 13, 51
on which gas will fail again:
pr98681.s: Assembler messages:
pr98681.s:11: Error: immediate value out of range 1 to 32 at operand 4 --
`ubfiz w1,w0,13,51'
So, I think it is better to keep INTVAL (mask) as is.
[Bug fortran/98565] internal compiler error: in conv_function_val, at fortran/trans-expr.c:3950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98565 --- Comment #3 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:bf8ee9e4eed6ba1a6d77b4cf168df480e1f954da commit r11-6863-gbf8ee9e4eed6ba1a6d77b4cf168df480e1f954da Author: Paul Thomas Date: Fri Jan 22 17:11:06 2021 + Fortran: Fix for class functions as associated target [PR98565]. 2021-01-22 Paul Thomas gcc/fortran PR fortran/98565 * trans-intrinsic.c (gfc_conv_associated): Do not add a _data component for scalar class function targets. Instead, fix the function result and access the _data from that. gcc/testsuite/ PR fortran/98565 * gfortran.dg/associated_target_7.f90 : New test.
[Bug tree-optimization/47059] compiler fails to coalesce loads/stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47059 --- Comment #6 from CVS Commits --- The master branch has been updated by Martin Jambor : https://gcc.gnu.org/g:d7e681fc3afff24a6279058cbb0b0dc4cd96be8c commit r11-6862-gd7e681fc3afff24a6279058cbb0b0dc4cd96be8c Author: Martin Jambor Date: Fri Jan 22 18:09:38 2021 +0100 Testcase for old PR 47059 I stumbled across PR 47059 from 2010 which has been addressed by store-merging. I am going to close it but would like to add its testcase too. gcc/testsuite/ChangeLog: 2021-01-08 Martin Jambor PR tree-optimization/47059 * gcc.dg/tree-ssa/pr47059.c: New test.
[Bug c++/98744] [11 Regression] ICE in gimple_call_arg, at gimple.h:3246 since r11-6735-g424deca72b63e644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98744 --- Comment #8 from Jason Merrill --- (In reply to Jakub Jelinek from comment #7) > looks strange, isn't DECL_HAS_IN_CHARGE_PARM_P (fn) false on all > base constructors (as those are the abstract ctors with the in_charge > parameter removed and implied to be false)? > I would have expected > if (!fn || DECL_HAS_VTT_PARM_P (fn)) > instead Yes, that's the bug, thanks. > But even elide4.C seems to suffer from this bug With the bug fixed, elide4.C doesn't elide, and that's OK.
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #16 from Xi Ruoyao --- (In reply to Richard Biener from comment #15) > So I see that > >242: 0 SECTION LOCAL DEFAULT UND > > and that's indeed broken (UND SECTION?) but ld complains that the SECTION > type is after the last section entry. So next up would be to look at the > assembly file the compiler generates for libsass.so.1.0.0.ltrans16.ltrans.o. > > The console output shows how it's generated: > > as -v -EL -mips64r2 -mips64r2 -mmsa -mloongson-ext -mloongson-ext > -mloongson-ext2 -mloongson-ext2 -O2 -mabi=64 -mabi=64 -march=gs464e > -march=gs464e -march=gs464e -mtune=gs464e -mtune=gs464e -mtune=gs464e -KPIC > -o libsass.so.1.0.0.ltrans16.ltrans.o libsass.so.1.0.0.ltrans16.s > > and the "last" section I see in there is > > .section.note.GNU-stack,"",@progbits > > and I can confirm that GNU as (2.35.1) produces an object with the strange > section (using a cross binutils). I think that no valid assembly file > should produce that so may I suggest to file a bug at sourceware for an > assembler issue? (just use the libsass.so.1.0.0.ltrans16.s file as testcase) > > Maybe there's more mips people around than here. I managed to make a smallest testcase (by removing lines in ltrans16.s) to generate such a buggy section: .text foo: .reloc 1f,R_MIPS_JALR,.LTHUNK5.lto_priv.0 1: nop I'm not a toolchain expert. If you believe it looks like a gas bug, let's report it to gas.
[Bug c++/98744] [11 Regression] ICE in gimple_call_arg, at gimple.h:3246 since r11-6735-g424deca72b63e644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98744 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/98681] [8/9/10/11 Regression] aarch64: Invalid ubfiz instruction rejected by assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98681 --- Comment #6 from Jakub Jelinek --- For shft_amnt that single UINTVAL check will make sure it is not negative, so whether the rest uses INTVAL or UINTVAL is then irrelevant. Up to you as maintainer what you want there. As for mask, let me check the exact insn behavior.
[Bug c++/98798] New: Custom operator new[] and delete[] is buggy for aligned class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98798
Bug ID: 98798
Summary: Custom operator new[] and delete[] is buggy for
aligned class
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marekr22 at wp dot pl
Target Milestone: ---
Basically when class has alignment requirement and custom operators `new[]` and
`delete[]` (C++17), then address sanitizer reports buffer overflow:
## MCVE:
```cpp
#include
#include
class EndlineOnDone {
std::ostream& out;
public:
EndlineOnDone(std::ostream& out) : out{out} {}
~EndlineOnDone()
{
out << std::endl;
}
std::ostream& stream() { return out; }
};
#define VAR(x) " " #x "=[" << x << "]"
#define LOG EndlineOnDone(std::cout).stream() << __PRETTY_FUNCTION__
std::ostream& operator<<(std::ostream& out, std::align_val_t a)
{
return out << static_cast(a);
}
class alignas(32) Foo
{
public :
double x, y, z;
void * operator new (size_t s, std::align_val_t a)
{
auto p = aligned_alloc(static_cast(a), s);
LOG << VAR(p) << VAR(s) << VAR(a);
return p;
}
void operator delete (void * p, size_t s, std::align_val_t a)
{
LOG << VAR(p) << VAR(s) << VAR(a);
if (p) free(p);
}
#if 1
void * operator new[ ] (size_t s, std::align_val_t a)
{
auto p = aligned_alloc(static_cast(a), s);
LOG << VAR(p) << VAR(s) << VAR(a);
return p;
}
void operator delete[ ] (void *p, size_t s, std::align_val_t a)
{
LOG << VAR(p) << VAR(s) << VAR(a);
if (p) free(p);
}
#endif
};
int main()
{
{
LOG << " std::make_unique";
auto p = std::make_unique();
}
{
LOG << " std::make_unique";
auto p = std::make_unique(3);
}
}
```
https://godbolt.org/z/7xd8YM
## gcc logs (no address sanitizer):
```txt
int main() std::make_unique
static void* Foo::operator new(size_t, std::align_val_t) p=[0x21d6ec0] s=[32]
a=[32]
static void Foo::operator delete(void*, size_t, std::align_val_t) p=[0x21d6ec0]
s=[32] a=[32]
int main() std::make_unique
static void* Foo::operator new [](size_t, std::align_val_t) p=[0x21d6f40]
s=[96] a=[32]
static void Foo::operator delete [](void*, size_t, std::align_val_t)
p=[0x21d6f40] s=[3616] a=[32]
```
Note that `s` value for `Foo[]` doesn't match for `new[]` and `delete[]`
operations.
Address sanitizer reports buffer overflow.
clang is fine (didn't check msvc).
## Workaround
Adding explicit destructor `~Foo() {}` fixes this issue:
https://godbolt.org/z/WoM91Y (use of `~Foo() = default;` doesn't fix it).
https://stackoverflow.com/q/65826663/1387438
[Bug tree-optimization/98766] [10 Regression] SVE: ICE in tree_to_shwi with -O3 --param=avoid-fma-max-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98766 ktkachov at gcc dot gnu.org changed: What|Removed |Added Summary|[10/11 Regression] SVE: ICE |[10 Regression] SVE: ICE in |in tree_to_shwi with -O3|tree_to_shwi with -O3 |--param=avoid-fma-max-bits |--param=avoid-fma-max-bits --- Comment #5 from ktkachov at gcc dot gnu.org --- Fixed for GCC 11.
[Bug tree-optimization/98766] [10/11 Regression] SVE: ICE in tree_to_shwi with -O3 --param=avoid-fma-max-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98766 --- Comment #4 from CVS Commits --- The master branch has been updated by Kyrylo Tkachov : https://gcc.gnu.org/g:9d33785f57daf29dc0c106c919da319fe1906bc6 commit r11-6861-g9d33785f57daf29dc0c106c919da319fe1906bc6 Author: Kyrylo Tkachov Date: Thu Jan 21 16:33:49 2021 + tree-ssa-mathopts: Use proper poly_int64 comparison with param_avoid_fma_max_bits [PR 98766] We ICE here because we end up comparing a poly_int64 with a scalar using <= rather than maybe_le. This patch fixes that in the way rich suggests in the PR. gcc/ChangeLog: PR tree-optimization/98766 * tree-ssa-math-opts.c (convert_mult_to_fma): Use maybe_le when comparing against type size with param_avoid_fma_max_bits. gcc/testsuite/ChangeLog: PR tree-optimization/98766 * gcc.dg/pr98766.c: New test.
[Bug target/98681] [8/9/10/11 Regression] aarch64: Invalid ubfiz instruction rejected by assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98681 --- Comment #5 from Richard Earnshaw --- Patch looks generally sensible, but I think all the INTVALs in that expression should be converted to UINTVAL. The mask, in particular, is unsigned and it is weird that one moment we're using a unsigned value and the next we're using a signed value for shift_amt.
[Bug target/93053] [9 Regression] libgcc build failure with old binutils on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053 avieira at gcc dot gnu.org changed: What|Removed |Added CC||avieira at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from avieira at gcc dot gnu.org --- I believe this has been fixed on all relevant branches.
[Bug analyzer/98797] New: Simpler version of the XFAIL in casts-1.c with proposed solution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98797
Bug ID: 98797
Summary: Simpler version of the XFAIL in casts-1.c with
proposed solution
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: brian.sobulefsky at protonmail dot com
Target Milestone: ---
I took some time to investigate the bug concerning the XFAILs in file
gcc/testsuite/gcc.dg/analyzer/casts-1.c and found that there is a simpler
manifestation of this error unrelated to casts. I also have a tentative
solution I can offer. I am new here so I'm sorry if I should be suggesting this
elsewhere, just let me know. In the casts-1.c file, a test is run of the form:
struct s1
{
char a;
char b;
char c;
char d;
};
struct s2
{
char arr[4];
};
struct s2 x = {{'A', 'B', 'C', 'D'}};
struct s1 *p = (struct s1 *)
__analyzer_eval (p->a == 'A');
Which should obviously be TRUE but comes out as UNKNOWN. The problem can
actually be replicated with just
char arc[4] = {{'A', 'B', 'C', 'D'}};
char *ptc = arc;
__analyzer_eval(*ptc == 'A');
__analyzer_eval(*(ptc+1) == 'B');
Both of these should obviously be TRUE, and they will print out UNKNOWN. These
do not require any contorted type conversion and suffer the same failure.
Briefly, this problem only occurs if you initialize an entire array and then
point to the array and try to access the individual values by pointer
de-reference. It does not occur if you initialize the array and try to access
the array element directly (you already programmed that case into it), and it
does not happen if you assign to the array elements directly for either case
(array access or pointer de-reference). Because direct assignment to the array
solves the problem, we do not see this problem with integers, as the
initialization of an integer array evidently compiles to individual assignments
to each element.
The easiest issue to solve was the *(ptc+1) version. This case runs as expected
through the whole program, just as arc[1] would, until we get to
region_model_manager::maybe_fold_sub_svalue. In the section of this method
commented /* Handle getting individual chars from a STRING_CST. */, there is
only a case for an element_region. By simply adding a analogous case for an
offset_region, modified as necessary for the different class, this can be
handled.
This solves *(ptc+N) for any N except 0. It also does not solve *ptc, which
evidently compiles the same as *(ptc+0). For this case, a modification can be
made to region_model_manager::get_offset_region in for section commented /* If
BYTE_OFFSET is zero, return PARENT. */. Before checking the zerop condition
and calling get_cast_region, we check a special case where argument region
*parent is of type ARRAY_TYPE and the type of that ARRAY_TYPE is the same as
argument tree type. In this case, we allow the normal method conclusion of
building an offset_region with a byte_offset of 0. After this, the fix
described in the prior paragraph will work for this case.
Finally, for the original issue involving converting between structs, an
analogous case can again be added again to the /* Handle getting individual
chars from a STRING_CST. */ section of
region_model_manager::maybe_fold_sub_svalue for a field_reg.
This will solve the three manifestations described here. It is known to not
solve the case where struct s2 was defined as {char arr1[2]; char arr2[2];},
which I am actually close to solving already. I have posted the current status
of my solution to GitHub. In the code, I left descriptive comments where I made
changes so that it is obvious. If you want to keep the changes, of course
remove the comments. In the ChangeLog, I put an entry that is a bit more
appropriate.
It is currently the only branch, but I have the branch named
xfail-casts-1-soln0.
https://github.com/poisson-aerohead/gcc
[Bug c++/98570] [8/9/10/11 Regression] ICE: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98570 --- Comment #3 from Marek Polacek --- Maybe it was r226992 and our bisect binaries are broken :/.
[Bug testsuite/98325] [11 regression] gcc.dg/pr25376.c fails after r11-5027
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98325 Bill Schmidt changed: What|Removed |Added CC||wschmidt at gcc dot gnu.org --- Comment #3 from Bill Schmidt --- Test case probably does not deal well with ELFv1 function descriptors.
[Bug c++/98570] [8/9/10/11 Regression] ICE: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98570 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I don't see how that commit could have changed the behavior.
[Bug fortran/98565] internal compiler error: in conv_function_val, at fortran/trans-expr.c:3950
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98565
Paul Thomas changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Comment #2 from Paul Thomas ---
Created attachment 50036
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50036=edit
Fix for the PR
Dear Yves,
I will be committing this patch to master this evening, after it has completed
regression testing, together with the testcase below. I will apply to 9- and
10-branches in a few weeks time.
You will note that I have made the components public so that I do not need to
write constructors.
Many thanks for the report. I hope that the fix will help your work in support
of sustainable development in Amazonia, even if in an insignificant way.
Regards
Paul
! { dg-do run }
!
! associated_target_7.f90: Test the fix for PR98565.
!
! Contributed by Yves Secretan
!
MODULE PS_SN0N_M
IMPLICIT NONE
PRIVATE
TYPE, PUBLIC :: DT_GRID_T
INTEGER :: NNT
CONTAINS
! PASS
END TYPE DT_GRID_T
TYPE, PUBLIC :: LM_ELEM_T
CLASS(DT_GRID_T), POINTER :: PGRID
CONTAINS
PROCEDURE, PUBLIC :: REQPGRID => LM_ELEM_REGPGRID
END TYPE LM_ELEM_T
TYPE, PUBLIC :: PS_SN0N_T
CLASS(DT_GRID_T), POINTER :: PGRID
CONTAINS
PROCEDURE, PUBLIC :: ASGOELE => PS_SN0N_ASGOELE
END TYPE PS_SN0N_T
CONTAINS
!
!
FUNCTION LM_ELEM_REGPGRID(SELF) RESULT(PGRID)
CLASS(DT_GRID_T), POINTER :: PGRID
CLASS(LM_ELEM_T), INTENT(IN) :: SELF
PGRID => SELF%PGRID
RETURN
END FUNCTION LM_ELEM_REGPGRID
!
!
FUNCTION PS_SN0N_ASGOELE(SELF, OELE) RESULT(ERMSG)
INTEGER :: ERMSG
CLASS(PS_SN0N_T), INTENT(IN) :: SELF
CLASS(LM_ELEM_T), INTENT(IN) :: OELE
!CLASS(DT_GRID_T), POINTER :: PGRID
LOGICAL :: ISOK
!
! ASSOCIATED with temp variable compiles
!PGRID => OELE%REQPGRID()
!ISOK = ASSOCIATED(SELF%PGRID, PGRID)
! ASSOCIATE without temp variable crashes with ICE
ISOK = ASSOCIATED(SELF%PGRID, OELE%REQPGRID())
ERMSG = 0
IF (ISOK) ERMSG = 1
RETURN
END FUNCTION PS_SN0N_ASGOELE
END MODULE PS_SN0N_M
USE PS_SN0N_M
CLASS(PS_SN0N_T), ALLOCATABLE :: SELF
CLASS(LM_ELEM_T), ALLOCATABLE :: OELE
TYPE (DT_GRID_T), TARGET :: GRID1 = DT_GRID_T (42)
TYPE (DT_GRID_T), TARGET :: GRID2 = DT_GRID_T (84)
ALLOCATE (PS_SN0N_T :: SELF)
ALLOCATE (LM_ELEM_T :: OELE)
SELF%PGRID => GRID1
OELE%PGRID => NULL ()
IF (SELF%ASGOELE (OELE) .NE. 0) STOP 1
OELE%PGRID => GRID2
IF (SELF%ASGOELE (OELE) .NE. 0) STOP 2
OELE%PGRID => GRID1
IF (SELF%ASGOELE (OELE) .NE. 1) STOP 3
END
[Bug target/98681] [8/9/10/11 Regression] aarch64: Invalid ubfiz instruction rejected by assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98681 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Jakub Jelinek --- Created attachment 50035 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50035=edit gcc11-pr98681.patch Untested fix.
[Bug target/98681] [8/9/10/11 Regression] aarch64: Invalid ubfiz instruction rejected by assembler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98681
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Adjusted testcase (-O2):
__attribute__((noipa)) int
foo (int x)
{
if (x > 32)
return (x << -64) & 255;
else
return x;
}
int
main ()
{
if (foo (32) != 32 || foo (-150) != -150)
__builtin_abort ();
return 0;
}
This doesn't invoke UB.
[Bug testsuite/98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- What is the current status of this PR?
[Bug fortran/98573] Dynamic type lost on assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98573 --- Comment #6 from David Neill Asanza --- Thanks for looking into this Paul. I'm looking forward to having this fixed. :)
[Bug testsuite/98795] modules testsuite testnames
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98795 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Nathan Sidwell --- eee8ed2f22b 2021-01-22 | testsuite: Uniquify test names [PR 98795]
[Bug testsuite/98795] modules testsuite testnames
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98795 --- Comment #1 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:eee8ed2f22b36dfe64a9516171871476e8ede477 commit r11-6860-geee8ed2f22b36dfe64a9516171871476e8ede477 Author: Nathan Sidwell Date: Fri Jan 22 06:44:22 2021 -0800 testsuite: Uniquify test names [PR 98795] Header unit names come from the path the preprocessor determines, and thus can be absolute. This tweaks the testsuite to elide that absoluteness when embedded in a CMI name. We were also not distinguishing link and execute tests by the $std flags, so append them when necessary. PR testsuite/98795 gcc/testsuite/ * g++.dg/modules/modules.exp (module_cmi_p): Avoid embedded absolute paths. (module_do_it): Append $std to test name.
[Bug debug/98796] Incorrect .debug_line emitted for DWARF5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98796 --- Comment #1 from Jakub Jelinek --- Created attachment 50034 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50034=edit gcc11-pr98796.patch Untested fix.
[Bug tree-optimization/98255] [10 Regression] wrong code at -Os and above with -fPIC on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98255 --- Comment #16 from Richard Biener --- (In reply to Jakub Jelinek from comment #15) > Fixed on the trunk. Not sure what to do in 10.3. Same, if there's no fallout.
[Bug tree-optimization/98793] [11 Regression] wrong code with --param=max-jump-thread-duplication-stmts=4 since r11-6468-g01da03c915f086fb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98793 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Richard Biener --- Fixed.
[Bug tree-optimization/98793] [11 Regression] wrong code with --param=max-jump-thread-duplication-stmts=4 since r11-6468-g01da03c915f086fb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98793 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:4be156d6bef317b8704052f11431457a577ed564 commit r11-6859-g4be156d6bef317b8704052f11431457a577ed564 Author: Richard Biener Date: Fri Jan 22 14:32:39 2021 +0100 middle-end/98793 - properly handle BLKmode vectors in vector_element_bits The previous change made AVX512 mask vectors correct but disregarded the possibility of generic (BLKmode) boolean vectors which are exposed by the frontends already. 2021-01-22 Richard Biener PR middle-end/98793 * tree.c (vector_element_bits): Key single-bit bool vector on integer mode rather than not vector mode. * gcc.dg/pr98793.c: New testcase.
[Bug debug/98796] Incorrect .debug_line emitted for DWARF5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98796 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2021-01-22 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED
[Bug debug/98796] New: Incorrect .debug_line emitted for DWARF5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98796 Bug ID: 98796 Summary: Incorrect .debug_line emitted for DWARF5 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- GCC emits incorrect DWARF5 on empty translation units. > empty.c gcc -S -gdwarf-5 -dA empty.c -o empty.s -gno-as-loc-support or gcc -S -gdwarf-5 -dA empty.c -o empty.s -flto -ffat-lto-objects emits .byte 0 # Directory entry format count .uleb128 0 # Directories count .byte 0 # File name entry format count .uleb128 0 # File names count at the end of .debug_line or .gnu.debuglto_.debug_line sections. The DWARF5 specification says: "The first entry is the current directory of the compilation." and "The first entry in the sequence is the primary source file whose file name exactly matches that given in the DW_AT_name attribute in the compilation unit debugging information entry." which is not honored when no directory and file name entries are provided.
[Bug other/98790] [10/11 Regression] ICE in append_to_statement_list_1 (Segmentation Fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98790 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/98756] Suspicious "(*this)." in mangled symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98756 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-01-22 --- Comment #2 from Marek Polacek --- Ah, thanks. Confirmed thus.
[Bug target/98093] ICE in gen_vsx_set_v2df, at config/rs6000/vsx.md:3276
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98093 --- Comment #3 from CVS Commits --- The master branch has been updated by Xiong Hu Luo : https://gcc.gnu.org/g:e3a8ef8ef2ac077b393687624b09db6ab31c7746 commit r11-6858-ge3a8ef8ef2ac077b393687624b09db6ab31c7746 Author: Xionghu Luo Date: Thu Jan 21 21:03:28 2021 -0600 rs6000: Enable vec_insert for P8 with rs6000_expand_vector_set_var_p8 [PR98093] Support P8 variable vec_insert and Update testcases' instruction count. gcc/ChangeLog: 2021-01-22 Xionghu Luo PR target/98093 * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Generate ARRAY_REF(VIEW_CONVERT_EXPR) for P8 and later platforms. * config/rs6000/rs6000.c (rs6000_expand_vector_set_var): Update to call different path for P8 and P9. (rs6000_expand_vector_set_var_p9): New function. (rs6000_expand_vector_set_var_p8): New function. gcc/testsuite/ChangeLog: 2021-01-22 Xionghu Luo * gcc.target/powerpc/pr79251.p8.c: New test. * gcc.target/powerpc/fold-vec-insert-char-p8.c: Adjust instruction counts. * gcc.target/powerpc/fold-vec-insert-char-p9.c: Likewise. * gcc.target/powerpc/fold-vec-insert-double.c: Likewise. * gcc.target/powerpc/fold-vec-insert-float-p8.c: Likewise. * gcc.target/powerpc/fold-vec-insert-float-p9.c: Likewise. * gcc.target/powerpc/fold-vec-insert-int-p8.c: Likewise. * gcc.target/powerpc/fold-vec-insert-int-p9.c: Likewise. * gcc.target/powerpc/fold-vec-insert-longlong.c: Likewise. * gcc.target/powerpc/fold-vec-insert-short-p8.c: Likewise. * gcc.target/powerpc/fold-vec-insert-short-p9.c: Likewise. * gcc.target/powerpc/vsx-builtin-7.c: Likewise.
[Bug target/98065] [11 Regression] ICE in rs6000_expand_vector_set, at config/rs6000/rs6000.c:7024 since r11-5457
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98065 --- Comment #5 from CVS Commits --- The master branch has been updated by Xiong Hu Luo : https://gcc.gnu.org/g:b29225597584b697762585e0b707b7cb4b427650 commit r11-6857-gb29225597584b697762585e0b707b7cb4b427650 Author: Xionghu Luo Date: Thu Jan 21 21:01:24 2021 -0600 rs6000: Support variable insert and Expand vec_insert in expander [PR79251] vec_insert accepts 3 arguments, arg0 is input vector, arg1 is the value to be insert, arg2 is the place to insert arg1 to arg0. Current expander generates stxv+stwx+lxv if arg2 is variable instead of constant, which causes serious store hit load performance issue on Power. This patch tries 1) Build VIEW_CONVERT_EXPR for vec_insert (i, v, n) like v[n&3] = i to unify the gimple code, then expander could use vec_set_optab to expand. 2) Expand the IFN VEC_SET to fast instructions: lvsr+insert+lvsl. In this way, "vec_insert (i, v, n)" and "v[n&3] = i" won't be expanded too early in gimple stage if arg2 is variable, avoid generating store hit load instructions. For Power9 V4SI: addi 9,1,-16 rldic 6,6,2,60 stxv 34,-16(1) stwx 5,9,6 lxv 34,-16(1) => rlwinm 6,6,2,28,29 mtvsrwz 0,5 lvsr 1,0,6 lvsl 0,0,6 xxperm 34,34,33 xxinsertw 34,0,12 xxperm 34,34,32 Though instructions increase from 5 to 7, the performance is improved 60% in typical cases. Tested with V2DI, V2DF V4SI, V4SF, V8HI, V16QI on Power9-LE. 2021-01-22 Xionghu Luo gcc/ChangeLog: PR target/79251 PR target/98065 * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Ajdust variable index vec_insert from address dereference to ARRAY_REF(VIEW_CONVERT_EXPR) tree expression. * config/rs6000/rs6000-protos.h (rs6000_expand_vector_set_var): New declaration. * config/rs6000/rs6000.c (rs6000_expand_vector_set_var): New function. 2021-01-22 Xionghu Luo gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr79251.p9.c: New test. * gcc.target/powerpc/pr79251-run.c: New test. * gcc.target/powerpc/pr79251.h: New header.
[Bug target/79251] PowerPC vec_insert generates store-hit-load if the element number is variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79251 --- Comment #6 from CVS Commits --- The master branch has been updated by Xiong Hu Luo : https://gcc.gnu.org/g:b29225597584b697762585e0b707b7cb4b427650 commit r11-6857-gb29225597584b697762585e0b707b7cb4b427650 Author: Xionghu Luo Date: Thu Jan 21 21:01:24 2021 -0600 rs6000: Support variable insert and Expand vec_insert in expander [PR79251] vec_insert accepts 3 arguments, arg0 is input vector, arg1 is the value to be insert, arg2 is the place to insert arg1 to arg0. Current expander generates stxv+stwx+lxv if arg2 is variable instead of constant, which causes serious store hit load performance issue on Power. This patch tries 1) Build VIEW_CONVERT_EXPR for vec_insert (i, v, n) like v[n&3] = i to unify the gimple code, then expander could use vec_set_optab to expand. 2) Expand the IFN VEC_SET to fast instructions: lvsr+insert+lvsl. In this way, "vec_insert (i, v, n)" and "v[n&3] = i" won't be expanded too early in gimple stage if arg2 is variable, avoid generating store hit load instructions. For Power9 V4SI: addi 9,1,-16 rldic 6,6,2,60 stxv 34,-16(1) stwx 5,9,6 lxv 34,-16(1) => rlwinm 6,6,2,28,29 mtvsrwz 0,5 lvsr 1,0,6 lvsl 0,0,6 xxperm 34,34,33 xxinsertw 34,0,12 xxperm 34,34,32 Though instructions increase from 5 to 7, the performance is improved 60% in typical cases. Tested with V2DI, V2DF V4SI, V4SF, V8HI, V16QI on Power9-LE. 2021-01-22 Xionghu Luo gcc/ChangeLog: PR target/79251 PR target/98065 * config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin): Ajdust variable index vec_insert from address dereference to ARRAY_REF(VIEW_CONVERT_EXPR) tree expression. * config/rs6000/rs6000-protos.h (rs6000_expand_vector_set_var): New declaration. * config/rs6000/rs6000.c (rs6000_expand_vector_set_var): New function. 2021-01-22 Xionghu Luo gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr79251.p9.c: New test. * gcc.target/powerpc/pr79251-run.c: New test. * gcc.target/powerpc/pr79251.h: New header.
[Bug c++/98756] Suspicious "(*this)." in mangled symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98756
ensadc at mailnesia dot com changed:
What|Removed |Added
CC||ensadc at mailnesia dot com
--- Comment #1 from ensadc at mailnesia dot com ---
Reduced:
```
class a {};
struct f {
template
int operator()(d, double, e);
};
struct i : f {
template
auto h(g...) -> decltype(operator()(g()...)) {}
// { dg-final { scan-assembler
"_ZN1i1hIJ1adS1_EEEDTcldtdefpTonclspcvT__EEEDpS2_" } }
};
a m, n;
int p = i{}.h(m, 1.0, n);
```
This is similar to the case mentioned in
https://itanium-cxx-abi.github.io/cxx-abi/cxx-abi-dev/archives/2011-July/002420.html
(but Clang does emit 'dtdefpT' in that example).
Itanium C++ ABI does not (yet) specify what to do in this case.
[Bug driver/98783] Wrong ouput of "-O3 -Q --help=optimizers" on gcc built with --enable-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98783 --- Comment #6 from Martin Liška --- (In reply to hasse.christoph from comment #5) > I wasn't aware of this fix yet, sorry for the duplicate. That's fine, you could not know about it :) > I really appreciate you taking the time to solve this so quickly! :) We're trying to do our best.
[Bug driver/98783] Wrong ouput of "-O3 -Q --help=optimizers" on gcc built with --enable-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98783 --- Comment #5 from hasse.christoph at cern dot ch --- I wasn't aware of this fix yet, sorry for the duplicate. I really appreciate you taking the time to solve this so quickly! :)
[Bug driver/98783] Wrong ouput of "-O3 -Q --help=optimizers" on gcc built with --enable-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98783 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #4 from Martin Liška --- (In reply to hasse.christoph from comment #3) > --help=optimizers on GCC 10.2.0 build with --enable-frame-pointer prints: > > -fomit-frame-pointer [enabled] > > This flag should however be disabled by default. Yes, but tip of gcc-10 branch is fine: likely since: https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=f7e39d1f137202a5d554849f6930ade58c312acd $ ./xgcc -B. -O3 -Q --help=optimizers | grep omit -fomit-frame-pointer [disabled]
[Bug tree-optimization/98793] [11 Regression] wrong code with --param=max-jump-thread-duplication-stmts=4 since r11-6468-g01da03c915f086fb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98793 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED Known to fail|11.0| --- Comment #4 from Richard Biener --- Mine. I have a fix, but there's a complication in that if we ever manage to get boolean vectors for 'generic' vectors (the vectorizer using sth like 'long' to hold a v8qi) then things will break.
[Bug other/98790] [10/11 Regression] ICE in append_to_statement_list_1 (Segmentation Fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98790 --- Comment #9 from Matthias Klose --- however reverting the fix for PR82099 lets the build succeed again. it also fixes the mkvtoolnix build (https://bugs.debian.org/PR980596).
[Bug libstdc++/98785] _Unwind_ForcedUnwind going through a non-empty exception specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98785 --- Comment #2 from Jonathan Wakely --- FWIW I think this belongs to the libgcc or c++ components, as _Unwind_ForcedUnwind is not defined in libstdc++.
[Bug driver/98783] Wrong ouput of "-O3 -Q --help=optimizers" on gcc built with --enable-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98783 --- Comment #3 from hasse.christoph at cern dot ch --- --help=optimizers on GCC 10.2.0 build with --enable-frame-pointer prints: -fomit-frame-pointer[enabled] This flag should however be disabled by default.
[Bug c++/98531] [11 Regression] g++.dg/modules/xtreme-header-2_a.H etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98531 --- Comment #6 from Nathan Sidwell --- I've moved the testsuite issues to 98795
[Bug testsuite/98795] modules testsuite testnames
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98795 Nathan Sidwell changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-01-22 Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug testsuite/98795] New: modules testsuite testnames
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98795 Bug ID: 98795 Summary: modules testsuite testnames Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- [from 98531] a) header-unit names are from the preprocessor's resolution of the header file. We end up with (relative) paths constructed from absolute paths, which is a problem when comparing test results: +FAIL: g++.dg/modules/xtreme-header-2_a.H module-cmi (gcm.cache/vol/gcc/src/hg/master/local/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H.gcm) must not use absolute filename here +FAIL: g++.dg/modules/xtreme-header-2_b.C -std=c++2a (test for excess errors) b) execution tests do not distinguish between c++2a and c++17, so they don't have unique names.
[Bug gcov-profile/98739] -fprofile-reproducible is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98739 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:b46027c6544d3680b3647d3c771c9844b8b95772 commit r11-6856-gb46027c6544d3680b3647d3c771c9844b8b95772 Author: Martin Liska Date: Fri Jan 22 14:00:30 2021 +0100 Drop time profile for multi-threaded training run. gcc/ChangeLog: PR gcov-profile/98739 * profile.c (compute_value_histograms): Drop time profile for -fprofile-reproducible=multithreaded.
[Bug target/94368] [9 Regression] ICE in final_scan_insn_1, at final.c:3074(error: could not split insn) on aarch64-linux-gnu since r9-3744
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94368 Wilco changed: What|Removed |Added CC||wilco at gcc dot gnu.org Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Wilco --- Closing since the fix has been backported to all active branches.
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 Richard Biener changed: What|Removed |Added Status|WAITING |UNCONFIRMED Version|10.0|10.2.0 Target|mips64 |mips64el-unknown-linux-gnua ||bi64 Ever confirmed|1 |0 --- Comment #15 from Richard Biener --- So I see that 242: 0 SECTION LOCAL DEFAULT UND and that's indeed broken (UND SECTION?) but ld complains that the SECTION type is after the last section entry. So next up would be to look at the assembly file the compiler generates for libsass.so.1.0.0.ltrans16.ltrans.o. The console output shows how it's generated: as -v -EL -mips64r2 -mips64r2 -mmsa -mloongson-ext -mloongson-ext -mloongson-ext2 -mloongson-ext2 -O2 -mabi=64 -mabi=64 -march=gs464e -march=gs464e -march=gs464e -mtune=gs464e -mtune=gs464e -mtune=gs464e -KPIC -o libsass.so.1.0.0.ltrans16.ltrans.o libsass.so.1.0.0.ltrans16.s and the "last" section I see in there is .section.note.GNU-stack,"",@progbits and I can confirm that GNU as (2.35.1) produces an object with the strange section (using a cross binutils). I think that no valid assembly file should produce that so may I suggest to file a bug at sourceware for an assembler issue? (just use the libsass.so.1.0.0.ltrans16.s file as testcase) Maybe there's more mips people around than here.
[Bug driver/98783] Wrong ouput of "-O3 -Q --help=optimizers" on gcc built with --enable-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98783 Martin Liška changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #2 from Martin Liška --- I think it's duplicate of PR98361. Can you please mention what --help output is wrong and for which releases?
[Bug driver/98794] @file error checking is inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98794 --- Comment #1 from Andrew Pinski --- Related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31566.
[Bug tree-optimization/98793] [11 Regression] wrong code with --param=max-jump-thread-duplication-stmts=4 since r11-6468-g01da03c915f086fb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98793 Martin Liška changed: What|Removed |Added Summary|[11 Regression] wrong code |[11 Regression] wrong code |with|with |--param=max-jump-thread-dup |--param=max-jump-thread-dup |lication-stmts=4|lication-stmts=4 since ||r11-6468-g01da03c915f086fb CC||marxin at gcc dot gnu.org Known to work||10.2.0 --- Comment #3 from Martin Liška --- Started with r11-6468-g01da03c915f086fb.
[Bug driver/98794] New: @file error checking is inconsistent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98794 Bug ID: 98794 Summary: @file error checking is inconsistent Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- The driver's behaviour with missing @files is inconsistent, possibly to allow actual source files of that form. See https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564008.html for some analysis.
[Bug c++/98452] error: unknown Compiled Module Interface: no such module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98452 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Nathan Sidwell --- 4804de453e7 2021-01-19 | driver: do not check file existence here [PR 98452]
[Bug other/98790] [10/11 Regression] ICE in append_to_statement_list_1 (Segmentation Fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98790 --- Comment #8 from Matthias Klose --- I tried to apply the trunk fix for PR98659 on the gcc-10 branch, but it still shows an ICE.
[Bug tree-optimization/98793] [11 Regression] wrong code with --param=max-jump-thread-duplication-stmts=4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98793 --- Comment #2 from Richard Biener --- Looks like an interaction between threading and vector lowering, with -mavx512bw it works (using SDE).
[Bug target/98092] [11 Regression] ICE in extract_insn, at recog.c:2315 (error: unrecognizable insn)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98092
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2021-01-22
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC||carll at gcc dot gnu.org,
||jakub at gcc dot gnu.org,
||segher at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
The expander emits an UNORDERED comparison:
(define_expand "bcdinvalid_"
[(parallel [(set (reg:CCFP CR6_REGNO)
(compare:CCFP
(unspec:V2DF [(match_operand:VBCD 1 "register_operand")]
UNSPEC_BCDADD)
(match_dup 2)))
(clobber (match_scratch:VBCD 3))])
(set (match_operand:SI 0 "register_operand")
(unordered:SI (reg:CCFP CR6_REGNO)
(const_int 0)))]
"TARGET_P8_VECTOR"
{
operands[2] = CONST0_RTX (V2DFmode);
})
But set_cc insn will not match with -ffinite-math-only for UNORDERED,
given:
(define_predicate "scc_comparison_operator"
(and (match_operand 0 "branch_comparison_operator")
(match_code "eq,lt,gt,ltu,gtu,unordered")))
(define_predicate "branch_comparison_operator"
(and (match_operand 0 "comparison_operator")
(match_test "GET_MODE_CLASS (GET_MODE (XEXP (op, 0))) == MODE_CC")
(if_then_else (match_test "GET_MODE (XEXP (op, 0)) == CCFPmode
&& !flag_finite_math_only")
(match_code "lt,gt,eq,unordered,unge,unle,ne,ordered")
(match_code "lt,ltu,le,leu,gt,gtu,ge,geu,eq,ne"))
(match_test "validate_condition_mode (GET_CODE (op),
GET_MODE (XEXP (op, 0))),
1")))
Dunno how to get out of this, perhaps for !flag_finite_math_only expand to a
different instruction that will do both the bcdadd. and mfcr and rlwinm and
just clobber the cc reg?
[Bug other/98790] [10/11 Regression] ICE in append_to_statement_list_1 (Segmentation Fault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98790 --- Comment #7 from Martin Liška --- (In reply to Martin Liška from comment #6) > I think it's fixed with r11-6804-g2b27f37f90cb66e2. But it fails on gcc-10 branch since g:ff22b4e8d0613170601d28eec9462ea31147c7c7. @Marek: Can you please take a look?
[Bug tree-optimization/98766] [10/11 Regression] SVE: ICE in tree_to_shwi with -O3 --param=avoid-fma-max-bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98766 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #3 from ktkachov at gcc dot gnu.org --- Patch posted at https://gcc.gnu.org/pipermail/gcc-patches/2021-January/564082.html
