[Bug c++/97034] [11 Regression] ICE on C++20 code: gcc_assert failure in return type deduction (gcc/cp/pt.c:26984 in type_dependent_expression_p(tree_node*))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97034
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
--- Comment #5 from Arthur O'Dwyer ---
Is mine the same bug? Mine is also a regression (trunk crashes where GCC 10.2
had succeeded).
// https://godbolt.org/z/Ysh6as
struct C { void f(auto) noexcept; };
void C::f(auto) noexcept(C::x) {}
Compile with -std=c++20:
:3:29: error: 'x' is not a member of 'C'
3 | void C::f(auto) noexcept(C::x) {}
| ^
:3:6: error: declaration of 'void C::f(auto:2)' has a different
exception specifier
3 | void C::f(auto) noexcept(C::x) {}
| ^
:2:17: note: from previous declaration 'void C::f(auto:1) noexcept'
2 | struct C { void f(auto) noexcept; };
| ^
:3:30: internal compiler error: in type_dependent_expression_p, at
cp/pt.c:27166
3 | void C::f(auto) noexcept(C::x) {}
| ^
0x1cc31d9 internal_error(char const*, ...)
???:0
0x6b25f7 fancy_abort(char const*, int, char const*)
???:0
0x8ee70a type_dependent_expression_p(tree_node*)
???:0
0x137d4f3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
???:0
0x1381b55 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*))
???:0
0x8ea937 instantiation_dependent_uneval_expression_p(tree_node*)
???:0
0x8f2198 instantiation_dependent_expression_p(tree_node*)
???:0
0x8f2216 uses_template_parms(tree_node*)
???:0
0x78ffe8 duplicate_decls(tree_node*, tree_node*, bool, bool)
???:0
0x79a2b6 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
???:0
0x79dda6 start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
???:0
0x8d803d c_parse_file()
???:0
0xa54072 c_common_parse_file()
???:0
[Bug c++/96197] Excess memory consumption, positive correlation with the size of a constexpr array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96197 Patrick Palka changed: What|Removed |Added CC||adamkzyzik at gmail dot com --- Comment #11 from Patrick Palka --- *** Bug 98604 has been marked as a duplicate of this bug. ***
[Bug c++/98604] Passing constexpr by const reference causes excessive memory usage during compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98604 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Patrick Palka --- Thanks for the bug report. I think this might be a dup of PR96197, which has been fixed on the 10 and 11 branches. *** This bug has been marked as a duplicate of bug 96197 ***
[Bug c++/96197] Excess memory consumption, positive correlation with the size of a constexpr array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96197 Patrick Palka changed: What|Removed |Added Target Milestone|--- |10.3 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Patrick Palka --- Fixed for GCC 10.3 and 11
[Bug c++/98551] [10/11 Regression] ICE in replace_result_decl, at cp/constexpr.c:2150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98551 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Patrick Palka --- Fixed for GCC 10.3+
[Bug c++/98551] [10/11 Regression] ICE in replace_result_decl, at cp/constexpr.c:2150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98551 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:ee697d4bbb7991c99539ba6c20ec76b5d488cffc commit r10-9241-gee697d4bbb7991c99539ba6c20ec76b5d488cffc Author: Patrick Palka Date: Fri Jan 8 10:11:25 2021 -0500 c++: ICE with constexpr call that returns a PMF [PR98551] We shouldn't do replace_result_decl after evaluating a call that returns a PMF because PMF temporaries aren't wrapped in a TARGET_EXPR (and so we can't trust ctx->object), and PMF initializers can't be self-referential anyway, so replace_result_decl would always be a no-op. To that end, this patch changes the relevant AGGREGATE_TYPE_P test to CLASS_TYPE_P, which should rule out PMFs (as well as arrays, which we can't return and therefore won't see here). This fixes an ICE from the sanity check in replace_result_decl in the below testcase during constexpr evaluation of the call f() in the initializer g(f()). gcc/cp/ChangeLog: PR c++/98551 * constexpr.c (cxx_eval_call_expression): Check CLASS_TYPE_P instead of AGGREGATE_TYPE_P before calling replace_result_decl. gcc/testsuite/ChangeLog: PR c++/98551 * g++.dg/cpp0x/constexpr-pmf2.C: New test. (cherry picked from commit bb1f0b50abbfa01e0ed720a5225a11aa7af32a89)
[Bug c++/96197] Excess memory consumption, positive correlation with the size of a constexpr array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96197 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:afe708223f0bfffe688674659f7a71c5130f01d1 commit r10-9240-gafe708223f0bfffe688674659f7a71c5130f01d1 Author: Patrick Palka Date: Thu Jul 30 22:21:41 2020 -0400 c++: decl_constant_value and unsharing [PR96197] In the testcase from the PR we're seeing excessive memory use (> 5GB) during constexpr evaluation, almost all of which is due to the call to decl_constant_value in the VAR_DECL/CONST_DECL branch of cxx_eval_constant_expression. We reach here every time we evaluate an ARRAY_REF of a constexpr VAR_DECL, and from there decl_constant_value makes an unshared copy of the VAR_DECL's initializer. But unsharing here is unnecessary because callers of cxx_eval_constant_expression already unshare its result when necessary. To fix this excessive unsharing, this patch adds a new defaulted parameter unshare_p to decl_really_constant_value and decl_constant_value so that callers can control whether to unshare. As a simplification, we can also move the call to unshare_expr in constant_value_1 outside of the loop, since doing unshare_expr on a DECL_P is a no-op. Now that we no longer unshare the result of decl_constant_value and decl_really_constant_value from cxx_eval_constant_expression, memory use during constexpr evaluation for the testcase from the PR falls from ~5GB to 15MB according to -ftime-report. gcc/cp/ChangeLog: PR c++/96197 * constexpr.c (cxx_eval_constant_expression) : Pass false to decl_constant_value and decl_really_constant_value so that they don't unshare their result. * cp-tree.h (decl_constant_value): New declaration with an added bool parameter. (decl_really_constant_value): Add bool parameter defaulting to true to existing declaration. * init.c (constant_value_1): Add bool parameter which controls whether to unshare the initializer before returning. Call unshare_expr at most once. (scalar_constant_value): Pass true to constant_value_1's new bool parameter. (decl_really_constant_value): Add bool parameter and forward it to constant_value_1. (decl_constant_value): Likewise, but instead define a new overload with an added bool parameter. gcc/testsuite/ChangeLog: PR c++/96197 * g++.dg/cpp1y/constexpr-array8.C: New test. (cherry picked from commit 8c00059ce058ea2aec2933319e270f5443b8b909)
[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577 --- Comment #21 from kargl at gcc dot gnu.org --- (In reply to Chinoune from comment #20) > won't fix. This is hilarious! Now, I know why you are so confused. >From your code in comment #2 call system_clock( t1, count_rate_r32 ) c = matmul( a, b ) call system_clock( t2 ) t1 and t2 are integer(8) and count_rate_r32 is integer(4). In the first call to system_clock(), the clock rate is set 1000 and t1 counts ticks on the millisecond time scale. In the second call to system_clock(), t2 counts ticks on the nanosecond time scale. gfortran uses the least kind type parameter of the actual arguments to determine which time scale to use. So, for the first call of system_clock(), min(kind(t1), kind(count_rate_r32)) = 4, and you get milliseconds. For the second, kind(t2) = 8, and you get nanoseconds. Intel, which appears to be your gold standard, chooses to use the kind type parameter of the first argument. Both implementations are correct because .. these are processor-dependent values. To paraphrase, Steve Lionel (former Intel Fortran compiler engineer), asks "why one would mix types?" See comp.lang.fortran for his comment. Note, the sequence call system_clock(count_rate_r32) call system_clock(t1) c = matmul( a, b ) call system_clock(t2) will give you the wrong timing with both gfortran and Intel, or will give a correct relative timing. So, to summarize, you are seeing processor-dependent behavior. There is no bug, here. There is nothing to fix.
[Bug rtl-optimization/97714] [8/9/10/11 Regression] ICE in notice_source_line, at final.c:3237 since r8-5241-g8697bf9f46f36168
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97714 Alexandre Oliva changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Alexandre Oliva --- Fixed
[Bug tree-optimization/98598] Missed opportunity to optimize dependent loads in loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98598 --- Comment #5 from Jiangning Liu --- > It has to be done with care of course, cost modeling is difficult > (we need to have a good estimate of n and m or need to version > the whole nest). That said, usually we attempt the reverse transform. Before tuning the cost model good enough, we may implement this optimization by adding a new optimization command line option. This won't hurt gcc, right? > > My personal opinion is that hinting the user to possibly refactor > his code (guided by profiling to be not too noisy) is much > prefered to the idea that the compiler can ever apply such transform > to the loops where it matters and not to the loops where it is > harmful. Sometimes, it is not always easy for the user to modify the code, and even the user may be lazy and reluctant to change the code. This kind of Memory Gathering Optimization can make end-user's life easier.
[Bug rtl-optimization/97714] [8/9/10/11 Regression] ICE in notice_source_line, at final.c:3237 since r8-5241-g8697bf9f46f36168
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97714 --- Comment #3 from CVS Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:57450da2fef3a32dc463b85e7b3d67f519b282cb commit r11-6561-g57450da2fef3a32dc463b85e7b3d67f519b282cb Author: Alexandre Oliva Date: Thu Dec 31 21:37:24 2020 -0300 final: accept markers at line 0 Back when I introduced debug markers, I seem to have been under the impression that location line 0 would only ever occur for unknown and builtin locations. Though line 0 never comes up in normal processing of source files, and debug info formats often cannot represent them, I suppose there's no need to preemptively discard them during final. for gcc/ChangeLog PR debug/97714 * final.c (notice_source_line): Narrow down the condition to skip a line-0 marker. for gcc/testsuite/ChangeLog PR debug/97714 * gcc.dg/debug/pr97714.c: New.
[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577 Chinoune changed: What|Removed |Added CC||anlauf at gcc dot gnu.org, ||rguenth at gcc dot gnu.org, ||tkoenig at gcc dot gnu.org Resolution|INVALID |--- Status|RESOLVED|UNCONFIRMED --- Comment #20 from Chinoune --- won't fix.
[Bug d/98607] GDC merging computations but rounding mode has changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98607 --- Comment #1 from Iain Buclaw --- To be fair, C++ does the same as well. The problem is the inliner (though no inlining occurs when using immintrin.h)
Re: [PATCH] c++: private inheritance access diagnostics fix [PR17314]
Hi Jason,
Thank you!
> To start with, do you have a copyright assignment on file or in the
> works already?
Good point. I incorrectly assumed it would only be a minor
contribution copyright-wise. Mr Edelsohn gave me a template which I've
now filled out and sent to ass...@gnu.org. I'm assuming I just need to
wait for them to send me the form. I'll update this thread when that's
sorted. In the meantime I've hopefully fixed some of the issues.
> Second, your patch was mangled by word wrap so that it can't be applied
> without manual repair. If you can't prevent word wrap in your mail
> client, please send it as an attachment rather than inline.
Oh yes I see where it's gotten mangled now. I'm attaching it as a
.patch file (I assume that's okay).
> Also, there are a few whitespace issues in the patch; please run
> contrib/check_GNU_style.sh on the patch before submitting.
Should be all fixed now (there is one style issue left but it's a
false positive). Visual Studio Code was lying to me about what the
file looks like so if there are any more formatting issues please let
me know.
> If you use contrib/gcc-git-customization.sh and then git
> gcc-commit-mklog you don't need to touch ChangeLog files at all, just
> adjust the generated ChangeLog entries in the git commit message. I
> personally tend to commit first with a placeholder message and then use
> git gcc-commit-mklog --amend to generate the ChangeLog entries.
Wouldn't that require read-write access? (Just from looking here
https://gcc.gnu.org/gitwrite.html.)
> Probably. Can you use sort/uniq/diff on the .sum testsuite output to
> determine which passes are missing in the patched sources?
According to contrib/dg-cmp-results.sh ...
I get a bunch of these weird NA->PASSes (and vice-versa), for example:
PASS->NA: g++.dg/modules/alias-1_a.H module-cmi
(gcm.cache/home/anthony/Desktop/GCC/builds_and_source/source_clean/gcc/testsuite/g++.dg/modules/alias-1_a.H.gcm)
NA->PASS: g++.dg/modules/alias-1_a.H module-cmi
(gcm.cache/home/anthony/Desktop/GCC/builds_and_source/source_pr17314/gcc/testsuite/g++.dg/modules/alias-1_a.H.gcm)
PASS->NA: g++.dg/modules/alias-1_a.H module-cmi
(gcm.cache/home/anthony/Desktop/GCC/builds_and_source/source_clean/gcc/testsuite/g++.dg/modules/alias-1_a.H.gcm)
NA->PASS: g++.dg/modules/alias-1_a.H module-cmi
(gcm.cache/home/anthony/Desktop/GCC/builds_and_source/source_pr17314/gcc/testsuite/g++.dg/modules/alias-1_a.H.gcm)
They're weird because I haven't actually touched those files (so I'm
assuming this is normal). There are about ~400 of those and they're
all .gcm files. They seem to balance out.
dr142.c reports:
NA->PASS: g++.dg/tc1/dr142.C -std=c++14 (test for warnings, line 11)
PASS->NA: g++.dg/tc1/dr142.C -std=c++14 (test for warnings, line 5)
PASS->NA: g++.dg/tc1/dr142.C -std=c++14 (test for warnings, line 7)
PASS->NA: g++.dg/tc1/dr142.C -std=c++14 (test for warnings, line 8)
NA->PASS: g++.dg/tc1/dr142.C -std=c++17 (test for warnings, line 11)
PASS->NA: g++.dg/tc1/dr142.C -std=c++17 (test for warnings, line 5)
PASS->NA: g++.dg/tc1/dr142.C -std=c++17 (test for warnings, line 7)
PASS->NA: g++.dg/tc1/dr142.C -std=c++17 (test for warnings, line 8)
NA->PASS: g++.dg/tc1/dr142.C -std=c++2a (test for warnings, line 11)
PASS->NA: g++.dg/tc1/dr142.C -std=c++2a (test for warnings, line 5)
PASS->NA: g++.dg/tc1/dr142.C -std=c++2a (test for warnings, line 7)
PASS->NA: g++.dg/tc1/dr142.C -std=c++2a (test for warnings, line 8)
NA->PASS: g++.dg/tc1/dr142.C -std=c++98 (test for warnings, line 11)
PASS->NA: g++.dg/tc1/dr142.C -std=c++98 (test for warnings, line 5)
PASS->NA: g++.dg/tc1/dr142.C -std=c++98 (test for warnings, line 7)
PASS->NA: g++.dg/tc1/dr142.C -std=c++98 (test for warnings, line 8)
In other words, there are 12 PASS->NAs and 4 NA->PASSes in this file,
meaning a net change of -8 (which explains why there are eight fewer).
My other changes also report PASS->NAs and vice-versa, but for those
the number of new NAs equals the number of new PASSes, so they don't
cause a change in quantity.
Thanks for being patient with me. I'll let you know when I've
completed the forms.
Also if I need to adjust the .patch to deal with the changelogs issue
please let me know.
Kind regards,
Anthony
Index: gcc/testsuite/g++.old-deja/g++.jason/access8.C
===
--- gcc/testsuite/g++.old-deja/g++.jason/access8.C 2020-12-31 16:51:34.0 +
+++ gcc/testsuite/g++.old-deja/g++.jason/access8.C 2021-01-03 00:22:14.969854000 +
@@ -4,5 +4,5 @@
// Bug: g++ forgets access decls after the definition.
-class inh { // { dg-message "" } inaccessible
+class inh {
int a;
protected:
@@ -10,5 +10,6 @@ protected:
};
-class mel : private inh {
+class mel : private inh // { dg-message "" } inaccessible
+{
protected:
int t;
Index: gcc/testsuite/g++.old-deja/g++.law/access4.C
[Bug analyzer/98599] fatal error: Cgraph edge statement index out of range with -Os -flto -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98599
--- Comment #2 from David Malcolm ---
As far as I can tell, there are two invocations of lto1: wpa, then ltrans.
The analyzer is run in the first invocation.
The analyzer updates the gimple stmt uids; if I disable this updating the crash
doesn't happen.
The crash happens in the 2nd invocation of lto1 at:
1200 for (cedge = node->indirect_calls; cedge; cedge =
cedge->next_callee)
1201{
1202 if (STMT_UID_NOT_IN_RANGE (cedge->lto_stmt_uid))
1203fatal_error (input_location,
1204 "Cgraph edge statement index out of
range");
I haven't managed to fully debug this yet, but it looks like the stmt uids are
stored into the callgraph edge's lto_stmt_uid, and somewhere between the cgraph
and LTO infrastructure it doesn't expect an IPA pass (the analyzer) to change
the uids in the stmts from under it, even though gimple.h has this for the stmt
field:
/* UID of this statement. This is used by passes that want to
assign IDs to statements. It must be assigned and used by each
pass. By default it should be assumed to contain garbage. */
unsigned uid;
and gimple_set_uid has:
Please note that this UID property is supposed to be undefined at
pass boundaries. This means that a given pass should not assume it
contains any useful value when the pass starts and thus can set it
to any value it sees fit.
Adjust offset of array reference in named address space
Hi,
I'm implementing named addresses spaces for a Harvard architecture machine
to support copying data from instruction memory to data memory. This is
achieved via a special instruction. e.g. think AVR and progmem/__flash.
However, the instruction memory is narrower than the data memory (12 vs 16
bits) on this machine. So a single data word is split across 2 instruction
words. When copied from IMEM to DMEM the two parts are combined via SHIFT +
OR patterns.
This is all working fine for regular variables (i.e. int som_var), but it
falls apart for array references (i.e. some_array[1]). Since the data is
stored across 2 IMEM words, I need to scale the calculated offset of each
array reference by 2. e.g. array[0] is actually stored in imem[0] & imem[1]
and array[1] is stored in imem[2] & imem[3].
e.g.
static __imem int imem_array[2];
return imem_array[1];
// needs to generate a symbol reference like
_array.869+2
Similarly if the array index was a function parameter, I need to scale the
parameter by 2.
__imem int imem_array[2];
int some_func(int a)
{
// a needs to be scaled by 2 when generating RTL/ASM
return imem_array[a];
}
I haven't found any target hooks that would allow me to override the offset
calculation. Originally I thought I could handle it in a splitter but this
approach didn't work for the function parameter example as I ended up
scaling the entire address instead of just the offset.
I had another thought of using a combo of
TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS and
TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P to scale the offset and mark it as
adjusted but I don't think this combo will work in the end.
Is there any way to achieve this?
Thanks,
Tucker
Re: [PATCH] issue -Wstring-compare for member arrays (PR 98097)
On 1/7/21 5:53 PM, Martin Sebor via Gcc-patches wrote: > In PR 98097 Richard expects -Wstring-compare for a call to strcmp() > with a member array and a string literal of larger size, used in > an equality test. > > In virtually all cases the test will indicate the two are unequal > because the string stored in the member must be shorter (to fit > the terminating nul), but GCC doesn't fold the result because > there's wicked code out there that treats whole aggregates as if > they were strings, up their full size. Because the warning is > based on the same conservative assumptions as the optimization, > it doesn't trigger, letting the almost certain bug go unnoticed. > > The attached patch allows -Wstring-compare to trigger for these > bugs by partly decoupling the warning from the underlying strcmp > optimization. Making this possible requires adding a new member > to the c_strlen_data struct, which in turn called for changing > the meaning of the existing decl member to nonstr. That led to > changes elsewhere, simply to adjust to the name change. For > the purposes of review, the meat of the warning changes is in > tree-ssa-strlen.c. All the rest of changes simply adjust code > to the new name. > > Tested on x86_64-linux (None of Binutils, GDB, Glibc, or Valgrind > triggers any instances of the warning with this change.) > > Martin > > gcc-98097.diff > > PR middle-end/98097 - missing -Wstring-compare with a member array > > gcc/ChangeLog: > > PR middle-end/98097 > * builtins.c (unterminated_array): Adjust to a name change. Adjust > indentation. > (c_strlen): Use a member instead of a local variable. > (expand_builtin_stpcpy_1): Adjust to a name change. > (fold_builtin_strlen): Same. > * builtins.h (struct c_strlen_data::nonstr): New data member to use > instead of decl. >(struct c_strlen_data::decl): Adjust comment. > * gimple-fold.c (get_range_strlen_tree): Set c_strlen_data::nonstr > in addition to c_strlen_data::decl. > (get_maxval_strlen): Adjust to a name change. > (gimple_fold_builtin_stpcpy): Same. > (gimple_fold_builtin_strlen): Same. > * gimple-ssa-sprintf.c (get_string_length): Same. > * tree-ssa-strlen.c (get_range_strlen_dynamic): Same. Also set > struct c_strlen_data::decl. > (get_len_or_size): Use c_strlen_data::decl. Succeed even for > nonconstant member arrays. > (strxcmp_eqz_result): Handle member arrays. > (handle_builtin_string_cmp): Issue warnings for member arrays. > > gcc/testsuite/ChangeLog: > > PR middle-end/98097 > * gcc.dg/Wstring-compare.c: > * gcc.dg/strcmpopt_10.c: > * gcc.dg/Wstring-compare-4.c: New test. > * gcc.dg/Wstring-compare-5.c: New test. I think you need to update the function comment for gen_len_or_size to describe the special case where we make the range invalidate and inverted. OK with that change. jeff
[Bug objc++/98606] [10 regression] obj-c++.dg/template-4.mm fails erratically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98606 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-01-08 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Marek Polacek --- I suspect that we need to backport r11-4706 to gcc-10 to fix this.
[Bug objc++/98606] [10 regression] obj-c++.dg/template-4.mm fails erratically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98606 seurer at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from seurer at gcc dot gnu.org --- g:6fd09a6e8bcadaa69e1fdca09263990cc1c5245f, r10-9208 OK, after a bit more bisecting I think this is what started things commit 6fd09a6e8bcadaa69e1fdca09263990cc1c5245f (HEAD, refs/bisect/bad) Author: Marek Polacek Date: Sat Oct 24 15:26:27 2020 -0400 make -k check-gcc RUNTESTFLAGS="dg.exp=obj-c++.dg/template-4.mm" FAIL: obj-c++.dg/template-4.mm -fgnu-runtime (test for excess errors) # of unexpected failures1 # of unresolved testcases 1 r10-9207 ran clean for about 10 tries while r10-9208 failed every time I tried. Note that this does NOT occur in trunk (gcc 11), only in gcc 10.
gcc-9-20210108 is now available
Snapshot gcc-9-20210108 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20210108/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision 6fab822465a941e0f7c0861f34a76067d64c801c You'll find: gcc-9-20210108.tar.xzComplete GCC SHA256=cd0b73dd53d4f9304e4f81d48cb9e02b6dbad360b3272e1c5ab1dbd30196d0f4 SHA1=3e9c7c7056b7340cb38e3f51046c8a76ee1476b1 Diffs from 9-20210101 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[Bug go/98610] New: syscall.TestUnshareUidGidMapping sporadically fails on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98610 Bug ID: 98610 Summary: syscall.TestUnshareUidGidMapping sporadically fails on powerpc64le Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: murphyp at linux dot vnet.ibm.com CC: cmang at google dot com Target Milestone: --- openat is not always called through the libc variadic wrapper in libgo. This results in stack corruption on powerpc64le.
[Bug sanitizer/98609] New: sanitizer diagnoses VLAs with length zero although zero-length arrays are a GNU extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98609
Bug ID: 98609
Summary: sanitizer diagnoses VLAs with length zero although
zero-length arrays are a GNU extension
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
The following code is diagnosed with -fsanitize=undefined:
int main()
{
int n = 0;
double x[n];
}
runtime error: variable length array bound evaluates to non-positive value 0
But arrays of zero length are often useful and also generally support by GCC as
an extension. So it would be useful if this would get diagnosed by default. At
least there should be a way to turn this off.
[Bug sanitizer/98608] New: missing sanitizer detection for arrays with invalid length defind using typeof
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98608
Bug ID: 98608
Summary: missing sanitizer detection for arrays with invalid
length defind using typeof
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: muecker at gwdg dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone: ---
The following invalid code is not detected with -fsanitize=undefined
void f(int n, double (*x)[n])
{
typeof(*x) y;
// double y[n];
}
int main()
{
f(-1, 0);
}
Using the definition without typedef yields:
src/test.c:5:9: runtime error: variable length array bound evaluates to
non-positive value -1
[PATCH] aarch64 : Mark rotate immediates with '#' as per DDI0487iFc.
Hi, The armv8_arm manual [C6.2.226, ROR (immediate)] uses a # in front of the immediate rotation quantity. Although, it seems, GAS is able to infer the # (or is leninent about its absence) assemblers based on the LLVM back end expect it and error out. tested on aarch64-linux-gnu (gcc115) and aarch64-darwin20 (experimental) OK for master? thanks Iain gcc/ChangeLog: * config/aarch64/aarch64.md (_rol3): Add a '#' mark in front of the immediate quantity. (_rolsi3_uxtw): Likewise. --- gcc/config/aarch64/aarch64.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md index 45d9c6ac45a..e0de82c938a 100644 --- a/gcc/config/aarch64/aarch64.md +++ b/gcc/config/aarch64/aarch64.md @@ -4416,7 +4416,7 @@ (match_operand:QI 2 "aarch64_shift_imm_" "n")) (match_operand:GPI 3 "register_operand" "r")))] "" - "\\t%0, %3, %1, ror ( - %2)" + "\\t%0, %3, %1, ror #( - %2)" [(set_attr "type" "logic_shift_imm")] ) @@ -4441,7 +4441,7 @@ (match_operand:QI 2 "aarch64_shift_imm_si" "n")) (match_operand:SI 3 "register_operand" "r"] "" - "\\t%w0, %w3, %w1, ror (32 - %2)" + "\\t%w0, %w3, %w1, ror #(32 - %2)" [(set_attr "type" "logic_shift_imm")] ) -- 2.24.1
[Bug fortran/66366] [OOP] ICE on invalid with non-allocatable CLASS variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66366 --- Comment #12 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #11) > The error vanishes if the typebound procedure is removed from the type > declaration and the corresponding typebound call. Or renaming the local instance: subroutine frf() type(h5) :: xxx call xxx%c() end subroutine frf
Re: [PATCH] ira: Skip some pseudos in move_unallocated_pseudos
On 1/5/21 8:12 PM, Kewen.Lin wrote:
> on 2021/1/6 上午2:19, Jeff Law wrote:
>>
>> On 1/4/21 7:36 PM, Kewen.Lin wrote:
>>> Hi Jeff,
>>>
>>> on 2021/1/5 上午7:13, Jeff Law wrote:
On 12/22/20 11:40 PM, Kewen.Lin via Gcc-patches wrote:
> Hi Segher,
>
> on 2020/12/22 下午9:55, Segher Boessenkool wrote:
>> Hi!
>>
>> Just a dumb formatting comment:
>>
>> On Tue, Dec 22, 2020 at 04:05:39PM +0800, Kewen.Lin wrote:
>>> This patch is to make move_unallocated_pseudos consistent
>>> to what we have in function find_moveable_pseudos, where we
>>> record the original pseudo into pseudo_replaced_reg only if
>>> validate_change succeeds with newreg. To ensure every
>>> unallocated pseudo in move_unallocated_pseudos has expected
>>> information, it's better to add a check and skip it if it's
>>> unexpected. This avoids possible ICEs in future.
>>>
>>> btw, I happened to found this in the bootstrapping for one
>>> experimental local patch, which is considered as impractical.
>>> --- a/gcc/ira.c
>>> +++ b/gcc/ira.c
>>> @@ -5111,6 +5111,11 @@ move_unallocated_pseudos (void)
>>>{
>>> int idx = i - first_moveable_pseudo;
>>> rtx other_reg = pseudo_replaced_reg[idx];
>>> + /* If there is no appropriate pseudo in pseudo_replaced_reg, it
>>> + means validate_change fails for this new pseudo in function
>>> + find_moveable_pseudos, then bypass it here.*/
>> Dot space space.
> Good catch, thanks! I forgot to reformat after polishing the comments.
> Will fix it with other potential comments.
>
>> The patch sounds fine to me. Hard to tell without seeing the patch that
>> exposed the problem (for onlookers like me who do not know this code
>> well, anyway ;-) )
> The patch which made this issue exposed looks like:
>
> +; Like *rotl3_insert_3 but work with nonzero_bits rather than
> +; explicit AND.
> +(define_insn "*rotl3_insert_8"
> + [(set (match_operand:GPR 0 "gpc_reg_operand" "=r")
> +(ior:GPR (ashift:GPR (match_operand:GPR 1 "gpc_reg_operand" "r")
> + (match_operand:SI 2 "u6bit_cint_operand"
> "n"))
> + (match_operand:GPR 3 "gpc_reg_operand" "0")))]
> + "HOST_WIDE_INT_1U << INTVAL (operands[2])
> + > nonzero_bits (operands[3], mode)"
> +{
> + if (mode == SImode)
> +return "rlwimi %0,%1,%h2,0,31-%h2";
> + else
> +return "rldimi %0,%1,%H2,0";
> +}
> + [(set_attr "type" "insert")])
>
> Some insn matches this pattern in combine, later ira tries to introduce
> one new pseudo since it meets the checks in find_moveable_pseudos, but
> it fails in the call to validate_change since the nonzero_bits is more
> rough and can't satisfy the pattern condition, leaving the unexpected
> entry in pseudo_replaced_reg.
But what doesn't make any sense to me is pseudo_replaced_reg[] is only
set when validation is successful in find_moveable_pseudos. So I can't
see how this patch actually helps the problem you're describing.
>>> Yeah, pseudo_replaced_reg[] is only set when validation is successful,
>>> but we bump the max pseudo number in ira_create_new_reg as below
>>> regardless of whether validation succeeds or not:
>>>
>>> rtx newreg = ira_create_new_reg (def_reg);
>>> if (validate_change (def_insn, DF_REF_REAL_LOC (def), newreg, 0))
>>>
>>> Later in move_unallocated_pseudos, the iterating could cover those
>>> pseudos which were created but not used due to failed validation.
>>>
>>> for (i = first_moveable_pseudo; i < last_moveable_pseudo; i++)
>>> if (reg_renumber[i] < 0)
>>> {
>>> int idx = i - first_moveable_pseudo;
>>> rtx other_reg = pseudo_replaced_reg[idx];// (1)
>>> rtx_insn *def_insn = DF_REF_INSN (DF_REG_DEF_CHAIN (i));
>>> /* The use must follow all definitions of OTHER_REG, so we can
>>>insert the new definition immediately after any of them. */
>>> df_ref other_def = DF_REG_DEF_CHAIN (REGNO (other_reg))
>>>
>>> Then we can get the NULL other_reg in (1), also have unexpected df info
>>> which causes ICE. The patch skips the handlings on those pseudos which
>>> were intended to be used in validatation INSN but failed to.
>> I was wondering if it was somehow related to creation of new pseudos.
>> The other important tidbit here is we reset last_movable_pseudo near the
>> end of find_moveable_pseudos.
> Yeah, the iterating will scan all new pseudos created in
> find_moveable_pseudos,
> the problem occurs on those ones that fail to validate.
>
>> OK for the trunk with an expanded comment.
> Thanks! Does the attached new version look good to you?
Yes. Thanks.
jeff
[Bug fortran/66366] [OOP] ICE on invalid with non-allocatable CLASS variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66366 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #11 from anlauf at gcc dot gnu.org --- (In reply to janus from comment #5) > The original problem in comment #0 is fixed with r242351. > > The ICE on comment #2 is a separate issue and still persists. Adding an IMPLICIT NONE to comment#2, we get a strange error (rejects-valid). module sps implicit none type :: spsf end type spsf type :: h5 contains procedure :: c => hC end type h5 contains subroutine hC(s) class(h5), intent(inout) :: s end subroutine hC subroutine frf() type(h5) :: spsf call spsf%c() end subroutine frf end module sps pr66366-c2.f90:3:14: 3 | type :: spsf | 1 Error: Symbol 'spsf' at (1) has no IMPLICIT type The error vanishes if the typebound procedure is removed from the type declaration and the corresponding typebound call. Maybe close this one and open a new one about typebound procedures (or merge)?
Re: [PATCH, libstdc++] GLIBCXX_HAVE_INT64_T
On Fri, Jan 8, 2021 at 1:52 PM Jakub Jelinek wrote: > > On Fri, Jan 08, 2021 at 06:37:03PM +, Jonathan Wakely wrote: > > This uses __INT64_TYPE__ if that's defined, and long long otherwise. I > > think that should be equivalent in all practical cases (I can imagine > > some strange target where __INT64_TYPE__ is defined by the compiler, > > but int64_t isn't defined when the configure checks look for it, and > > so the current code would use long long and with my patch would use > > __INT64_TYPE__ which could be long ... but I think in practice that's > > unlikely. It was probably more likely in older releases where the > > configure test would have been done with -std=gnu++98 and so int64_t > > might not have been declared by libc's , but if that was the > > case then any ABI break it caused happened years ago. > > Does clang and ICC define __INT64_TYPE__ (at least on most architectures) > and does it match what gcc defines it to? Clang (at least back to 3.0.0) and ICC (at least back to 16.0.0) define __INT64_TYPE__. If the value is not compatible with the target __int64_t type (matching GCC), there presumably are deeper problems. Thanks, David
Re: Pointer width in GCC?
On Fri, Jan 8, 2021 at 12:15 PM Jeff Law via Gcc-patches wrote: > > > > On 1/8/21 12:55 PM, Qing Zhao via Gcc-patches wrote: > > Hi, > > > > Is there an utility routine in GCC to query the pointer width of the > > current target? Whether it’s 32bit pointer or 64 bit pointer for the target? > > > > Thanks a lot for the help. > You can look at the GET_MODE_SIZE (Pmode) or POINTER_SIZE. They can > differ in some circumstances. > It is ptr_mode vs Pmode. ptr_mode is the software pointer mode. Pmode is the hardware pointer mode. They can be different. -- H.J.
Re: [PATCH] Add pytest for a GCOV test-case
On 1/7/21 9:14 AM, Martin Liška wrote: > On 1/6/21 12:36 AM, Jeff Law wrote: >> unresolved "could not find python interpreter $testcase" in >> run-gcov-pytest if you find the right magic in the output of your spawn. > > Achieved that with the updated patch. > > Ready for master? > Thanks, > Martin > > 0001-Add-pytest-for-a-GCOV-test-case.patch > > From 53f5169156044acf8ecec498aa89d6be44c7173a Mon Sep 17 00:00:00 2001 > From: Martin Liska > Date: Mon, 21 Dec 2020 09:14:28 +0100 > Subject: [PATCH] Add pytest for a GCOV test-case > > gcc/testsuite/ChangeLog: > > PR gcov-profile/98273 > * lib/gcov.exp: Add run-gcov-pytest function which runs pytest. > * g++.dg/gcov/pr98273.C: New test. > * g++.dg/gcov/gcov.py: New test. > * g++.dg/gcov/test-pr98273.py: New test. OK jeff
[Bug d/98607] New: GDC merging computations but rounding mode has changed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98607
Bug ID: 98607
Summary: GDC merging computations but rounding mode has changed
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: guillaume.piolat at gmail dot com
Target Milestone: ---
Created attachment 49923
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49923=edit
Repro file
# Description
It seems GCC optimize common sub-expressions despite they are separated by a
__builtin_ia32_ldmxcsr call, which changes SSE rounding mode.
# Compiler version
GDC 10.2
# Godbolt
See on Godbolt: https://godbolt.org/z/c7EKfY
You can notice how only one cvtps2dq instruction is generated.
# Reproduce failure
Run this D program with GDC 10.2:
-- repro.d -
import core.simd;
import gcc.builtins;
alias __m128 = float4;
alias __m128i = int4;
alias __m128d = double2;
void bug()
{
uint savedRounding = _MM_GET_ROUNDING_MODE();
_MM_SET_ROUNDING_MODE(_MM_ROUND_NEAREST);
__m128i A = _mm_cvtps_epi32(_mm_setr_ps(1.4f, -2.1f, 53.5f, -2.9f));
assert(A.array == [1, -2, 54, -3]);
// GCC might merge this branch with above! Despite _MM_SET_ROUNDING_MODE
// not being pure.
_MM_SET_ROUNDING_MODE(_MM_ROUND_DOWN);
A = _mm_cvtps_epi32(_mm_setr_ps(1.4f, -2.1f, 53.5f, -2.9f)); // that whole
expression is computed once, but rounding mode has changed
assert(A.array == [1, -3, 53, -3]);
}
uint _mm_getcsr()
{
return __builtin_ia32_stmxcsr();
}
void _mm_setcsr(uint controlWord) @trusted
{
__builtin_ia32_ldmxcsr(controlWord);
}
__m128i _mm_cvtps_epi32 (__m128 a)
{
return __builtin_ia32_cvtps2dq(a);
}
enum int _MM_ROUND_NEAREST = 0x; /// MXCSR Rounding mode.
enum int _MM_ROUND_DOWN= 0x2000; ///ditto
enum int _MM_ROUND_UP = 0x4000; ///ditto
enum int _MM_ROUND_TOWARD_ZERO = 0x6000; ///ditto
enum int _MM_ROUND_MASK= 0x6000; /// MXCSR Rounding mode mask.
uint _MM_GET_ROUNDING_MODE()
{
return _mm_getcsr() & _MM_ROUND_MASK;
}
void _MM_SET_ROUNDING_MODE(int _MM_ROUND_)
{
_mm_setcsr((_mm_getcsr() & ~_MM_ROUND_MASK) | _MM_ROUND_);
}
__m128 _mm_setr_ps (float e3, float e2, float e1, float e0)
{
float[4] result = [e3, e2, e1, e0];
return loadUnaligned!(float4)(result.ptr);
}
float4 loadUnaligned(Vec)(const(float)* pvec) @trusted if (is(Vec == float4))
{
return __builtin_ia32_loadups(pvec);
}
--
Re: [RFC] restricting aliasing by standard containers (PR 98465)
On 1/8/21 12:51 AM, Richard Biener wrote:
On Thu, Jan 7, 2021 at 10:41 PM Martin Sebor wrote:
The test case in PR 98465 brings to light a problem we've discussed
before (e.g., PR 93971) where a standard container (std::string in
this case but the problem applies to any class that owns and manages
allocated memory) might trigger warnings for unreachable code.
The code is not eliminated due to a missing aliasing constraint:
because GCC doesn't know that the member pointer to the memory
managed by the container cannot alias other objects, it emits code
that can never be executed in a valid program and that's prone to
causing false positives.
To illustrate, at the moment it's impossible to fold away the assert
below because there's no way to determine in the middle end that
String::s cannot point to a:
extern char array[];
class String {
char *s;
public:
String (const char *p): s (strdup (p)) { }
String (const String ): s (strdup (str.s)) { }
~String () { free (s); }
void f () { assert (s != array); }
};
The constraint is obvious to a human reader (String::s is private
and nothing sets it to point to array) but there's no way for GCC
to infer it from the code alone (at least not in general): there
could be member or friend functions defined in other translation
units that violate this assumption.
One way to solve the problem is to explicitly declare that
String::s, in fact, doesn't point to any such objects and that it
only ever points to allocated memory. My idea for doing that is
to extend attribute malloc to (or add a new attribute for) pointer
variables to imply that the pointer only points to allocated memory.
However, besides pointing to allocated memory, std::string can also
point to its own internal buffer, so the extended malloc attribute
couldn't be used there by itself. I think this could be solved by
also either extending the may_alias attribute or adding a new
"alias" (or some such) attribute to denote that a pointer variable
may point to an object or subobject.
Putting the two together, to eliminate the assert, std::string would
be annotated like so:
class string {
char *s __attribute__ ((malloc, may_alias (buf)));
char buf[8];
public:
string (): s (buf) { }
string (const char *p): s (strdup (p)) { }
string (const string ): s (strdup (str.s)) { }
~string () { if (s != buf) free (s); }
void f () { assert (s != array); }
};
The may_alias association with members is relative to the this pointer
(i.e., as if by may_alias (this->buf), as opposed to being taken as
may_alias (String::buf) and meaning that s might be equal to any other
String::s with a different this. To help avoid mistakes, setting s
in violation of the constraints would trigger warnings.
If this sounds reasonable I'm prepared to prototype it, either for
GCC 11 if it's in scope to solve the PR and there's still time, or
(I suspect more likely) for GCC 12.
Richard, what are your thoughts/concerns?
I'm not sure it's feasible to make use of this attribute. First
there's the malloc part which has difficult semantics (similar
to restrict) when generating PTA constraints. We might see
_1 = str.s;
_2 = str.s;
but are of course required to associate the same allocated
dummy object with both pointers (as opposed to when we'd
see two malloc calls). What would possibly work is to
have the object keyed on the field decl, but then for
_1 = p_to_str_4(D);
_2 = _1 + offsetof-s;
_3 = *_2;
we have to somehow conservatively arrive at the same object.
I don't see how that can work out.
All the same applies to the may_alias part but I guess when the
malloc part falls apart that's not of much interest.
So I'm concerned about correctness - I'm sure you can hack
sth together to get some testcases optimized. But I'm not sure
you can make it correct in all cases (within the current PTA
framework).
Thanks for the feedback.
Absent some source level annotation I can't think of a good way
to avoid these false positives. Do you have any other ideas?
If not, would you be opposed to introducing these attributes to
suppress warnings (at least at first)? Besides avoiding the false
positives, implementing just that part might also be a good proof
of concept for the aliasing solution (or a confirmation of your
intuition).
Martin
Richard.
Martin
PS An alternate solution might be to provide a late-evaluated built-in,
something like
__builtin_decl (T *ptr)
that would return a answer if ptr could be determined to point
to a declared object or subobject, a if not (e.g., it points to
allocated storage), and a if it couldn't be determined.
The built-in would then be used in code to eliminate infeasible
paths. For example, a built-in like that could be used to eliminate
the assert in string::f():
void string::f ()
{
if ( == __builtin_decl_p (s) && s != buf)
__builtin_unreachable
Re: Pointer width in GCC?
On 1/8/21 12:55 PM, Qing Zhao via Gcc-patches wrote: > Hi, > > Is there an utility routine in GCC to query the pointer width of the current > target? Whether it’s 32bit pointer or 64 bit pointer for the target? > > Thanks a lot for the help. You can look at the GET_MODE_SIZE (Pmode) or POINTER_SIZE. They can differ in some circumstances. jeff
Re: [PATCH 4/4] VAX: Remove a duplicate `cc' mode attribute
On 1/7/21 6:51 PM, Maciej W. Rozycki wrote: > Remove the `cc' mode attribute that duplicates the implicitly defined > `mode' attribute. No change to semantics. > > gcc/ > * config/vax/vax.md (cc): Remove mode attribute. > (subst_, subst_f): Rename to... > (subst_, subst_f): ... these respectively. > (*cbranch4_): Update for `cc' removal. > (*cbranch4_): Likewise. > (*branch_, *branch__reversed): Likewise. OK jeff
Re: [PATCH 3/4] VAX: Use a mode with `const_double_zero' expressions
On 1/7/21 6:50 PM, Maciej W. Rozycki wrote: > For predictable semantics propagate the mode from operands referred by > the FP substitution to the `const_double_zero' expressions used with the > associated condition code calculation. Use an iterator to make copies > of the FP substitution across the FP modes supported as the substitution > now has to match the mode of the operands. > > gcc/ > * config/pdp11/pdp11.md (subst_f): Add mode to operands and > `const_double_zero'. OK jeff
Re: [PATCH 1/4] RTL: Update `const_double_zero' handling for mode and callable insns
On 1/7/21 6:50 PM, Maciej W. Rozycki wrote:
> Handle machine mode specification with `const_double_zero' and handle
> the rtx with callable code produced from named insns. Complementing
> commit 20ab43b5cad6 ("RTL: Add `const_double_zero' syntactic rtx") and
> removing a commit c60d0736dff7 ("PDP11: Use `const_double_zero' to
> express double zero constant") build regression observed with the
> `pdp11-aout' target:
>
> genemit: Internal error: abort in gen_exp, at genemit.c:202
> make[2]: *** [Makefile:2427: s-emit] Error 1
>
> where a:
>
> (const_double 0 [0] 0 [0] 0 [0] 0 [0])
>
> rtx coming from:
>
> (parallel [
> (set (reg:CC 16)
> (compare:CC (abs:DF (match_operand:DF 1 ("general_operand")
> ("0,0")))
> (const_double 0 [0] 0 [0] 0 [0] 0 [0])))
> (set (match_operand:DF 0 ("nonimmediate_operand") ("=fR,Q"))
> (abs:DF (match_dup 1)))
> ])
>
> and ultimately `(const_double_zero)' referred in a named RTL insn cannot
> be interpreted. Handle the rtx then by supplying the constant 0 double
> operand requested, resulting in the following update to insn-emit.c code
> produced for the `pdp11-aout' target, relative to before the triggering
> commit:
>
> @@ -1514,7 +1514,7 @@ gen_absdf2_cc (rtx operand0 ATTRIBUTE_UN
> gen_rtx_COMPARE (CCmode,
> gen_rtx_ABS (DFmode,
> operand1),
> - const0_rtx)),
> + CONST_DOUBLE_ATOF ("0", VOIDmode))),
> gen_rtx_SET (operand0,
> gen_rtx_ABS (DFmode,
> copy_rtx (operand1);
> @@ -1555,7 +1555,7 @@ gen_negdf2_cc (rtx operand0 ATTRIBUTE_UN
> gen_rtx_COMPARE (CCmode,
> gen_rtx_NEG (DFmode,
> operand1),
> - const0_rtx)),
> + CONST_DOUBLE_ATOF ("0", VOIDmode))),
> gen_rtx_SET (operand0,
> gen_rtx_NEG (DFmode,
> copy_rtx (operand1);
> @@ -1790,7 +1790,7 @@ gen_muldf3_cc (rtx operand0 ATTRIBUTE_UN
> gen_rtx_MULT (DFmode,
> operand1,
> operand2),
> - const0_rtx)),
> + CONST_DOUBLE_ATOF ("0", VOIDmode))),
> gen_rtx_SET (operand0,
> gen_rtx_MULT (DFmode,
> copy_rtx (operand1),
> @@ -1942,7 +1942,7 @@ gen_divdf3_cc (rtx operand0 ATTRIBUTE_UN
> gen_rtx_DIV (DFmode,
> operand1,
> operand2),
> - const0_rtx)),
> + CONST_DOUBLE_ATOF ("0", VOIDmode))),
> gen_rtx_SET (operand0,
> gen_rtx_DIV (DFmode,
> copy_rtx (operand1),
>
> This does not (yet) remove VOIDmode CONST_DOUBLE use, as it is up to
> individual machine descriptions to choose.
>
> gcc/
> * genemit.c (gen_exp) : Handle `const_double_zero'
> rtx.
> * read-rtl.c (rtx_reader::read_rtx_code): Handle machine mode
> with `const_double_zero'.
> * doc/rtl.texi (Constant Expression Types): Document it.
OK
jeff
Re: [PATCH] VAX/testsuite: Remove notsi comparison elimination regressions
On 1/8/21 5:49 AM, Maciej W. Rozycki wrote:
> Remove fallout from commit 0bd675183d94 ("match.pd: Add ~(X - Y) -> ~X
> + Y simplification [PR96685]") and paper over the regression caused as
> it is not the matter of the test cases affected.
>
> Previously assembly like this:
>
> .text
> .align 1
> .globl eq_notsi
> .type eq_notsi, @function
> eq_notsi:
> .word 0 # 35[c=0] procedure_entry_mask
> subl2 $4,%sp# 46[c=32] *addsi3
> mcoml 4(%ap),%r0# 32[c=16] *one_cmplsi2_ccz
> jeql .L1# 34[c=26] *branch_ccz
> addl2 $2,%r0# 31[c=32] *addsi3
> .L1:
> ret # 40[c=0] return
> .size eq_notsi, .-eq_notsi
>
> was produced. Now this:
>
> .text
> .align 1
> .globl eq_notsi
> .type eq_notsi, @function
> eq_notsi:
> .word 0 # 36[c=0] procedure_entry_mask
> subl2 $4,%sp# 48[c=32] *addsi3
> movl 4(%ap),%r0 # 33[c=16] *movsi_2
> cmpl %r0,$-1# 34[c=8] *cmpsi_ccz/1
> jeql .L3# 35[c=26] *branch_ccz
> subl3 %r0,$1,%r0# 32[c=32] *subsi3/1
> ret # 27[c=0] return
> .L3:
> clrl %r0# 31[c=2] *movsi_2
> ret # 41[c=0] return
> .size eq_notsi, .-eq_notsi
>
> is, which cannot work with post-reload comparison elimination, due to
> the comparison against -1 rather than 0.
>
> Use subtraction from a constant then rather than addition as the former
> operation is not transformed, removing these regressions:
>
> FAIL: gcc.target/vax/cmpelim-eq-notsi.c -O1 scan-rtl-dump-times cmpelim
> "deleting insn with uid" 1
> FAIL: gcc.target/vax/cmpelim-eq-notsi.c -O1 scan-assembler-not
> \t(bit|cmpz?|tst).
> FAIL: gcc.target/vax/cmpelim-eq-notsi.c -O1 scan-assembler one_cmplsi[^
> ]*_ccz(/[0-9]+)?\n
> FAIL: gcc.target/vax/cmpelim-lt-notsi.c -O1 scan-rtl-dump-times cmpelim
> "deleting insn with uid" 1
> FAIL: gcc.target/vax/cmpelim-lt-notsi.c -O1 scan-assembler-not
> \t(bit|cmpz?|tst).
> FAIL: gcc.target/vax/cmpelim-lt-notsi.c -O1 scan-assembler one_cmplsi[^
> ]*_ccn(/[0-9]+)?\n
>
> and likewise across some of the other the optimization levels verified.
>
> The LE variant appears unaffected as the new transformation produces
> slightly different although still suboptimal code:
>
> .text
> .align 1
> .globl le_notsi
> .type le_notsi, @function
> le_notsi:
> .word 0 # 27[c=0] procedure_entry_mask
> subl2 $4,%sp# 34[c=32] *addsi3
> movl 4(%ap),%r1 # 23[c=16] *movsi_2
> mcoml %r1,%r0 # 24[c=8] *one_cmplsi2_ccnz
> jleq .L1# 26[c=26] *branch_ccnz
> subl3 %r1,$1,%r0# 22[c=32] *subsi3/1
> .L1:
> ret # 32[c=0] return
> .size le_notsi, .-le_notsi
>
> but update the test case too, for consistency with the other two.
>
> gcc/testsuite/
> * gcc.target/vax/cmpelim-eq-notsi.c: Use subtraction from a
> constant then rather than addition.
> * gcc.target/vax/cmpelim-le-notsi.c: Likewise.
> * gcc.target/vax/cmpelim-lt-notsi.c: Likewise.
OK
jeff
[Bug c/98592] ICE in gimple_canonical_types_compatible_p while formatting a MEM_REF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98592 --- Comment #2 from Martin Sebor --- The idea is to print the cast indicating the MEM_REF type only when the size of the accessed type is different from the size of the element type of the underlying array or pointer. Structural equivalence seemed like a good fit. But using TYPE_MAIN_VARIANT would work too (and include more information).
Pointer width in GCC?
Hi, Is there an utility routine in GCC to query the pointer width of the current target? Whether it’s 32bit pointer or 64 bit pointer for the target? Thanks a lot for the help. Qing
Re: [PATCH] c++, abi: Fix abi_tag attribute handling [PR98481]
On Fri, Jan 08, 2021 at 02:22:59PM -0500, Jason Merrill wrote:
> I like the idea to use *walk_subtrees to distinguish between walking
> syntactic subtrees and walking type-identity subtrees. But it should be
> more general; how does this look to you?
LGTM, thanks.
> diff --git a/gcc/cp/class.c b/gcc/cp/class.c
> index c41ac7deefe..00c0dba0a55 100644
> --- a/gcc/cp/class.c
> +++ b/gcc/cp/class.c
> @@ -1507,6 +1507,10 @@ mark_or_check_tags (tree t, tree *tp, abi_tag_data *p,
> bool val)
> static tree
> find_abi_tags_r (tree *tp, int *walk_subtrees, void *data)
> {
> + if (TYPE_P (*tp) && *walk_subtrees == 1)
> +/* Tell cp_walk_subtrees to look though typedefs. */
> +*walk_subtrees = 2;
> +
>if (!OVERLOAD_TYPE_P (*tp))
> return NULL_TREE;
>
> @@ -1527,6 +1531,10 @@ find_abi_tags_r (tree *tp, int *walk_subtrees, void
> *data)
> static tree
> mark_abi_tags_r (tree *tp, int *walk_subtrees, void *data)
> {
> + if (TYPE_P (*tp) && *walk_subtrees == 1)
> +/* Tell cp_walk_subtrees to look though typedefs. */
> +*walk_subtrees = 2;
> +
>if (!OVERLOAD_TYPE_P (*tp))
> return NULL_TREE;
>
> diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
> index b10671091b5..b087753cfba 100644
> --- a/gcc/cp/decl2.c
> +++ b/gcc/cp/decl2.c
> @@ -2358,9 +2358,6 @@ min_vis_r (tree *tp, int *walk_subtrees, void *data)
>int this_vis = VISIBILITY_DEFAULT;
>if (! TYPE_P (*tp))
> *walk_subtrees = 0;
> - else if (typedef_variant_p (*tp))
> -/* Look through typedefs despite cp_walk_subtrees. */
> -this_vis = type_visibility (DECL_ORIGINAL_TYPE (TYPE_NAME (*tp)));
>else if (OVERLOAD_TYPE_P (*tp)
> && !TREE_PUBLIC (TYPE_MAIN_DECL (*tp)))
> {
> @@ -2379,6 +2376,10 @@ min_vis_r (tree *tp, int *walk_subtrees, void *data)
>if (this_vis > *vis_p)
> *vis_p = this_vis;
>
> + /* Tell cp_walk_subtrees to look through typedefs. */
> + if (*walk_subtrees == 1)
> +*walk_subtrees = 2;
> +
>return NULL;
> }
>
> diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
> index 82027cc9abf..c536eb581a7 100644
> --- a/gcc/cp/tree.c
> +++ b/gcc/cp/tree.c
> @@ -5146,16 +5146,26 @@ cp_walk_subtrees (tree *tp, int *walk_subtrees_p,
> walk_tree_fn func,
>
>if (TYPE_P (*tp))
> {
> - /* Walk into template args without looking through typedefs. */
> - if (tree ti = TYPE_TEMPLATE_INFO_MAYBE_ALIAS (*tp))
> - WALK_SUBTREE (TI_ARGS (ti));
> - /* Don't look through typedefs; walk_tree_fns that want to look through
> - typedefs (like min_vis_r) need to do that themselves. */
> - if (typedef_variant_p (*tp))
> + /* If *WALK_SUBTREES_P is 1, we're interested in the syntactic form of
> + the argument, so don't look through typedefs, but do walk into
> + template arguments for alias templates (and non-typedefed classes).
> +
> + If *WALK_SUBTREES_P > 1, we're interested in type identity or
> + equivalence, so look through typedefs, ignoring template arguments for
> + alias templates, and walk into template args of classes.
> +
> + See find_abi_tags_r for an example of setting *WALK_SUBTREES_P to 2
> + when that's the behavior the walk_tree_fn wants. */
> + if (*walk_subtrees_p == 1 && typedef_variant_p (*tp))
> {
> + if (tree ti = TYPE_ALIAS_TEMPLATE_INFO (*tp))
> + WALK_SUBTREE (TI_ARGS (ti));
> *walk_subtrees_p = 0;
> return NULL_TREE;
> }
> +
> + if (tree ti = TYPE_TEMPLATE_INFO (*tp))
> + WALK_SUBTREE (TI_ARGS (ti));
> }
>
>/* Not one of the easy cases. We must explicitly go through the
Jakub
[Bug objc++/98606] New: [10 regression] obj-c++.dg/template-4.mm fails erratically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98606 Bug ID: 98606 Summary: [10 regression] obj-c++.dg/template-4.mm fails erratically Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: objc++ Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- I have been seeing this test failing albeit erratically for some time now. I am not sure exactly when it started but it was at or before g:ff22b4e8d0613170601d28eec9462ea31147c7c7, r10-9209 Executing on host: /home3/seurer/gcc/git/build/gcc-10-test/gcc/testsuite/obj-c++/../../xg++ -B/home3/seurer/gcc/git/build/gcc-10-test/gcc/testsuite/obj-c++/../../ /home/seurer/gcc/git/gcc-10-test/gcc/testsuite/obj-c++.dg/template-4.mm -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++ -I/home/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-10-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-10-test/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-10-test/libstdc++-v3/testsuite/util -fmessage-length=0 -fgnu-runtime -ansi -pedantic-errors -Wno-long-long -I/home/seurer/gcc/git/gcc-10-test/gcc/testsuite/../../libobjc /home/seurer/gcc/git/gcc-10-test/gcc/testsuite/obj-c++.dg/../objc-obj-c++-shared/nsconstantstring-class-impl.mm -B/home3/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -L/home3/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home3/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -L/home3/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home3/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/./libobjc/.libs -L/home3/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/./libobjc/.libs -lobjc -lm -o ./template-4.exe(timeout = 300) spawn -ignore SIGHUP /home3/seurer/gcc/git/build/gcc-10-test/gcc/testsuite/obj-c++/../../xg++ -B/home3/seurer/gcc/git/build/gcc-10-test/gcc/testsuite/obj-c++/../../ /home/seurer/gcc/git/gcc-10-test/gcc/testsuite/obj-c++.dg/template-4.mm -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++ -I/home/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/git/gcc-10-test/libstdc++-v3/libsupc++ -I/home/seurer/gcc/git/gcc-10-test/libstdc++-v3/include/backward -I/home/seurer/gcc/git/gcc-10-test/libstdc++-v3/testsuite/util -fmessage-length=0 -fgnu-runtime -ansi -pedantic-errors -Wno-long-long -I/home/seurer/gcc/git/gcc-10-test/gcc/testsuite/../../libobjc /home/seurer/gcc/git/gcc-10-test/gcc/testsuite/obj-c++.dg/../objc-obj-c++-shared/nsconstantstring-class-impl.mm -B/home3/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -L/home3/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home3/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -L/home3/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home3/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/./libobjc/.libs -L/home3/seurer/gcc/git/build/gcc-10-test/powerpc64le-unknown-linux-gnu/./libobjc/.libs -lobjc -lm -o ./template-4.exe^M /home/seurer/gcc/git/gcc-10-test/gcc/testsuite/obj-c++.dg/template-4.mm: In instantiation of 'int TestT::abc(ARR*) [with ARR = Array; TYPE = int]':^M /home/seurer/gcc/git/gcc-10-test/gcc/testsuite/obj-c++.dg/template-4.mm:82:3: required from here^M /home/seurer/gcc/git/gcc-10-test/gcc/testsuite/obj-c++.dg/template-4.mm:28:26: sorry, unimplemented: unexpected AST of kind message_send_expr^M /home/seurer/gcc/git/gcc-10-test/gcc/testsuite/obj-c++.dg/template-4.mm:28: confused by earlier errors, bailing out^M compiler exited with status 1 FAIL: obj-c++.dg/template-4.mm -fgnu-runtime (test for excess errors) Excess errors: /home/seurer/gcc/git/gcc-10-test/gcc/testsuite/obj-c++.dg/template-4.mm:28:26: sorry, unimplemented: unexpected AST of kind message_send_expr /home/seurer/gcc/git/gcc-10-test/gcc/testsuite/obj-c++.dg/template-4.mm:28: confused by earlier errors, bailing out
Re: [PATCH v2] testsuite: Fix test failures from outputs.exp [PR98225]
Hi, Bernd
Thanks for investigating this and creating a revised version of the
patch. With the second patch, the gcc.misc-test/outputs.exp results
are clean on AIX.
Thanks, David
On Fri, Jan 8, 2021 at 1:59 PM Bernd Edlinger wrote:
>
> On 1/8/21 3:23 PM, David Edelsohn wrote:
> > On Thu, Jan 7, 2021 at 5:18 PM Bernd Edlinger
> > wrote:
> >>
> >> Hi,
> >>
> >> On 1/7/21 5:12 PM, Rainer Orth wrote:
> >>> The unsetenv needs to be wrapped in
> >>>
> >>> if [info exists env(MAKEFLAGS)] {
> >>>
> >>
> >> Done.
> >>
> >>> @@ -163,6 +167,9 @@ proc outest { test sources opts dirs out
> >>> if { $ogl != {} } {
> >>> pass "$test: $d$o"
> >>> file delete $ogl
> >>> + } elseif { [string match "*.ld1_args" $o] } {
> >>> + # This file may be missing if !HAVE_GNU_LD
> >>> + pass "$test: $d$o"
> >>>
> >>> Always PASSing the test even if it isn't run is wrong. Either wrap
> >>> the whole group of tests with response files in
> >>>
> >>> if [check_effective_target_gld] {
> >>>
> >>> or make the test for the *.ld1_args file conditional on that
> >>> (e.g. along the lines of $ltop used elsewhere). I'd welcome input
> >>> from Alexandre which is preferred.
> >>>
> >>
> >> Ah, yes that is a good idea. Thanks.
> >>
> >>
> >> I think the .cdtor.* handling, is probably a bad example that I followed
> >> here.
> >> I don't know why that is there in the first place, as there
> >> are no C++ test cases, these files should not be created at all.
> >> If they are ever created we would have a couple of other files created
> >> as well IMHO.
> >> If there are still missing files in some cases,
> >> I'd prefer to track these per test case, instead of globally.
> >>
> >> Therefore I propose to remove that exception for now.
> >>
> >> Is it OK for trunk?
> >
> > As Alex said, please don't just remove features and functionality if
> > you don't know why they were added. The history is online in the
> > mailing list and the repo history.
> >
> > AIX uses constructors to register EH frames and libgcc has an EH
> > frame. ctors and dtors can be found in non-C++ code.
> >
>
> Okydoky.
>
> I think I understand now better what the issue is here.
> Although the name cdtor suggests that it has something to do with
> C++ it is also needed to collect EH frame info, in certain targets.
> Those are mainly AIX but also hppa*-*-hpux*.
> I believe those exceptions are only necessary for targets that
> define EH_FRAME_THROUGH_COLLECT2.
>
> I have tested this new version of my patch but only on not-affected
> x86_64-pc-linux-gnu.
>
> @David, @Rainer: I would very much appreciate if you could give this patch
> a test on your systems.
>
>
> Thanks
> Berns.
Re: [PATCH] c++, abi: Fix abi_tag attribute handling [PR98481]
On 1/7/21 11:47 AM, Jakub Jelinek wrote:
In GCC10 cp_walk_subtrees has been changed to walk template arguments.
As the following testcase, that changed the mangling of some functions.
Argh.
I believe the previous behavior that find_abi_tags_r doesn't recurse into
template args has been the correct one, but setting *walk_subtrees = 0
for the types and handling the types subtree walking manually in
find_abi_tags_r looks too hard, there are a lot of subtrees and details what
should and shouldn't be walked, both in tree.c (walk_type_fields there,
which is static) and in cp_walk_subtrees itself.
The following patch abuses the fact that *walk_subtrees is an int to
tell cp_walk_subtrees it shouldn't walk the template args.
Another option would be to have two separate cp_walk_subtrees-like
callbacks, one that wouldn't walk into template args and the other
that would and then would tail call the other one, and
cp_walk_tree_without_duplicates but call walk_tree_1 directly or use
some other macro.
I like the idea to use *walk_subtrees to distinguish between walking
syntactic subtrees and walking type-identity subtrees. But it should be
more general; how does this look to you?
Jason
diff --git a/gcc/cp/class.c b/gcc/cp/class.c
index c41ac7deefe..00c0dba0a55 100644
--- a/gcc/cp/class.c
+++ b/gcc/cp/class.c
@@ -1507,6 +1507,10 @@ mark_or_check_tags (tree t, tree *tp, abi_tag_data *p, bool val)
static tree
find_abi_tags_r (tree *tp, int *walk_subtrees, void *data)
{
+ if (TYPE_P (*tp) && *walk_subtrees == 1)
+/* Tell cp_walk_subtrees to look though typedefs. */
+*walk_subtrees = 2;
+
if (!OVERLOAD_TYPE_P (*tp))
return NULL_TREE;
@@ -1527,6 +1531,10 @@ find_abi_tags_r (tree *tp, int *walk_subtrees, void *data)
static tree
mark_abi_tags_r (tree *tp, int *walk_subtrees, void *data)
{
+ if (TYPE_P (*tp) && *walk_subtrees == 1)
+/* Tell cp_walk_subtrees to look though typedefs. */
+*walk_subtrees = 2;
+
if (!OVERLOAD_TYPE_P (*tp))
return NULL_TREE;
diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index b10671091b5..b087753cfba 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -2358,9 +2358,6 @@ min_vis_r (tree *tp, int *walk_subtrees, void *data)
int this_vis = VISIBILITY_DEFAULT;
if (! TYPE_P (*tp))
*walk_subtrees = 0;
- else if (typedef_variant_p (*tp))
-/* Look through typedefs despite cp_walk_subtrees. */
-this_vis = type_visibility (DECL_ORIGINAL_TYPE (TYPE_NAME (*tp)));
else if (OVERLOAD_TYPE_P (*tp)
&& !TREE_PUBLIC (TYPE_MAIN_DECL (*tp)))
{
@@ -2379,6 +2376,10 @@ min_vis_r (tree *tp, int *walk_subtrees, void *data)
if (this_vis > *vis_p)
*vis_p = this_vis;
+ /* Tell cp_walk_subtrees to look through typedefs. */
+ if (*walk_subtrees == 1)
+*walk_subtrees = 2;
+
return NULL;
}
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 82027cc9abf..c536eb581a7 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -5146,16 +5146,26 @@ cp_walk_subtrees (tree *tp, int *walk_subtrees_p, walk_tree_fn func,
if (TYPE_P (*tp))
{
- /* Walk into template args without looking through typedefs. */
- if (tree ti = TYPE_TEMPLATE_INFO_MAYBE_ALIAS (*tp))
- WALK_SUBTREE (TI_ARGS (ti));
- /* Don't look through typedefs; walk_tree_fns that want to look through
- typedefs (like min_vis_r) need to do that themselves. */
- if (typedef_variant_p (*tp))
+ /* If *WALK_SUBTREES_P is 1, we're interested in the syntactic form of
+ the argument, so don't look through typedefs, but do walk into
+ template arguments for alias templates (and non-typedefed classes).
+
+ If *WALK_SUBTREES_P > 1, we're interested in type identity or
+ equivalence, so look through typedefs, ignoring template arguments for
+ alias templates, and walk into template args of classes.
+
+ See find_abi_tags_r for an example of setting *WALK_SUBTREES_P to 2
+ when that's the behavior the walk_tree_fn wants. */
+ if (*walk_subtrees_p == 1 && typedef_variant_p (*tp))
{
+ if (tree ti = TYPE_ALIAS_TEMPLATE_INFO (*tp))
+ WALK_SUBTREE (TI_ARGS (ti));
*walk_subtrees_p = 0;
return NULL_TREE;
}
+
+ if (tree ti = TYPE_TEMPLATE_INFO (*tp))
+ WALK_SUBTREE (TI_ARGS (ti));
}
/* Not one of the easy cases. We must explicitly go through the
[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577 --- Comment #19 from Steve Kargl --- On Fri, Jan 08, 2021 at 06:43:20PM +, mehdi.chinoune at hotmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577 > > --- Comment #17 from Chinoune --- > Once I reported a bug to gcc/gfortran > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91337 but someone argued that it > was my fault to use "-Ofast" so I rewrite the reproducer in C and reported > again under another category > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734. the bug was confirmed and > fixed without someone blaming me for that. Fortran and C are different languages. I standby my assessment. Options that cause the compiler to knowingly violate the Fortran Standard and cause unexpected behavior do not justify a bug. > Another when I reported another bug but that "someone" said that my reproducer > is invalid, fortunately some other guys didn't take his opinion under > consideration and they fixed the bug. > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92736 Well, I actually I never stated the code was invalid. In comment #1, I said I "Not sure the code is conforming, and don't have time to investigate (unless someone is willing to cough up $$)." Also, suggested two workarounds that would get you passed the issue. In comment #2, you stated "You introduced a regression and it is your duty to fix it." In comment #3, I clearly stated "When it comes to gfortran, I have no duty to you or anyone else. I have neither the time nor now the inclination to look at this bug (unless someone coughs up (price just went up ;))." At this point, I stopped looking at the bug because I have a real job that pays me $ to feed my family, and I found the tone of your comment #3 to b rude. So, in summary you once again are bending what is written to your reality. > The problem is that "someone" still there (fortran category) > attacking anyone who dare to report a bug in gfortran. You are not being attacked. You are being educated on what processor-dependent behavior means, and you have been told that the gfortran documentation tells you what the processor-dependent behavior is. If you refuse to learn, neither I nor anyone else can help you.
[Bug libstdc++/98605] New: clang-tidy error parsing on libstdc++-v3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98605
Bug ID: 98605
Summary: clang-tidy error parsing on libstdc++-v3
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: mizvekov at gmail dot com
Target Milestone: ---
clang-tidy errors parsing `#include ` when _GLIBCXX_HAVE_TLS is not
defined, with the following message:
```
include/c++/mutex:738:7: error: use of undeclared identifier '__once_callable';
did you mean '__callable'? [clang-diagnostic-error]
__once_callable = nullptr;
^
include/c++/mutex:716:12: note: '__callable' declared here
auto __callable = [&] {
^
include/c++/mutex:739:7: error: use of undeclared identifier '__once_call'
[clang-diagnostic-error]
__once_call = nullptr;
^
```
This was caused by the following commit:
```
commit 018813c8994b7dceab1b7d999e9c09654a22ef50
Author: Jonathan Wakely
Date: Fri Oct 13 12:56:07 2017 +0100
PR libstdc++/82481 Suppress clang-tidy warnings
PR libstdc++/82481
* include/std/mutex (call_once): Suppress clang-tidy warnings about
dangling references.
diff --git a/libstdc++-v3/include/std/mutex b/libstdc++-v3/include/std/mutex
index 8c692a88ffd..50420ee22d4 100644
--- a/libstdc++-v3/include/std/mutex
+++ b/libstdc++-v3/include/std/mutex
@@ -688,6 +688,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__set_once_functor_lock_ptr(0);
#endif
+#ifdef __clang_analyzer__
+ // PR libstdc++/82481
+ __once_callable = nullptr;
+ __once_call = nullptr;
+#endif
+
if (__e)
__throw_system_error(__e);
}
```
The problem is that __once_callable et al are only declared when
_GLIBCXX_HAVE_TLS is defined.
A simple patch like this would fix it:
```
--- a/libstdc++-v3/include/std/mutex
+++ b/libstdc++-v3/include/std/mutex
@@ -731,9 +731,7 @@
#ifndef _GLIBCXX_HAVE_TLS
if (__functor_lock)
__set_once_functor_lock_ptr(0);
-#endif
-
-#ifdef __clang_analyzer__
+#elif defined(__clang_analyzer__)
// PR libstdc++/82481
__once_callable = nullptr;
__once_call = nullptr;
```
Re: Fw: Problems with compiling autogen with GCC8 or newer versions
On 1/8/21 10:39 AM, Bruce Korb via Gcc wrote: > Hi, > > You are supposed to be able to post once you've subscribed. > > Also, GCC's code analysis is wrong. "name_bf" contains *NO MORE* than > MAXNAMELEN characters. That is provable. > > "def_str" points into a buffer of size ((MAXNAMELEN * 2) + 8) and at > an offset maximum of MAXNAMELEN+1 (also provable), meaning that at a > minimum there are MAXNAMELEN+6 bytes left in the buffer. > > That objected-to sprintf can add a maximum of MAXNAMELEN + 4 to where > "def_str" points. > > GCC is wrong. It is unable to figure out how far into the buffer > "def_str" can point. Can you get a .i file, command line and file a report. It'd be appreciated. jeff
[PATCH v2] testsuite: Fix test failures from outputs.exp [PR98225]
On 1/8/21 3:23 PM, David Edelsohn wrote:
> On Thu, Jan 7, 2021 at 5:18 PM Bernd Edlinger
> wrote:
>>
>> Hi,
>>
>> On 1/7/21 5:12 PM, Rainer Orth wrote:
>>> The unsetenv needs to be wrapped in
>>>
>>> if [info exists env(MAKEFLAGS)] {
>>>
>>
>> Done.
>>
>>> @@ -163,6 +167,9 @@ proc outest { test sources opts dirs out
>>> if { $ogl != {} } {
>>> pass "$test: $d$o"
>>> file delete $ogl
>>> + } elseif { [string match "*.ld1_args" $o] } {
>>> + # This file may be missing if !HAVE_GNU_LD
>>> + pass "$test: $d$o"
>>>
>>> Always PASSing the test even if it isn't run is wrong. Either wrap
>>> the whole group of tests with response files in
>>>
>>> if [check_effective_target_gld] {
>>>
>>> or make the test for the *.ld1_args file conditional on that
>>> (e.g. along the lines of $ltop used elsewhere). I'd welcome input
>>> from Alexandre which is preferred.
>>>
>>
>> Ah, yes that is a good idea. Thanks.
>>
>>
>> I think the .cdtor.* handling, is probably a bad example that I followed
>> here.
>> I don't know why that is there in the first place, as there
>> are no C++ test cases, these files should not be created at all.
>> If they are ever created we would have a couple of other files created
>> as well IMHO.
>> If there are still missing files in some cases,
>> I'd prefer to track these per test case, instead of globally.
>>
>> Therefore I propose to remove that exception for now.
>>
>> Is it OK for trunk?
>
> As Alex said, please don't just remove features and functionality if
> you don't know why they were added. The history is online in the
> mailing list and the repo history.
>
> AIX uses constructors to register EH frames and libgcc has an EH
> frame. ctors and dtors can be found in non-C++ code.
>
Okydoky.
I think I understand now better what the issue is here.
Although the name cdtor suggests that it has something to do with
C++ it is also needed to collect EH frame info, in certain targets.
Those are mainly AIX but also hppa*-*-hpux*.
I believe those exceptions are only necessary for targets that
define EH_FRAME_THROUGH_COLLECT2.
I have tested this new version of my patch but only on not-affected
x86_64-pc-linux-gnu.
@David, @Rainer: I would very much appreciate if you could give this patch
a test on your systems.
Thanks
Berns.
From 861f6631c34bdcbc0d6f61247cc231c1f1b36708 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger
Date: Thu, 7 Jan 2021 09:37:32 +0100
Subject: [PATCH] testsuite: Fix test failures from outputs.exp [PR98225]
The .ld1_args file is not created when HAVE_GNU_LD is false.
The ltrans0.ltrans_arg file is not created when the make jobserver
is available, so remove the MAKEFLAGS variable.
Add an exception for *.gcc_args files similar to the
exception for *.cdtor.* files.
Limit both exceptions to targets that define EH_FRAME_THROUGH_COLLECT2.
That means although the test case does not use C++ constructors
or destructors it is still using dwarf2 frame info.
2021-01-07 Bernd Edlinger
PR testsuite/98225
* gcc.misc-tests/outputs.exp: Unset MAKEFLAGS.
Expect .ld1_args only when GNU LD is used.
Add an exception for *.gcc_args files.
---
gcc/testsuite/gcc.misc-tests/outputs.exp | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/gcc/testsuite/gcc.misc-tests/outputs.exp b/gcc/testsuite/gcc.misc-tests/outputs.exp
index 80d4b61..d5a9709 100644
--- a/gcc/testsuite/gcc.misc-tests/outputs.exp
+++ b/gcc/testsuite/gcc.misc-tests/outputs.exp
@@ -50,6 +50,9 @@ if !$skip_lto {
set ltop [check_linker_plugin_available]
}
+# Check for GNU LD. Some files like .ld1_args depend on this.
+set gld [check_effective_target_gld]
+
# Prepare additional options to be used for linking.
# We do not compile to an executable, because that requires naming an output.
set link_options ""
@@ -67,6 +70,12 @@ if {[board_info $dest exists output_format]} {
append link_options " additional_flags=-Wl,-oformat,[board_info $dest output_format]"
}
+# Avoid possible influence from the make jobserver,
+# otherwise ltrans0.ltrans_args files may be missing.
+if [info exists env(MAKEFLAGS)] {
+unsetenv MAKEFLAGS
+}
+
# For the test named TEST, run the compiler with SOURCES and OPTS, and
# look in DIRS for OUTPUTS. SOURCES is a list of suffixes for source
# files starting with $b in $srcdir/$subdir, OPTS is a string with
@@ -130,6 +139,7 @@ proc outest { test sources opts dirs outputs } {
foreach og $olist {
if { [string index $og 0] == "!" } {
global gspd ltop
+ global gld
set cond [expr $og]
continue
}
@@ -181,7 +191,10 @@ proc outest { test sources opts dirs outputs } {
file delete $f
# collect2 may create .cdtor* files in -save-temps link tests,
# ??? without regard to aux output naming conventions.
- if ![string match "*.cdtor.*" $f] then {
+ # Limit this exception to targets that define EH_FRAME_THROUGH_COLLECT2.
[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577 --- Comment #18 from Steve Kargl --- On Fri, Jan 08, 2021 at 06:43:20PM +, mehdi.chinoune at hotmail dot com wrote: > > I concluded that is a waste of time arguing with him. > Did you run the test program from my last comment?
[Bug tree-optimization/58243] Suboptimal structure initialization with tree-sra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58243 --- Comment #2 from Hans-Peter Nilsson --- Confirmed; identical code w./wo. -fno-tree-sra for cris-elf too. Thanks.
Re: [PATCH, libstdc++] GLIBCXX_HAVE_INT64_T
On Fri, Jan 08, 2021 at 06:37:03PM +, Jonathan Wakely wrote: > This uses __INT64_TYPE__ if that's defined, and long long otherwise. I > think that should be equivalent in all practical cases (I can imagine > some strange target where __INT64_TYPE__ is defined by the compiler, > but int64_t isn't defined when the configure checks look for it, and > so the current code would use long long and with my patch would use > __INT64_TYPE__ which could be long ... but I think in practice that's > unlikely. It was probably more likely in older releases where the > configure test would have been done with -std=gnu++98 and so int64_t > might not have been declared by libc's , but if that was the > case then any ABI break it caused happened years ago. Does clang and ICC define __INT64_TYPE__ (at least on most architectures) and does it match what gcc defines it to? Jakub
[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577 --- Comment #17 from Chinoune --- Once I reported a bug to gcc/gfortran https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91337 but someone argued that it was my fault to use "-Ofast" so I rewrite the reproducer in C and reported again under another category https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91734. the bug was confirmed and fixed without someone blaming me for that. Another when I reported another bug but that "someone" said that my reproducer is invalid, fortunately some other guys didn't take his opinion under consideration and they fixed the bug. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92736 The problem is that "someone" still there (fortran category) attacking anyone who dare to report a bug in gfortran. I concluded that is a waste of time arguing with him.
[Bug fortran/91726] [8/9 Regression] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91726 --- Comment #8 from Paul Thomas --- (In reply to José Rui Faustino de Sousa from comment #7) > Hi all! > > Still ICEs with 9/10/11 using -ftrapv -fcheck=bounds > > Best regards, > José Rui Yes, indeed. This with those compile options module m type s class(*), allocatable :: a[:]! This ICEd end type end gives ../pr91726/pr91726.f90:5:3: 5 | end | ^ Error: mismatching comparison operand types integer(kind=8) unsigned long if (_10 != 1) goto ; else goto ; ../pr91726/pr91726.f90:5:3: internal compiler error: ‘verify_gimple’ failed 0xec247d verify_gimple_in_seq(gimple*) ../../gcc/gcc/tree-cfg.c:5119 The problem appears to lie in the bounds checking in trans-expr.c(gfc_copy_class_to_class) at line 1425 in master. It is produced by the vtable _copy function. For some reason that I cannot see from the code, 10-branch compiles this snippet just fine, while 9-branch produces a completely different error. It's now in my spreadsheet as an intersting one! Paul
Re: [PATCH, libstdc++] GLIBCXX_HAVE_INT64_T
On 06/01/21 19:41 -0500, David Edelsohn wrote:
Thanks for clarifying the issue.
As you implicitly point out, GCC knows the type of INT64 and defines
the macro __INT64_TYPE__ . The revised code can use that directly,
such as:
#if defined(_GLIBCXX_HAVE_INT64_T_LONG) \
|| defined(_GLIBCXX_HAVE_INT64_T_LONG_LONG)
typedef __INT64_TYPE__ streamoff;
#elif defined(_GLIBCXX_HAVE_INT64_T)
typedef int64_t streamoff;
#else
typedef long long streamoff;
#endif
Are there any additional issues not addressed by that approach, other
than possible further simplification?
That avoids the ABI break that Jakub pointed out. But I think we can
simplify it further, as in the attached patch.
This uses __INT64_TYPE__ if that's defined, and long long otherwise. I
think that should be equivalent in all practical cases (I can imagine
some strange target where __INT64_TYPE__ is defined by the compiler,
but int64_t isn't defined when the configure checks look for it, and
so the current code would use long long and with my patch would use
__INT64_TYPE__ which could be long ... but I think in practice that's
unlikely. It was probably more likely in older releases where the
configure test would have been done with -std=gnu++98 and so int64_t
might not have been declared by libc's , but if that was the
case then any ABI break it caused happened years ago.
diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index e4175ea3e64..f13c5d2467f 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -474,63 +474,6 @@ AC_DEFUN([GLIBCXX_CHECK_WRITEV], [
])
-dnl
-dnl Check whether int64_t is available in , and define HAVE_INT64_T.
-dnl Also check whether int64_t is actually a typedef to long or long long.
-dnl
-AC_DEFUN([GLIBCXX_CHECK_INT64_T], [
-
- AC_LANG_SAVE
- AC_LANG_CPLUSPLUS
-
- AC_MSG_CHECKING([for int64_t])
- AC_CACHE_VAL(glibcxx_cv_INT64_T, [
-AC_TRY_COMPILE(
- [#include ],
- [int64_t var;],
- [glibcxx_cv_INT64_T=yes],
- [glibcxx_cv_INT64_T=no])
- ])
-
- if test $glibcxx_cv_INT64_T = yes; then
-AC_DEFINE(HAVE_INT64_T, 1, [Define if int64_t is available in .])
-AC_MSG_RESULT($glibcxx_cv_INT64_T)
-
-AC_MSG_CHECKING([for int64_t as long])
-AC_CACHE_VAL(glibcxx_cv_int64_t_long, [
- AC_TRY_COMPILE(
- [#include
- template struct same { enum { value = -1 }; };
- template struct same { enum { value = 1 }; };
- int array[same::value];], [],
- [glibcxx_cv_int64_t_long=yes], [glibcxx_cv_int64_t_long=no])
-])
-
-if test $glibcxx_cv_int64_t_long = yes; then
- AC_DEFINE(HAVE_INT64_T_LONG, 1, [Define if int64_t is a long.])
- AC_MSG_RESULT($glibcxx_cv_int64_t_long)
-fi
-
-AC_MSG_CHECKING([for int64_t as long long])
-AC_CACHE_VAL(glibcxx_cv_int64_t_long_long, [
- AC_TRY_COMPILE(
- [#include
- template struct same { enum { value = -1 }; };
- template struct same { enum { value = 1 }; };
- int array[same::value];], [],
- [glibcxx_cv_int64_t_long_long=yes], [glibcxx_cv_int64_t_long_long=no])
-])
-
-if test $glibcxx_cv_int64_t_long_long = yes; then
- AC_DEFINE(HAVE_INT64_T_LONG_LONG, 1, [Define if int64_t is a long long.])
- AC_MSG_RESULT($glibcxx_cv_int64_t_long_long)
-fi
- fi
-
- AC_LANG_RESTORE
-])
-
-
dnl
dnl Check whether LFS support is available.
dnl
diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac
index 3c799be82b1..a816ff79d16 100644
--- a/libstdc++-v3/configure.ac
+++ b/libstdc++-v3/configure.ac
@@ -185,9 +185,6 @@ GLIBCXX_CHECK_STDIO_PROTO
GLIBCXX_CHECK_MATH11_PROTO
GLIBCXX_CHECK_UCHAR_H
-# For the streamoff typedef.
-GLIBCXX_CHECK_INT64_T
-
# For LFS support.
GLIBCXX_CHECK_LFS
diff --git a/libstdc++-v3/include/bits/postypes.h b/libstdc++-v3/include/bits/postypes.h
index 718ff44628c..d2fbfc35dee 100644
--- a/libstdc++-v3/include/bits/postypes.h
+++ b/libstdc++-v3/include/bits/postypes.h
@@ -39,32 +39,6 @@
#include // For mbstate_t
-// XXX If is really needed, make sure to define the macros
-// before including it, in order not to break (and
-// in C++11). Reconsider all this as soon as possible...
-#if (defined(_GLIBCXX_HAVE_INT64_T) && !defined(_GLIBCXX_HAVE_INT64_T_LONG) \
- && !defined(_GLIBCXX_HAVE_INT64_T_LONG_LONG))
-
-#ifndef __STDC_LIMIT_MACROS
-# define _UNDEF__STDC_LIMIT_MACROS
-# define __STDC_LIMIT_MACROS
-#endif
-#ifndef __STDC_CONSTANT_MACROS
-# define _UNDEF__STDC_CONSTANT_MACROS
-# define __STDC_CONSTANT_MACROS
-#endif
-#include // For int64_t
-#ifdef _UNDEF__STDC_LIMIT_MACROS
-# undef __STDC_LIMIT_MACROS
-# undef _UNDEF__STDC_LIMIT_MACROS
-#endif
-#ifdef _UNDEF__STDC_CONSTANT_MACROS
-# undef __STDC_CONSTANT_MACROS
-# undef _UNDEF__STDC_CONSTANT_MACROS
-#endif
-
-#endif
-
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -84,12 +58,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
* Note: In versions of GCC up to and including GCC 3.3, streamoff
* was
[Bug tree-optimization/58243] Suboptimal structure initialization with tree-sra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58243 Martin Jambor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #1 from Martin Jambor --- Store-merging now merges all the separate-byte setting. I have looked at optimized dumps with and without SRA (on x86_64-linux) and SRA never pessimizes the code but often helps to avoid the extra final copy. Not always, because that would (currently) require total scalarization which we do not do for bit-fields. So I am closing this as fixed.
[Bug tree-optimization/47059] compiler fails to coalesce loads/stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47059 Martin Jambor changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Martin Jambor --- Eh, really closing.
[Bug tree-optimization/47059] compiler fails to coalesce loads/stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47059 Martin Jambor changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #4 from Martin Jambor --- Store merging currently merges the two loads and stores of short ints into a normal int, so this can be closed. I have proposed to add this testcase to the testsuite: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563096.html
[PATCH] Testcase for old PR 47059
Hi,
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.
OK for trunk?
Thanks,
Martin
gcc/testsuite/ChangeLog:
2021-01-08 Martin Jambor
PR tree-optimization/47059
* gcc.dg/tree-ssa/pr47059.c: New test.
---
gcc/testsuite/gcc.dg/tree-ssa/pr47059.c | 45 +
1 file changed, 45 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr47059.c
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr47059.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr47059.c
new file mode 100644
index 000..9f9c61aa213
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr47059.c
@@ -0,0 +1,45 @@
+/* { dg-do compile } */
+/* { dg-options "-Os -fdump-tree-optimized" } */
+
+
+struct struct1
+{
+ void *data;
+ unsigned short f1;
+ unsigned short f2;
+};
+typedef struct struct1 S1;
+
+struct struct2
+{
+ int f3;
+ S1 f4;
+};
+typedef struct struct2 S2;
+
+
+extern void foo (S1 *ptr);
+extern S2 gstruct2_var;
+extern S1 gstruct1_var;
+
+static inline S1 bar (const S1 *ptr) __attribute__ ((always_inline));
+
+static inline S1
+bar (const S1 *ptr)
+{
+ S1 ls_var = *ptr;
+ foo (_var);
+ return ls_var;
+}
+
+int
+main ()
+{
+ S2 *ps_var;
+
+ ps_var = _var;
+ ps_var->f4 = bar (_var);
+
+ return 0;
+}
+/* { dg-final { scan-tree-dump-times "short unsigned int\[^*\]*;" 0
"optimized"} } */
--
2.29.2
Re: Fw: Problems with compiling autogen with GCC8 or newer versions
Hi, You are supposed to be able to post once you've subscribed. Also, GCC's code analysis is wrong. "name_bf" contains *NO MORE* than MAXNAMELEN characters. That is provable. "def_str" points into a buffer of size ((MAXNAMELEN * 2) + 8) and at an offset maximum of MAXNAMELEN+1 (also provable), meaning that at a minimum there are MAXNAMELEN+6 bytes left in the buffer. That objected-to sprintf can add a maximum of MAXNAMELEN + 4 to where "def_str" points. GCC is wrong. It is unable to figure out how far into the buffer "def_str" can point. On 1/8/21 2:26 AM, Oppe, Thomas C ERDC-RDE-ITL-MS Contractor wrote: Dear Sir: I would like to post the following message to the mailing list "autogen-us...@lists.sourceforge.net". Could you please add me to this list? I am an HPC user at ERDC DSRC in Vicksburg, MS. One of my projects is building GCC snapshots and releases using various software prerequisite packages necessary in the "make check" phase. One of these packages is autogen-5.18.16. Thank you for your consideration. Tom Oppe - Thomas C. Oppe HPCMP Benchmarking Team HITS Team SAIC thomas.c.o...@erdc.dren.mil Work: (601) 634-2797 Cell:(601) 642-6391 - From: Oppe, Thomas C ERDC-RDE-ITL-MS Contractor Sent: Friday, January 8, 2021 12:32 AM To: autogen-us...@lists.sourceforge.net Subject: Problems with compiling autogen with GCC8 or newer versions Dear Sir: When compiling autogen-5.18.16 with gcc8 or newer, I am getting format overflow errors like the following during the "make" step: top_builddir=".." top_srcdir=".." VERBOSE="" /bin/bash "../build-aux/run-ag.sh" -MFstamp-opts -MTstamp-opts -MP ./opts.def gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../autoopts -g -O2 -I/p/home/oppe/gcc/10.2.0/include -Wno-format-contains-nul -fno-strict-aliasing -Wall -Werror -Wcast-align -Wmissing-prototypes -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Wstrict-aliasing=3 -Wextra -Wno-cast-qual -g -O2 -I/p/home/oppe/gcc/10.2.0/include -Wno-format-contains-nul -fno-strict-aliasing -c -o gd.o gd.c In file included from gd.c:11: getdefs.c: In function 'buildDefinition': getdefs.c:451:29: error: '%s' directive writing up to 255 bytes into a region of size 253 [-Werror=format-overflow=] 451 | sprintf(def_str, " %s'", name_bf); | ^~~~~ getdefs.c:451:9: note: 'sprintf' output between 4 and 259 bytes into a destination of size 255 451 | sprintf(def_str, " %s'", name_bf); | ^~ cc1: all warnings being treated as errors make[2]: *** [gd.o] Error 1 make[2]: Leaving directory `/p/work1/oppe/autogen-5.18.16/getdefs' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/p/work1/oppe/autogen-5.18.16' make: *** [all] Error 2 Do I just add "-Wno-error=format-overflow" to the compile options? Do you have a fix? Tom Oppe - Thomas C. Oppe HPCMP Benchmarking Team HITS Team SAIC thomas.c.o...@erdc.dren.mil Work: (601) 634-2797 Cell:(601) 642-6391 -
[Bug c++/98600] Pointer-to-member deduced type not accepted as template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98600 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-01-08 CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Confirmed.
Re: [PATCH] PR libstdc++/71579 assert that type traits are not misused with an incomplete type
On Thu, Nov 12, 2020, 21:55 Antony Polukhin wrote: > Final bits for libstdc/71579 > Gentle reminder on last patch >
[Bug c++/98604] New: Passing constexpr by const reference causes excessive memory usage during compilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98604 Bug ID: 98604 Summary: Passing constexpr by const reference causes excessive memory usage during compilation Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: adamkzyzik at gmail dot com Target Milestone: --- Created attachment 49922 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49922=edit code https://stackoverflow.com/questions/65621617/huge-memory-consumption-during-compilation-when-passing-constexpr-by-const-refer Seems like passing constexpr object to a constexpr constructor by const reference causes excessive memory footprint during compilation. The more that object is used in the constructor, the more memory is consumed. g++ (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0 I tested it on few other versions and the behavior was the same. It doesn't occur on clang-10.
[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577 kargl at gcc dot gnu.org changed: What|Removed |Added Resolution|WONTFIX |INVALID --- Comment #16 from kargl at gcc dot gnu.org --- (In reply to Chinoune from comment #15) > Bug is a bug! It's not a bug if the behavior is documented. What does Intel do with this standard conforming program? program foo use iso_fortran_env, only : int32, int64, real64 implicit none integer(int32) rate4, t1, t2 integer(int64) rate8, u1, u2 ! ! Both Intel and gfortran should give the same timings as ! COUNT and COUNT_RATE variables have the same kind type ! parameter. This is documented by both gfortran and Intel. ! print '(A)', 'Behavior documented to give valid timings with gfortran and Intel' call system_clock(count_rate=rate4) print '(A,I0)', 'rate4 = ', rate4 call system_clock(count_rate=rate8) print '(A,I0)', 'rate8 = ', rate8 call system_clock(count=t1) call loop call system_clock(count=t2) print '(A,F0.3,A)', 'time = ', real(t2-t1,real64)/rate4, ' seconds (int32/int32)' call system_clock(count=u1) call loop call system_clock(count=u2) print '(A,F0.3,A)', 'time = ', real(u2-u1,real64)/rate8, ' seconds (int64/int64)' ! ! gfortran gives an invalid time with the following, but gfortran ! also documents the behavior. What does Intel do? ! print * print '(A)', 'Behavior documented to give invalid timings with gfortran' call system_clock(count_rate=rate8) print '(A,I0)', 'rate8 = ', rate8 call system_clock(count=t1) call loop call system_clock(count=t2) print '(A,F0.3,A)', 'time = ', real(t2-t1,real64)/rate8, ' seconds (int32/int64)' call system_clock(count_rate=rate4) print '(A,I0)', 'rate4 = ', rate4 call system_clock(count=u1) call loop call system_clock(count=u2) print '(A,F0.3,A)', 'time = ', real(u2-u1,real64)/rate4, ' seconds (int64/int32)' contains subroutine loop implicit none real(real64) dx, x, y integer i integer, parameter :: n = 10001 dx = 1._real64 / (n - 1) do i = 1, n x = 1000 + (i - 1) * dx y = cos(x) x = sin(x) if (x * y > 2) stop 1 end do end subroutine loop end program foo
Re: [PATCH] IBM Z: Fix constraints in vpdi patterns
On 1/8/21 5:35 PM, Ilya Leoshkevich wrote: > Bootstrapped and regtested on s390x-redhat-linux. Ok for master? > > > > The destination register is only partially overwritten, so + should be > used instead of =. > > gcc/ChangeLog: > > 2021-01-08 Ilya Leoshkevich > > * config/s390/vector.md (*tf_to_fprx2_0): Rename from > *mov_tf_to_fprx2_0 for consistency, fix constraint. > (*tf_to_fprx2_1): Rename from *mov_tf_to_fprx2_1 for > consistency, fix constraint. Ok, thanks! Andreas
[Bug target/98482] -mfentry creates invalid call for -mcmodel=large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98482 --- Comment #15 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:745d04e796c1a7ebcea0185d0742d58b0c0030ab commit r11-6557-g745d04e796c1a7ebcea0185d0742d58b0c0030ab Author: H.J. Lu Date: Fri Jan 8 08:41:38 2021 -0800 x86-64: Require lp64 for PR target/98482 tests Require lp64 for PR target/98482 tests since -mcmodel=large is isn't supported for x32. PR target/98482 * gcc.target/i386/pr98482-1.c: Require lp64. * gcc.target/i386/pr98482-2.c: Likewise.
[PATCH] x86-64: Require lp64 for PR target/98482 tests
On Fri, Jan 8, 2021 at 6:43 AM H.J. Lu wrote:
>
> On Fri, Jan 8, 2021 at 6:31 AM Uros Bizjak wrote:
> >
> > On Fri, Jan 8, 2021 at 2:28 PM H.J. Lu wrote:
> > >
> > > On Fri, Jan 8, 2021 at 4:50 AM H.J. Lu wrote:
> > > >
> > > > On Fri, Jan 8, 2021 at 1:24 AM Uros Bizjak wrote:
> > > > >
> > > > > > Since R10 is preserved when calling mcount, R10 can be used a
> > > > > > scratch
> > > > > > register to call mcount in large model.
> > > > >
> > > > > Please mention that R10 can be used as a static chain registers and is
> > > > > preserved when calling mcount for nested functions.
> > > > >
> > > > > > gcc/
> > > > > >
> > > > > > PR target/98482
> > > > > > * config/i386/i386.c (x86_function_profiler): Use R10 to call
> > > > > > mcount in large model. Sorry for large model with PIC.
> > > > > >
> > > > > > gcc/testsuite/
> > > > > >
> > > > > > PR target/98482
> > > > > > * gcc.target/i386/pr98482-1.c: New test.
> > > > > > * gcc.target/i386/pr98482-1.c: Likewise.
> > > > >
> > > > > OK with comment fixes.
> > > > >
> > > > > Thanks,
> > > > > Uros.
> > > > >
> > > > > +case CM_LARGE:
> > > > > + /* NB: R10 can be used as a scratch register here since
> > > > > +R10 is preserved when calling mcount. */
> > > > >
> > > > > Also mention that R10 can be used as a static chain register and is
> > > > > preserved when calling mcount for nested functions.
> > > > >
> > > > > + fprintf (file, "1:\tmovabsq\t$%s, %%r10\n\tcall\t*%%r10\n",
> > > > > + mcount_name);
> > > > > + break;
> > > >
> > > > This is the patch I am checking in.
> > > >
> > >
> > > For NO_PROFILE_COUNTERS targets, R11 is a scratch register. We can use
> > > R10 and R11 to call mcount in large model with PIC.
> > >
> > > OK for master?
> >
> > + fprintf (file, "\tmovabsq\t$%s@PLTOFF, %%r11\n",
> > + mcount_name);
> >
> > Please put mcount_name in the same line (and please do the same for
> > case CM_MEDIUM_PIC).
>
> Fixed.
>
> > OK with the above fixes.
> >
> > Thanks,
> > Uros.
>
> Here is the updated patch I am checking in.
>
I am checking in this patch since -mcmodel=large is isn't
supported for x32.
--
H.J.
From e7797264b2b8bee6b9a429385d91af0858ee0c8a Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Fri, 8 Jan 2021 08:41:38 -0800
Subject: [PATCH] x86-64: Require lp64 for PR target/98482 tests
Require lp64 for PR target/98482 tests since -mcmodel=large is isn't
supported for x32.
PR target/98482
* gcc.target/i386/pr98482-1.c: Require lp64.
* gcc.target/i386/pr98482-1.c: Likewise.
---
gcc/testsuite/gcc.target/i386/pr98482-1.c | 2 +-
gcc/testsuite/gcc.target/i386/pr98482-2.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/testsuite/gcc.target/i386/pr98482-1.c b/gcc/testsuite/gcc.target/i386/pr98482-1.c
index 72d5ccb269c..912cbe09191 100644
--- a/gcc/testsuite/gcc.target/i386/pr98482-1.c
+++ b/gcc/testsuite/gcc.target/i386/pr98482-1.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { *-*-linux* && { ! ia32 } } } } */
+/* { dg-do compile { target { *-*-linux* && lp64 } } } */
/* { dg-require-effective-target mfentry } */
/* { dg-options "-fprofile -mfentry -O2 -mcmodel=large" } */
/* { dg-final { scan-assembler "movabsq\t\\\$__fentry__, %r10\n\tcall\t\\*%r10" } } */
diff --git a/gcc/testsuite/gcc.target/i386/pr98482-2.c b/gcc/testsuite/gcc.target/i386/pr98482-2.c
index 0ee142db12c..03c62a4b67b 100644
--- a/gcc/testsuite/gcc.target/i386/pr98482-2.c
+++ b/gcc/testsuite/gcc.target/i386/pr98482-2.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { *-*-linux* && { ! ia32 } } } } */
+/* { dg-do compile { target { *-*-linux* && lp64 } } } */
/* { dg-require-effective-target mfentry } */
/* { dg-require-effective-target fpic } */
/* { dg-options "-fpic -fprofile -mfentry -O2 -mcmodel=large" } */
--
2.29.2
[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577 Chinoune changed: What|Removed |Added Resolution|INVALID |WONTFIX --- Comment #15 from Chinoune --- Bug is a bug!
[Bug tree-optimization/36602] memset should be optimized into an empty CONSTRUCTOR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36602 Martin Jambor changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #13 from Martin Jambor --- Memset is not being turned into a constructor but early DSE eliminates it now anyway and then the testcase is optimized just into return 0;. Do we want to keep this bug opened? (Issues with SRA padding are also tracked elsewhere.)
[Bug analyzer/98599] fatal error: Cgraph edge statement index out of range with -Os -flto -fanalyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98599 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Last reconfirmed||2021-01-08 --- Comment #1 from David Malcolm --- Thanks for filing this. Confirmed (on x86_64-pc-linux-gnu); am debugging it.
[PATCH] IBM Z: Fix constraints in vpdi patterns
Bootstrapped and regtested on s390x-redhat-linux. Ok for master? The destination register is only partially overwritten, so + should be used instead of =. gcc/ChangeLog: 2021-01-08 Ilya Leoshkevich * config/s390/vector.md (*tf_to_fprx2_0): Rename from *mov_tf_to_fprx2_0 for consistency, fix constraint. (*tf_to_fprx2_1): Rename from *mov_tf_to_fprx2_1 for consistency, fix constraint. --- gcc/config/s390/vector.md | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/gcc/config/s390/vector.md b/gcc/config/s390/vector.md index 5b8d75f18f0..0e3c31f5d4f 100644 --- a/gcc/config/s390/vector.md +++ b/gcc/config/s390/vector.md @@ -737,16 +737,16 @@ (define_insn "*vec_perm" "vperm\t%v0,%v1,%v2,%v3" [(set_attr "op_type" "VRR")]) -(define_insn "*mov_tf_to_fprx2_0" - [(set (subreg:DF (match_operand:FPRX2 0 "nonimmediate_operand" "=f") 0) +(define_insn "*tf_to_fprx2_0" + [(set (subreg:DF (match_operand:FPRX2 0 "nonimmediate_operand" "+f") 0) (subreg:DF (match_operand:TF1 "general_operand" "v") 0))] "TARGET_VXE" ; M4 == 1 corresponds to %v0[0] = %v1[0]; %v0[1] = %v0[1]; "vpdi\t%v0,%v1,%v0,1" [(set_attr "op_type" "VRR")]) -(define_insn "*mov_tf_to_fprx2_1" - [(set (subreg:DF (match_operand:FPRX2 0 "nonimmediate_operand" "=f") 8) +(define_insn "*tf_to_fprx2_1" + [(set (subreg:DF (match_operand:FPRX2 0 "nonimmediate_operand" "+f") 8) (subreg:DF (match_operand:TF1 "general_operand" "v") 8))] "TARGET_VXE" ; M4 == 5 corresponds to %V0[0] = %v1[1]; %V0[1] = %V0[1]; -- 2.26.2
Re: [PATCH v2] IBM Z: Introduce __LONG_DOUBLE_VX__ macro
On 1/8/21 2:14 PM, Ilya Leoshkevich wrote: > v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563034.html > v1 -> v2: Use TARGET_VXE_P instead of TARGET_Z14_P. > > > > Give end users the opportunity to find out whether long doubles are > stored in floating-point register pairs or in vector registers, so that > they could fine-tune their asm statements. > > gcc/ChangeLog: > > 2020-12-14 Ilya Leoshkevich > > * config/s390/s390-c.c (s390_def_or_undef_macro): Accept > callables instead of mask values. > (struct target_flag_set_p): New predicate. > (s390_cpu_cpp_builtins_internal): Define or undefine > __LONG_DOUBLE_VX__ macro. > > gcc/testsuite/ChangeLog: > > 2020-12-14 Ilya Leoshkevich > > * gcc.target/s390/vector/long-double-vx-macro-off.c: New test. > * gcc.target/s390/vector/long-double-vx-macro-on.c: New test. Ok, thanks! Andreas
[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577 kargl at gcc dot gnu.org changed: What|Removed |Added Resolution|WONTFIX |INVALID --- Comment #14 from kargl at gcc dot gnu.org --- (In reply to Chinoune from comment #12) > First example: > > $ ifort bug_gcc_tic.f90 -o test.x > $ ./test.x > count(int_32): > count_rate(int32) =1 > count_rate(int64) = 1 > count_rate(real32) =1.00 > count_rate(real64) =1.00 > count(int_64): > count_rate(int32) = 100 > count_rate(int64) =100 > count_rate(real32) =100. > count_rate(real64) =100. > > Unlike gfortran, count_rate with ifort depends only on the precision of the > first argument of system_clock. It doesn't mixup. That is not required by the Fortran Standard, but conforms because COUNT and COUNT_RATE are processor-dependent. I also took the opportunity to look at the Intel Fortran documentation at https://software.intel.com/content/www/us/en/develop/documentation/fortran-compiler-oneapi-dev-guide-and-reference/top/language-reference/a-to-z-reference/s-1/system-clock.html dated 4 dec 2020. Note, the following hightlighted sentence on that page: "All integer arguments used must have the same integer kind parameter." That is not required by Fortran Standard. Why would Intel require compatible kind type parameters? Your program in comment #0 does meet the requirements placed on system_clock() by Intel.
Re: [PATCH] c++: ICE with constexpr call that returns a PMF [PR98551]
On Thu, 7 Jan 2021, Jason Merrill wrote:
> On 1/7/21 10:10 AM, Patrick Palka wrote:
> > We shouldn't do replace_result_decl after evaluating a call that returns
> > a PMF because PMF temporaries aren't wrapped in a TARGET_EXPR (and so we
> > can't trust ctx->object), and PMF initializers can't be self-referential
> > anyway, so replace_result_decl would always be a no-op. This fixes an
> > ICE from the sanity check in replace_result_decl in the below testcase
> > during cxx_eval_call_expression of the call f() in the initializer g(f()).
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> > trunk?
> >
> > gcc/cp/ChangeLog:
> >
> > PR c++/98551
> > * constexpr.c (cxx_eval_call_expression): Don't call
> > replace_result_decl when the result is a PMF.
> >
> > gcc/testsuite/ChangeLog:
> >
> > PR c++/98551
> > * g++.dg/cpp0x/constexpr-pmf2.C: New test.
> > ---
> > gcc/cp/constexpr.c | 1 +
> > gcc/testsuite/g++.dg/cpp0x/constexpr-pmf2.C | 9 +
> > 2 files changed, 10 insertions(+)
> > create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-pmf2.C
> >
> > diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
> > index 0c12f608d36..a7272d49d0d 100644
> > --- a/gcc/cp/constexpr.c
> > +++ b/gcc/cp/constexpr.c
> > @@ -2788,6 +2788,7 @@ cxx_eval_call_expression (const constexpr_ctx *ctx,
> > tree t,
> >current object under construction. */
> > if (!*non_constant_p && ctx->object
> > && AGGREGATE_TYPE_P (TREE_TYPE (res))
> > + && !TYPE_PTRMEMFUNC_P (TREE_TYPE (res))
>
> It ought to work to change AGGREGATE_TYPE_P to CLASS_TYPE_P; we can't return
> an array, and a vector can't contain a pointer to itself.
>
> Alternately, we could change the same-type assert in replace_result_decl to a
> test and return false if different.
>
> OK with either change.
Sounds good. I went with changing AGGREGATE_TYPE_P to CLASS_TYPE_P and
leaving alone the assert in replace_result_decl for now:
-- >8 --
Subject: [PATCH] c++: ICE with constexpr call that returns a PMF [PR98551]
We shouldn't do replace_result_decl after evaluating a call that returns
a PMF because PMF temporaries aren't wrapped in a TARGET_EXPR (and so we
can't trust ctx->object), and PMF initializers can't be self-referential
anyway, so replace_result_decl would always be a no-op.
To that end, this patch changes the relevant AGGREGATE_TYPE_P test to
CLASS_TYPE_P, which should rule out PMFs (as well as arrays, which we
can't return and therefore won't see here). This fixes an ICE from the
sanity check in replace_result_decl in the below testcase during
constexpr evaluation of the call f() in the initializer g(f()).
gcc/cp/ChangeLog:
PR c++/98551
* constexpr.c (cxx_eval_call_expression): Check CLASS_TYPE_P
instead of AGGREGATE_TYPE_P before calling replace_result_decl.
gcc/testsuite/ChangeLog:
PR c++/98551
* g++.dg/cpp0x/constexpr-pmf2.C: New test.
---
gcc/cp/constexpr.c | 2 +-
gcc/testsuite/g++.dg/cpp0x/constexpr-pmf2.C | 9 +
2 files changed, 10 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-pmf2.C
diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 4a5e6384da6..9dddc53ca52 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -2790,7 +2790,7 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree
t,
/* Rewrite all occurrences of the function's RESULT_DECL with the
current object under construction. */
if (!*non_constant_p && ctx->object
- && AGGREGATE_TYPE_P (TREE_TYPE (res))
+ && CLASS_TYPE_P (TREE_TYPE (res))
&& !is_empty_class (TREE_TYPE (res)))
if (replace_result_decl (, res, ctx->object))
cacheable = false;
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-pmf2.C
b/gcc/testsuite/g++.dg/cpp0x/constexpr-pmf2.C
new file mode 100644
index 000..a76e712afe1
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-pmf2.C
@@ -0,0 +1,9 @@
+// PR c++/98551
+// { dg-do compile { target c++11 } }
+
+struct A {};
+struct B { int t(); };
+using pmf = decltype(::t);
+constexpr pmf f() { return ::t; }
+constexpr A g(pmf) { return {}; };
+constexpr A x = g(f());
--
2.30.0
Re: [PATCH] c++: Fix access checking of scoped non-static member [PR98515]
On Thu, 7 Jan 2021, Jason Merrill wrote:
> On 1/7/21 5:47 PM, Patrick Palka wrote:
> > On Thu, 7 Jan 2021, Jason Merrill wrote:
> >
> > > On 1/6/21 1:19 PM, Patrick Palka wrote:
> > > > In the first testcase below, we incorrectly reject the use of the
> > > > protected non-static member A::var0 from C::g() because
> > > > check_accessibility_of_qualified_id, at template parse time, determines
> > > > that the access doesn't go through 'this'. (This happens because the
> > > > dependent base B of C doesn't have a binfo object, so it appears
> > > > to DERIVED_FROM_P that A is not an indirect base of C.) From there
> > > > we create the corresponding deferred access check, which we then
> > > > perform at instantiation time and which (unsurprisingly) fails.
> > > >
> > > > The problem ultimately seems to be that we can't, in general, know
> > > > whether a use of a scoped non-static member goes through 'this' until
> > > > instantiation time, as the second testcase below demonstrates. So this
> > > > patch makes check_accessibility_of_qualified_id punt in this situation.
> > > >
> > > > Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK to
> > > > commit?
> > > >
> > > > gcc/cp/ChangeLog:
> > > >
> > > > PR c++/98515
> > > > * semantics.c (check_accessibility_of_qualified_id): Punt if
> > > > we're checking the access of a scoped non-static member at
> > > > class template parse time.
> > > >
> > > > gcc/testsuite/ChangeLog:
> > > >
> > > > PR c++/98515
> > > > * g++.dg/template/access32.C: New test.
> > > > * g++.dg/template/access33.C: New test.
> > > > ---
> > > >gcc/cp/semantics.c | 20 +++-
> > > >gcc/testsuite/g++.dg/template/access32.C | 8
> > > >gcc/testsuite/g++.dg/template/access33.C | 9 +
> > > >3 files changed, 32 insertions(+), 5 deletions(-)
> > > >create mode 100644 gcc/testsuite/g++.dg/template/access32.C
> > > >create mode 100644 gcc/testsuite/g++.dg/template/access33.C
> > > >
> > > > diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
> > > > index b448efe024a..f52b2e4d1e7 100644
> > > > --- a/gcc/cp/semantics.c
> > > > +++ b/gcc/cp/semantics.c
> > > > @@ -2107,14 +2107,24 @@ check_accessibility_of_qualified_id (tree decl,
> > > > /* If the reference is to a non-static member of the
> > > > current class, treat it as if it were referenced through
> > > > `this'. */
> > > > - tree ct;
> > > > if (DECL_NONSTATIC_MEMBER_P (decl)
> > > > - && current_class_ptr
> > > > - && DERIVED_FROM_P (scope, ct = current_nonlambda_class_type
> > > > ()))
> > > > - qualifying_type = ct;
> > > > + && current_class_ptr)
> > > > + {
> > > > + if (dependent_type_p (TREE_TYPE (current_class_ptr)))
> > >
> > > This should also look at current_nonlambda_class_type.
> >
> > Ah, ack. But it seems to me we really only need to be checking
> > dependence of current_nonlambda_class_type here.
>
> Yes, that's what I meant, sorry about the ambiguous use of "also". :)
Oops, I see what you had meant now, sorry about the confusion :)
>
> > IIUC, dependence of
> > these two types should coincide except in the case where we're inside a
> > generic lambda within a non-template class (in which case
> > current_class_ptr will dependent and current_nonlambda_class_type won't).
> > But in this case we have enough information to be able to resolve the
> > access check at parse time, I think (and so we shouldn't punt).
> >
> > The below patch, which seems to pass 'make check-c++', checks the
> > dependence of current_nonlambda_class_type instead of that of
> > current_class_ptr. Does this approach seem right?
>
> OK.
Thanks.
>
> > -- >8 --
> >
> > Subject: [PATCH] c++: Fix access checking of scoped non-static member
> > [PR98515]
> >
> > In the first testcase below, we incorrectly reject the use of the
> > protected non-static member A::var0 from C::g() because
> > check_accessibility_of_qualified_id, at template parse time, determines
> > that the access doesn't go through 'this'. (This happens because the
> > dependent base B of C doesn't have a binfo object, so it appears
> > to DERIVED_FROM_P that A is not an indirect base of C.) From there
> > we create the corresponding deferred access check, which we then
> > perform at instantiation time and which (unsurprisingly) fails.
> >
> > The problem ultimately seems to be that we can't in general determine
> > whether a use of a scoped non-static member goes through 'this' until
> > instantiation time, as the second testcase below illustrates. So this
> > patch makes check_accessibility_of_qualified_id punt in such situations
> > to avoid creating a bogus deferred access check.
> >
> > gcc/cp/ChangeLog:
> >
> > PR c++/98515
> > * semantics.c (check_accessibility_of_qualified_id): Punt if
> > we're
[Bug libstdc++/98473] std::vector::insert(pos, first, last) doesn't compile for T which has a deleted assignment operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98473 --- Comment #4 from Jonathan Wakely --- (In reply to Borislav Stanimirov from comment #2) > (In reply to Jonathan Wakely from comment #1) > > > To meet the requirements of the standard we would need to insert them at the > > end and then use std::rotate to reposition them. > > Or, to save move assignments, first "make a hole" and then copy-construct > b's in place (some destructors of moved-out objects) will have to be called. If any of those copy constructions throws then you have a vector with holes in it, breaking the invariant. Making that exception safe makes the code more complicated (and slower) which is why inserting them at the end and rotating is a better choice.
[Bug c++/98515] [11 Regression] Possible regression causing "is protected within this context" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98515 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Patrick Palka --- This should now be fixed on trunk; thanks for the bug report.
[Bug c++/98551] [10/11 Regression] ICE in replace_result_decl, at cp/constexpr.c:2150
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98551 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:bb1f0b50abbfa01e0ed720a5225a11aa7af32a89 commit r11-6554-gbb1f0b50abbfa01e0ed720a5225a11aa7af32a89 Author: Patrick Palka Date: Fri Jan 8 10:11:25 2021 -0500 c++: ICE with constexpr call that returns a PMF [PR98551] We shouldn't do replace_result_decl after evaluating a call that returns a PMF because PMF temporaries aren't wrapped in a TARGET_EXPR (and so we can't trust ctx->object), and PMF initializers can't be self-referential anyway, so replace_result_decl would always be a no-op. To that end, this patch changes the relevant AGGREGATE_TYPE_P test to CLASS_TYPE_P, which should rule out PMFs (as well as arrays, which we can't return and therefore won't see here). This fixes an ICE from the sanity check in replace_result_decl in the below testcase during constexpr evaluation of the call f() in the initializer g(f()). gcc/cp/ChangeLog: PR c++/98551 * constexpr.c (cxx_eval_call_expression): Check CLASS_TYPE_P instead of AGGREGATE_TYPE_P before calling replace_result_decl. gcc/testsuite/ChangeLog: PR c++/98551 * g++.dg/cpp0x/constexpr-pmf2.C: New test.
[Bug c++/98515] [11 Regression] Possible regression causing "is protected within this context" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98515 --- Comment #5 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:98a1fb705ead9258642f2dec0431f11508a9b13c commit r11-6553-g98a1fb705ead9258642f2dec0431f11508a9b13c Author: Patrick Palka Date: Fri Jan 8 10:02:04 2021 -0500 c++: Fix access checking of scoped non-static member [PR98515] In the first testcase below, we incorrectly reject the use of the protected non-static member A::var0 from C::g() because check_accessibility_of_qualified_id, at template parse time, determines that the access doesn't go through 'this'. (This happens because the dependent base B of C doesn't have a binfo object, so it appears to DERIVED_FROM_P that A is not an indirect base of C.) From there we create the corresponding deferred access check, which we then perform at instantiation time and which (expectedly) fails. The problem ultimately seems to be that we can't in general determine whether a use of a scoped non-static member goes through 'this' until instantiation time, as the second testcase below illustrates. So this patch makes check_accessibility_of_qualified_id punt in such situations to avoid creating a bogus deferred access check. gcc/cp/ChangeLog: PR c++/98515 * semantics.c (check_accessibility_of_qualified_id): Punt if we're checking access of a scoped non-static member inside a class template. gcc/testsuite/ChangeLog: PR c++/98515 * g++.dg/template/access32.C: New test. * g++.dg/template/access33.C: New test.
Re: [PATCH] c++: Add support for -std=c++2b
I think we should consider making this -std=c++23 right away this time, since we're on a three-year release schedule. Up to Jason though. Marek
[Bug c++/98556] [8/9/10/11 Regression] ICE: 'verify_gimple' failed since r8-4821-g1af4ebf5985ef2aa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98556 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 49921 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49921=edit gcc11-pr98556.patch Untested fix.
Re: [PATCH 2/4] PDP11: Use a mode with `const_double_zero' expressions
> On Jan 7, 2021, at 8:50 PM, Maciej W. Rozycki wrote: > > ... > > Provide a new iterator to provide copies of FP substitutions across the > FP modes supported as the substitutions now need to match the mode of > the operands. > > gcc/ > * config/pdp11/pdp11.md (PDPfp): New mode iterator. > (fcc_cc, fcc_ccnz): Use it. Add mode to `const_double_zero' and > operands. > --- > gcc/config/pdp11/pdp11.md | 10 ++ > 1 file changed, 6 insertions(+), 4 deletions(-) > > gcc-pdp11-const-double-zero-mode.diff > Index: gcc/gcc/config/pdp11/pdp11.md > === > --- gcc.orig/gcc/config/pdp11/pdp11.md > +++ gcc/gcc/config/pdp11/pdp11.md > @@ -82,6 +82,8 @@ > > (define_code_iterator SHF [ashift ashiftrt lshiftrt]) > > +(define_mode_iterator PDPfp [SF DF]) > + > ;; Substitution to turn a CC clobber into a CC setter. We have four of > ;; these: for CCmode vs. CCNZmode, and for CC_REGNUM vs. FCC_REGNUM. > (define_subst "cc_cc" > @@ -101,19 +103,19 @@ >(set (match_dup 0) (match_dup 1))]) > > (define_subst "fcc_cc" > - [(set (match_operand 0 "") (match_operand 1 "")) > + [(set (match_operand:PDPfp 0 "") (match_operand:PDPfp 1 "")) >(clobber (reg FCC_REGNUM))] > "" > [(set (reg:CC FCC_REGNUM) > - (compare:CC (match_dup 1) (const_double_zero))) > + (compare:CC (match_dup 1) (const_double_zero:PDPfp))) >(set (match_dup 0) (match_dup 1))]) > > (define_subst "fcc_ccnz" > - [(set (match_operand 0 "") (match_operand 1 "")) > + [(set (match_operand:PDPfp 0 "") (match_operand:PDPfp 1 "")) >(clobber (reg FCC_REGNUM))] > "" > [(set (reg:CCNZ FCC_REGNUM) > - (compare:CCNZ (match_dup 1) (const_double_zero))) > + (compare:CCNZ (match_dup 1) (const_double_zero:PDPfp))) >(set (match_dup 0) (match_dup 1))]) > > (define_subst_attr "cc_cc" "cc_cc" "_nocc" "_cc") Ok. Thanks Maciej. paul
[Bug target/98482] -mfentry creates invalid call for -mcmodel=large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98482 --- Comment #14 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #10) > If we are emitting for nested functions > pushq %r10 > 1:call__fentry__ > popq%r10 > (is it ok to misalign the stack for __fentry__? but then even plain call > __fentry__ actually misaligns it), then perhaps we can do similarly for the > PIC case. But I wonder how does __fentry__ then find the caller if it can't > rely on the return address being right above the return address to the > function that called __fentry__ (appart from unwind info of course, but we > don't really emit .cfi_* directives here either, do we?). Generic part of the compiler pushes static chain register for nested functions, so there is little we can do in the target part. If there is a problem with misaligned stack, then I think __mcount_internal will have to be realigned, because calls to both, mcount and __fentry__ can be misaligned. I don't know what to do with __fentry__ argument. Luckily, mcount finds its argument via frame pointer, so it works there.
[Bug target/98482] -mfentry creates invalid call for -mcmodel=large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98482 --- Comment #13 from H.J. Lu --- Fixed for GCC 11 so far. Please open a new GCC bug for mcount stack alignment.
[Bug target/98482] -mfentry creates invalid call for -mcmodel=large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98482 --- Comment #12 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:76be18f442948d1a4bc49a7d670b07097f9e5983 commit r11-6552-g76be18f442948d1a4bc49a7d670b07097f9e5983 Author: H.J. Lu Date: Fri Jan 8 05:20:19 2021 -0800 x86-64: Use R10 and R11 for profiling large model with PIC For NO_PROFILE_COUNTERS targets, R11 is a scratch register. We can use R10 and R11 to call mcount in large model with PIC. gcc/ PR target/98482 * config/i386/i386.c (x86_function_profiler): Use R10 and R11 to call mcount in large model with PIC for NO_PROFILE_COUNTERS targets. gcc/testsuite/ PR target/98482 * gcc.target/i386/pr98482-2.c: Updated.
Re: [PATCH] x86-64: Use R10 and R11 for profiling large model with PIC
On Fri, Jan 8, 2021 at 6:31 AM Uros Bizjak wrote:
>
> On Fri, Jan 8, 2021 at 2:28 PM H.J. Lu wrote:
> >
> > On Fri, Jan 8, 2021 at 4:50 AM H.J. Lu wrote:
> > >
> > > On Fri, Jan 8, 2021 at 1:24 AM Uros Bizjak wrote:
> > > >
> > > > > Since R10 is preserved when calling mcount, R10 can be used a scratch
> > > > > register to call mcount in large model.
> > > >
> > > > Please mention that R10 can be used as a static chain registers and is
> > > > preserved when calling mcount for nested functions.
> > > >
> > > > > gcc/
> > > > >
> > > > > PR target/98482
> > > > > * config/i386/i386.c (x86_function_profiler): Use R10 to call
> > > > > mcount in large model. Sorry for large model with PIC.
> > > > >
> > > > > gcc/testsuite/
> > > > >
> > > > > PR target/98482
> > > > > * gcc.target/i386/pr98482-1.c: New test.
> > > > > * gcc.target/i386/pr98482-1.c: Likewise.
> > > >
> > > > OK with comment fixes.
> > > >
> > > > Thanks,
> > > > Uros.
> > > >
> > > > +case CM_LARGE:
> > > > + /* NB: R10 can be used as a scratch register here since
> > > > +R10 is preserved when calling mcount. */
> > > >
> > > > Also mention that R10 can be used as a static chain register and is
> > > > preserved when calling mcount for nested functions.
> > > >
> > > > + fprintf (file, "1:\tmovabsq\t$%s, %%r10\n\tcall\t*%%r10\n",
> > > > + mcount_name);
> > > > + break;
> > >
> > > This is the patch I am checking in.
> > >
> >
> > For NO_PROFILE_COUNTERS targets, R11 is a scratch register. We can use
> > R10 and R11 to call mcount in large model with PIC.
> >
> > OK for master?
>
> + fprintf (file, "\tmovabsq\t$%s@PLTOFF, %%r11\n",
> + mcount_name);
>
> Please put mcount_name in the same line (and please do the same for
> case CM_MEDIUM_PIC).
Fixed.
> OK with the above fixes.
>
> Thanks,
> Uros.
Here is the updated patch I am checking in.
Thanks.
--
H.J.
From a9b5c1263cada2e0b3d59aa8a65b8bbc841775f2 Mon Sep 17 00:00:00 2001
From: "H.J. Lu"
Date: Fri, 8 Jan 2021 05:20:19 -0800
Subject: [PATCH] x86-64: Use R10 and R11 for profiling large model with PIC
For NO_PROFILE_COUNTERS targets, R11 is a scratch register. We can use
R10 and R11 to call mcount in large model with PIC.
gcc/
PR target/98482
* config/i386/i386.c (x86_function_profiler): Use R10 and R11
to call mcount in large model with PIC for NO_PROFILE_COUNTERS
targets.
gcc/testsuite/
PR target/98482
* gcc.target/i386/pr98482-2.c: Updated.
---
gcc/config/i386/i386.c| 12 ++--
gcc/testsuite/gcc.target/i386/pr98482-2.c | 3 ++-
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index d3068462fcd..d35af37a49c 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -20806,12 +20806,20 @@ x86_function_profiler (FILE *file, int labelno ATTRIBUTE_UNUSED)
mcount_name);
break;
case CM_LARGE_PIC:
+#ifdef NO_PROFILE_COUNTERS
+ fprintf (file, "1:\tmovabsq\t$_GLOBAL_OFFSET_TABLE_-1b, %%r11\n");
+ fprintf (file, "\tleaq\t1b(%%rip), %%r10\n");
+ fprintf (file, "\taddq\t%%r11, %%r10\n");
+ fprintf (file, "\tmovabsq\t$%s@PLTOFF, %%r11\n", mcount_name);
+ fprintf (file, "\taddq\t%%r11, %%r10\n");
+ fprintf (file, "\tcall\t*%%r10\n");
+#else
sorry ("profiling %<-mcmodel=large%> with PIC is not supported");
+#endif
break;
case CM_SMALL_PIC:
case CM_MEDIUM_PIC:
- fprintf (file, "1:\tcall\t*%s@GOTPCREL(%%rip)\n",
- mcount_name);
+ fprintf (file, "1:\tcall\t*%s@GOTPCREL(%%rip)\n", mcount_name);
break;
default:
x86_print_call_or_nop (file, mcount_name);
diff --git a/gcc/testsuite/gcc.target/i386/pr98482-2.c b/gcc/testsuite/gcc.target/i386/pr98482-2.c
index aed3ca4b6ff..0ee142db12c 100644
--- a/gcc/testsuite/gcc.target/i386/pr98482-2.c
+++ b/gcc/testsuite/gcc.target/i386/pr98482-2.c
@@ -2,8 +2,9 @@
/* { dg-require-effective-target mfentry } */
/* { dg-require-effective-target fpic } */
/* { dg-options "-fpic -fprofile -mfentry -O2 -mcmodel=large" } */
+/* { dg-final { scan-assembler "movabsq\t\\\$__fentry__@PLTOFF, %r11\n\taddq\t%r11, %r10\n\tcall\t\\*%r10" } } */
void
func (void)
{
-} /* { dg-message "sorry, unimplemented: profiling '-mcmodel=large' with PIC is not supported" } */
+}
--
2.29.2
[Bug rtl-optimization/98603] aarch64: ICE in extract_insn (ira) on asm goto with bad constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98603 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-01-08 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Jakub Jelinek --- Created attachment 49920 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49920=edit gcc11-pr98603.patch Untested fix.
[Bug tree-optimization/98069] [8/9/10/11 Regression] Miscompilation with -O3 since r8-2380-g2d7744d4ef93bfff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98069 Richard Biener changed: What|Removed |Added Assignee|rguenth at gcc dot gnu.org |rsandifo at gcc dot gnu.org Known to work||11.0 --- Comment #6 from Richard Biener --- This is now also fixed, since g:4cf70c20cb10acd6fb10166 presumably. Assigning to Richard in case he's planning backports.
Re: [PATCH] if-to-switch: remove memory leaks
On Fri, Jan 8, 2021 at 3:27 PM Martin Liška wrote:
>
> The patch removes some memory leaks spotted by valgrind.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
OK.
Richard.
> Thanks,
> Martin
>
>
> gcc/ChangeLog:
>
> * gimple-if-to-switch.cc (struct condition_info): Use auto_var.
> (if_chain::is_beneficial): Delete clusters
> (find_conditions): Make second argument of conditions_in_bbs a
> pointer so that we control over it's lifetime.
> (pass_if_to_switch::execute): Delete them.
> ---
> gcc/gimple-if-to-switch.cc | 97 ++
> 1 file changed, 56 insertions(+), 41 deletions(-)
>
> diff --git a/gcc/gimple-if-to-switch.cc b/gcc/gimple-if-to-switch.cc
> index 6dba4e2c39c..560753d0311 100644
> --- a/gcc/gimple-if-to-switch.cc
> +++ b/gcc/gimple-if-to-switch.cc
> @@ -59,7 +59,7 @@ using namespace tree_switch_conversion;
>
> struct condition_info
> {
> - typedef vec> mapping_vec;
> + typedef auto_vec> mapping_vec;
>
> condition_info (gcond *cond): m_cond (cond), m_bb (gimple_bb (cond)),
> m_forwarder_bb (NULL), m_ranges (), m_true_edge (NULL), m_false_edge
> (NULL),
> @@ -75,7 +75,7 @@ struct condition_info
> gcond *m_cond;
> basic_block m_bb;
> basic_block m_forwarder_bb;
> - vec m_ranges;
> + auto_vec m_ranges;
> edge m_true_edge;
> edge m_false_edge;
> mapping_vec m_true_edge_phi_mapping;
> @@ -253,6 +253,10 @@ if_chain::is_beneficial ()
> r = output.length () < filtered_clusters.length ();
> if (r)
> dump_clusters (, "BT can be built");
> +
> + for (unsigned i = 0; i < output.length (); i++)
> +delete output[i];
> +
> output.release ();
> return r;
> }
> @@ -377,7 +381,7 @@ convert_if_conditions_to_switch (if_chain *chain)
>
> static void
> find_conditions (basic_block bb,
> -hash_map *conditions_in_bbs)
> +hash_map *conditions_in_bbs)
> {
> gimple_stmt_iterator gsi = gsi_last_nondebug_bb (bb);
> if (gsi_end_p (gsi))
> @@ -394,7 +398,7 @@ find_conditions (basic_block bb,
> tree rhs = gimple_cond_rhs (cond);
> tree_code code = gimple_cond_code (cond);
>
> - condition_info info (cond);
> + condition_info *info = new condition_info (cond);
>
> gassign *def;
> if (code == NE_EXPR
> @@ -405,49 +409,53 @@ find_conditions (basic_block bb,
> enum tree_code rhs_code = gimple_assign_rhs_code (def);
> if (rhs_code == BIT_IOR_EXPR)
> {
> - info.m_ranges.safe_grow (2, true);
> - init_range_entry (_ranges[0], gimple_assign_rhs1 (def),
> NULL);
> - init_range_entry (_ranges[1], gimple_assign_rhs2 (def),
> NULL);
> + info->m_ranges.safe_grow (2, true);
> + init_range_entry (>m_ranges[0], gimple_assign_rhs1 (def),
> NULL);
> + init_range_entry (>m_ranges[1], gimple_assign_rhs2 (def),
> NULL);
> }
> }
> else
> {
> - info.m_ranges.safe_grow (1, true);
> - init_range_entry (_ranges[0], NULL_TREE, cond);
> + info->m_ranges.safe_grow (1, true);
> + init_range_entry (>m_ranges[0], NULL_TREE, cond);
> }
>
> /* All identified ranges must have equal expression and IN_P flag. */
> - if (!info.m_ranges.is_empty ())
> + if (!info->m_ranges.is_empty ())
> {
> edge true_edge, false_edge;
> - tree expr = info.m_ranges[0].exp;
> - bool in_p = info.m_ranges[0].in_p;
> + tree expr = info->m_ranges[0].exp;
> + bool in_p = info->m_ranges[0].in_p;
>
> extract_true_false_edges_from_block (bb, _edge, _edge);
> - info.m_true_edge = in_p ? true_edge : false_edge;
> - info.m_false_edge = in_p ? false_edge : true_edge;
> -
> - for (unsigned i = 0; i < info.m_ranges.length (); ++i)
> - if (info.m_ranges[i].exp == NULL_TREE
> - || !INTEGRAL_TYPE_P (TREE_TYPE (info.m_ranges[i].exp))
> - || info.m_ranges[i].low == NULL_TREE
> - || info.m_ranges[i].high == NULL_TREE
> - || (TYPE_PRECISION (TREE_TYPE (info.m_ranges[i].low))
> - != TYPE_PRECISION (TREE_TYPE (info.m_ranges[i].high
> - return;
> -
> - for (unsigned i = 1; i < info.m_ranges.length (); ++i)
> - if (info.m_ranges[i].exp != expr
> - || info.m_ranges[i].in_p != in_p)
> - return;
> -
> - info.record_phi_mapping (info.m_true_edge,
> - _true_edge_phi_mapping);
> - info.record_phi_mapping (info.m_false_edge,
> - _false_edge_phi_mapping);
> + info->m_true_edge = in_p ? true_edge : false_edge;
> + info->m_false_edge = in_p ? false_edge : true_edge;
> +
> + for (unsigned i = 0; i < info->m_ranges.length (); ++i)
> + if (info->m_ranges[i].exp == NULL_TREE
> + || !INTEGRAL_TYPE_P (TREE_TYPE (info->m_ranges[i].exp))
> + || info->m_ranges[i].low ==
Re: [PATCH] x86-64: Use R10 and R11 for profiling large model with PIC
On Fri, Jan 8, 2021 at 2:28 PM H.J. Lu wrote: > > On Fri, Jan 8, 2021 at 4:50 AM H.J. Lu wrote: > > > > On Fri, Jan 8, 2021 at 1:24 AM Uros Bizjak wrote: > > > > > > > Since R10 is preserved when calling mcount, R10 can be used a scratch > > > > register to call mcount in large model. > > > > > > Please mention that R10 can be used as a static chain registers and is > > > preserved when calling mcount for nested functions. > > > > > > > gcc/ > > > > > > > > PR target/98482 > > > > * config/i386/i386.c (x86_function_profiler): Use R10 to call > > > > mcount in large model. Sorry for large model with PIC. > > > > > > > > gcc/testsuite/ > > > > > > > > PR target/98482 > > > > * gcc.target/i386/pr98482-1.c: New test. > > > > * gcc.target/i386/pr98482-1.c: Likewise. > > > > > > OK with comment fixes. > > > > > > Thanks, > > > Uros. > > > > > > +case CM_LARGE: > > > + /* NB: R10 can be used as a scratch register here since > > > +R10 is preserved when calling mcount. */ > > > > > > Also mention that R10 can be used as a static chain register and is > > > preserved when calling mcount for nested functions. > > > > > > + fprintf (file, "1:\tmovabsq\t$%s, %%r10\n\tcall\t*%%r10\n", > > > + mcount_name); > > > + break; > > > > This is the patch I am checking in. > > > > For NO_PROFILE_COUNTERS targets, R11 is a scratch register. We can use > R10 and R11 to call mcount in large model with PIC. > > OK for master? + fprintf (file, "\tmovabsq\t$%s@PLTOFF, %%r11\n", + mcount_name); Please put mcount_name in the same line (and please do the same for case CM_MEDIUM_PIC). OK with the above fixes. Thanks, Uros.
[PATCH] if-to-switch: remove memory leaks
The patch removes some memory leaks spotted by valgrind.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
* gimple-if-to-switch.cc (struct condition_info): Use auto_var.
(if_chain::is_beneficial): Delete clusters
(find_conditions): Make second argument of conditions_in_bbs a
pointer so that we control over it's lifetime.
(pass_if_to_switch::execute): Delete them.
---
gcc/gimple-if-to-switch.cc | 97 ++
1 file changed, 56 insertions(+), 41 deletions(-)
diff --git a/gcc/gimple-if-to-switch.cc b/gcc/gimple-if-to-switch.cc
index 6dba4e2c39c..560753d0311 100644
--- a/gcc/gimple-if-to-switch.cc
+++ b/gcc/gimple-if-to-switch.cc
@@ -59,7 +59,7 @@ using namespace tree_switch_conversion;
struct condition_info
{
- typedef vec> mapping_vec;
+ typedef auto_vec> mapping_vec;
condition_info (gcond *cond): m_cond (cond), m_bb (gimple_bb (cond)),
m_forwarder_bb (NULL), m_ranges (), m_true_edge (NULL), m_false_edge
(NULL),
@@ -75,7 +75,7 @@ struct condition_info
gcond *m_cond;
basic_block m_bb;
basic_block m_forwarder_bb;
- vec m_ranges;
+ auto_vec m_ranges;
edge m_true_edge;
edge m_false_edge;
mapping_vec m_true_edge_phi_mapping;
@@ -253,6 +253,10 @@ if_chain::is_beneficial ()
r = output.length () < filtered_clusters.length ();
if (r)
dump_clusters (, "BT can be built");
+
+ for (unsigned i = 0; i < output.length (); i++)
+delete output[i];
+
output.release ();
return r;
}
@@ -377,7 +381,7 @@ convert_if_conditions_to_switch (if_chain *chain)
static void
find_conditions (basic_block bb,
-hash_map *conditions_in_bbs)
+hash_map *conditions_in_bbs)
{
gimple_stmt_iterator gsi = gsi_last_nondebug_bb (bb);
if (gsi_end_p (gsi))
@@ -394,7 +398,7 @@ find_conditions (basic_block bb,
tree rhs = gimple_cond_rhs (cond);
tree_code code = gimple_cond_code (cond);
- condition_info info (cond);
+ condition_info *info = new condition_info (cond);
gassign *def;
if (code == NE_EXPR
@@ -405,49 +409,53 @@ find_conditions (basic_block bb,
enum tree_code rhs_code = gimple_assign_rhs_code (def);
if (rhs_code == BIT_IOR_EXPR)
{
- info.m_ranges.safe_grow (2, true);
- init_range_entry (_ranges[0], gimple_assign_rhs1 (def), NULL);
- init_range_entry (_ranges[1], gimple_assign_rhs2 (def), NULL);
+ info->m_ranges.safe_grow (2, true);
+ init_range_entry (>m_ranges[0], gimple_assign_rhs1 (def), NULL);
+ init_range_entry (>m_ranges[1], gimple_assign_rhs2 (def), NULL);
}
}
else
{
- info.m_ranges.safe_grow (1, true);
- init_range_entry (_ranges[0], NULL_TREE, cond);
+ info->m_ranges.safe_grow (1, true);
+ init_range_entry (>m_ranges[0], NULL_TREE, cond);
}
/* All identified ranges must have equal expression and IN_P flag. */
- if (!info.m_ranges.is_empty ())
+ if (!info->m_ranges.is_empty ())
{
edge true_edge, false_edge;
- tree expr = info.m_ranges[0].exp;
- bool in_p = info.m_ranges[0].in_p;
+ tree expr = info->m_ranges[0].exp;
+ bool in_p = info->m_ranges[0].in_p;
extract_true_false_edges_from_block (bb, _edge, _edge);
- info.m_true_edge = in_p ? true_edge : false_edge;
- info.m_false_edge = in_p ? false_edge : true_edge;
-
- for (unsigned i = 0; i < info.m_ranges.length (); ++i)
- if (info.m_ranges[i].exp == NULL_TREE
- || !INTEGRAL_TYPE_P (TREE_TYPE (info.m_ranges[i].exp))
- || info.m_ranges[i].low == NULL_TREE
- || info.m_ranges[i].high == NULL_TREE
- || (TYPE_PRECISION (TREE_TYPE (info.m_ranges[i].low))
- != TYPE_PRECISION (TREE_TYPE (info.m_ranges[i].high
- return;
-
- for (unsigned i = 1; i < info.m_ranges.length (); ++i)
- if (info.m_ranges[i].exp != expr
- || info.m_ranges[i].in_p != in_p)
- return;
-
- info.record_phi_mapping (info.m_true_edge,
- _true_edge_phi_mapping);
- info.record_phi_mapping (info.m_false_edge,
- _false_edge_phi_mapping);
+ info->m_true_edge = in_p ? true_edge : false_edge;
+ info->m_false_edge = in_p ? false_edge : true_edge;
+
+ for (unsigned i = 0; i < info->m_ranges.length (); ++i)
+ if (info->m_ranges[i].exp == NULL_TREE
+ || !INTEGRAL_TYPE_P (TREE_TYPE (info->m_ranges[i].exp))
+ || info->m_ranges[i].low == NULL_TREE
+ || info->m_ranges[i].high == NULL_TREE
+ || (TYPE_PRECISION (TREE_TYPE (info->m_ranges[i].low))
+ != TYPE_PRECISION (TREE_TYPE (info->m_ranges[i].high
+ goto exit;
+
+ for (unsigned i = 1; i < info->m_ranges.length (); ++i)
+ if (info->m_ranges[i].exp != expr
+ ||
Re: [PATCH] testsuite: Fix test failures from outputs.exp [PR98225]
On Thu, Jan 7, 2021 at 5:18 PM Bernd Edlinger wrote:
>
> Hi,
>
> On 1/7/21 5:12 PM, Rainer Orth wrote:
> > The unsetenv needs to be wrapped in
> >
> > if [info exists env(MAKEFLAGS)] {
> >
>
> Done.
>
> > @@ -163,6 +167,9 @@ proc outest { test sources opts dirs out
> > if { $ogl != {} } {
> > pass "$test: $d$o"
> > file delete $ogl
> > + } elseif { [string match "*.ld1_args" $o] } {
> > + # This file may be missing if !HAVE_GNU_LD
> > + pass "$test: $d$o"
> >
> > Always PASSing the test even if it isn't run is wrong. Either wrap
> > the whole group of tests with response files in
> >
> > if [check_effective_target_gld] {
> >
> > or make the test for the *.ld1_args file conditional on that
> > (e.g. along the lines of $ltop used elsewhere). I'd welcome input
> > from Alexandre which is preferred.
> >
>
> Ah, yes that is a good idea. Thanks.
>
>
> I think the .cdtor.* handling, is probably a bad example that I followed here.
> I don't know why that is there in the first place, as there
> are no C++ test cases, these files should not be created at all.
> If they are ever created we would have a couple of other files created
> as well IMHO.
> If there are still missing files in some cases,
> I'd prefer to track these per test case, instead of globally.
>
> Therefore I propose to remove that exception for now.
>
> Is it OK for trunk?
As Alex said, please don't just remove features and functionality if
you don't know why they were added. The history is online in the
mailing list and the repo history.
AIX uses constructors to register EH frames and libgcc has an EH
frame. ctors and dtors can be found in non-C++ code.
Thanks, David
[Bug rtl-optimization/98603] aarch64: ICE in extract_insn (ira) on asm goto with bad constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98603
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek ---
The bug is function.c (instantiate_virtual_regs_in_insn):
if (!check_asm_operands (PATTERN (insn)))
{
error_for_asm (insn, "impossible constraint in %");
/* For asm goto, instead of fixing up all the edges
just clear the template and clear input operands
(asm goto doesn't have any output operands). */
if (JUMP_P (insn))
{
rtx asm_op = extract_asm_operands (PATTERN (insn));
ASM_OPERANDS_TEMPLATE (asm_op) = ggc_strdup ("");
ASM_OPERANDS_INPUT_VEC (asm_op) = rtvec_alloc (0);
ASM_OPERANDS_INPUT_CONSTRAINT_VEC (asm_op) = rtvec_alloc (0);
}
else
delete_insn (insn);
}
As the comment documents, that was correct before support for outputs in asm
goto has been added, but for asm insn with outputs, there are multiple
problems.
One is that extract_asm_operands extracts just one of the ASM_OPERANDS, but
with multiple outputs there can be several, and those need to be handled in
sync.
And the other is that we still keep the incorrectly constrained outputs if any
in the IL.
[Bug tree-optimization/98544] [11 regression] Wrong code generated by tree vectorizer since r11-3917-g28290cb50c7dbf87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544 --- Comment #23 from rguenther at suse dot de --- On January 8, 2021 3:07:48 PM GMT+01:00, "mar...@mpa-garching.mpg.de" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544 > >--- Comment #22 from Martin Reinecke --- >Brilliant, thank you very much for tracking this one down! >My FFT library now works correctly again with all optimizations >enabled, which >is a great relief. The scipy maintainers will be happy that they won't >need to >fiddle with flags depending on gcc versions :) Thanks again for testing and reporting issues before we released GCC 11!
[Bug target/98557] [11 Regression] ICE in insert_operand_rank, at tree-ssa-reassoc.c:367 on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98557 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Martin Liška --- Yes, it should be fixed.
[Bug tree-optimization/98544] [11 regression] Wrong code generated by tree vectorizer since r11-3917-g28290cb50c7dbf87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98544 --- Comment #22 from Martin Reinecke --- Brilliant, thank you very much for tracking this one down! My FFT library now works correctly again with all optimizations enabled, which is a great relief. The scipy maintainers will be happy that they won't need to fiddle with flags depending on gcc versions :)
[Bug lto/83967] LTO removes C functions declared as weak in assembler(depending on files order in linking)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83967 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #17 from Christophe Lyon --- Any chance you can try with a toolchain using binutils-2.35? As I indicated in https://bugs.launchpad.net/gcc-arm-embedded/+bug/1747966 there's a related bug fix in binutils-2.35, but Arm's 2020-q2 toolchain still uses 2.34.50.20200226.
[Bug target/98557] [11 Regression] ICE in insert_operand_rank, at tree-ssa-reassoc.c:367 on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98557 --- Comment #12 from Jakub Jelinek --- So fixed now? clang_delta bugs should be tracked elsewhere.
[Bug c++/96504] [coroutines] Use after free in std::__n4861::coroutine_handle::done()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96504 --- Comment #10 from Iain Sandoe --- (In reply to Jakub Jelinek from comment #9) > Are you going to fix co-ret-17-void-ret-coro.C too? should be done with https://gcc.gnu.org/pipermail/gcc-cvs/2021-January/340327.html (as far as I am aware, having discussed with Jonathan about libstdc++ back ports, we're up to date - it remains to see how many of the open coros PRs I can look at this week, they will most likely also need back porting).
[Bug rtl-optimization/98603] New: aarch64: ICE in extract_insn (ira) on asm goto with bad constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98603
Bug ID: 98603
Summary: aarch64: ICE in extract_insn (ira) on asm goto with
bad constraint
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
$ cat test.c
int a() {
int b, c;
asm goto("" : "=R"(b), "=r"(c) : : : d);
d:
}
$ aarch64-elf-gcc -c test.c
test.c: In function 'a':
test.c:3:3: error: impossible constraint in 'asm'
3 | asm goto("" : "=R"(b), "=r"(c) : : : d);
| ^~~
test.c:5:1: error: unrecognizable insn:
5 | }
| ^
(jump_insn 7 2 8 2 (parallel [
(set (reg:SI 93 [ b ])
(asm_operands:SI ("") ("=R") 0 []
[]
[
(label_ref:DI 8)
] test.c:3))
(set (reg:SI 94 [ c ])
(asm_operands:SI ("") ("=r") 1 []
[]
[
(label_ref:DI 8)
] test.c:3))
]) "test.c":3:3 -1
(nil)
-> 8)
during RTL pass: ira
test.c:5:1: internal compiler error: in extract_insn, at recog.c:2760
0xd574db _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/alecop01/toolchain/src/gcc/gcc/rtl-error.c:108
0xd574fa _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/alecop01/toolchain/src/gcc/gcc/rtl-error.c:116
0xd27455 extract_insn(rtx_insn*)
/home/alecop01/toolchain/src/gcc/gcc/recog.c:2760
0xbb4266 ira
/home/alecop01/toolchain/src/gcc/gcc/ira.c:5423
0xbb4266 execute
/home/alecop01/toolchain/src/gcc/gcc/ira.c:5945
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/98602] Failure to optimise vector “x > -100 ? x : -100” to MAX_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98602
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2021-01-08
--- Comment #1 from Richard Biener ---
Guess we miss folders for this since it is represented as VEC_COND_EXPR from
the start (the testcase only builds with the C++ frontend) and scalar MIN/MAX
are usually detected by phiopt. Ah, fold_cond_expr_with_comparison doesn't
handle adjusted constants:
return = VEC_COND_EXPR < x >= { -99, -99, -99, -99 } , x , { -100,
-100, -100, -100 } > ;
[Bug c++/96504] [coroutines] Use after free in std::__n4861::coroutine_handle::done()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96504 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Are you going to fix co-ret-17-void-ret-coro.C too?
