[Bug fortran/102826] Glibc "--disable-mathvec" configure option fail to disable traces to libmvec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102826 --- Comment #3 from haochen.jiang at intel dot com --- (In reply to Andrew Pinski from comment #2) > math-vector-fortran.h comes from glibc so this is a glibc bug and not a GCC > bug. > installed header files from glibc should match --disable-mathvec . >From my perspective, there maybe bug in glibc. However, in the gfortran config part of gcc, it should not has the finclude part for F951 under all circumstances or there should be some option to control that. This is also a bug I believe.
[Bug tree-optimization/102703] [12 Regression] Dead Code Elimination Regression at -O3 since r12-2591-g2e96b5f14e402569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102703 Andrew Pinski changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2021-October ||/581963.html Keywords||patch --- Comment #15 from Andrew Pinski --- Patch series starts here: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581963.html
[Bug tree-optimization/102822] [12 regression] 27_io/ios_base/failure/dual_abi.cc failure after r12-4443
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102822 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- Fixed by r12-4486.
[Bug middle-end/102464] Miss optimization for (_Float16) sqrtf ((float) f16)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102464 --- Comment #8 from Hongtao.liu --- (In reply to Richard Biener from comment #3) > There's related optimizations in convert () which should ideally move to > match.pd When i try to mov convert stuffs to match.pd, i find some "mismatch", there's 3 cases 1. math functions are transformed under condition "optimize" 2. math functions are transformed under condition "optimize && flag_unsafe_math_optimizations" 3. math functions are transformed under condition "optimize && flag_unsafe_math_optimizations flag_errno_maths" And for logb, it's case 1, which means it can be transformed w/o !flag_errno_maths, but according to DEF_C99_BUILTIN(BUILT_IN_LOGB, "logb", BT_FN_DOUBLE_DOUBLE, ATTR_MATHFN_FPROUNDING_ERRNO), !flag_errno_maths is needed and the transformation will be prevented by gimple-match-head.c：maybe_push_res_to_seq /* We can't and should not emit calls to non-const functions. */ if (!(flags_from_decl_or_type (decl) & ECF_CONST)) return NULL; /* fabsl (extend(x)) -> extend(fabsf(x)), etc., if x is a float. */ (for froms (BUILT_IN_FABS BUILT_IN_FABSL BUILT_IN_LOGB BUILT_IN_LOGBL) tos (BUILT_IN_FABSF BUILT_IN_FABSF BUILT_IN_LOGBF BUILT_IN_LOGBF) (simplify (froms (convert float_value_p@0)) (if (optimize && canonicalize_math_p () && mathfn_built_in (TREE_TYPE (@0), froms)) (convert (tos @0)
[Bug fortran/102826] Glibc "--disable-mathvec" configure option fail to disable traces to libmvec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102826 Andrew Pinski changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- math-vector-fortran.h comes from glibc so this is a glibc bug and not a GCC bug. installed header files from glibc should match --disable-mathvec .
[Bug fortran/102826] Glibc "--disable-mathvec" configure option fail to disable traces to libmvec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102826 --- Comment #1 from Andrew Pinski --- Isn't this a bug in glibc and not gcc. Gcc is doing what glibc header file is telling it can be done.
[Bug fortran/102826] New: Glibc "--disable-mathvec" configure option fail to disable traces to libmvec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102826
Bug ID: 102826
Summary: Glibc "--disable-mathvec" configure option fail to
disable traces to libmvec
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: haochen.jiang at intel dot com
Target Milestone: ---
When I build Glibc with "--disable-mathvec" and run through this simple
testcase:
program test_overloaded_intrinsic
real(4) :: x4(3200), y4(3200)
real(8) :: x8(3200), y8(3200)
y4 = sin(x4)
print *, y4
end
It reports error: undefined reference to `_ZGVeN8v_sin'
It is trying to find libmvec functions, while because of the disabling,
libmvec.so will not be generated.
When I go through gcc file. In gcc/config/gnu-user.h Line 156, we have:
#undef TARGET_F951_OPTIONS
#define TARGET_F951_OPTIONS "%{!nostdinc:\
%:fortran-preinclude-file(-fpre-include= math-vector-fortran.h finclude%s/)}"
, which is maybe the cause of the error. Because when I clear that
math-vector-fortran.h, the testcase will pass.
[Bug libstdc++/102825] std::move_only_function's implementation breaking existing code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102825
--- Comment #1 from 康桓瑋 ---
(In reply to 康桓瑋 from comment #0)
> mofunc_impl.h#L111:
>
> : _Mofunc_base(nullptr), _M_invoke(&_S_invoke<_Tp>)
>
> _Mofunc_basede does not have a constructor which accepts a nullptr.
>
> #include
> https://godbolt.org/z/59T4obz4j
gcc test:
#include
struct F {
F(std::initializer_list);
void operator()() const;
};
int main() {
std::move_only_function f(std::in_place_type, {0});
}
https://godbolt.org/z/8qsEqbh9s
[Bug libstdc++/102825] New: std::move_only_function's implementation breaking existing code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102825 Bug ID: 102825 Summary: std::move_only_function's implementation breaking existing code Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: --- mofunc_impl.h#L111: : _Mofunc_base(nullptr), _M_invoke(&_S_invoke<_Tp>) _Mofunc_basede does not have a constructor which accepts a nullptr. #include https://godbolt.org/z/59T4obz4j
[Bug target/102812] Unoptimal (and wrong) code for _Float16 insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102812 --- Comment #1 from Hongtao.liu --- ix86_get_ssemov needs to be updated for V8HF/V16HF since they cound be existed under TARGET_SSE2/TARGET_AVX.
[Bug jit/102824] New: building pdf/dvi documentation for libgccjit fails on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102824 Bug ID: 102824 Summary: building pdf/dvi documentation for libgccjit fails on darwin Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: egallager at gcc dot gnu.org CC: iains at gcc dot gnu.org Target Milestone: --- Build: darwin Running `make pdf` fails in gcc/jit for me with the following error: !pdfTeX error: pdfetex: cannot find image file libgccjit-figures/sum-of-squares 1. ==> Fatal error occurred, no output PDF file produced! /opt/iains/x86_64-apple-darwin19/gcc-7-5-toolchain/bin/texi2dvi: pdfetex exited with bad status, quitting. make[2]: *** [../../gcc/jit/Make-lang.in:283: doc/libgccjit.pdf] Error 1 make[2]: Leaving directory '/Users/ericgallager/gcc_newgit/abcdefghijklmnopqrstuvwxyz_01234567890.build/gcc' make[1]: *** [Makefile:5361: pdf-gcc] Error 1 make[1]: Leaving directory '/Users/ericgallager/gcc_newgit/abcdefghijklmnopqrstuvwxyz_01234567890.build' make: *** [Makefile:1280: do-pdf] Error 2 I also got a similar error with `make dvi`, the full log for which can be found here: https://github.com/cooljeanius/gcc_bugs/blob/master/doc_logs/libgccjit.log (I originally reported this on IRC while testing a patch for bug 102663)
[Bug classpath/39747] Installation documentation should suggest building libgmp as PIC for building with libjava
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747 Eric Gallager changed: What|Removed |Added Keywords||documentation CC||egallager at gcc dot gnu.org --- Comment #8 from Eric Gallager --- Is this still relevant now that gcc no longer ships with java?
[Bug other/102663] add an install-dvi Makefile target to the toplevel Makefile and all subdirectories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102663 Eric Gallager changed: What|Removed |Added URL|https://gcc.gnu.org/legacy- |https://gcc.gnu.org/piperma |ml/gcc-patches/2016-10/msg0 |il/gcc-patches/2021-October |0380.html |/581960.html Assignee|marxin at gcc dot gnu.org |egallager at gcc dot gnu.org --- Comment #5 from Eric Gallager --- (In reply to Eric Gallager from comment #4) > (In reply to Martin Liška from comment #3) > > I would install the patch for now. > > OK, I'll need to regenerate it and re-test it first... OK, regenerated and re-tested; new patch is here: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581960.html I'm going to self-assign this since I've been working on it.
[Bug tree-optimization/102822] [12 regression] 27_io/ios_base/failure/dual_abi.cc failure after r12-4443
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102822 Bug 102822 depends on bug 102796, which changed state. Bug 102796 Summary: [12 Regresson] ICE in useless_type_conversion_p at gcc/gimple-expr.c:87 since r12-4443-g93ac832f1846e4867aa6537f76f510fab8e3e87d https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102796 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/102796] [12 Regresson] ICE in useless_type_conversion_p at gcc/gimple-expr.c:87 since r12-4443-g93ac832f1846e4867aa6537f76f510fab8e3e87d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102796 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Andrew Macleod --- Should be fixed.
[Bug c/88727] Diagnostics improvement: Detection of undefined behaviour. Incomplete type in tenative definition with internal linkage. [-Wtentative-definition-incomplete-type]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88727 Joseph S. Myers changed: What|Removed |Added CC||pavel.morozkin at gmail dot com --- Comment #3 from Joseph S. Myers --- *** Bug 102821 has been marked as a duplicate of this bug. ***
[Bug c/102821] Tentative definition of variable with internal linkage has incomplete non-array type: missing diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102821 Joseph S. Myers changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Joseph S. Myers --- This is in a Semantics section of the standard, not Constraints, so no diagnostic is required, but as a quality-of-implementation matter we should diagnose it. *** This bug has been marked as a duplicate of bug 88727 ***
[Bug tree-optimization/102796] [12 Regresson] ICE in useless_type_conversion_p at gcc/gimple-expr.c:87 since r12-4443-g93ac832f1846e4867aa6537f76f510fab8e3e87d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102796 --- Comment #8 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:4d92a69fc5882c86aab63d52382b393d4f20b3ed commit r12-4486-g4d92a69fc5882c86aab63d52382b393d4f20b3ed Author: Andrew MacLeod Date: Mon Oct 18 13:52:18 2021 -0400 Process EH edges again and call get_tree_range on non gimple_range_ssa_p names. PR tree-optimization/102796 gcc/ * gimple-range.cc (gimple_ranger::range_on_edge): Process EH edges normally. Return get_tree_range for non gimple_range_ssa_p names. (gimple_ranger::range_of_stmt): Use get_tree_range for non gimple_range_ssa_p names. gcc/testsuite/ * g++.dg/pr102796.C: New.
[Bug fortran/102787] ICE in new test case gfortran.dg/reshape_shape_2.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102787
--- Comment #6 from anlauf at gcc dot gnu.org ---
WIP patch that fixes comment#5 as like comment#0 and regtests cleanly:
diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index 6552eaf3b0c..e1ab2e06fdb 100644
--- a/gcc/fortran/array.c
+++ b/gcc/fortran/array.c
@@ -1812,6 +1812,29 @@ expand_constructor (gfc_constructor_base base)
continue;
}
+ /* Expand constant array within array constructor. */
+ if (e->expr_type == EXPR_VARIABLE && e->rank && e->ref
+ && e->symtree && e->symtree->n.sym
+ && e->symtree->n.sym->attr.flavor == FL_PARAMETER
+ && e->symtree->n.sym->value
+ && e->symtree->n.sym->value->value.constructor)
+ {
+ gfc_ref *ref;
+ for (ref = e->ref; ref; ref = ref->next)
+ if (ref->type == REF_ARRAY)
+ break;
+
+ if (ref && ref->u.ar.as && ref->u.ar.as->type == AS_EXPLICIT
+ && ref->u.ar.type == AR_FULL)
+ {
+ gfc_expr *value = e->symtree->n.sym->value;
+ if (!expand_constructor (value->value.constructor))
+ return false;
+
+ continue;
+ }
+ }
+
empty_constructor = false;
e = gfc_copy_expr (e);
if (!gfc_simplify_expr (e, 1))
It only lacks goodies such as array sections in the constructor.
[Bug target/102783] [powerpc] FPSCR manipulations cannot be relied upon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102783 --- Comment #6 from joseph at codesourcery dot com --- Generically (and if the command-line options are such that floating-point control / status bits are to be respected by optimizations), *any* function call might access or modify floating-point control and status bits, subject to e.g. const functions not being able to access them, pure functions not being able to modify them, functions whose body is known having properties based on analysis of that body, built-in functions having semantics based on what the compiler knows about those functions. And then a subset of asms may similarly access or modify them (based on inputs / outputs / clobbers, but maybe on some architectures existing practice doesn't provide a register name that inputs / outputs / clobbers can use to refer to floating-point state). Then you'd need something like Marc Glisse's -ffenv-access patches (August 2020) to represent the other side of things, how floating-point operations also access / modify such bits.
[Bug c/102821] Tentative definition of variable with internal linkage has incomplete non-array type: missing diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102821 --- Comment #2 from Pavel M --- Addition to "Notes" above. 3. C11, 5.1.1.3 Diagnostics, 1: > A conforming implementation shall produce at least one diagnostic message > (identified in an implementation-defined manner) if a preprocessing > translation unit or translation unit contains a violation of any syntax rule > or constraint, even if the behavior is also explicitly specified as undefined > or implementation-defined.
[Bug target/102811] vcvtph2ps and vcvtps2ph should be used to convert _Float16 to SFmode with -mf16c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Severity|normal |enhancement
[Bug tree-optimization/102329] [11/12 Regression] pointer "maybe uninitialized" right after assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102329 Andrew Pinski changed: What|Removed |Added Summary|pointer "maybe |[11/12 Regression] pointer |uninitialized" right after |"maybe uninitialized" right |assignment |after assignment Target Milestone|--- |11.3 --- Comment #8 from Andrew Pinski --- There might be another bug referencing the same.
[Bug c++/102804] [9/10/11/12 Regression] template matching fails w/ false ambiguity on ternary expressions with enums class defined with unsigned typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102804 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org Target Milestone|--- |9.5 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=82307
[Bug tree-optimization/102814] [12 regression] quadratique/exponential time complexity for max-jump-thread-duplication-stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102814 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Keywords||compile-time-hog CC||aldyh at gcc dot gnu.org, ||pinskia at gcc dot gnu.org
[Bug target/102761] [10/11/12 Regression] ICE with -O1 and above: in ix86_print_operand_address_as due to %a0 and if_then_else and X constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102761 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:e9c3a7243bf7a4db9b0dec44d278e9bf527f3d9b commit r11-9171-ge9c3a7243bf7a4db9b0dec44d278e9bf527f3d9b Author: Uros Bizjak Date: Mon Oct 18 17:03:28 2021 +0200 i386: Fix ICE in ix86_print_opreand_address [PR 102761] 2021-10-18 Uroš Bizjak PR target/102761 gcc/ChangeLog: * config/i386/i386.c (ix86_print_operand_address): Error out for non-address_operand asm operands. gcc/testsuite/ChangeLog: * gcc.target/i386/pr102761.c: New test.
[Bug middle-end/102823] [11/12 Regression] glm-0.9.9.8 fails on gcc-11 and above (-fno-strict-aliasing)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102823 --- Comment #1 from Andrew Pinski --- Hmm: *reinterpret_cast::type, Q> const *>() That seems like it could be a violation of C/C++ aliasing rules. This is in: template static glm::vec bitCount_bitfield(glm::vec const& v)
[Bug tree-optimization/102796] [12 Regresson] ICE in useless_type_conversion_p at gcc/gimple-expr.c:87 since r12-4443-g93ac832f1846e4867aa6537f76f510fab8e3e87d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102796 --- Comment #7 from H.J. Lu --- (In reply to Andrew Macleod from comment #6) > Created attachment 51624 [details] > Allow EDGE_EH edges to be processed > > range_on_edge needs to continue processing EDGE_EH.. > See if this fixes all the problems. It results ina lot of UNDEFINED values > which caused no end of issues. > Its currently running through tests. If it works, please remove "or EH" from comments.
[Bug middle-end/102823] [11/12 Regression] glm-0.9.9.8 fails on gcc-11 and above (-fno-strict-aliasing)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102823 Andrew Pinski changed: What|Removed |Added Summary|glm-0.9.9.8 fails on gcc-11 |[11/12 Regression] |and above |glm-0.9.9.8 fails on gcc-11 |(-fno-strict-aliasing) |and above ||(-fno-strict-aliasing) Target Milestone|--- |11.3
[Bug c++/102823] New: glm-0.9.9.8 fails on gcc-11 and above (-fno-strict-aliasing)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102823 Bug ID: 102823 Summary: glm-0.9.9.8 fails on gcc-11 and above (-fno-strict-aliasing) Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: slyfox at gcc dot gnu.org Target Milestone: --- Created attachment 51626 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51626=edit z.tar.gz On gcc-10 glm test suite worked successfully. On gcc-11 single test fails as: glm> The following tests FAILED: glm> 39 - test-core_func_integer (Failed) I extracted self-contained example that hopefully illustrates the problem: $ g++-10 -I. -O2 core_func_integer.cpp -o a && ./a; echo $? 0 $ g++-11 -I. -O2 core_func_integer.cpp -o a && ./a; echo $? 4 $ g++-12 -I. -O2 core_func_integer.cpp -o a && ./a; echo $? 4 Adding -fno-strict-aliasing makes the test pass. Can you help me understand where alaising violation happens? I tried adding -fopt-info, but there is not much difference in the output.
[Bug tree-optimization/102822] [12 regression] 27_io/ios_base/failure/dual_abi.cc failure after r12-4443
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102822 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-10-18 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102796 Depends on||102796 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Most likely will be fixed with the patch attached to PR 102796. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102796 [Bug 102796] [12 Regresson] ICE in useless_type_conversion_p at gcc/gimple-expr.c:87 since r12-4443-g93ac832f1846e4867aa6537f76f510fab8e3e87d
[Bug tree-optimization/102822] [12 regression] 27_io/ios_base/failure/dual_abi.cc failure after r12-4443
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102822 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |12.0 Component|other |tree-optimization
[Bug other/102822] New: [12 regression] 27_io/ios_base/failure/dual_abi.cc failure after r12-4443
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102822
Bug ID: 102822
Summary: [12 regression] 27_io/ios_base/failure/dual_abi.cc
failure after r12-4443
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: seurer at gcc dot gnu.org
Target Milestone: ---
g:93ac832f1846e4867aa6537f76f510fab8e3e87d, r12-4443
make -k check RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'
conformance.exp=27_io/ios_base/failure/dual_abi.cc"
FAIL: 27_io/ios_base/failure/dual_abi.cc execution test
FAIL: 27_io/ios_base/failure/dual_abi.cc execution test
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/27_io/ios_base/failure/dual_abi.cc:52:
void test01(): Assertion 'caught_ios_failure' failed.
FAIL: 27_io/ios_base/failure/dual_abi.cc execution test
commit 93ac832f1846e4867aa6537f76f510fab8e3e87d
Author: Andrew MacLeod
Date: Thu Oct 7 10:12:29 2021 -0400
Ranger : Do not process abnormal ssa-names.
[Bug c/102821] Tentative definition of variable with internal linkage has incomplete non-array type: missing diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102821 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-10-18 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c/102821] New: Tentative definition of variable with internal linkage has incomplete non-array type: missing diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102821
Bug ID: 102821
Summary: Tentative definition of variable with internal linkage
has incomplete non-array type: missing diagnostics
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pavel.morozkin at gmail dot com
Target Milestone: ---
Sample code (t940.c):
static struct s foo;
static struct s {int a;} foo;
Invocation:
$ gcc t940.c -c -std=c11 -pedantic -Wall -Wextra -Wno-unused-variable
Expected diagnostics:
t940.c:1:17: warning: tentative definition of variable with internal linkage
has incomplete non-array type 'struct s'
[-Wtentative-definition-incomplete-type]
Actual diagnostics:
Notes:
1. C11, 6.9.2 External object definitions, 3:
> If the declaration of an identifier for an object is a tentative definition
> and has internal linkage, the declared type shall not be an incomplete type.
2. C11, 4. Conformance, 1:
> In this International Standard, ‘‘shall’’ is to be interpreted as a
> requirement on an implementation or on a program; conversely, ‘‘shall not’’
> is to be interpreted as a prohibition.
[Bug tree-optimization/102819] [11/12 Regression] IFN_COMPLEX_MUL matches things that it shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819 Tamar Christina changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-10-18 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |tnfchris at gcc dot gnu.org --- Comment #1 from Tamar Christina --- bad3 is fixed already by my local patch set, I will fix bad1 and bad2 next week and cleanup a bit and make a patch for backport. > (If we don't currently check that the SUB node has the same children as the ADD node then perhaps we should check that too. Now that we have general VEC_PERM_EXPR nodes, the children could in principle be different.) Already done in the new patches.
[Bug c++/102820] Failure to compile void{}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102820 Marek Polacek changed: What|Removed |Added Last reconfirmed||2021-10-18 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/102820] New: Failure to compile void{}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102820
Bug ID: 102820
Summary: Failure to compile void{}
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
void f()
{
void{};
}
This has been considered valid since
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#2351 was accepted
as a DR in 2018, but GCC fails to compile it, with this error:
: In function 'void f()':
:3:10: error: compound literal of non-object type 'void'
3 | void{};
| ^
[Bug c++/92909] [8/9/10 Regression] ICE on incorrect lambda inside variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92909 --- Comment #8 from Patrick Palka --- *** Bug 92911 has been marked as a duplicate of this bug. ***
[Bug c++/92911] Valid lambda inside variadic template does not compile (2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92911 Patrick Palka changed: What|Removed |Added Resolution|--- |DUPLICATE CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED --- Comment #3 from Patrick Palka --- dup *** This bug has been marked as a duplicate of bug 92909 ***
[Bug c++/94310] using constructor inheritance breaks the code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94310 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED CC||ppalka at gcc dot gnu.org Target Milestone|--- |11.0 --- Comment #4 from Patrick Palka --- This looks fixed in GCC 11/12, ever since r11-6942
[Bug tree-optimization/102819] New: [11/12 Regression] IFN_COMPLEX_MUL matches things that it shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102819 Bug ID: 102819 Summary: [11/12 Regression] IFN_COMPLEX_MUL matches things that it shouldn't Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rsandifo at gcc dot gnu.org CC: tnfchris at gcc dot gnu.org Target Milestone: --- Created attachment 51625 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51625=edit Examples of correct and incorrect matches complex_mul_pattern::matches() seems to accept too much. IIUC, for the non-conjugate case, it matches if: * the root is an interleaving of a SUB node and an ADD node * the children of the ADD node are two multiplications * the left-hand multiplication includes an EVEN/EVEN permute (i.e. multiplication by real) However, for the non-conjugate case, there don't seem to be any checks for the contents of the right-hand multiplication or how they match up with the left-hand multiplication. The later code then drops one child of this right-hand node. (If we don't currently check that the SUB node has the same children as the ADD node then perhaps we should check that too. Now that we have general VEC_PERM_EXPR nodes, the children could in principle be different.) With -O3 -march=armv8.2-a+sve, all of the functions in the attached test are recognised as complex multiplications, even though only good1 and good2 really are. There are quite a few other cases in which we incorrectly match a COMPLEX_MUL but then bail out due to: Built SLP cancelled: all SLP instances support load/store-lanes (Perhaps we should have a --param to disable that load/store-lanes check?)
[Bug fortran/102818] New: ICE in gfc_resolve_formal_arglist, at fortran/resolve.c:282
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102818 Bug ID: 102818 Summary: ICE in gfc_resolve_formal_arglist, at fortran/resolve.c:282 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- The following error message always shows the symbol name 'ppr@'. Finally found a case with ICE, seems to be older than r5. $ cat z1.f90 module m type t contains procedure :: f end type contains integer function f() procedure(real), pointer :: f end end $ cat z2.f90 # no ICE, same error module m type t contains procedure, nopass :: f end type contains integer function f() procedure(real), pointer :: f end end $ gfortran-12-20211017 -c z1.f90 z1.f90:8:35: 8 | procedure(real), pointer :: f | 1 Error: Symbol 'ppr@' at (1) already has basic type of INTEGER f951: internal compiler error: Segmentation fault 0xeed8df crash_signal ../../gcc/toplev.c:322 0x857700 gfc_resolve_formal_arglist(gfc_symbol*) ../../gcc/fortran/resolve.c:282 0x873672 do_traverse_symtree ../../gcc/fortran/symbol.c:4171 0x8579e3 resolve_formal_arglists ../../gcc/fortran/resolve.c:563 0x8579e3 resolve_contained_functions ../../gcc/fortran/resolve.c:1147 0x8579e3 resolve_types ../../gcc/fortran/resolve.c:17419 0x85307c gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17545 0x83b1c2 gfc_parse_file() ../../gcc/fortran/parse.c:6721 0x8891bf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/102817] [12 Regression] ICE in gfc_clear_shape, at fortran/expr.c:422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102817 G. Steinmetz changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from G. Steinmetz --- This variant still works : $ cat z2.f90 program p type t integer :: a(1,2) = 3 end type type(t), parameter :: x(1) = t(4) integer :: y(1,2) y = x(1)%a print *, y end $ gfortran-12-20211017 z2.f90 && ./a.out 4 4 $
[Bug fortran/102817] New: [12 Regression] ICE in gfc_clear_shape, at fortran/expr.c:422
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102817 Bug ID: 102817 Summary: [12 Regression] ICE in gfc_clear_shape, at fortran/expr.c:422 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started between 20211003 and 20211010 : $ cat z1.f90 program p type t integer :: a(1,2) = 3 end type type(t), parameter :: x(1) = t(4) integer :: y(1,2) y = (x(1)%a) print *, y end $ gfortran-12-20211003 -c z1.f90 $ $ gfortran-12-20211017 -c z1.f90 f951: internal compiler error: Segmentation fault 0xd47e4f crash_signal ../../gcc/toplev.c:322 0x798d1b gfc_clear_shape(__mpz_struct (*) [1], int) ../../gcc/fortran/expr.c:422 0x798d1b gfc_free_shape(__mpz_struct (**) [1], int) ../../gcc/fortran/expr.c:432 0x798e3d free_expr0 ../../gcc/fortran/expr.c:513 0x798ff0 gfc_replace_expr(gfc_expr*, gfc_expr*) ../../gcc/fortran/expr.c:626 0x79c768 simplify_const_ref ../../gcc/fortran/expr.c:1999 0x79ce5e gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.c:2312 0x79d0ab simplify_parameter_variable ../../gcc/fortran/expr.c:2141 0x79ce2d gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.c:2279 0x79c9a6 simplify_intrinsic_op ../../gcc/fortran/expr.c:1188 0x79c9a6 gfc_simplify_expr(gfc_expr*, int) ../../gcc/fortran/expr.c:2268 0x80bb79 resolve_operator ../../gcc/fortran/resolve.c:4470 0x80807f gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7136 0x810aa4 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:11806 0x810aa4 gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11908 0x812097 resolve_codes ../../gcc/fortran/resolve.c:17512 0x81215e gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:17547 0x7fa494 resolve_all_program_units ../../gcc/fortran/parse.c:6519 0x7fa494 gfc_parse_file() ../../gcc/fortran/parse.c:6771 0x8476bf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/102816] New: [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102816 Bug ID: 102816 Summary: [12 Regression] ICE in resolve_structure_cons, at fortran/resolve.c:1467 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started between 20211010 and 20211017 : $ cat z1.f90 program p type t integer :: a([2]) end type type(t) :: x = t([3, 4]) end $ gfortran-12-20211017 -c z1.f90 f951: internal compiler error: in resolve_structure_cons, at fortran/resolve.c:1467 0x81a894 resolve_structure_cons ../../gcc/fortran/resolve.c:1466 0x80a31c resolve_generic_f ../../gcc/fortran/resolve.c:2799 0x80a31c resolve_function ../../gcc/fortran/resolve.c:3301 0x80a31c gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7143 0x79c024 gfc_reduce_init_expr(gfc_expr*) ../../gcc/fortran/expr.c:3125 0x79f290 gfc_match_init_expr(gfc_expr**) ../../gcc/fortran/expr.c:3173 0x789a04 variable_decl ../../gcc/fortran/decl.c:3019 0x789a04 gfc_match_data_decl() ../../gcc/fortran/decl.c:6328 0x7f2d63 match_word ../../gcc/fortran/parse.c:67 0x7f2d63 decode_statement ../../gcc/fortran/parse.c:378 0x7f47aa next_free ../../gcc/fortran/parse.c:1388 0x7f47aa next_statement ../../gcc/fortran/parse.c:1620 0x7f5ecb parse_spec ../../gcc/fortran/parse.c:4159 0x7f8c9c parse_progunit ../../gcc/fortran/parse.c:6125 0x7fa421 gfc_parse_file() ../../gcc/fortran/parse.c: 0x8476bf gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug tree-optimization/102796] [12 Regresson] ICE in useless_type_conversion_p at gcc/gimple-expr.c:87 since r12-4443-g93ac832f1846e4867aa6537f76f510fab8e3e87d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102796 Andrew Macleod changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |amacleod at redhat dot com --- Comment #6 from Andrew Macleod --- Created attachment 51624 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51624=edit Allow EDGE_EH edges to be processed range_on_edge needs to continue processing EDGE_EH.. See if this fixes all the problems. It results ina lot of UNDEFINED values which caused no end of issues. Its currently running through tests.
[Bug fortran/102815] New: gfortran.dg/bind-c-contiguous-5.f90 fails at execution on armeb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102815 Bug ID: 102815 Summary: gfortran.dg/bind-c-contiguous-5.f90 fails at execution on armeb Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: clyon at gcc dot gnu.org Target Milestone: --- The new test gfortran.dg/bind-c-contiguous-5.f90 fails on armeb (arm big-endian), such as armeb-linux-gnueabihf: The output contains: At line 928 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_assumed_size_f' At line 928 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_assumed_size_f' At line 928 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_assumed_size_f' abcghinop defghijlm At line 946 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_assumed_size_in_f' At line 946 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_assumed_size_in_f' At line 946 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_assumed_size_in_f' abcghinop defghijlm At line 965 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_expl_size_f' At line 965 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_expl_size_f' At line 965 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_expl_size_f' abcghinop defghijlm At line 983 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_expl_size_in_f' At line 983 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_expl_size_in_f' At line 983 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_expl_size_in_f' abcghinop defghijlm abcghinop abcghinop abcghinop defghijlm defghijlm defghijlm abcghinop abcghinop abcghinop defghijlm defghijlm defghijlm At line 1039 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_assumed_rank_cont_f' At line 1039 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_assumed_rank_cont_f' At line 1039 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_assumed_rank_cont_f' abcghinop abcghinop abcghinop defghijlm defghijlm defghijlm At line 1057 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_assumed_rank_cont_in_f' At line 1057 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_assumed_rank_cont_in_f' At line 1057 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_assumed_rank_cont_in_f' abcghinop abcghinop abcghinop defghijlm defghijlm defghijlm abcghinop defghijlm abcghinop defghijlm At line 1113 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'xx' of procedure 'char_assumed_shape_cont_f' At line 1113 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'yy' of procedure 'char_assumed_shape_cont_f' At line 1113 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for argument 'zz' of procedure 'char_assumed_shape_cont_f' abcghinop defghijlm At line 1131 of file /gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 Fortran runtime warning: An array temporary was created for
[Bug tree-optimization/102814] New: [12 regression] quadratique/exponential time complexity for max-jump-thread-duplication-stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102814
Bug ID: 102814
Summary: [12 regression] quadratique/exponential time
complexity for max-jump-thread-duplication-stmts
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dimhen at gmail dot com
Target Milestone: ---
r12-4256 FAST
r12- SLOW
g++ -fpreprocessed -std=c++98 -O2 --param max-jump-thread-duplication-stmts=NNN
-c x.ii
r12-4256 r12-
1800.5s 0.21s
1810.8s > 100s
1901.0s 52s
cat x.ii # cvise'd from proprietary codebase
struct a {
a operator+(int);
};
void *operator new(unsigned long, void *c) { return c; }
struct d {
void h(int *j) { new (j) int(); }
};
struct k {
struct {
int e;
int f;
} g;
};
struct n : k {
a m_fn2();
a o();
int m_fn4();
int operator[](int);
int ae;
void s() {
if (g.e != g.f) {
d l;
int *b;
l.h(b);
}
a m = o();
t(m, ae);
}
template void u(a, af, af);
void t(a, unsigned char);
};
int ah;
struct v {
n w();
};
void x() {
v p;
n ak = p.w(), al, rapdu;
int q(ak.m_fn4());
int r;
for (int i = 0; q; i++) {
if (i == q - 1) {
al.s();
r = ak.m_fn4();
}
al.s();
al.s();
al.s();
al.s();
a am, an = ak.m_fn2(), ao = an + 1, ap = ak.m_fn2(), aq = ap + ah,
ar = aq + r;
al.u(am, ao, ar);
if (i == q - 1)
al.s();
i &[1];
}
}
g++ -v
Using built-in specs.
COLLECT_GCC=/home/dimhen/arch-gcc/gcc_current/bin/g++
COLLECT_LTO_WRAPPER=/home/dimhen/arch-gcc/gcc_current/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
Target: x86_64-pc-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/home/dimhen/arch-gcc/gcc_current
--enable-checking=yes,df,fold,rtl,extra --enable-languages=c,c++,lto
--disable-multilib --enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=native
--enable-libstdcxx-debug
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211015 (experimental) [master r12--ga01704fc45a] (GCC)
[Bug target/102768] [feature request] Add support for aarch64 shadow call stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102768 --- Comment #3 from nsz at gcc dot gnu.org --- well, protection mechanisms are rarely equivalent. neither scs nor traditional stack protector are perfect. to me compiler support for freestanding environments such as linux makes sense. i cannot immediately tell if libc support would work. (android is not a good indicator of what can be done in linux userspace: the android abi is broken between releases while glibc is abi stable, bionic can do hacks in longjmp/setcontext that is not acceptable in glibc and android does not have mixed toolchain issues such as old unwinder tries to unwind across a new binary.)
[Bug objc/102537] Objective-C: can't use >= USE_FIXUP_BEFORE paths on non-Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102537
--- Comment #2 from Matt Jacobson ---
I certainly haven't spent as much time thinking about this as you, but I think
my personal preference would be to add new values to the `flag_objc_abi`
argument. It's already the case that "objc-next-runtime-abi-01.c" supports
both 0 and 1 values; I think it would be reasonable to have
`objc-next-runtime-abi-02.c` support multiple values too. I'd imagine
something like:
2 -- "modern" runtime ABI, pre-SnowLeopard (fixup messages, etc.)
3 -- "modern" runtime ABI, SnowLeopard and later (no fixup messages, weak
protocol metadata
Then the Darwin-target code could (absent an explicit override in the
arguments) select the value for `flag_objc_abi` based on
`-mmacosx-version-min`. And non-Darwin targets could simply default to the
newest ABI (absent an explicit override).
Other versions could be added in the future as support for newer
runtime-ABI-dependent features (e.g., `objc_autoreleasePoolPush()`,
`objc_opt_self()`, `objc_loadWeak()`) is added.
Under this scheme, I think it would make sense to switch `flag_next_runtime` to
being a simple boolean.
===
I think I like this better than using the high byte of `flag_next_runtime`,
which could be cumbersome to build conditionals for. For example, taking your
example of using 0x0100 as the "AVR" platform, a check of whether to use
non-fixup messaging might end up look like:
#define PLATFORM(r) (((r) >> 24) & 0xFF)
#define VERSION(r) ((r) & 0xFF)
if ((PLATFORM(flag_next_runtime) == DARWIN && VERSION(flag_next_runtime) >=
USE_FIXUP_BEFORE)
|| PLATFORM(flag_next_runtime) == AVR)
{ ... }
Yeah, the existing `flag_next_runtime >= USE_FIXUP_BEFORE` would technically
work, but you could imagine other platforms with ID > 0 that want the
pre-USE_FIXUP_BEFORE behavior.
===
> These two were both thoughts during the development but I suspect that the
> mapping to values is a build-time decision and ought to be done in the flags
> override code.
I'd like to understand better what you mean here. Is it that, under the
`flag_objc_abi` scheme I described, the x86_64-Darwin target may want different
logic to select `flag_objc_abi` than the AVR target (for example)? If so then
I agree -- shouldn't that be similar to how the `flag_next_runtime` override is
currently target-dependent? Apologies if I've completely misread that.
[Bug c++/102804] [9/10/11/12 Regression] template matching fails w/ false ambiguity on ternary expressions with enums class defined with unsigned typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102804
--- Comment #7 from Jonathan Wakely ---
Oops, sorry the reduced example was missing the first line.
Fixed, and further reduced:
using int32_t = int;
enum: unsigned int32_t { foo };
int f(int);
int f(unsigned);
auto x = f(1 ? foo : 1);
[Bug c++/102804] [9/10/11/12 Regression] template matching fails w/ false ambiguity on ternary expressions with enums class defined with unsigned typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102804
Jonathan Wakely changed:
What|Removed |Added
Status|RESOLVED|NEW
Summary|template matching fails w/ |[9/10/11/12 Regression]
|false ambiguity on ternary |template matching fails w/
|expressions with enums |false ambiguity on ternary
|class defined with unsigned |expressions with enums
|typdef |class defined with unsigned
||typedef
CC||mukesh.kapoor at oracle dot com
Resolution|INVALID |---
Known to work||7.4.0
Last reconfirmed||2021-10-18
Ever confirmed|0 |1
Keywords||rejects-valid
Known to fail||8.1.0
--- Comment #6 from Jonathan Wakely ---
This is a bug, we should either reject 'unsigned int32_t' immediately (which we
only do with -pedantic-errors) or we should accept it and treat it consistently
as unsigned int.
Reduced:
enum: unsigned int32_t { FOO, BAR } foobar = FOO;
int f(int);
int f(unsigned);
auto x = f(1 ? foobar : 13);
With r254043 we just have a pedwarn:
102804.C:2:16: warning: long, short, signed or unsigned used invalidly for
'type name' [-Wpedantic]
enum: unsigned int32_t { FOO, BAR } foobar = FOO;
^~~
With r254046 we get the error:
102804.C:2:16: warning: long, short, signed or unsigned used invalidly for
'type name' [-Wpedantic]
enum: unsigned int32_t { FOO, BAR } foobar = FOO;
^~~
102804.C:5:27: error: call of overloaded 'f(unsigned int)' is ambiguous
auto x = f(1 ? foobar : 13);
^
102804.C:3:5: note: candidate: 'int f(int)'
int f(int);
^
102804.C:4:5: note: candidate: 'int f(unsigned int)'
int f(unsigned);
^
re PR c++/82307 (unscoped enum-base incorrect cast)
/cp
2017-10-24 Mukesh Kapoor
Paolo Carlini
PR c++/82307
* cvt.c (type_promotes_to): Implement C++17, 7.6/4, about unscoped
enumeration type whose underlying type is fixed.
So it was actually caused by fixing the promotion rules for enums (PR 82307),
not by the handling of 'unsigned' applied to a typedef.
[Bug c++/102804] template matching fails w/ false ambiguity on ternary expressions with enums class defined with unsigned typdef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102804 --- Comment #5 from Todd Rudick --- Richard, is there a way to represent the part of this that is a bug? Presumably accepting the construct but having it break template specialization with an error that can be arbitrarily disconnected from the definition is not a desired behavior. In the production code that I eventually isolated this from, there is in fact no reference at all to the header that contained the enum. Also, it seems likely that the compiler state is bad at that point (?), as the error message indicates an 'unsigned int' ambiguity that doesn't actually exist.
[Bug middle-end/100316] [11/12 Regression] __clear_cache() does not support NULL-pointer arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100316 Kito Cheng changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Kito Cheng --- Fixed are committed to both trunk and gcc-11 branch now :)
[Bug middle-end/100316] [11/12 Regression] __clear_cache() does not support NULL-pointer arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100316
--- Comment #4 from CVS Commits ---
The releases/gcc-11 branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:aa827fa170d3e61d17c3daaf4d5008a3c674a005
commit r11-9170-gaa827fa170d3e61d17c3daaf4d5008a3c674a005
Author: Kito Cheng
Date: Thu Oct 7 16:17:13 2021 +0800
[PR/target 100316] Allow constant address for __builtin___clear_cache.
__builtin___clear_cache was able to accept constant address for the
argument, but it seems no longer accept recently, and it even not
accept constant address which is hold in variable when optimization is
enable:
```
void foo3(){
void *yy = (void*)0x1000;
__builtin___clear_cache(yy, yy);
}
```
So this patch make BEGIN and END accept VOIDmode, like cselib_lookup_mem
did per
Jim Wilson's suggestion.
```
static cselib_val *
cselib_lookup_mem (rtx x, int create)
{
...
addr_mode = GET_MODE (XEXP (x, 0));
if (addr_mode == VOIDmode)
addr_mode = Pmode;
```
Changes v2 -> v3:
- Use gcc_assert rather than error, maybe_emit_call_builtin___clear_cache
is
internal use only, and we already checked the type in other place.
Changes v1 -> v2:
- Check is CONST_INT intead of cehck mode, no new testcase, since
constant value with other type like CONST_DOUBLE will catched by
front-end.
e.g.
Code:
```c
void foo(){
__builtin___clear_cache(1.11, 0);
}
```
Error message:
```
clearcache-double.c: In function 'foo':
clearcache-double.c:2:27: error: incompatible type for argument 1 of
'__builtin___clear_cache'
2 | __builtin___clear_cache(1.11, 0);
| ^~~~
| |
| double
clearcache-double.c:2:27: note: expected 'void *' but argument is of type
'double'
```
gcc/ChangeLog:
PR target/100316
* builtins.c (maybe_emit_call_builtin___clear_cache): Allow
CONST_INT for BEGIN and END, and use gcc_assert rather than
error.
gcc/testsuite/ChangeLog:
PR target/100316
* gcc.c-torture/compile/pr100316.c: New.
(cherry picked from commit 4e5bc4e4506a7ae7bb88fc925a425652a1da6b2d)
[Bug middle-end/102810] [11/12 Regression] Bogus Wstringop-overread passing a smaller array to an array parameter without a bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102810
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2021-10-18
Component|c |middle-end
Summary|Bogus Wstringop-overread|[11/12 Regression] Bogus
|warning when special|Wstringop-overread passing
|(integer) pointer values|a smaller array to an array
|passed to array parameter |parameter without a bound
|of a function |
Status|UNCONFIRMED |NEW
--- Comment #1 from Martin Sebor ---
GCC issues the -Wstringop-xxx warnings in this context only because there isn't
a more appropriate option yet. One should be added.
The warning for argument 2 is a bug. With -Warray-parameter enabled, for the
purposes of out-of-bounds access detection, GCC treats function parameters
declared using the array form (as in void f (int a[2]);) as an indication that
the function expects an array argument with at least as many elements. A bug
in the code applies the same logic to an array parameter declared with no
bounds, as in the example. I confirm this report for this problem.
With the following snippet, a read access warning should only be expected for
the third argument:
extern int foo(const int *a, const int b[], const int c[1]);
int main (void)
{
foo ((int*)2, (int*)2, (int*2));
}
The warning in this instance is issued because functions that take const array
parameters with non-zero bound are assumed to read as many elements from the
parameters as the bound indicates. Because (int*)2 is not a pointer to an
array with at least two elements (or a valid pointer at all), the warning
triggers.
(Note that using invalid pointers like (int*)2 in any expression, including
assigning them to function parameters, is undefined and may be diagnosed in the
future regardless of the context they're used in, including in in arguments 1
and 2 above.)
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #67 from Eric Botcazou --- > Note that, as before, .text.startup is present in gcc-10 but missing in > gcc-11 crtend.o. That's expected if you compile with -Og or -O1, i.e. it requires -O2 or above.
[Bug go/102813] gccgo ICE when build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102813 --- Comment #2 from cqwrteur --- Created attachment 51623 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51623=edit config.log
[Bug target/102761] [10/11/12 Regression] ICE with -O1 and above: in ix86_print_operand_address_as due to %a0 and if_then_else and X constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102761 --- Comment #3 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:4abc0c196b10251dc80d0743ba9e8ab3e56c61ed commit r12-4484-g4abc0c196b10251dc80d0743ba9e8ab3e56c61ed Author: Uros Bizjak Date: Mon Oct 18 17:03:28 2021 +0200 i386: Fix ICE in ix86_print_opreand_address [PR 102761] 2021-10-18 Uroš Bizjak PR target/102761 gcc/ChangeLog: * config/i386/i386.c (ix86_print_operand_address): Error out for non-address_operand asm operands. gcc/testsuite/ChangeLog: * gcc.target/i386/pr102761.c: New test.
[Bug tree-optimization/102796] [12 Regresson] ICE in useless_type_conversion_p at gcc/gimple-expr.c:87 since r12-4443-g93ac832f1846e4867aa6537f76f510fab8e3e87d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102796 Andrew Pinski changed: What|Removed |Added CC||unlvsur at live dot com --- Comment #5 from Andrew Pinski --- *** Bug 102813 has been marked as a duplicate of this bug. ***
[Bug go/102813] gccgo ICE when build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102813 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 102796 ***
[Bug go/102813] New: gccgo ICE when build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102813 Bug ID: 102813 Summary: gccgo ICE when build Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: unlvsur at live dot com CC: cmang at google dot com Target Milestone: --- inux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -minline-all-stringops -O2 -g -m32 -I . -c -fgo-pkgpath=cmd/go/internal/get ../../../../../../gcc/libgo/go/cmd/go/internal/get/get.go -o cmd/go/internal/get.o during GIMPLE pass: evrp In function 'cmd/go/internal/modget.resolver.resolveQueries': go1: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:87 0x863cdf tree_class_check_failed(tree_node const*, tree_code_class, char const*, int, char const*) ../../../../gcc/gcc/tree.c:8739 0x791f66 tree_class_check(tree_node*, tree_code_class, char const*, int, char const*) ../../../../gcc/gcc/tree.h:3556 0x791f66 useless_type_conversion_p(tree_node*, tree_node*) ../../../../gcc/gcc/gimple-expr.c:87 0xf742f8 verify_gimple_phi ../../../../gcc/gcc/tree-cfg.c:5128 0xf742f8 verify_gimple_in_cfg(function*, bool) ../../../../gcc/gcc/tree-cfg.c:5457 0xe472a7 execute_function_todo ../../../../gcc/gcc/passes.c:2042 0xe47cce execute_todo ../../../../gcc/gcc/passes.c:2096 Please submit a full bug report, with preprocessed source if appropriate.
[Bug tree-optimization/102329] pointer "maybe uninitialized" right after assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102329 Florian Weimer changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=28458 --- Comment #7 from Florian Weimer --- We need to suppress this warning for pthread_setspecific in glibc because it is incorrect there. There is currently no good way to implement that suppression unfortunately.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #66 from Óscar Fuentes --- (In reply to Eric Botcazou from comment #65) > Thanks. Do you still have this line: > > r .eh_frame > > for crtend.o of the GCC 10 compiler after the grep mess was resolved? Do > you have the same line for the crtend.o of the GCC 11 compiler? The problem with grep didn't affect my gcc 10 install because it was built with grep 3.0, so crtend.o didn't change. Here it is again for completeness: $ for f in `find /mingw32 -name crtend.o` ; do echo $f && nm $f ; done /mingw32/lib/gcc/i686-w64-mingw32/10.3.0/crtend.o b .bss d .ctors.65535 d .data r .eh_frame r .rdata$zzz t .text t .text.startup r ___FRAME_END__ U ___gcc_register_frame t _register_frame_ctor Now, these are the crtend.o created in the gcc 11.2 build directory before it failed at a-except.o (this is also with grep 3.0, while in comment#29 was with the botched grep 3.6, but I see no differences): $ for f in `find /d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32 -name crtend.o` ; do echo $f && nm $f ; done /d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/prev-gcc/crtend.o b .bss d .ctors.65535 d .data r .eh_frame r .rdata$zzz t .text r ___FRAME_END__ U ___gcc_register_frame t _register_frame_ctor /d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/prev-i686-w64-mingw32/libgcc/crtend.o b .bss d .ctors.65535 d .data r .eh_frame r .rdata$zzz t .text r ___FRAME_END__ U ___gcc_register_frame t _register_frame_ctor Note that, as before, .text.startup is present in gcc-10 but missing in gcc-11 crtend.o.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #65 from Eric Botcazou --- > Searching for HAVE_LD_RO_RW_SECTION_MIXING in the build directory used for > extracting the previous gdb backtraces shows this: > > gcc/auto-host.h:1684:11:/* #undef HAVE_LD_RO_RW_SECTION_MIXING */ Thanks. Do you still have this line: r .eh_frame for crtend.o of the GCC 10 compiler after the grep mess was resolved? Do you have the same line for the crtend.o of the GCC 11 compiler?
[Bug gcov-profile/102746] gcov returns 0 un erroneuos incovation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102746 --- Comment #9 from Илья Шипицин --- ok, so we'll migrate to gcc-12 :)
[Bug gcov-profile/102746] gcov returns 0 un erroneuos incovation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102746 --- Comment #8 from Martin Liška --- (In reply to Илья Шипицин from comment #7) > wow. thanks for that. > > btw, will it be "gcc-12 only" or it is going to be backported (I'm > interested in gcc-8) ? No, I'm not planning backporting that as it's quite a change in functionality. Note gcc-8 is out of support: https://gcc.gnu.org/
[Bug gcov-profile/102746] gcov returns 0 un erroneuos incovation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102746 --- Comment #7 from Илья Шипицин --- wow. thanks for that. btw, will it be "gcc-12 only" or it is going to be backported (I'm interested in gcc-8) ?
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #64 from Óscar Fuentes --- Searching for HAVE_LD_RO_RW_SECTION_MIXING in the build directory used for extracting the previous gdb backtraces shows this: gcc/auto-host.h:1684:11:/* #undef HAVE_LD_RO_RW_SECTION_MIXING */
[Bug target/102812] New: Unoptimal (and wrong) code for _Float16 insert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102812
Bug ID: 102812
Summary: Unoptimal (and wrong) code for _Float16 insert
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
Following code:
--cut here--
typedef _Float16 v8hf __attribute__((__vector_size__ (16)));
v8hf t (_Float16 a)
{
return (v8hf){a, 0, 0, 0, 0, 0, 0, 0};
}
--cut here--
compiles with -msse4 to:
pxor%xmm15, %xmm15
movaps %xmm15, -56(%rsp)
pextrw $0, %xmm0, -56(%rsp)
vmovdqa64 -56(%rsp), %xmm0
PBLWNDW with cleared %xmm15 would be much more optimal, and wouldn't use
memory.
Also, VMOVDQA64 is an AVX512F/AVX512VL, not a SSE4 (not even AVX) instruction.
[Bug target/102811] vcvtph2ps and vcvtps2ph should be used to convert _Float16 to SFmode with -mf16c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811 --- Comment #2 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #1) > vxorps %xmm1, %xmm1, %xmm1 > vblendps %xmm1, %xmm1, %xmm0, $1 > vcvtps2ph %xmm0, %xmm1 vmovss %xmm1, %xmm1, %xmm0 instead of vblendps would also do the trick.
[Bug target/26915] missed sized opt returning -1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26915
--- Comment #8 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:247c407c83f0015f4b92d5f71e45b63192f6757e
commit r12-4475-g247c407c83f0015f4b92d5f71e45b63192f6757e
Author: Roger Sayle
Date: Mon Oct 18 12:15:40 2021 +0100
Try placing RTL folded constants in the constant pool.
My recent attempts to come up with a testcase for my patch to evaluate
ss_plus in simplify-rtx.c, identified a missed optimization opportunity
(that's potentially a long-time regression): The RTL optimizers no longer
place constants in the constant pool.
The motivating x86_64 example is the simple program:
typedef char v8qi __attribute__ ((vector_size (8)));
v8qi foo()
{
v8qi tx = { 1, 0, 0, 0, 0, 0, 0, 0 };
v8qi ty = { 2, 0, 0, 0, 0, 0, 0, 0 };
v8qi t = __builtin_ia32_paddsb(tx, ty);
return t;
}
which (with my previous patch) currently results in:
foo:movq.LC0(%rip), %xmm0
movq.LC1(%rip), %xmm1
paddsb %xmm1, %xmm0
ret
even though the RTL contains the result in a REG_EQUAL note:
(insn 7 6 12 2 (set (reg:V8QI 83)
(ss_plus:V8QI (reg:V8QI 84)
(reg:V8QI 85))) "ssaddqi3.c":7:12 1419 {*mmx_ssaddv8qi3}
(expr_list:REG_DEAD (reg:V8QI 85)
(expr_list:REG_DEAD (reg:V8QI 84)
(expr_list:REG_EQUAL (const_vector:V8QI [
(const_int 3 [0x3])
(const_int 0 [0]) repeated x7
])
(nil)
Together with the patch below, GCC will now generate the much
more sensible:
foo:movq.LC2(%rip), %xmm0
ret
My first approach was to look in cse.c (where the REG_EQUAL note gets
added) and notice that the constant pool handling functionality has been
unreachable for a while. A quick search for constant_pool_entries_cost
shows that it's initialized to zero, but never set to a non-zero value,
meaning that force_const_mem is never called. This functionality used
to work way back in 2003, but has been lost over time:
https://gcc.gnu.org/pipermail/gcc-patches/2003-October/116435.html
The changes to cse.c below restore this functionality (placing suitable
constants in the constant pool) with two significant refinements;
(i) it only attempts to do this if the function already uses a constant
pool (thanks to the availability of crtl->uses_constant_pool since 2003).
(ii) it allows different constants (i.e. modes) to have different costs,
so that floating point "doubles" and 64-bit, 128-bit, 256-bit and 512-bit
vectors don't all have the share the same cost. Back in 2003, the
assumption was that everything in a constant pool had the same
cost, hence the global variable constant_pool_entries_cost.
Although this is a useful CSE fix, it turns out that it doesn't cure
my motivating problem above. CSE only considers a single instruction,
so determines that it's cheaper to perform the ss_plus (COSTS_N_INSNS(1))
than read the result from the constant pool (COSTS_N_INSNS(2)). It's
only when the other reads from the constant pool are also eliminated,
that this transformation is a win. Hence a better place to perform
this transformation is in combine, where after failing to "recog" the
load of a suitable constant, it can retry after calling force_const_mem.
This achieves the desired transformation and allows the backend insn_cost
call-back to control whether or not using the constant pool is preferrable.
Alas, it's rare to change code generation without affecting something in
GCC's testsuite. On x86_64-pc-linux-gnu there were two families of new
failures (and I'd predict similar benign fallout on other platforms).
One failure was gcc.target/i386/387-12.c (aka PR target/26915), where
the test is missing an explicit -m32 flag. On i686, it's very reasonable
to materialize -1.0 using "fld1; fchs", but on x86_64-pc-linux-gnu we
currently generate the awkward:
testm1: fld1
fchs
fstpl -8(%rsp)
movsd -8(%rsp), %xmm0
ret
which combine now very reasonably simplifies to just:
testm1: movsd .LC3(%rip), %xmm0
ret
The other class of x86_64-pc-linux-gnu failure was from materialization
of vector constants using vpbroadcast (e.g. gcc.target/i386/pr90773-17.c)
where the decision is finely balanced; the load of an integer register
with an immediate constant, followed by a vpbroadcast is deemed to be
COSTS_N_INSNS(2), whereas a load from the constant pool is also reported
as COSTS_N_INSNS(2). My solution is to tweak the i386.c's rtx_costs
so that all other things being equal, an instruction (sequence) that
accesses memory is
[Bug target/102811] vcvtph2ps and vcvtps2ph should be used to convert _Float16 to SFmode with -mf16c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811 --- Comment #1 from Uroš Bizjak --- Something like (argument and result in %xmm0): vpxor %xmm1, %xmm1, %xmm1 vpblendw %xmm1, %xmm1, %xmm0, $1 vcvtph2ps %xmm0, %xmm1 instead of __extendhfsf2 and: vxorps %xmm1, %xmm1, %xmm1 vblendps %xmm1, %xmm1, %xmm0, $1 vcvtps2ph %xmm0, %xmm1 instead of __truncsfhf2.
[Bug gcov-profile/102747] gcov returns 0 when invoked on gcda generated by previous gcc version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102747 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Martin Liška --- Fixed on master.
[Bug gcov-profile/102746] gcov returns 0 un erroneuos incovation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102746 Martin Liška changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Martin Liška --- Fixed on master.
[Bug gcov-profile/102746] gcov returns 0 un erroneuos incovation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102746 --- Comment #5 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:815f15d3384edbdd73cc54536f30947e15183151 commit r12-4474-g815f15d3384edbdd73cc54536f30947e15183151 Author: Martin Liska Date: Mon Oct 18 11:30:55 2021 +0200 gcov: return proper exit code when error happens PR gcov-profile/102746 PR gcov-profile/102747 gcc/ChangeLog: * gcov.c (main): Return return_code. (output_gcov_file): Mark return_code when error happens. (generate_results): Likewise. (read_graph_file): Likewise. (read_count_file): Likewise.
[Bug gcov-profile/102747] gcov returns 0 when invoked on gcda generated by previous gcc version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102747 --- Comment #2 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:815f15d3384edbdd73cc54536f30947e15183151 commit r12-4474-g815f15d3384edbdd73cc54536f30947e15183151 Author: Martin Liska Date: Mon Oct 18 11:30:55 2021 +0200 gcov: return proper exit code when error happens PR gcov-profile/102746 PR gcov-profile/102747 gcc/ChangeLog: * gcov.c (main): Return return_code. (output_gcov_file): Mark return_code when error happens. (generate_results): Likewise. (read_graph_file): Likewise. (read_count_file): Likewise.
[Bug tree-optimization/102809] [12 Regression] Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102809 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |12.0 Summary|Some TSVC benchmarks are|[12 Regression] Some TSVC |slower after|benchmarks are slower after |r12-4195-gec0124e0acb556cd |r12-4195-gec0124e0acb556cd
[Bug tree-optimization/102788] [11 Regression] Wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102788 Richard Biener changed: What|Removed |Added Target Milestone|12.0|11.3 Known to work||12.0 Summary|[12 Regression] Wrong code |[11 Regression] Wrong code |with -O3|with -O3 Priority|P1 |P2 --- Comment #8 from Richard Biener --- Fixed on trunk but the issue is latent since the introduction of the forwprop pattern. I'm considering backporting to GCC 11.
[Bug target/102811] New: vcvtph2ps and vcvtps2ph should be used to convert _Float16 to SFmode with -mf16c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102811
Bug ID: 102811
Summary: vcvtph2ps and vcvtps2ph should be used to convert
_Float16 to SFmode with -mf16c
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ubizjak at gmail dot com
Target Milestone: ---
The following testcase:
_Float16 test (_Float16 a, _Float16 b)
{
return a + b;
}
compiles with -O2 -mf16c to:
--cut here--
subq$24, %rsp
pextrw $0, %xmm1, 14(%rsp)
call__extendhfsf2
pinsrw $0, 14(%rsp), %xmm1
vmovss %xmm0, 8(%rsp)
vmovss %xmm1, %xmm1, %xmm0
call__extendhfsf2
vaddss 8(%rsp), %xmm0, %xmm0
call__truncsfhf2
addq$24, %rsp
ret
--cut here--
Instead of calling __extendhfsf2 and __truncsfhf2, we should use vcvtph2ps and
vcvtps2ph (with zeroed elements 1..3) for -m16c targets.
[Bug tree-optimization/102788] [12 Regression] Wrong code with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102788 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:eb032893675afea4b01cc6ad06a3e0dcfe9b51cd commit r12-4472-geb032893675afea4b01cc6ad06a3e0dcfe9b51cd Author: Richard Biener Date: Mon Oct 18 10:31:19 2021 +0200 tree-optimization/102788 - avoid spurious bool pattern fails Bool pattern recog is required for correctness since vectorized compares otherwise produce -1 for true so any context where bool is used as value and not as condition or mask needs to be replaced with CMP ? 1 : 0. When we fail to find a vector type for the result of such use we may not simply elide such transform since a new bool result can emerge when for example the cast_forwprop pattern is applied. So the following avoids failing of the bool pattern recog process and instead not assign a vector type for the stmt. 2021-10-18 Richard Biener PR tree-optimization/102788 * tree-vect-patterns.c (vect_init_pattern_stmt): Allow a NULL vectype. (vect_pattern_recog_1): Likewise. (vect_recog_bool_pattern): Continue matching the pattern even if we do not have a vector type for a conversion result. * g++.dg/vect/pr102788.cc: New testcase.
[Bug tree-optimization/102809] Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102809 --- Comment #3 from Aldy Hernandez --- (In reply to Martin Liška from comment #2) > > Does this fix the problem? > > Yes, it helps! Thank you for the patch. Thanks for all your help here, and sorry for all the noise. Getting the jump threading restrictions in the presence of loops has been chore. It seems we have finally agreed on what should be allowed, and Jeff is about to approve the last bits. Unfortunately, the next step is playing with the pipeline to see if we can remove some threading passes. This will probably unsettle things, but hopefully not as much. Again, thanks.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #63 from Arnaud Charlet --- (In reply to Eric Botcazou from comment #62) > > No need to, there are actually several reasons to not rely on exception > > propagation during bootstrap, so let's restore this invariant instead, I'm > > testing a change to that effect. > > Fair enough. In any case, the symptoms are again consistent with a lack of > registration of unwind tables, this time for libgcc, so this might be the > same underlying issue as the grep-induced mess for GCC 10. My hunch would > point to a constructor section merging issue in the linker, maybe related > to the GCC configure check for HAVE_LD_RO_RW_SECTION_MIXING, which should > fail for MinGW and may incorrectly succeed when things go wrong. Right, that's most likely the underlying issue and indeed ensuring we don't use exception propagation during the bootstrap is just a way to hide/avoid this underlying mismatch.
[Bug tree-optimization/102809] Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102809 --- Comment #2 from Martin Liška --- > Does this fix the problem? Yes, it helps! Thank you for the patch.
[Bug ada/100486] Ada build fails for 32bit Windows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100486 --- Comment #62 from Eric Botcazou --- > No need to, there are actually several reasons to not rely on exception > propagation during bootstrap, so let's restore this invariant instead, I'm > testing a change to that effect. Fair enough. In any case, the symptoms are again consistent with a lack of registration of unwind tables, this time for libgcc, so this might be the same underlying issue as the grep-induced mess for GCC 10. My hunch would point to a constructor section merging issue in the linker, maybe related to the GCC configure check for HAVE_LD_RO_RW_SECTION_MIXING, which should fail for MinGW and may incorrectly succeed when things go wrong.
[Bug libstdc++/59675] -D_GLIBCXX_DEBUG asserts to stdout (it should stderr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59675 --- Comment #8 from Jonathan Wakely --- (In reply to Jay Feldblum from comment #7) > The caveat, not to pollute `bits/c++config` with `#include really */>`. Are there more caveats to be aware of? No, that's it. The additional overhead of calling a function defined in the library is not a problem, because we're aborting anyway. > > The suggestion, to export a helper routine that would work like `printf` but > emit to stderr. I can't tell whether that's a strong or weak preference. The > patch I went with - exporting a helper routine that returns the value of > `stderr` - is a bit smaller. But if that's not the preference then I can > change the patch. That seems OK. Another option would be to export the existing __snprintf_lite function and print into a buffer, then use ::write(2, ...) to output that. Either way requires adding a new export to the library. Using write has some other advantages, but means polluting the namespace (and isn't available on all targets) which isn't a problem with __builtin_printf or __builtin_fprintf. > Beyond the question of what helper routine to add, there is where to add it. > I cam e up with a guess but perhaps a better place will be suggested. src/c++98/compatibility.cc is definitely wrong, that's for symbols that are only retained for backwards compatibility with previous releases. Not for new symbols for new features. Patches should be sent to the libstdc++ and gcc-patches mailing lists for review though, rather than attached here. Thanks for working on this!
[Bug c/102810] New: Bogus Wstringop-overread warning when special (integer) pointer values passed to array parameter of a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102810
Bug ID: 102810
Summary: Bogus Wstringop-overread warning when special
(integer) pointer values passed to array parameter of
a function
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ian at abbott dot org
Target Milestone: ---
I don't know why this code produces a Wstringop-overread warning since it has
nothing to do with string operations. Also, why is there a warning for
argument 2, but not for argument 1?
extern int foo(const int *a, const int b[]);
#define SPECIAL ((int *)2)
int main(void)
{
foo(SPECIAL, SPECIAL);
}
int foo(const int a[], const int b[])
{
return 0;
}
: In function 'main':
:7:5: warning: 'foo' reading 4 bytes from a region of size 0
[-Wstringop-overread]
7 | foo(SPECIAL, SPECIAL);
| ^
:7:5: note: referencing argument 2 of type 'const int *'
:10:5: note: in a call to function 'foo'
10 | int foo(const int a[], const int b[])
| ^~~
[Bug target/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789 --- Comment #3 from Jakub Jelinek --- On the trunk, -O2 -fopenmp -mcpu=power6 -maltivec -m32 works fine, while -O2 -fopenmp -mcpu=power6 -mvsx -m32 is miscompiled too.
[Bug tree-optimization/102809] Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102809 --- Comment #1 from Aldy Hernandez --- There's a pending patch in this area that restricts loop threading: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581894.html Does this fix the problem?
[Bug target/93183] SVE does not use neg as conditional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93183 --- Comment #4 from CVS Commits --- The master branch has been updated by Prathamesh Kulkarni : https://gcc.gnu.org/g:20dcda98ed376cb61c74b2c71656f99c671ec9ce commit r12-4470-g20dcda98ed376cb61c74b2c71656f99c671ec9ce Author: prathamesh.kulkarni Date: Mon Oct 18 15:44:06 2021 +0530 [sve] PR93183 - Add support for conditional neg. gcc/ChangeLog: PR target/93183 * gimple-match-head.c (try_conditional_simplification): Add case for single operand. * internal-fn.def: Add entry for COND_NEG internal function. * internal-fn.c (FOR_EACH_CODE_MAPPING): Add entry for NEGATE_EXPR, COND_NEG mapping. * optabs.def: Add entry for cond_neg_optab. * match.pd (UNCOND_UNARY, COND_UNARY): New operator lists. (vec_cond COND (foo A) B) -> (IFN_COND_FOO COND A B): New pattern. (vec_cond COND B (foo A)) -> (IFN_COND_FOO ~COND A B): Likewise. gcc/testsuite/ChangeLog: PR target/93183 * gcc.target/aarch64/sve/cond_unary_4.c: Adjust. * gcc.target/aarch64/sve/pr93183.c: New test.
[Bug tree-optimization/102809] Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102809 Martin Liška changed: What|Removed |Added Last reconfirmed||2021-10-18 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug tree-optimization/102809] New: Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102809 Bug ID: 102809 Summary: Some TSVC benchmarks are slower after r12-4195-gec0124e0acb556cd Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: aldyh at gcc dot gnu.org Target Milestone: --- Tested with https://github.com/UoB-HPC/TSVC_2/pull/2 where one can run a single benchmark. Happens with -Ofast -march=native on znver1 machine: gcc-bisect.py 'gcc *.c -lm -Ofast -march=native -fuse-ld=bfd && timeout 100.7 ./a.out va' -l -e r12-4194-g1f51e9af7b615838 -s r12-4195-gec0124e0acb556cd Bisecting latest revisions ec0124e0acb556cd(05 Oct 2021 18:24)(al...@redhat.com): [took: 7.050s] result: OK LoopTime(sec) Checksum va3.719 1.644725 1f51e9af7b615838(05 Oct 2021 16:47)(jwak...@redhat.com): [took: 5.433s] result: OK LoopTime(sec) Checksum va2.006 1.644725 and can be seen here: https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=14.920.0 https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=14.887.0 https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=14.943.0
[Bug target/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Component|libgomp |target
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-10-18
CC||dje at gcc dot gnu.org,
||segher at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Ok, I can reproduce, but only with -mcpu=power7. The cost model patch just
uncovered a latent power7 vectorization bug (backend or vectorizer) I'd say.
I've instrumented the testcase a little bit:
// { dg-do run }
// { dg-additional-options "-msse2" { target sse2_runtime } }
// { dg-additional-options "-mavx" { target avx_runtime } }
extern "C" void abort ();
int a[1024] __attribute__((aligned (32))) = { 1 };
int b[1024] __attribute__((aligned (32))) = { 1 };
unsigned char c[1024] __attribute__((aligned (32))) = { 1 };
int k, m;
__UINTPTR_TYPE__ u, u2, u3;
__attribute__((noinline, noclone)) int
foo (int *p)
{
int i, s = 0, s2 = 0, t, t2;
#pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s) \
lastprivate (t2)
for (i = 0; i < 512; i++)
{
a[i] *= p[i];
t2 = k + p[i];
k += m + 1;
s += p[i] + k;
c[i]++;
}
#pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s2) \
lastprivate (t, u, u2, u3)
for (i = 512; i < 1024; i++)
{
a[i] *= p[i];
k += m + 1;
t = k + p[i];
u = (__UINTPTR_TYPE__)
u2 = (__UINTPTR_TYPE__)
u3 = (__UINTPTR_TYPE__)
s2 += t;
c[i]++;
}
__builtin_printf ("foo %d %d %d %d\n", s, s2, t, t2);
return s + s2 + t + t2;
}
__attribute__((noinline, noclone)) long int
bar (int *p, long int n, long int o)
{
long int i, s = 0, s2 = 0, t, t2;
#pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s) \
lastprivate (t2)
for (i = 0; i < n; i++)
{
a[i] *= p[i];
t2 = k + p[i];
k += m + 1;
s += p[i] + k;
c[i]++;
}
#pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s2) \
lastprivate (t, u, u2, u3)
for (i = n; i < o; i++)
{
a[i] *= p[i];
k += m + 1;
t = k + p[i];
u = (__UINTPTR_TYPE__)
u2 = (__UINTPTR_TYPE__)
u3 = (__UINTPTR_TYPE__)
s2 += t;
c[i]++;
}
__builtin_printf ("bar %d %d %d %d\n", s, s2, t, t2);
return s + s2 + t + t2;
}
int
main ()
{
#if __SIZEOF_INT__ >= 4
int i;
k = 4;
m = 2;
for (i = 0; i < 1024; i++)
{
a[i] = i - 512;
b[i] = (i - 51) % 39;
c[i] = (unsigned char) i;
}
int s = foo (b);
for (i = 0; i < 1024; i++)
{
if (b[i] != (i - 51) % 39
|| a[i] != (i - 512) * b[i]
|| c[i] != (unsigned char) (i + 1))
{
__builtin_printf ("#1 %d %d %d %d\n", i, b[i], a[i], c[i]);
abort ();
}
a[i] = i - 512;
}
if (k != 4 + 3 * 1024
|| s != 1596127 + (4 + 3 * 511 + b[511]) + (4 + 3 * 1024 + b[1023]))
{
__builtin_printf ("#2 %d %d\n", k, s);
abort ();
}
k = 4;
s = bar (b, 512, 1024);
for (i = 0; i < 1024; i++)
{
if (b[i] != (i - 51) % 39
|| a[i] != (i - 512) * b[i]
|| c[i] != (unsigned char) (i + 2))
{
__builtin_printf ("#3 %d %d %d %d\n", i, b[i], a[i], c[i]);
abort ();
}
a[i] = i - 512;
}
if (k != 4 + 3 * 1024
|| s != 1596127 + (4 + 3 * 511 + b[511]) + (4 + 3 * 1024 + b[1023]))
{
__builtin_printf ("#4 %d %d\n", k, s);
abort ();
}
k = 4;
s = bar (b, 511, 1021);
for (i = 0; i < 1021; i++)
{
if (b[i] != (i - 51) % 39
|| a[i] != (i - 512) * b[i]
|| c[i] != (unsigned char) (i + 3))
{
__builtin_printf ("#5 %d %d %d %d\n", i, b[i], a[i], c[i]);
abort ();
}
a[i] = i - 512;
}
for (i = 1021; i < 1024; i++)
if (b[i] != (i - 51) % 39
|| a[i] != i - 512
|| c[i] != (unsigned char) (i + 2))
{
__builtin_printf ("#6 %d %d %d %d\n", i, b[i], a[i], c[i]);
abort ();
}
if (k != 4 + 3 * 1021
|| s != 1586803 + (4 + 3 * 510 + b[510]) + (4 + 3 * 1021 + b[1020]))
{
__builtin_printf ("#7 %d %d %d %d\n", k, s, b[510], b[1020]);
abort ();
}
#endif
return 0;
}
When compiled with -O2 -m32 -fopenmp -mcpu=power6, this prints:
foo 403860 1192267 3112 1568
bar 403860 1192267 3112 1568
bar 402289 1184514 3100 1564
while with -O2 -m32 -fopenmp -mcpu=power7 it prints:
foo 403860 1192267 3112 1568
bar 403860 1192267 3112 1568
bar 402289 919217 3100 1564
#7 3067 1326170 30 33
Aborted
which seems to suggest it is the:
#pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s2) \
lastprivate (t, u, u2, u3)
for (i =
[Bug libstdc++/102807] Simple code using ranges::views::keys does not compile with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102807 Jonathan Wakely changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED See Also||https://bugs.llvm.org/show_ ||bug.cgi?id=44833 --- Comment #5 from Jonathan Wakely --- (In reply to Pilar Latiesa from comment #3) > I believe this is a consequence of Clang bug 44833. Ah yes, that's exactly it. Thanks!
[Bug libstdc++/102807] Simple code using ranges::views::keys does not compile with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102807
--- Comment #4 from Jonathan Wakely ---
#include
struct Range
{
int* begin() { return 0; }
int* end() { return 0; }
};
int main()
{
static_assert(std::ranges::range);
using R = std::ranges::ref_view;
static_assert( std::ranges::__cust_access::__member_begin );
}
The problem happens when instantiating ref_view for any R. The
view_interface> CRTP base class gets instantiated and that checks
the constraints of its member functions, which depends on the derived class,
which is incomplete at that point.
I think this is a clang bug. It should not be checking the constraints for
view_interface>::data() when checking satisfaction of
range>.
[Bug libstdc++/102807] Simple code using ranges::views::keys does not compile with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102807 Pilar Latiesa changed: What|Removed |Added CC||pilarlatiesa at gmail dot com --- Comment #3 from Pilar Latiesa --- I believe this is a consequence of Clang bug 44833.
[Bug libstdc++/102807] Simple code using ranges::views::keys does not compile with clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102807
--- Comment #2 from Jonathan Wakely ---
It evaluates to false because is_array_v is false for that type.
The next candidate is the problem:
and 'std::ranges::ref_view> &' does not satisfy
'__member_begin'
because '__decay_copy(__t.begin())' would be invalid: no member named 'begin'
in 'std::ranges::ref_view>'
That's wrong. I don't know why ref_view::begin() isn't usable.
Reduced:
#include
struct Range
{
int* begin() { return }
int* end() { return begin() + 1; }
const int* begin() const { return }
const int* end() const { return begin() + 1; }
int i = 0;
};
int main()
{
static_assert(std::ranges::range);
static_assert(std::ranges::range);
using R = std::ranges::ref_view;
static_assert(std::ranges::range);
using I = decltype(std::declval().begin());
}
[Bug target/100208] amdgcn fails to build with llvm-mc from llvm12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100208 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:92aed72a73993607b845651630ba8a48f332097c commit r11-9163-g92aed72a73993607b845651630ba8a48f332097c Author: Andrew Stubbs Date: Tue Jul 27 15:40:21 2021 +0100 amdgcn: Fix attributes for LLVM-12 [PR 100208] This should work for a wider range of LLVM 12 variants now. More work required for LLVM 13 though. gcc/ChangeLog: PR target/100208 * config.in: Regenerate. * config/gcn/gcn-hsa.h (A_FIJI): New define. (A_900): New define. (A_906): New define. (A_908): New define. (ASM_SPEC): Use A_FIJI, A_900, A_906 and A_908. * config/gcn/gcn.c (output_file_start): Adjust attributes according to the assembler capabilities. * config/gcn/mkoffload.c (main): Likewise. * configure: Regenerate. * configure.ac: Add tests for LLVM assembler attribute features.
[Bug target/100208] amdgcn fails to build with llvm-mc from llvm12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100208 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:9552afb2aec54b793d61ce85c93869a2f2a7958f commit r11-9162-g9552afb2aec54b793d61ce85c93869a2f2a7958f Author: Andrew Stubbs Date: Thu Jul 8 15:47:53 2021 +0100 amdgcn: Add -mxnack and -msram-ecc [PR 100208] gcc/ChangeLog: PR target/100208 * config/gcn/gcn-hsa.h (DRIVER_SELF_SPECS): New. (ASM_SPEC): Set -mattr for xnack and sram-ecc. * config/gcn/gcn-opts.h (enum sram_ecc_type): New. * config/gcn/gcn-valu.md: Add a warning comment. * config/gcn/gcn.c (gcn_option_override): Add "sorry" for -mxnack. (output_file_start): Add xnack and sram-ecc state to ".amdgcn_target". * config/gcn/gcn.md: Add a warning comment. * config/gcn/gcn.opt: Add -mxnack and -msram-ecc. * config/gcn/mkoffload.c (EF_AMDGPU_MACH_AMDGCN_GFX908): Remove SRAM-ECC flag. (EF_AMDGPU_XNACK): New. (EF_AMDGPU_SRAM_ECC): New. (elf_flags): New. (copy_early_debug_info): Use elf_flags. (main): Handle -mxnack and -msram-ecc options. * doc/invoke.texi: Document -mxnack and -msram-ecc. gcc/testsuite/ChangeLog: PR target/100208 * gcc.target/gcn/sram-ecc-1.c: New test. * gcc.target/gcn/sram-ecc-2.c: New test. * gcc.target/gcn/sram-ecc-3.c: New test. * gcc.target/gcn/sram-ecc-4.c: New test. * gcc.target/gcn/sram-ecc-5.c: New test. * gcc.target/gcn/sram-ecc-6.c: New test. * gcc.target/gcn/sram-ecc-7.c: New test. * gcc.target/gcn/sram-ecc-8.c: New test. (cherry picked from commit aad32a00b7d2b64ae158b2b167768a9ae3e20f6e)
