[Bug c++/101402] New: top cv qualifier not dropped for array type typedef in template class (core 1001)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101402
Bug ID: 101402
Summary: top cv qualifier not dropped for array type typedef in
template class (core 1001)
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
Created attachment 51127
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51127=edit
a diagnositic message to print functions arguments for comparison
This example code from core
1001(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1001) is still
giving no matching template declaration error.
template struct A {
typedef T arr[3];
};
template void f(const typename A::arr) { } // #1
template void f(const A::arr);
1. This happens for all gcc versions. The root cause is template function
argument is considered as ‘(const int*)’ instead of ‘(int*)’ (see attached
debug output for details.)
2. C++ standard requires top level cv qualifier being dropped when forming
function type.(https://timsong-cpp.github.io/cppwp/dcl.fct#5)
3. When both 'const' are removed from template function and specialization,
there is no error which proves array type works as long as there is no top
level cv qualifier.
4. I feel this is rather a high-profile bug as the example code is listed in
active core language issues long ago, particularly when both clang and MSVC
have fixed this issue. (see godbolt: https://www.godbolt.org/z/cofrEWEbs)
[Bug bootstrap/101374] [12 Regression] bootstrap failure varpool.c:490:19: error: array subscript 'varpool_node[0]' is partly outside array bounds of 'varpool_node [0]' [-Werror=array-bounds]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101374 --- Comment #14 from CVS Commits --- The master branch has been updated by Ian Lance Taylor : https://gcc.gnu.org/g:1798cac7a8b3331a277da1f106752ce0a34f8937 commit r12-2234-g1798cac7a8b3331a277da1f106752ce0a34f8937 Author: Ian Lance Taylor Date: Thu Jul 8 19:25:55 2021 -0700 runtime: remove direct assignments to memory locations PR bootstrap/101374 They cause a warning with the updated GCC -Warray-bounds option. Replace them with calls to abort, which for our purposes is fine. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/333409
[Bug c++/82110] Concept for default constructing works with new T, not with new T[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82110 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:b9119edc09e4660d772dea771578715858f7fbdb commit r12-2233-gb9119edc09e4660d772dea771578715858f7fbdb Author: Patrick Palka Date: Fri Jul 9 22:40:07 2021 -0400 c++: 'new T[N]' and SFINAE [PR82110] Here we're failing to treat 'new T[N]' as erroneous in a SFINAE context when T isn't default constructible because expand_aggr_init_1 doesn't communicate to build_aggr_init (its only SFINAE caller) whether the initialization was actually successful. To fix this, this patch makes expand_aggr_init_1 and its subroutine expand_default_init return true on success, false on failure so that build_aggr_init can properly return error_mark_node on failure. PR c++/82110 gcc/cp/ChangeLog: * init.c (build_aggr_init): Return error_mark_node if expand_aggr_init_1 returns false. (expand_default_init): Change return type to bool. Return false on error, true on success. (expand_aggr_init_1): Likewise. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/pr78765.C: Expect another conversion failure diagnostic. * g++.dg/template/sfinae14.C: Flip incorrect assertion. * g++.dg/cpp2a/concepts-requires27.C: New test.
[Bug c++/101371] [9/10/11/12 Regression] constexpr expansions trigger internal Compiler Error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101371
--- Comment #6 from Marek Polacek ---
And this should compile fine but doesn't since r269078:
struct A {
int i;
};
struct B {
A a{};
constexpr B() : a() {}
constexpr B(const B ) : a(rhs.a) {}
};
struct C {
B arr[1];
};
constexpr C
fn ()
{
C c{};
return c;
}
constexpr C c = fn();
$ ./cc1plus -quiet 101371.C
101371.C:20:20: in ‘constexpr’ expansion of ‘fn()()’
101371.C:17:10: in ‘constexpr’ expansion of ‘C(c)’
101371.C:20:20: in ‘constexpr’ expansion of ‘B(.C::arr[0])’
101371.C:20:20: in ‘constexpr’ expansion of ‘B()’
101371.C:20:20: error: accessing value of ‘.B::a’ through a ‘B’
glvalue in a constant expression
20 | constexpr C c = fn();
|^
[Bug c++/82110] Concept for default constructing works with new T, not with new T[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82110 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org
[Bug fortran/101399] Horizonal tab character not ignored on print statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101399 --- Comment #5 from Steve Kargl --- On Fri, Jul 09, 2021 at 11:44:11PM +, urbanjost at comcast dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101399 > > --- Comment #4 from urbanjost at comcast dot net --- > Wow. I cannot get a pizza delivered that fast. > A patch has been attached to the PR. No telling when someone might commit it to the source repository. I no longer commit as I have zero interest in git.
[Bug fortran/101399] Horizonal tab character not ignored on print statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101399 --- Comment #4 from urbanjost at comcast dot net --- Wow. I cannot get a pizza delivered that fast. Thanks! I have -Wtabs set in my compiler script and the script I use for editing codes does a :retabs after turning off tabs in vim(1) and runs any file ending in a Fortran suffix through expand(1) if using any other editor; so I would totally vote for -Wtabs being the default but I know a lot of others who would definitely vote for tabs being allowed as part of the standard. In fact, the majority of Fortran users I know would prefer it being standard.
[Bug bootstrap/101379] libatomic arm build failure after r12-2132 due -Warray-bounds on a constant address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379 Martin Sebor changed: What|Removed |Added Last reconfirmed||2021-07-09 Target Milestone|--- |12.0 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1 Keywords||patch Status|UNCONFIRMED |ASSIGNED --- Comment #8 from Martin Sebor --- Thanks for testing. I've submitted the patch for review: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574880.html
[Bug target/52268] native tls support should be added for darwin11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268 --- Comment #13 from Eric Gallager --- This could potentially arrive with the arm64 darwin port: https://github.com/iains/gcc-darwin-arm64/issues/1
[Bug fortran/101399] Horizonal tab character not ignored on print statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101399
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
Last reconfirmed||2021-07-09
Priority|P3 |P5
Status|UNCONFIRMED |NEW
Severity|normal |enhancement
Ever confirmed|0 |1
--- Comment #3 from kargl at gcc dot gnu.org ---
diff --git a/gcc/fortran/io.c b/gcc/fortran/io.c
index 40cd76eb585..8c3f841098f 100644
--- a/gcc/fortran/io.c
+++ b/gcc/fortran/io.c
@@ -4226,7 +4226,10 @@ match_io (io_kind k)
if (gfc_current_form == FORM_FREE)
{
- char c = gfc_peek_ascii_char ();
+ char c;
+
+ gfc_gobble_whitespace ();
+ c = gfc_peek_ascii_char ();
if (c != ' ' && c != '*' && c != '\'' && c != '"')
{
m = MATCH_NO;
Personally, I think -Wtab should be the default behavior.
I lost that fight years ago.
PS: you'll need someone to commit this for you, or it
will sit with the 10 to 20 patches I've put into PRs.
[Bug libffi/101336] Incorrect target on gnux32 hosts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101336 H.J. Lu changed: What|Removed |Added Target Milestone|--- |12.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from H.J. Lu --- Fixed for GCC 12.
[Bug libffi/101336] Incorrect target on gnux32 hosts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101336 --- Comment #1 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:506f337ad2d75c0feceaaf28fd4997c157979956 commit r12-2231-g506f337ad2d75c0feceaaf28fd4997c157979956 Author: H.J. Lu Date: Mon Jul 5 14:15:04 2021 -0700 libffi/x86: Always check __x86_64__ for x86 hosts The upstream libffi has commit cb8474368cdef3207638d047bd6c707ad8fcb339 Author: hjl-tools Date: Wed Dec 2 12:52:12 2020 -0800 libffi/x86: Always check __x86_64__ for x32 hosts (#601) (#602) Since for x86_64-*x32 and x86_64-x32-* hosts, -m32 generates ia32 codes. We should always check __x86_64__ for x32 hosts. Since for gnux32 hosts, -m32 generates i386 codes, always check __x86_64__ for x86 hosts. PR libffi/101336 * configure.host: Always check __x86_64__ for x86 hosts.
[Bug tree-optimization/101401] New: strlen of a constant char vector not folded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101401
Bug ID: 101401
Summary: strlen of a constant char vector not folded
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The strlen pass only folds the result in f() but not the equivalent in g(). It
should be able to handle both.
$ cat a.c && gcc -O2 -S -fdump-tree-optimized=/dev/stdout a.c
void f (void)
{
char c8[8] = { 1, 2, 3 };
if (__builtin_strlen ([0]) != 3)
__builtin_abort ();
}
void g (void)
{
__attribute__ ((vector_size (8))) char c8 = { 1, 2, 3 };
if (__builtin_strlen ([0]) != 3)
__builtin_abort ();
}
;; Function f (f, funcdef_no=0, decl_uid=1943, cgraph_uid=1, symbol_order=0)
void f ()
{
[local count: 1073741824]:
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1947, cgraph_uid=2, symbol_order=1)
void g ()
{
vector(8) char c8;
long unsigned int _1;
[local count: 1073741824]:
c8 = { 1, 2, 3, 0, 0, 0, 0, 0 };
_1 = __builtin_strlen (_CONVERT_EXPR(c8)[0]);
if (_1 != 3)
goto ; [0.00%]
else
goto ; [100.00%]
[count: 0]:
__builtin_abort ();
[local count: 1073741824]:
c8 ={v} {CLOBBER};
return;
}
[Bug bootstrap/101379] libatomic arm build failure after r12-2132 due -Warray-bounds on a constant address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379 --- Comment #7 from Christophe Lyon --- The patch in comment #6 lets the build complete, thanks!
[Bug fortran/101399] Horizonal tab character not ignored on print statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101399 --- Comment #2 from urbanjost at comcast dot net --- I agree tabs are not part of the standard, but even by default it is a very common extension ( I tried it with gfortran, ifort, nvfortran just today). I not not use the extension normally myself, but it came up in another context today and is an odd inconsistency. I ran 200 000, lines of Fortran through the ULS command unexpand(1) to create many source files with tabs in them and had no other problem with gfortran with tabs. I also took a small program with no long lines in it and replaced all spaces with tabs and had no problem compiling it with gfortran. This is not a high priority for me but seems like an odd inconsistency that would not be hard to rectify.
[Bug driver/101383] GCC 11 Reproducibility Issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101383 --- Comment #6 from Toolybird --- The patch you posted to gcc-patches solves my problem. Thank you for the quick fix!
[Bug c/101400] New: comments mention gnu-attributes[opt] even though it can be empty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101400 Bug ID: 101400 Summary: comments mention gnu-attributes[opt] even though it can be empty Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- gcc/c/c-parser.c says: > gnu-attributes: > empty > gnu-attributes gnu-attribute Several other comments in that file refer to that grammar rule as gnu-attributes[opt]. The [opt] is not necessary in those references. To avoid confusion, the [opt] should be removed from the references. Apart from potentially confusing readers of the code, there is no actual problem.
[Bug libstdc++/98449] [DR 3343] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98449 Vinícius dos Santos Oliveira changed: What|Removed |Added CC||vini.ipsmaker at gmail dot com --- Comment #2 from Vinícius dos Santos Oliveira --- Created attachment 51126 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51126=edit bugfix Here's a patch fixing the issue. If you want a codebase affected by the issue, here's the code for a thread joining detached threads through a condition variable: https://gitlab.com/emilua/emilua/-/blob/e5706426305733af02983ecb92a08dd8a00ebf2e/src/main.ypp#L275 Once the condition is met, both resources (mutex + condition variables) are destroyed just before the application exits. Therefore I cannot use notify_all_at_thread_exit (there would be a race there).
[Bug fortran/101399] Horizonal tab character not ignored on print statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101399 --- Comment #1 from Andrew Pinski --- tab is not part of Fortran character set.
[Bug fortran/101399] New: Horizonal tab character not ignored on print statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101399 Bug ID: 101399 Summary: Horizonal tab character not ignored on print statement Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net Target Milestone: --- Although gfortran defaults to allowing tab characters in source input as an extension, a PRINT statement followed immediately by a horizontal tab character fails print<\I>*,'tab not always ignored' end where <\I> is a tab character reproduces the problem. Showing source with a simple cat(1): $ cat x-x.f90 print *,'tab not always ignored' end$ Showing it actually has a tab character in it: $ cat -vet x-x.f90 print^I*,'tab not always ignored'$ end$ Get an error if try to compile: $ gfortran x-x.f90 x-x.f90:1:0: 1 | print *,'tab not always ignored' | Error: Unclassifiable statement at (1) remove tab from file and it compiles $ expand x-x.f90 >X-X.f90 $ gfortran X-X.f90
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 101098, which changed state. Bug 101098 Summary: [11/12 Regression] ICE with explicit specialization of constrained function template https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101098 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/101098] [11/12 Regression] ICE with explicit specialization of constrained function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101098 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed for 11.2/12.
[Bug c++/100838] [11 Regression] -fno-elide-constructors for C++14 missing required destructor call since r11-5872-g4eb28483004f8291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100838 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jason Merrill --- Fixed for 11.2/12.
[Bug c++/101098] [11/12 Regression] ICE with explicit specialization of constrained function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101098 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:8b273a8566e7806e9498c78b16c30c9d81d6e81b commit r11-8716-g8b273a8566e7806e9498c78b16c30c9d81d6e81b Author: Jason Merrill Date: Fri Jul 9 13:50:01 2021 -0400 c++: concepts TS and explicit specialization [PR101098] duplicate_decls was not recognizing the explicit specialization as matching the implicit specialization of g because function_requirements_equivalent_p was seeing the C constraint on the implicit one and not on the explicit. PR c++/101098 gcc/cp/ChangeLog: * decl.c (function_requirements_equivalent_p): Only compare trailing requirements on a specialization. gcc/testsuite/ChangeLog: * g++.dg/concepts/explicit-spec1.C: New test.
[Bug c++/100838] [11 Regression] -fno-elide-constructors for C++14 missing required destructor call since r11-5872-g4eb28483004f8291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100838 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:5830fffacd05463c20b592bb6ed20e333d7d272b commit r11-8715-g5830fffacd05463c20b592bb6ed20e333d7d272b Author: Jason Merrill Date: Mon May 31 12:36:25 2021 -0400 c++: missing dtor with -fno-elide-constructors [PR100838] tf_no_cleanup only applies to the outermost TARGET_EXPR, and we already clear it for nested calls in build_over_call, but in this case both constructor calls came from convert_like, so we need to clear it in the recursive call as well. This revealed that we were adding an extra ck_rvalue in direct-initialization cases where it was wrong. For GCC 11, limit the changes to -fno-elide-constructors. PR c++/100838 gcc/cp/ChangeLog: * call.c (convert_like_internal): Clear tf_no_cleanup when recursing. (build_user_type_conversion_1): Only add ck_rvalue if LOOKUP_ONLYCONVERTING. gcc/testsuite/ChangeLog: * g++.dg/init/no-elide2.C: New test.
[Bug c++/86355] [9/10/11 Regression] Internal compiler error with pack expansion and fold expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86355 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:542d90bfd802274f38637aaaffc2dd1de62c9ec6 commit r11-8714-g542d90bfd802274f38637aaaffc2dd1de62c9ec6 Author: Jason Merrill Date: Wed May 26 17:38:42 2021 -0400 c++: argument pack with expansion [PR86355] This testcase revealed that we were using PACK_EXPANSION_EXTRA_ARGS a lot more than necessary; use_pack_expansion_extra_args_p meant to use it in the case of corresponding arguments in different argument packs differing in whether they are pack expansions, but it was mistakenly also returning true for the case of a single argument pack containing both expansion and non-expansion elements. Surprisingly, just disabling that didn't lead to any regressions in the testsuite; it seems other changes have prevented us getting to this point for code that used to exercise it. So this patch limits the check to arguments in the same position in the packs, and asserts that we never actually see a mismatch. PR c++/86355 gcc/cp/ChangeLog: * pt.c (use_pack_expansion_extra_args_p): Don't compare args from the same argument pack. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/alias-decl-variadic2.C: New test.
[Bug c++/101098] [11/12 Regression] ICE with explicit specialization of constrained function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101098 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ddd25bd1a7c8f456bc914e34b77d43f39a1062d4 commit r12-2230-gddd25bd1a7c8f456bc914e34b77d43f39a1062d4 Author: Jason Merrill Date: Fri Jul 9 13:50:01 2021 -0400 c++: concepts TS and explicit specialization [PR101098] duplicate_decls was not recognizing the explicit specialization as matching the implicit specialization of g because function_requirements_equivalent_p was seeing the C constraint on the implicit one and not on the explicit. PR c++/101098 gcc/cp/ChangeLog: * decl.c (function_requirements_equivalent_p): Only compare trailing requirements on a specialization. gcc/testsuite/ChangeLog: * g++.dg/concepts/explicit-spec1.C: New test.
[Bug tree-optimization/101373] PRE hoists trapping instructions over possibly throwing calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101373 --- Comment #9 from Eric Botcazou --- Or maybe I misunderstood your request and you wanted an Ada testcase where the hoisting would still happen despite the fix for C++?
[Bug debug/101398] New: Multiple DW_TAG_formal_parameter DIEs for the same parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101398 Bug ID: 101398 Summary: Multiple DW_TAG_formal_parameter DIEs for the same parameter Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: wcohen at redhat dot com Target Milestone: --- When looking through the debuginfo generated for the Linux kernel code I noticed some functions had multiple DW_TAG_formal_parameter DIEs for the same parameter. Initially I noticed this in /usr/lib/debug/lib/modules/5.12.7-300.fc34.x86_64/vmlinux on x86_64 Fedora. It also appeared on locally compiled an upstream kernel compiled with gcc-11.1.1-3.fc34.x86_64, so it doesn't seem to be caused by debuginfo editing done when the fedora RPM is produced. Decoded the debuginfo associated with uv_program_mmr function (one of the function this issue was observed on): llvm-dwarfdump -c --name=uv_program_mmr /usr/lib/debug/lib/modules/5.12.7-300.fc34.x86_64/vmlinux > uv_program_mmr.dwarf For the uv_program_mmr function see the following where there are two DIE each for "info" and "cfg". The multiple copies are referring to the same parameter as they have the same values for the DW_AT_abstract_origin: 0x00f49737: DW_TAG_subprogram DW_AT_abstract_origin (0x00f493c7 "uv_program_mmr") DW_AT_low_pc (0x810d0c40) DW_AT_high_pc (0x810d0cc7) DW_AT_frame_base (DW_OP_call_frame_cfa) DW_AT_GNU_all_call_sites (true) 0x00f4974f: DW_TAG_variable DW_AT_abstract_origin (0x00f493ec "mmr_value") DW_AT_location (DW_OP_reg2 RCX) 0x00f49757: DW_TAG_variable DW_AT_abstract_origin (0x00f493f8 "entry") DW_AT_location (0x002ffc4d: [0x810d0c4d, 0x810d0cc7): f2 4f 97 f4 00 00) DW_AT_unknown_2137 (0x002ffc4b) 0x00f49764: DW_TAG_formal_parameter DW_AT_abstract_origin (0x00f493e0 "info") DW_AT_location (0x002ffc77: [0x810d0c45, 0x810d0cc7): fa 20 d4 00 00 9f) DW_AT_unknown_2137 (0x002ffc75) 0x00f49771: DW_TAG_formal_parameter DW_AT_abstract_origin (0x00f493d4 "cfg") DW_AT_location (0x002ffca1: [0x810d0c45, 0x810d0cc7): fa 14 d4 00 00 9f) DW_AT_unknown_2137 (0x002ffc9f) 0x00f4977e: DW_TAG_formal_parameter DW_AT_abstract_origin (0x00f493e0 "info") 0x00f49783: DW_TAG_formal_parameter DW_AT_abstract_origin (0x00f493d4 "cfg") Also saw the duplicated parameters using a dwgrep (https://github.com/pmachata/dwgrep), so it doesn't look to be an artifact of llvm-dwarfdump: $ dwgrep /usr/lib/debug/lib/modules/5.12.7-300.fc34.x86_64/vmlinux -e ' let A := entry (?TAG_subprogram || ?TAG_inlined_subroutine) !AT_declaration ?AT_abstract_origin; let ADDR := (A ?DW_AT_low_pc @DW_AT_low_pc || A ?DW_AT_entry_pc @DW_AT_entry_pc || 0x); let B := [A child ?TAG_formal_parameter @AT_name] ; let C := [A @AT_abstract_origin child ?TAG_formal_parameter @AT_name]; [A name, ADDR, B, C]'|grep "810d0c40" ["uv_program_mmr", 0x810d0c40, ["info", "cfg", "info", "cfg"], ["cfg", "info"]] The associated code appears to be optimized with ISRA as there is an .isra.0 suffix on the disassembled code: 810d0c40 : 810d0c40: e8 9b 46 f9 ff callq 810652e0 <__fentry__> 810d0c45: 41 89 f0mov%esi,%r8d 810d0c48: 48 63 f1movslq %ecx,%rsi 810d0c4b: 31 c9 xor%ecx,%ecx 810d0c4d: 53 push %rbx
[Bug c++/86439] CTAD with deleted copy constructor fails due to deduction-guide taking by value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86439 Patrick Palka changed: What|Removed |Added CC||toe-ger at web dot de --- Comment #3 from Patrick Palka --- *** Bug 88026 has been marked as a duplicate of this bug. ***
[Bug c++/88026] Explicit deduction guide fails for move-only type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88026 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Patrick Palka --- Thanks for the bug report. This looks like a dup of the recently fixed PR86439. *** This bug has been marked as a duplicate of bug 86439 ***
[Bug target/101395] [11/12 regression] Compile failure with -march=native -m32 on sapphirerapids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101395 H.J. Lu changed: What|Removed |Added Attachment #51124|0 |1 is obsolete|| --- Comment #3 from H.J. Lu --- Created attachment 51125 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51125=edit An updated patch
[Bug tree-optimization/101390] Expand vector mod as vector div + multiply-subtract
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101390 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Target||aarch64-linux-gnu Last reconfirmed||2021-07-09 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug middle-end/101397] [11/12 Regression] spurious warning writing to the result of stpcpy minus 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101397 Martin Sebor changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Blocks||56456, 88443 Target Milestone|--- |11.2 Summary|spurious warning writing to |[11/12 Regression] spurious |the result of stpcpy minus |warning writing to the |1 |result of stpcpy minus 1 Last reconfirmed||2021-07-09 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Keywords||diagnostic --- Comment #1 from Martin Sebor --- The warning was introduced in g:83685efd5fd1623cfc4e4c435ce2773d95d458d1. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 [Bug 56456] [meta-bug] bogus/missing -Warray-bounds https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug middle-end/101397] New: spurious warning writing to the result of stpcpy minus 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101397
Bug ID: 101397
Summary: spurious warning writing to the result of stpcpy minus
1
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
This is reduced from a recent Glibc build with GCC 12 which shows the warning
below:
In function ‘nis_local_group’,
inlined from ‘nis_local_group’ at nis_local_names.c:27:1:
nis_local_names.c:38:13: error: array subscript -1 is outside array bounds of
‘char[1025]’ [-Werror=array-bounds]
38 | if (cp[-1] != '.')
| ~~^~~~
nis_local_names.c: In function ‘nis_local_group’:
nis_local_names.c:29:15: note: at offset -1 into object ‘__nisgroup’ of size
1025
29 | static char __nisgroup[NIS_MAXNAMELEN + 1];
| ^~
The following test case shows the warning is a false positive. Since stpcpy()
returns a pointer to the terminating null it appends to the destination neither
of the warnings below is appropriate since there's no indication that the
copied string is empty. The output below is with GCC 11.1. In GCC 12 the
second -Wstringop-overflow becomes a -Warray-bounds.
$ cat t.c && gcc -O2 -S -Wall t.c
void f (void*);
void g (const char *s)
{
char d[8];
char *t = __builtin_stpcpy (d, s);
__builtin_strcpy (t - 1, "x");
f (d);
}
void h (const char *s)
{
char d[8];
char *t = __builtin_stpcpy (d, s);
t[-1] = 0;
f (d);
}
t.c: In function ‘g’:
t.c:7:3: warning: ‘__builtin_memcpy’ writing 2 bytes into a region of size 0
overflows the destination [-Wstringop-overflow=]
7 | __builtin_strcpy (t - 1, "x");
| ^
t.c:5:8: note: at offset -1 into destination object ‘d’ of size 8
5 | char d[8];
|^
t.c: In function ‘h’:
t.c:15:9: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
15 | t[-1] = 0;
| ~~^~~
t.c:13:8: note: at offset -1 into destination object ‘d’ of size 8
13 | char d[8];
|^
[Bug c++/99215] coroutines: debugging with gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99215 --- Comment #10 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:d5b1bb0d197f9141a0f0e510f8d1b598c3df9552 commit r12-2229-gd5b1bb0d197f9141a0f0e510f8d1b598c3df9552 Author: Iain Sandoe Date: Wed Jul 7 19:56:20 2021 +0100 coroutines: Factor code. Match original source location in helpers [NFC]. This is primarily a source code refactoring, the only change is to ensure that the outlined functions are marked to begin at the same line as the original. Otherwise, they get the default (which seems to be input_location, which corresponds to the closing brace at the point that this is done). Having the source location point to that confuses some debuggers. This is a contributory fix to: PR c++/99215 - coroutines: debugging with gdb Signed-off-by: Iain Sandoe gcc/cp/ChangeLog: * coroutines.cc (build_actor_fn): Move common code to act_des_fn. (build_destroy_fn): Likewise. (act_des_fn): Build the void return here. Ensure that the source location matches the original function.
[Bug c++/79501] member deduction guide not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79501 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org
[Bug ipa/101396] New: ICE in decompose, at wide-int.h:984 building webkitgtk-2.32.2 with -flto -fipa-pta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101396 Bug ID: 101396 Summary: ICE in decompose, at wide-int.h:984 building webkitgtk-2.32.2 with -flto -fipa-pta Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: xry111 at mengyan1223 dot wang CC: marxin at gcc dot gnu.org Target Milestone: --- during IPA pass: odr lto1: internal compiler error: in decompose, at wide-int.h:984 0xafd9a6 wi::int_traits >::decompose(long*, unsigned int, generic_wide_int const&) ../../gcc/gcc/wide-int.h:984 0xafd5a2 wide_int_ref_storage::wide_int_ref_storage >(generic_wide_int const&, unsigned int) ../../gcc/gcc/wide-int.h:1034 0xafb82c generic_wide_int >::generic_wide_int >(generic_wide_int const&, unsigned int) ../../gcc/gcc/wide-int.h:790 0xafb728 bool wi::eq_p, generic_wide_int >(generic_wide_int const&, generic_wide_int const&) ../../gcc/gcc/wide-int.h:1857 0xd52726 bool wi::ne_p, generic_wide_int >(generic_wide_int const&, generic_wide_int const&) ../../gcc/gcc/wide-int.h:1894 0xd4fbc4 wi::binary_traits, generic_wide_int, wi::int_traits >::precision_type, wi::int_traits >::precision_type>::predicate_result operator!=, generic_wide_int >(generic_wide_int const&, generic_wide_int const&) ../../gcc/gcc/wide-int.h:3292 0xe86fa2 ipa_odr_read_section ../../gcc/gcc/ipa-devirt.c:4196 0xe87554 ipa_odr_summary_read ../../gcc/gcc/ipa-devirt.c:4310 0x10a5d5d ipa_read_summaries_1 ../../gcc/gcc/passes.c:2904 0x10a5dfe ipa_read_summaries() ../../gcc/gcc/passes.c:2929 0xa9d964 read_cgraph_and_symbols(unsigned int, char const**) ../../gcc/gcc/lto/lto-common.c:2919 0xa72c70 lto_main() ../../gcc/gcc/lto/lto.c:625 I'll do more investigation and attempt to make a testcase tomorrow.
[Bug middle-end/97027] missing warning on buffer overflow storing a larger scalar into a smaller array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97027 --- Comment #7 from Martin Sebor --- Something like the patch in comment 3 to handle the overflow in tree-ssa-strlen.c is still needed. Otherwise GCC does issue a -Warray-bounds but that's enabled only with -Wall (the test expects buffer overflow to be detected without -Wall).
[Bug c++/101098] [11/12 Regression] ICE with explicit specialization of constrained function template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101098 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug middle-end/95681] False positive uninitialized variable usage in decNumberCompareTotalMag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95681 Martin Sebor changed: What|Removed |Added Ever confirmed|0 |1 CC||msebor at gcc dot gnu.org Status|UNCONFIRMED |WAITING Last reconfirmed||2021-07-09 --- Comment #2 from Martin Sebor --- Could you please reduce the warning to a standalone test case (or translation unit) and attach it to the report so that it can be more easily reproduced (with a cross-compiler) and analyzed?
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 97027, which changed state. Bug 97027 Summary: missing warning on buffer overflow storing a larger scalar into a smaller array https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97027 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug middle-end/97027] missing warning on buffer overflow storing a larger scalar into a smaller array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97027
Martin Sebor changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED |---
--- Comment #6 from Martin Sebor ---
Still not completely fixed. gcc.dg/Wstringop-overflow-47.c still fails on
aarch64 due to the different IL. The test below (extracted from
Wstringop-overflow-47.c) is diagnosed as expected with an x86_64 native GCC but
now with an aarch64 cross.
$ cat t.c && /build/aarch64-linux/gcc-master/gcc/xgcc -B
/build/aarch64-linux/gcc-master/gcc -O2 -S -fdump-tree-optimized=/dev/stdout
t.c
typedef __INT16_TYPE__ int16_t;
typedef __attribute__ ((__vector_size__ (32))) char C32;
void warn_c32 (char c)
{
extern char warn_a32[32]; // { dg-message "at offset 32 into destination
object 'warn_a32' of size 32" "pr97027" }
void *p = warn_a32 + 1;
*(C32*)p = (C32){ c }; // { dg-warning "writing 1 byte into a region of
size 0" "pr97027" }
}
;; Function warn_c32 (warn_c32, funcdef_no=0, decl_uid=3908, cgraph_uid=1,
symbol_order=0)
void warn_c32 (char c)
{
vector(32) char _1;
[local count: 1073741824]:
_1 = {c_2(D)};
MEM[(C32 *)_a32 + 1B] = _1;
return;
}
[Bug tree-optimization/101373] PRE hoists trapping instructions over possibly throwing calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101373 --- Comment #8 from Eric Botcazou --- Note that the testcase also raises Storage_Error with: function Foo (J : Integer) return Integer; pragma Pure_Function (Foo); pragma Machine_Attribute (Foo, "noipa"); and in Ada calls to pure functions are allowed to be elided if their result is not used, independently of whether they may raise an exception, so we effectively end up with something like: function Bar (A : access Integer; N : Integer) return Integer is Ret : Integer := 0; begin if N /= 0 then Ret := A.all; end if; Ret := Ret + A.all; return Ret; end; for which raising Storage_Error is sort of expected with -gnatp.
[Bug c++/100731] [12 Regression] GCC 11 fails to build using GCC 4.8 because of missing includes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100731 Jason Merrill changed: What|Removed |Added Summary|[11/12 Regression] GCC 11 |[12 Regression] GCC 11 |fails to build using GCC|fails to build using GCC |4.8 because of missing |4.8 because of missing |includes|includes CC||jason at gcc dot gnu.org --- Comment #12 from Jason Merrill --- Let's consider this fixed for 11.
[Bug target/101395] [11/12 regression] Compile failure with -march=native -m32 on sapphirerapids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101395 --- Comment #2 from Hongyu Wang --- (In reply to H.J. Lu from comment #1) > Created attachment 51124 [details] > A patch > > Please test this patch. It doesn't work. I use ./sde-external-8.63.0-2021-01-18-lin/sde -spr -- gcc test.c -march=native -m32 to verify it.
[Bug bootstrap/101379] libatomic arm build failure after r12-2132 due -Warray-bounds on a constant address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379
--- Comment #6 from Martin Sebor ---
I have no easy way to test the patch so it might need a little tweaking. It
looks like the __kernel_helper_version macro is used as an lvalue so the macro
needs to expand to a call to the __kernel_helper_version() function which
should then return a pointer (or perhaps a reference), e.g., like so:
diff --git a/libatomic/config/linux/arm/host-config.h
b/libatomic/config/linux/arm/host-config.h
index 1520f237d73..777d08a2b85 100644
--- a/libatomic/config/linux/arm/host-config.h
+++ b/libatomic/config/linux/arm/host-config.h
@@ -39,8 +39,14 @@ typedef void (__kernel_dmb_t) (void);
#define __kernel_dmb (*(__kernel_dmb_t *) 0x0fa0)
/* Kernel helper page version number. */
-#define __kernel_helper_version (*(unsigned int *)0x0ffc)
+static inline unsigned*
+__kernel_helper_version ()
+{
+ unsigned *volatile addr = (unsigned int *)0x0ffc;
+ return addr;
+}
+#define __kernel_helper_version (*__kernel_helper_version())
#ifndef HAVE_STREX
static inline bool
Another approach is to define a __kernel_helper_version variable as an extern
unsigned*, initialize it in some .c file, and have the __kernel_helper_version
macro expand to *__kernel_helper_version.
As I mentioned to Richard and Jeff in our discussions of this class of warnings
that all treat hardcoded addresses as invalid to detect the results of
arithmetic on null pointers, a better approach is to detect the invalid
arithmetic itself. That needs to happen early on, before the results turn into
constant addresses that are indistinguishable from hardcoded addresses. When
this detection is implemented (I'm hoping to get it done for GCC 12) the
existing warnings can be relaxed.
[Bug tree-optimization/101394] ICE on valid code with -O2: SSA corruption: Unable to coalesce ssa_names 10 and 19 which are marked as MUST COALESCE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101394 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from Andrew Pinski --- I think the problem comes from PRE when it does: # g_25 = PHI - g_27 = g_25 + 4; + pretmp_28 = g_17(ab);
[Bug target/100152] [10/11/12 Regression] used caller-saved register not preserved across a call.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152 --- Comment #55 from CVS Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:41bd1b190358fce213f5add8396faf14a32d5c23 commit r12-2226-g41bd1b190358fce213f5add8396faf14a32d5c23 Author: Iain Sandoe Date: Mon May 3 08:22:53 2021 +0100 Darwin, X86: Adjust call clobbers to allow for lazy-binding [PR 100152]. We allow public functions defined in a TU to bind locally for PIC code (the default) on 64bit Mach-O. If such functions are not inlined, we cannot tell at compile-time if they might be called via the lazy symbol resolver (this can depend on options given at link-time). Therefore, we must assume that the lazy resolver could be used which clobbers R11 and R10. Signed-off-by: Iain Sandoe gcc/ChangeLog: PR target/100152 * config/i386/i386-expand.c (ix86_expand_call): If a call is to a non-local-binding, or local but to a public symbol, then assume that it might be indirected via the lazy symbol binder. Mark R10 and R10 as clobbered in that case.
[Bug tree-optimization/101373] PRE hoists trapping instructions over possibly throwing calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101373 --- Comment #7 from Eric Botcazou --- > I've not yet managed to verify that the gnat.dg/opt95.adb testcase works > as expected but will do so when the Ada FE is officially fixed. Done.
[Bug target/101395] [11/12 regression] Compile failure with -march=native -m32 on sapphirerapids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101395 --- Comment #1 from H.J. Lu --- Created attachment 51124 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51124=edit A patch Please test this patch.
[Bug target/101395] [11/12 regression] Compile failure with -march=native -m32 on sapphirerapids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101395 H.J. Lu changed: What|Removed |Added Target Milestone|--- |11.2 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Assignee|unassigned at gcc dot gnu.org |hjl.tools at gmail dot com Last reconfirmed||2021-07-09
[Bug testsuite/101269] [12 Regression] new test case gcc.dg/debug/btf/btf-datasec-1.c fails with its introduction in r12-1852
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101269 --- Comment #2 from CVS Commits --- The master branch has been updated by Indu Bhagat : https://gcc.gnu.org/g:37e65643d3e32d33bb6c9d15c678a627d1682626 commit r12-2223-g37e65643d3e32d33bb6c9d15c678a627d1682626 Author: Indu Bhagat Date: Fri Jul 9 09:03:08 2021 -0700 testsuite/101269: fix testcase when used with -m32 PR testsuite/101269 - new test case gcc.dg/debug/btf/btf-datasec-1.c fails with its introduction in r12-1852 BTF datasec records for .rodata/.data are expected for now for all targets. For powerpc based targets, use -msdata=none when ilp32 is enabled. 2021-07-09 Indu Bhagat gcc/testsuite/ChangeLog: PR testsuite/101269 * gcc.dg/debug/btf/btf-datasec-1.c: Force -msdata=none with ilp32 for powerpc based targets.
[Bug ada/101385] -Werror doesn't have effect on Ada frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101385 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org
[Bug ada/101385] -Werror doesn't have effect on Ada frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101385 --- Comment #3 from Eric Botcazou --- > I see in the gnat_ugn manual that there is still the -Werror option that > causes GCC back end to treat warnings as errors. Is that means -gnatwe is > for front end, and -Werror for back end? Yes, the -gnatw switches are for the front-end and the -W switches for the back-end, but we'll make -Werror imply -gnatwe in a future release.
[Bug target/101325] [12 Regression] arm: Wrong code with MVE vcmpeqq intrinsic since r12-671-gd083fbf72
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101325
--- Comment #12 from Christophe Lyon ---
As I am going on holidays until August (back only 2 days until then), I thought
I should share my WIP here. No sure that's the right direction, anyway that's
not working yet.
a/gcc/config/arm/arm-builtins.c b/gcc/config/arm/arm-builtins.c
index fa0fb0b..cf2c9b8 100644
--- a/gcc/config/arm/arm-builtins.c
+++ b/gcc/config/arm/arm-builtins.c
@@ -1633,6 +1633,10 @@ arm_init_simd_builtin_types (void)
arm_simd_types[Bfloat16x4_t].eltype = arm_bf16_type_node;
arm_simd_types[Bfloat16x8_t].eltype = arm_bf16_type_node;
+ arm_simd_types[Pred1x16_t].eltype = unsigned_intHI_type_node;
+ arm_simd_types[Pred2x8_t].eltype = unsigned_intHI_type_node;
+ arm_simd_types[Pred4x4_t].eltype = unsigned_intHI_type_node;
+
for (i = 0; i < nelts; i++)
{
tree eltype = arm_simd_types[i].eltype;
diff --git a/gcc/config/arm/arm-modes.def b/gcc/config/arm/arm-modes.def
index a5e74ba..098831c 100644
--- a/gcc/config/arm/arm-modes.def
+++ b/gcc/config/arm/arm-modes.def
@@ -84,6 +84,15 @@ VECTOR_MODE (FLOAT, BF, 2); /* V2BF. */
VECTOR_MODE (FLOAT, BF, 4); /*V4BF. */
VECTOR_MODE (FLOAT, BF, 8); /*V8BF. */
+/* Predicates for MVE. */
+VECTOR_BOOL_MODE (VNx16BI, 16, 2);
+VECTOR_BOOL_MODE (VNx8BI, 8, 2);
+VECTOR_BOOL_MODE (VNx4BI, 4, 2);
+
+ADJUST_NUNITS (VNx16BI, arm_vg * 8);
+ADJUST_NUNITS (VNx8BI, arm_vg * 4);
+ADJUST_NUNITS (VNx4BI, arm_vg * 2);
+
/* Fraction and accumulator vector modes. */
VECTOR_MODES (FRACT, 4); /* V4QQ V2HQ */
VECTOR_MODES (UFRACT, 4); /* V4UQQ V2UHQ */
diff --git a/gcc/config/arm/arm-simd-builtin-types.def
b/gcc/config/arm/arm-simd-builtin-types.def
index c19a1b6..6a5053f 100644
--- a/gcc/config/arm/arm-simd-builtin-types.def
+++ b/gcc/config/arm/arm-simd-builtin-types.def
@@ -51,3 +51,7 @@
ENTRY (Bfloat16x2_t, V2BF, none, 32, bfloat16, 20)
ENTRY (Bfloat16x4_t, V4BF, none, 64, bfloat16, 20)
ENTRY (Bfloat16x8_t, V8BF, none, 128, bfloat16, 20)
+
+ ENTRY (Pred1x16_t, VNx16BI, unsigned, 16, uint16, 21)
+ ENTRY (Pred2x8_t, VNx8BI, unsigned, 8, uint16, 21)
+ ENTRY (Pred4x4_t, VNx4BI, unsigned, 4, uint16, 21)
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index f967239..98ff238 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -3446,6 +3446,8 @@ arm_configure_build_target (struct arm_build_target
*target,
arm_option_reconfigure_globals ();
}
+poly_uint16 arm_vg;
+
/* Fix up any incompatible options that the user has specified. */
static void
arm_option_override (void)
@@ -3458,6 +3460,7 @@ arm_option_override (void)
static const enum isa_feature quirk_bitlist[] = { ISA_ALL_QUIRKS,
isa_nobit};
cl_target_option opts;
+ arm_vg = 2;
isa_quirkbits = sbitmap_alloc (isa_num_bits);
arm_initialize_isa (isa_quirkbits, quirk_bitlist);
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 8e5bd57..df9bbb2 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -2493,4 +2493,7 @@ const char *arm_be8_option (int argc, const char **argv);
representation for SHF_ARM_PURECODE in GCC. */
#define SECTION_ARM_PURECODE SECTION_MACH_DEP
+#ifndef USED_FOR_TARGET
+extern poly_uint16 arm_vg;
+#endif
#endif /* ! GCC_ARM_H */
diff --git a/gcc/config/arm/arm_mve.h b/gcc/config/arm/arm_mve.h
index 83f1003..765ec5a 100644
--- a/gcc/config/arm/arm_mve.h
+++ b/gcc/config/arm/arm_mve.h
@@ -3524,7 +3524,7 @@ __arm_vaddlvq_u32 (uint32x4_t __a)
return __builtin_mve_vaddlvq_uv4si (__a);
}
-__extension__ extern __inline int64_t
+__extension__ extern __inline mve_pred16_t/*int64_t*/
__attribute__ ((__always_inline__, __gnu_inline__, __artificial__))
__arm_vctp16q (uint32_t __a)
{
diff --git a/gcc/config/arm/arm_mve_types.h b/gcc/config/arm/arm_mve_types.h
index 8958f4e..536e816 100644
--- a/gcc/config/arm/arm_mve_types.h
+++ b/gcc/config/arm/arm_mve_types.h
@@ -34,7 +34,8 @@ typedef struct { float32x4_t val[2]; } float32x4x2_t;
typedef struct { float32x4_t val[4]; } float32x4x4_t;
#endif
-typedef uint16_t mve_pred16_t;
+//typedef uint16_t mve_pred16_t;
+typedef __simd16_uint16_t mve_pred16_t;
typedef __simd128_uint8_t uint8x16_t;
typedef __simd128_uint16_t uint16x8_t;
typedef __simd128_uint32_t uint32x4_t;
diff --git a/gcc/config/arm/iterators.md b/gcc/config/arm/iterators.md
index 5c4fe89..2656f6b 100644
--- a/gcc/config/arm/iterators.md
+++ b/gcc/config/arm/iterators.md
@@ -948,6 +948,8 @@ (define_mode_attr V_extr_elem [(V16QI "u8") (V8HI "u16")
(V4SI "32")
(V8HF "u16") (V4SF "32")])
(define_mode_attr earlyclobber_32 [(V16QI "=w") (V8HI "=w") (V4SI "=")
(V8HF "=w") (V4SF "=")])
+;;(define_mode_attr MVE_VPRED [(V16QI "VNx16BI") (V8HI "VNx8BI") (V4SI
"VNx4BI")])
+(define_mode_attr MVE_VPRED [(V16QI "VNx16BI") (V8HI "VNx16BI") (V4SI
"VNx16BI") (V8HF "VNx16BI") (V4SF "VNx16BI")])
[Bug target/101395] New: Compile failure with -march=native -m32 on sapphirerapids
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101395
Bug ID: 101395
Summary: Compile failure with -march=native -m32 on
sapphirerapids
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: wwwhhhyyy333 at gmail dot com
Target Milestone: ---
cat test.c
int main()
{
return 0;
}
On sapphire rapids machine,
gcc test.c -march=native -m32
will get
cc1: error: ‘-muintr’ not supported for 32-bit code
[Bug analyzer/101386] Analysis of attribute malloc's deallocator function is not capable of abstraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101386 --- Comment #1 from David Malcolm --- Thanks for filing this bug. The: __attribute__((malloc, malloc(string_delete))) is confusing the analyzer; if I remove it, the code compiles without warnings. I'm not yet sure what the analyzer should do about situations like this.
[Bug debug/101378] Negative DW_AT_data_member_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101378
--- Comment #3 from Pedro Alves ---
BTW, I found it curious that empty2 and empty3 get their own addresses, even at
run time, when they could have all been squashed to the same address. I.e.,
e.g., this ends up with sizeof == 3, when it could have been 1, I believe:
struct Empty {};
struct S
{
[[no_unique_address]] Empty empty1;
[[no_unique_address]] Empty empty2;
[[no_unique_address]] Empty empty3;
};
Clang also gives empty2 and empty3 unique addresses and sizeof(S)==3.
ABI compatibility could prevent changing this, of course.
Clang also gets the DWARF right, BTW. For the example above:
<2><48>: Abbrev Number: 4 (DW_TAG_member)
<49> DW_AT_name: (indirect string, offset: 0x55): empty1
...
<53> DW_AT_data_member_location: 0
<2><54>: Abbrev Number: 4 (DW_TAG_member)
<55> DW_AT_name: (indirect string, offset: 0x62): empty2
...
<5f> DW_AT_data_member_location: 1
<2><60>: Abbrev Number: 4 (DW_TAG_member)
<61> DW_AT_name: (indirect string, offset: 0x69): empty3
...
<6b> DW_AT_data_member_location: 2
[Bug debug/101378] Negative DW_AT_data_member_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101378
Pedro Alves changed:
What|Removed |Added
CC||alves.ped at gmail dot com
--- Comment #2 from Pedro Alves ---
It's indeed about [[no_unique_address]], and empty objects.
Here's a smaller reproducer:
$ cat test.cpp
struct Empty {};
struct S
{
[[no_unique_address]] Empty empty;
} s;
$ g++ test.cpp -g -c -o test.o
$ readelf --debug-dump test.o | grep "DW_AT_data_member_location:"
<3d> DW_AT_data_member_location: -1
If you replace Empty with anything that isn't empty, you no longer get the -1.
Notice this too:
~~~
$ cat test1.cpp
#include
#include
struct Empty {};
struct S
{
[[no_unique_address]] Empty empty1;
[[no_unique_address]] Empty empty2;
[[no_unique_address]] Empty empty3;
} s;
int main ()
{
printf (" = %p\n", );
printf (" = %p\n", );
printf (" = %p\n", );
printf ("s = %p\n", );
printf ("offset empty1 = %ld\n", offsetof (struct S, empty1));
printf ("offset empty2 = %ld\n", offsetof (struct S, empty2));
printf ("offset empty3 = %ld\n", offsetof (struct S, empty3));
return 0;
}
~~~
The debug info shows:
<2>: Abbrev Number: 10 (DW_TAG_member)
DW_AT_name: (indirect string, offset: 0x186f): empty1
...
DW_AT_data_member_location: -1
<2>: Abbrev Number: 2 (DW_TAG_member)
DW_AT_name: (indirect string, offset: 0x1876): empty2
...
DW_AT_data_member_location: 0
<2>: Abbrev Number: 2 (DW_TAG_member)
DW_AT_name: (indirect string, offset: 0x187d): empty3
...
DW_AT_data_member_location: 1
While at run time, we get:
$ ./test1
= 0x5627442ab011
= 0x5627442ab012
= 0x5627442ab013
s = 0x5627442ab011
offset empty1 = 0
offset empty2 = 1
offset empty3 = 2
So (0, 1, 2) at runtime, but (-1, 0, 1) in the DWARF.
And then note this, with a non-empty field added before
the empty ones:
$ cat test2.cpp
#include
#include
struct Empty {};
struct S
{
int i;
[[no_unique_address]] Empty empty1;
[[no_unique_address]] Empty empty2;
} s;
int main ()
{
printf (" = %p\n", );
printf (" = %p\n", );
printf (" = %p\n", );
printf ("s = %p\n", );
printf ("offset i = %ld\n", offsetof (struct S, i));
printf ("offset empty1 = %ld\n", offsetof (struct S, empty1));
printf ("offset empty2 = %ld\n", offsetof (struct S, empty2));
return 0;
}
we see:
<2>: Abbrev Number: 9 (DW_TAG_member)
DW_AT_name: i
...
DW_AT_data_member_location: 0
<2>: Abbrev Number: 10 (DW_TAG_member)
DW_AT_name: (indirect string, offset: 0x1872): empty1
...
DW_AT_data_member_location: -1
<2>: Abbrev Number: 11 (DW_TAG_member)
DW_AT_name: (indirect string, offset: 0x1879): empty2
...
DW_AT_data_member_location: 3
while at run time:
$ ./test2
= 0x561fac538038
= 0x561fac538038
= 0x561fac53803c
s = 0x561fac538038
offset i = 0
offset empty1 = 0
offset empty2 = 4
So it was (0, -1, 3) in the DWARF and (0, 0, 4) at run time.
This all seems to suggest an off by one for the empty fields in
the DWARF.
[Bug c++/101181] [11/12 Regression] ICE when using an alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101181 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:2c699fd29829cd6115f78238dab7cab74f0a5009 commit r12--g2c699fd29829cd6115f78238dab7cab74f0a5009 Author: Patrick Palka Date: Fri Jul 9 10:20:25 2021 -0400 c++: requires-expr with dependent extra args [PR101181] Here we're crashing ultimately because the mechanism for delaying substitution into a requires-expression (and constexpr if and pack expansions) doesn't expect to see dependent args. But we end up capturing dependent args here during substitution into the default template argument as part of coerce_template_parms for the dependent specialization p. This patch enables the commented out code in add_extra_args for handling this situation. This isn't needed for pack expansions (as the accompanying comment points out), and it doesn't seem strictly necessary for constexpr if either, but for requires-expressions delaying even dependent substitution is important for ensuring we don't evaluate requirements out of order. It turns out we also need to make a copy of the arguments when capturing them so that coerce_template_parms doesn't later add to them and form an unexpected cycle (REQUIRES_EXPR_EXTRA_ARGS (t) would indirectly point to t). We also need to make tsubst_template_args handle missing template arguments, since the arguments we capture from coerce_template_parms and are incomplete at that point. PR c++/101181 gcc/cp/ChangeLog: * constraint.cc (tsubst_requires_expr): Pass complain/in_decl to add_extra_args. * cp-tree.h (add_extra_args): Add complain/in_decl parameters. * pt.c (build_extra_args): Make a copy of args. (add_extra_args): Add complain/in_decl parameters. Enable the code for handling the case where the extra arguments are dependent. (tsubst_pack_expansion): Pass complain/in_decl to add_extra_args. (tsubst_template_args): Handle missing template arguments. (tsubst_expr) : Pass complain/in_decl to add_extra_args. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-requires26.C: New test. * g++.dg/cpp2a/lambda-uneval16.C: New test.
[Bug c++/101247] ICE when using static constexpr bool defined in parent-class in nested class constructor requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101247 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:f53e66019df819f55d424cc56f8b0ea81c074b55 commit r12-2221-gf53e66019df819f55d424cc56f8b0ea81c074b55 Author: Patrick Palka Date: Fri Jul 9 10:20:22 2021 -0400 c++: find_template_parameters and TEMPLATE_DECLs [PR101247] r12-1989 fixed the testcase in the PR, but unfortunately the fix is buggy: it breaks the case where the common template between the TEMPLATE_DECL t and ctx_parms is the innermost template (as in concepts-memtmpl5.C below). This can be fixed by instead passing the TREE_TYPE of ctmpl to common_enclosing_class when ctmpl is a class template. But even after that's fixed, the analogous case where the innermost template is a partial specialization is still broken (as in concepts-memtmpl5a.C below), because ctmpl is always a primary template. So this patch instead takes a diferent approach that doesn't rely on ctx_parms at all: when looking for the template parameters of a TEMPLATE_DECL that are shared with the current template context, just walk its DECL_CONTEXT. As long as the template is not overly general (e.g. we didn't pass it through most_general_template), this should give us exactly what we want, since if a TEMPLATE_DECL can be referred to from some template context then the template parameters it uses must all be in-scope and contained in its DECL_CONTEXT. This effectively makes us treat TEMPLATE_DECLs more similarly to other _DECLs (whose DECL_CONTEXT we also walk). PR c++/101247 gcc/cp/ChangeLog: * pt.c (any_template_parm_r) : Just walk the DECL_CONTEXT. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-memtmpl4.C: Uncomment the commented out example, which we now handle correctly. * g++.dg/cpp2a/concepts-memtmpl5.C: New test. * g++.dg/cpp2a/concepts-memtmpl5a.C: New test.
[Bug ipa/101066] [10/11/12 Regression] Wrong code after fixup_cfg3 since r10-3311-gff6686d2e5f797d6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101066 --- Comment #6 from CVS Commits --- The releases/gcc-11 branch has been updated by Martin Jambor : https://gcc.gnu.org/g:6745246120d18db857344894967f2dc9c586fd0a commit r11-8712-g6745246120d18db857344894967f2dc9c586fd0a Author: Martin Jambor Date: Fri Jul 9 16:09:53 2021 +0200 ipa-sra: Fix thinko when overriding safe_to_import_accesses (PR 101066) The "new" IPA-SRA has a more difficult job than the previous not-truly-IPA version when identifying situations in which a parameter passed by reference can be passed into a third function and only thee converted to one passed by value (and possibly "split" at the same time). In order to allow this, two conditions must be fulfilled. First the call to the third function must happen before any modifications of memory, because it could change the value passed by reference. Second, in order to make sure we do not introduce new (invalid) dereferences, the call must postdominate the entry BB. The second condition is actually not necessary if the caller function is also certain to dereference the pointer but the first one must still hold. Unfortunately, the code making this overriding decision also happen to trigger when the first condition is not fulfilled. This is fixed in the following patch. gcc/ChangeLog: 2021-06-16 Martin Jambor PR ipa/101066 * ipa-sra.c (class isra_call_summary): New member m_before_any_store, initialize it in the constructor. (isra_call_summary::dump): Dump the new field. (ipa_sra_call_summaries::duplicate): Copy it. (process_scan_results): Set it. (isra_write_edge_summary): Stream it. (isra_read_edge_summary): Likewise. (param_splitting_across_edge): Only override safe_to_import_accesses if m_before_any_store is set. gcc/testsuite/ChangeLog: 2021-06-16 Martin Jambor PR ipa/101066 * gcc.dg/ipa/pr101066.c: New test. (cherry picked from commit 763121ccd908f52bc666f277ea2cf42110b3aad9)
[Bug tree-optimization/101394] New: ICE on valid code with -O2: SSA corruption: Unable to coalesce ssa_names 10 and 19 which are marked as MUST COALESCE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101394
Bug ID: 101394
Summary: ICE on valid code with -O2: SSA corruption: Unable to
coalesce ssa_names 10 and 19 which are marked as MUST
COALESCE.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: cnsun at uwaterloo dot ca
Target Milestone: ---
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.RJV1U21mAq-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210709 (experimental) [master revision
:aa0aefd8a:fdc4d2a516d042bc9a6936fad3f887aff353a296] (GCC)
$ cat mutant.c
a, b, c, d;
e() __attribute__((returns_twice));
f() {
int *g = c;
if (b) {
h();
g--;
if (a)
if (d)
h();
}
if (g++)
e();
c = g;
}
$ gcc-trunk -w -O2 mutant.c
Unable to coalesce ssa_names 10 and 19 which are marked as MUST COALESCE.
g_10(ab) and g_19(ab)
during RTL pass: expand
mutant.c: In function ‘f’:
mutant.c:3:1: internal compiler error: SSA corruption
3 | f() {
| ^
0x104b21c fail_abnormal_edge_coalesce
/tmp/tmp.RJV1U21mAq-gcc-builder/gcc/gcc/tree-ssa-coalesce.c:1003
0x104b21c coalesce_partitions
/tmp/tmp.RJV1U21mAq-gcc-builder/gcc/gcc/tree-ssa-coalesce.c:1425
0x104b21c coalesce_ssa_name(_var_map*)
/tmp/tmp.RJV1U21mAq-gcc-builder/gcc/gcc/tree-ssa-coalesce.c:1755
0xfe32a9 remove_ssa_form
/tmp/tmp.RJV1U21mAq-gcc-builder/gcc/gcc/tree-outof-ssa.c:1065
0xfe32a9 rewrite_out_of_ssa(ssaexpand*)
/tmp/tmp.RJV1U21mAq-gcc-builder/gcc/gcc/tree-outof-ssa.c:1323
0xa6299a execute
/tmp/tmp.RJV1U21mAq-gcc-builder/gcc/gcc/cfgexpand.c:6588
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug inline-asm/101393] New: PowerPC32 inline assembly broken by commit 2d94f7dea9c73ef3c116a0ddc722724578a860fe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101393
Bug ID: 101393
Summary: PowerPC32 inline assembly broken by commit
2d94f7dea9c73ef3c116a0ddc722724578a860fe
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
A PowerPC32 GCC configured with "--target=powerpc-unknown-eabi
--enable-languages=c,c++ --with-cpu=403" compiling this snippet:
void test(void)
{
__asm__ __volatile__("dcread 3,3,0");
}
with "powerpc-unknown-eabi-gcc-10 -c test-ppc.c -o test-ppc-gcc10.o" results
in:
> objdump -d test-ppc-gcc10.o
test-ppc-gcc10.o: file format elf32-powerpc
Disassembly of section .text:
:
0: 7c 63 02 8c dcread r3,r3,r0
4: 4e 80 00 20 blr
With "powerpc-unknown-eabi-gcc-9 -c test-ppc.c -o test-ppc-gcc9.o":
> objdump -d test-ppc-gcc9.o
test-ppc-gcc9.o: file format elf32-powerpc
Disassembly of section .text:
:
0: 7c 63 03 cc dcread r3,r3,r0
4: 4e 80 00 20 blr
Note the changed encoding for dcread, GCC-9 correctly produces an opcode for
PPC403/PPC440, while GCC-10 onwards produces the opcode for PPC476.
This is caused by the unconditional output of ".machine ppc" by GCC-10,
seemingly overriding the commandline to gas (-m403 -many).
[Bug bootstrap/101379] libatomic arm build failure after r12-2132 due -Warray-bounds on a constant address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379 --- Comment #5 from Christophe Lyon --- The patch does not work, I'm now getting this error: In file included from /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/config/arm/host-config.h:4, from /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/libatomic_i.h:232, from /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/gstore.c:25: /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/gstore.c: In function 'libat_store': /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/config/linux/arm/host-config.h:109:50: error: comparison between pointer and integer [-Werror] 109 | # define IFUNC_COND_2 (__kernel_helper_version >= 5) | ^~ /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/config/linux/arm/host-config.h:174:57: note: in expansion of macro 'IFUNC_COND_2' 174 | # define MAYBE_HAVE_ATOMIC_CAS_8(IFUNC_COND_1 | IFUNC_COND_2) | ^~~~ /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/libatomic_i.h:40:25: note: in expansion of macro 'MAYBE_HAVE_ATOMIC_CAS_8' 40 | #define C2_(X,Y)X ## Y | ^ /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/libatomic_i.h:41:25: note: in expansion of macro 'C2_' 41 | #define C2(X,Y) C2_(X,Y) | ^~~ /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/gstore.c:58:10: note: in expansion of macro 'C2' 58 | if (!C2(MAYBE_HAVE_ATOMIC_CAS_,N)) break; \ | ^~ /home/christophe.lyon/src/GCC/sources/gcc-fsf-git/trunk/libatomic/gstore.c:95:25: note: in expansion of macro 'LARGER' 95 | case 5 ... 7: L8: LARGER(8); /* FALLTHRU */ | ^~ cc1: all warnings being treated as errors make[4]: *** [Makefile:586: gstore.lo] Error 1
[Bug modula2/101392] New: cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101392 Bug ID: 101392 Summary: cc1gm2 -fdump-system-exports SEGV on Solaris/SPARC Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: gaiusmod2 at gmail dot com Target Milestone: --- Target: sparc-sun-solaris2.11 The devel/modula-2 build on Solaris/SPARC finally breaks down like this: sh /vol/gcc/src/git/modula-2/gcc/m2/tools-src/makeSystem -fpim \ /vol/gcc/src/git/modula-2/gcc/m2/gm2-libs/SYSTEM.def \ /vol/gcc/src/git/modula-2/gcc/m2/gm2-libs/SYSTEM.mod \ -I/vol/gcc/src/git/modula-2/gcc/m2/gm2-libs \ "/var/gcc/gcc-12.0.0-20210708/11.4-gm2/./gcc/gm2 -B/var/gcc/gcc-12.0.0-20210708/11.4-gm2/./gcc/" /var/gcc/gcc-12.0.0-20210708/11.4-gm2/gcc/m2/gm2-libs/SYSTEM.def gm2: internal compiler error: Segmentation Fault signal terminated program cc1gm2 As an aside, it seems weird to hardcode sh here rather than using $(SHELL) as set in the Makefile's. The failing gm2 invocation is /var/gcc/gcc-12.0.0-20210708/11.4-gm2/./gcc/gm2 -B/var/gcc/gcc-12.0.0-20210708/11.4-gm2/./gcc/ -fpim -I/vol/gcc/src/git/modula-2/gcc/m2/gm2-libs -fno-m2-plugin -c -fdump-system-exports /vol/gcc/src/git/modula-2/gcc/m2/gm2-libs/SYSTEM.mod -o /dev/null SYSTEM module creates type: LOC SYSTEM module creates type: WORD SYSTEM module creates type: BYTE SYSTEM module creates type: ADDRESS SYSTEM module creates type: INTEGER8 SYSTEM module creates type: INTEGER16 SYSTEM module creates type: INTEGER32 SYSTEM module creates type: INTEGER64 SYSTEM module creates type: CARDINAL8 SYSTEM module creates type: CARDINAL16 SYSTEM module creates type: CARDINAL32 SYSTEM module creates type: CARDINAL64 SYSTEM module creates type: WORD16 SYSTEM module creates type: WORD32 SYSTEM module creates type: WORD64 SYSTEM module creates type: BITSET8 SYSTEM module creates type: BITSET16 SYSTEM module creates type: BITSET32 SYSTEM module creates type: REAL32 SYSTEM module creates type: REAL64 SYSTEM module creates type: REAL128 SYSTEM module creates type: COMPLEX32 SYSTEM module creates type: COMPLEX64 SYSTEM module creates type: COMPLEX128 SYSTEM module creates type: CSIZE_T SYSTEM module creates type: CSSIZE_T gm2: internal compiler error: Segmentation Fault signal terminated program cc1gm2 Running it with -v shows the cc1gm2 command line: /var/gcc/gcc-12.0.0-20210708/11.4-gm2/./gcc/cc1gm2 -quiet -dumpdir /dev/ -dumpbase SYSTEM.mod -dumpbase-ext .mod -mcpu=v9 -version -fobject-path=/vol/gcc/src/git/modula-2/gcc/m2/gm2-libs -ftarget-ar=/usr/gnu/bin/ar -ftarget-ranlib=/usr/gnu/bin/ranlib -fpim -fno-m2-plugin -fdump-system-exports -fobject-path=/vol/gcc/src/git/modula-2/gcc/m2/gm2-libs -ftarget-ar=/usr/gnu/bin/ar -ftarget-ranlib=/usr/gnu/bin/ranlib -fpim -fno-m2-plugin -fdump-system-exports -I/vol/gcc/src/git/modula-2/gcc/m2/gm2-libs -I/usr/local/lib/gcc/sparc-sun-solaris2.11/12.0.0/m2/m2pim /vol/gcc/src/git/modula-2/gcc/m2/gm2-libs/SYSTEM.mod -o SYSTEM.s When I tried to add -save-temps instead of explicitly giving -o SYSTEM.s, I got cc1gm2: fatal error: cannot open ‘/dev/SYSTEM.s’ for writing: No such device or address -dumpdir /dev/ is bogus, it seems. Besides, most cc1gm2 options given twice! I get the SEGV even with cc1gm2 -quiet -fdump-system-exports -I /vol/gcc/src/git/modula-2/gcc/m2/gm2-libs/SYSTEM.mod -o SYSTEM.s under gdb: Thread 2 received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0xfeb51bb0 in strlen () from /lib/libc.so.1 (gdb) where #0 0xfeb51bb0 in strlen () from /lib/libc.so.1 #1 0xfeb937fc in strdup () from /lib/libc.so.1 #2 0x017cbed4 in lrealpath () #3 0x017ca494 in canonical_filename_eq () #4 0x00c35fa8 in toplev::main(int, char**) () #5 0x0172379c in main () running the full command and gdb: SYSTEM module creates type: CSSIZE_T cc1gm2:1:unrecognised symbol cc1gm2:1: cc1gm2:1: ^ cc1gm2:1:unrecognised symbol cc1gm2:1:3: error: expecting one of: ‘IMPLEMENTATION’ ‘MODULE’ ‘DEFINITION’ 1 | ELF Qdx 4��� 4( 2 1 4 4 � � �z�z �z�z '� �E ��D��D � � ��T��T l < dd�P ( ( �t �t /usr/lib/ld.so.1 ��� um Pe Pe Pe Pe Pe Pe��� Pe���( Pf@��` Pp���| Pp Pq��� PqL��� PqT��� P@��� P�x�� P�T��( P���D P�8��` P�`��| P� P� P�|��� P� ��� P��� P P( P�\��D P�d��T PĄ��d PĤ��t P� P� P P�T��� PŐ��D PŰ��� PȠ��� P�X��� P�\��� P� ��� P P�,��� P� P��� P�h��� P�T��� P�T�� P( P���D P�(��` P���|
[Bug modula2/101391] New: Unresolved reference to module getopt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101391 Bug ID: 101391 Summary: Unresolved reference to module getopt Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- Created attachment 51123 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51123=edit Mechanical patch The next build error from the devel/modula-2 branch occured like this: /vol/gcc/src/git/modula-2/libgm2/libm2pim/../../gcc/m2/gm2-libs/GetOpt.mod:213:11: error: the file containing the definition module ‘getopt’ cannot be found 213 | END GetOpt. | ^ make[5]: *** [Makefile:950: GetOpt.lo] Error 1 make[5]: Leaving directory '/var/gcc/gcc-12.0.0-20210708/11.4-gm2/i386-pc-solaris2.11/libgm2/libm2pim' The module has been renamed to cgetopt since. I'm attaching a patch for gcc/m2/gm2-libs/GetOpt.mod for correct this. While the Makefile.am's reflect the new name, the corresponding Makefile.in's haven't been regenerated. On top of that, the current files have been generated with automake 1.16.1, while gcc requires automake 1.15.1 as documented in install.text. To get around this, one first needs to regenerate aclocal.m4 with aclocal 1.15.1 in order to be able rerun automake.
[Bug tree-optimization/101390] New: Expand vector mod as vector div + multiply-subtract
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101390
Bug ID: 101390
Summary: Expand vector mod as vector div + multiply-subtract
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
When the target supports an sdiv/udiv pattern for vector modes we could
synthesise a vector modulus operation using the division and a
multiply-subtract operation.
#define N 128
extern signed int si_a[N], si_b[N], si_c[N];
void
test_si ()
{
for (int i = 0; i < N; i++)
si_c[i] = si_a[i] % si_b[i];
}
On AArch64 SVE (but not Neon) has vector SDIV/UDIV instructions and so could
generate:
.L2:
ld1wz2.s, p0/z, [x4, x0, lsl 2]
ld1wz1.s, p0/z, [x3, x0, lsl 2]
movprfx z0, z2
sdivz0.s, p1/m, z0.s, z1.s
msb z0.s, p1/m, z1.s, z2.s
st1wz0.s, p0, [x1, x0, lsl 2]
incwx0
whilelo p0.s, w0, w2
b.any .L2
This can be achieved by implementing the smod and mod optabs in the aarch64
backend for SVE, but this is a generic transformation, so could be handled more
generally in vect_recog_divmod_pattern and/or the vector lowering code so that
more targets can benefit.
[Bug modula2/101389] New: Parallel build doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101389 Bug ID: 101389 Summary: Parallel build doesn't work Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org Target Milestone: --- I initially tried the builds of the devel/modula-2 branch on both Solaris 11 and Linux/x86_64 in parallel mode (-j48/-j64/-j32). This failed like this make[5]: *** No rule to make target 'ASCII.lo', needed by 'libm2pim.la'. Stop. make[5]: Leaving directory '/var/gcc/gcc-12.0.0-20210708/11.4-gm2/i386-pc-solaris2.11/libgm2/libm2pim' make[4]: *** [Makefile:538: all] Error 2 ASCII.mod lives in gcc/m2/gm2-libs, but there's no ASCII.lo anywhere in the tree at this time. Running the build sequentially allows it to continue past this error.
[Bug modula2/101388] New: Unconditional use of __MAX_BAUD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101388 Bug ID: 101388 Summary: Unconditional use of __MAX_BAUD Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: gaiusmod2 at gmail dot com Target Milestone: --- Target: *-*-solaris2.11 Building the devel/modula-2 branch on Solaris 11 fails with undefined references to __MAX_BAUD in two places: /vol/gcc/src/git/modula-2/gcc/m2/mc-boot-ch/Gtermios.c: In function 'termios_GetFlag': /vol/gcc/src/git/modula-2/gcc/m2/mc-boot-ch/Gtermios.c:872:27: error: '__MAX_BAUD' undeclared (first use in this function) *b = ((t->c_cflag & __MAX_BAUD) == __MAX_BAUD); ^~ /vol/gcc/src/git/modula-2/gcc/m2/gm2-libs-ch/termios.c: In function 'termios_GetFlag': /vol/gcc/src/git/modula-2/gcc/m2/gm2-libs-ch/termios.c:877:27: error: '__MAX_BAUD' undeclared (first use in this function) 877 | *b = ((t->c_cflag & __MAX_BAUD) == __MAX_BAUD); | ^~ __MAX_BAUD seems to be Linux/glibc specific, but the current problem is obviously cause by a wrong guard which checks for defined(MAX) instead of defined(__MAX_BAUD). Correcting this lets the build continue.
[Bug modula2/101387] New: Unconditional use of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101387 Bug ID: 101387 Summary: Unconditional use of Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: gaiusmod2 at gmail dot com Target Milestone: --- Target: *-*-solaris2.11 When I tried to build the devel/modula-2 branch as of 20210708 on Solaris 11 (both SPARC and x86), the build failed early with /vol/gcc/src/git/modula-2/gcc/m2/mc-boot/GRTExceptions.c:42:13: fatal error: sys/cdefs.h: No such file or directory # include "sys/cdefs.h" ^ compilation terminated. make[3]: *** [/vol/gcc/src/git/modula-2/gcc/m2/Make-lang.in:1579: m2/mc-boot/GRTExceptions.o] Error 1 (preferably with <> rather than "") originates from *BSD, I believe and is certainly not universal. sys/defs.h also emitted in gcc/m2/mc/keyc.mod, mc-boot/Gkeyc.c To hack around this, I've disabled/commented the header in the affected files with no apparent ill effect.
[Bug ada/101385] -Werror doesn't have effect on Ada frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101385 --- Comment #2 from Iru Cai --- Thanks, -gnatwe works for both gcc and gnatmake. I see in the gnat_ugn manual that there is still the -Werror option that causes GCC back end to treat warnings as errors. Is that means -gnatwe is for front end, and -Werror for back end?
[Bug tree-optimization/101373] PRE hoists trapping instructions over possibly throwing calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101373 --- Comment #6 from Richard Biener --- Created attachment 51122 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51122=edit patch This is the patch fixing the issue for the C++ testcase (when a fix for PR100409 is applied), it also fixes the Ada testcase to not perform the hoisting with my hack active and probably with your real fix. I've not yet managed to verify that the gnat.dg/opt95.adb testcase works as expected but will do so when the Ada FE is officially fixed. The patch also touches RTL (postreload) PRE as both suffer from the same issue as GIMPLE PRE. At least for the C++ testcase it shows the RTL PRE issue at -Os.
[Bug tree-optimization/101373] PRE hoists trapping instructions over possibly throwing calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101373 --- Comment #5 from Eric Botcazou --- > The issue I can see is that the middle-end does not consider > the Foo function 'const' (gimple_call_flags does not return ECF_CONST) > which is likely because the decl isn't TREE_READONLY and for 'const' > we nowhere lookup the actual attribute but handlers are expected to > mimic c-family/c-attribs.c handling. We do that, but then the flag is overwritten... The fix is just: diff --git a/gcc/ada/gcc-interface/utils.c b/gcc/ada/gcc-interface/utils.c index 952f032072b..bfacb0eaeb4 100644 --- a/gcc/ada/gcc-interface/utils.c +++ b/gcc/ada/gcc-interface/utils.c @@ -3543,9 +3543,6 @@ finish_subprog_decl (tree decl, tree asm_name, tree type) DECL_BY_REFERENCE (result_decl) = TREE_ADDRESSABLE (type); DECL_RESULT (decl) = result_decl; - /* Propagate the "const" property. */ - TREE_READONLY (decl) = TYPE_READONLY (type); - /* Propagate the "pure" property. */ DECL_PURE_P (decl) = TYPE_RESTRICT (type); > I first thought that non-call exceptions might be the issue > (we wouldn't move A.all then), but non-call exceptions seem off. Yes, -gnatp disables -fnon-call-exceptions.
[Bug c++/100772] Templated coroutine new function's arguments have incorrect value categories/overload selection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100772 --- Comment #1 from David Ledger --- Bump, is there anything else I need to provide to assist in this matter?
[Bug analyzer/101386] New: Analysis of attribute malloc's deallocator function is not capable of abstraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101386
Bug ID: 101386
Summary: Analysis of attribute malloc's deallocator function is
not capable of abstraction
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: morrison.levi at gmail dot com
Target Milestone: ---
Consider the program string_allocator.c below. It creates reference counted
strings. The analyzer will trigger `-Wanalyzer-mismatching-deallocation`, but
it is incorrect.
```
#include
#include
#include
#include
struct string_s {
_Atomic size_t refcount;
size_t len;
char data[]; // flexible array member
};
void string_delete(struct string_s *string) {
if (string && --string->refcount == 0) {
free(string);
}
}
__attribute__((malloc, malloc(string_delete)))
struct string_s *
string_alloc(size_t len) {
struct string_s *obj = calloc(1, offsetof(struct string_s, data) + len + 1);
if (obj) {
obj->refcount = 1;
obj->len = len;
}
return obj;
}
int main() {
const char *hello_world = "Hello, World!";
size_t size = strlen(hello_world);
struct string_s *str = string_alloc(size);
if (str) {
memcpy(str->data + 0, hello_world, str->len);
printf("%s\n", str->data + 0);
}
string_delete(str);
return 0;
}
```
When compiling with:
$ gcc -g -O2 -std=c11 -Wall -Wextra -fanalyzer -fsanitize=address
string_allocator.c -o string_allocator
I get the warning:
string_allocator.c: In function 'main':
string_allocator.c:37:3: warning: 'str' should have been deallocated with
'free' but was deallocated with 'string_delete' [CWE-762]
[-Wanalyzer-mismatching-deallocation]
37 | string_delete(str);
| ^~
'main': events 1-2
|
| 29 | int main() {
| | ^~~~
| | |
| | (1) entry to 'main'
|..
| 32 | struct string_s *str = string_alloc(size);
| | ~~
| | |
| | (2) calling 'string_alloc' from 'main'
|
+--> 'string_alloc': events 3-7
|
| 20 | string_alloc(size_t len) {
| | ^~~~
| | |
| | (3) entry to 'string_alloc'
| 21 | struct string_s *obj = calloc(1, offsetof(struct
string_s, data) + len + 1);
| |
| | |
| | (4) allocated here (expects
deallocation with 'free')
| 22 | if (obj) {
| | ~
| | |
| | (5) assuming 'obj' is non-NULL
| | (6) following 'true' branch (when 'obj' is
non-NULL)...
| 23 | obj->refcount = 1;
| | ~~~
| | |
| | (7) ...to here
|
<--+
|
'main': events 8-11
|
| 32 | struct string_s *str = string_alloc(size);
| | ^~
| | |
| | (8) returning to 'main' from
'string_alloc'
| 33 | if (str) {
| | ~
| | |
| | (9) following 'true' branch (when 'str' is non-NULL)...
| 34 | memcpy(str->data + 0, hello_world, str->len);
| | ~~
| | |
| | (10) ...to here
|..
| 37 | string_delete(str);
| | ~~
| | |
| | (11) deallocated with 'string_delete' here; allocation at (4)
expects deallocation with 'free'
|
Note that I also get this warning, which either I don't understand or it is
bogus:
string_allocator.c: In function 'string_alloc':
string_allocator.c:26:10: warning: leak of 'str' [CWE-401]
[-Wanalyzer-malloc-leak]
26 | return obj;
| ^~~
'main': events 1-3
|
| 29 | int main() {
| | ^~~~
| | |
| | (1) entry to 'main'
|..
| 32 | struct string_s *str = string_alloc(size);
| | ~~
| | |
| | (2) allocated here
| | (3) calling 'string_alloc' from 'main'
|
+--> 'string_alloc': events 4-7
|
| 20 | string_alloc(size_t len) {
| | ^~~~
| | |
| | (4) entry to 'string_alloc'
| 21 | struct string_s *obj = calloc(1, offsetof(struct
string_s, data) + len + 1);
| 22
[Bug ada/101385] -Werror doesn't have effect on Ada frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101385 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Last reconfirmed||2021-07-09 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Eric Botcazou --- You need to pass -gnatwe instead.
[Bug ada/101385] New: -Werror doesn't have effect on Ada frontend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101385 Bug ID: 101385 Summary: -Werror doesn't have effect on Ada frontend Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: mytbk920423 at gmail dot com Target Milestone: --- I try to make the GCC Ada compiler error when there're warnings, but -Werror doesn't work. $ gcc -c -O2 -Werror test.adb && echo "Command returns $?" test.adb:3:22: warning: value not in range of type "MyChar" defined at line 2 test.adb:3:22: warning: "Constraint_Error" will be raised at run time Command returns 0 $ gnatmake test.adb -cargs -Werror && echo "Command returns $?" gcc -c -Werror test.adb test.adb:3:22: warning: value not in range of type "MyChar" defined at line 2 test.adb:3:22: warning: "Constraint_Error" will be raised at run time gnatbind -x test.ali gnatlink test.ali gnatlink: warning: executable name "test" may conflict with shell command Command returns 0
[Bug target/101377] [11/12 Regression] 'exec format error' on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #18 from Eric Botcazou --- Thanks for reporting the problem.
[Bug target/101377] [11/12 Regression] 'exec format error' on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377 --- Comment #17 from CVS Commits --- The releases/gcc-11 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:d9d954ebd507572a460f93f404bba71e271e2dda commit r11-8711-gd9d954ebd507572a460f93f404bba71e271e2dda Author: Eric Botcazou Date: Fri Jul 9 12:08:52 2021 +0200 Fix build failure on Windows with older binutils This is the build failure on Windows with binutils for which GNU as accepts the --gdwarf-5 switch but GNU ld generates broken binaries with DWARF 5. We already have the HAVE_LD_BROKEN_PE_DWARF5 kludge to disable DWARF 5 in this case but it only tames the DWARF version in the compiler, so the driver still passes --gdwarf-5 when invoked on an assembly file with -g. gcc/ PR target/101377 * gcc.c (ASM_DEBUG_DWARF_OPTION): Set again to --gdwarf2 in the case where HAVE_AS_WORKING_DWARF_N_FLAG is not defined and HAVE_LD_BROKEN_PE_DWARF5 is defined.
[Bug target/101377] [11/12 Regression] 'exec format error' on x86_64-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101377 --- Comment #16 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:e37e175e7dc3376244eb7705269ada6755616831 commit r12-2189-ge37e175e7dc3376244eb7705269ada6755616831 Author: Eric Botcazou Date: Fri Jul 9 12:08:52 2021 +0200 Fix build failure on Windows with older binutils This is the build failure on Windows with binutils for which GNU as accepts the --gdwarf-5 switch but GNU ld generates broken binaries with DWARF 5. We already have the HAVE_LD_BROKEN_PE_DWARF5 kludge to disable DWARF 5 in this case but it only tames the DWARF version in the compiler, so the driver still passes --gdwarf-5 when invoked on an assembly file with -g. gcc/ PR target/101377 * gcc.c (ASM_DEBUG_DWARF_OPTION): Set again to --gdwarf2 in the case where HAVE_AS_WORKING_DWARF_N_FLAG is not defined and HAVE_LD_BROKEN_PE_DWARF5 is defined.
[Bug tree-optimization/101373] PRE hoists trapping instructions over possibly throwing calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101373
--- Comment #4 from rguenther at suse dot de ---
On Fri, 9 Jul 2021, ebotcazou at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101373
>
> --- Comment #3 from Eric Botcazou ---
> > Eric, is it possible to write an equivalent testcase in Ada?
>
> procedure P is
>
> function Foo (J : Integer) return Integer;
> pragma Machine_Attribute (Foo, "const");
> pragma Machine_Attribute (Foo, "noipa");
>
> function Foo (J : Integer) return Integer is
> begin
> if J /= 0 then
> raise Constraint_Error;
> end if;
> return 0;
> end;
>
> function Bar (A : access Integer; N : Integer) return Integer;
> pragma Machine_Attribute (Bar, "noipa");
>
> function Bar (A : access Integer; N : Integer) return Integer is
> Ret : Integer := 0;
> begin
> if N /= 0 then
> Ret := Foo (N);
> Ret := A.all;
> end if;
> Ret := Ret + A.all;
> return Ret;
> end;
>
> V : Integer;
> pragma Volatile (V);
>
> begin
> V := Bar (null, 1);
> exception
> when Constraint_Error => null;
> end;
>
> compiled with -O2 -gnatp, but I cannot have the load hoisted in this case.
The issue I can see is that the middle-end does not consider
the Foo function 'const' (gimple_call_flags does not return ECF_CONST)
which is likely because the decl isn't TREE_READONLY and for 'const'
we nowhere lookup the actual attribute but handlers are expected to
mimic c-family/c-attribs.c handling.
With
diff --git a/gcc/gimple.c b/gcc/gimple.c
index 60a90667e4b..576b5df5cec 100644
--- a/gcc/gimple.c
+++ b/gcc/gimple.c
@@ -1470,7 +1470,11 @@ gimple_call_flags (const gimple *stmt)
{
tree decl = gimple_call_fndecl (stmt);
if (decl)
- flags = flags_from_decl_or_type (decl);
+ {
+ flags = flags_from_decl_or_type (decl);
+ if (lookup_attribute ("const", DECL_ATTRIBUTES (decl)))
+ flags |= ECF_CONST;
+ }
flags |= flags_from_decl_or_type (gimple_call_fntype (stmt));
}
I see the access hoisted (but as said, the Ada FE should set
TREE_READONLY here).
I first thought that non-call exceptions might be the issue
(we wouldn't move A.all then), but non-call exceptions seem off.
[Bug tree-optimization/101373] PRE hoists trapping instructions over possibly throwing calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101373 --- Comment #3 from Eric Botcazou --- > Eric, is it possible to write an equivalent testcase in Ada? procedure P is function Foo (J : Integer) return Integer; pragma Machine_Attribute (Foo, "const"); pragma Machine_Attribute (Foo, "noipa"); function Foo (J : Integer) return Integer is begin if J /= 0 then raise Constraint_Error; end if; return 0; end; function Bar (A : access Integer; N : Integer) return Integer; pragma Machine_Attribute (Bar, "noipa"); function Bar (A : access Integer; N : Integer) return Integer is Ret : Integer := 0; begin if N /= 0 then Ret := Foo (N); Ret := A.all; end if; Ret := Ret + A.all; return Ret; end; V : Integer; pragma Volatile (V); begin V := Bar (null, 1); exception when Constraint_Error => null; end; compiled with -O2 -gnatp, but I cannot have the load hoisted in this case.
[Bug driver/101383] GCC 11 Reproducibility Issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101383 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener --- The following simple patch seems to work: diff --git a/gcc/gcc.c b/gcc/gcc.c index 36a88fc99b0..16da5a0b46b 100644 --- a/gcc/gcc.c +++ b/gcc/gcc.c @@ -10831,7 +10831,7 @@ debug_level_greater_than_spec_func (int argc, const char **argv) long arg = strtol (argv[0], , 10); gcc_assert (converted != argv[0]); - if (debug_info_level > arg) + if (!flag_gtoggle && debug_info_level > arg) return ""; return NULL;
[Bug driver/101383] GCC 11 Reproducibility Issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101383 Richard Biener changed: What|Removed |Added CC||aoliva at gcc dot gnu.org Status|UNCONFIRMED |NEW Component|debug |driver Last reconfirmed||2021-07-09 Ever confirmed|0 |1 --- Comment #4 from Richard Biener --- I can for example trigger it with gcc -c t.c -Wa,--gdwarf-5 or also gcc -c t.c -g -gtoggle where despite treating -g -gtoggle as -g0 we still end up passing --gdwarf-5 to the assembler. So this way will cause different stage2 checksum (since stage2 is built with -g -gtoggle) and that's re-used for stage3 and thus causes the difference (in just the checksum). It looks like debug-level-gt is not affected by -gtoggle (gcc.c:debug_level_greater_than_spec_func) or too late for the driver to notice. In fact it seems to be handled in the compiler only (process_options).
[Bug debug/101383] GCC 11 Reproducibility Issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101383 Richard Biener changed: What|Removed |Added Component|other |debug --- Comment #3 from Richard Biener --- Huh, I can indeed see temporary filenames in debug in some cases - trying to see what triggers it.
[Bug other/101383] GCC 11 Reproducibility Issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101383 --- Comment #2 from Richard Biener --- How did you configure / make and on what host / target?
[Bug other/101383] GCC 11 Reproducibility Issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101383 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #1 from Richard Biener --- The difference you show lists temporary assembler filenames - I don't see any of those in a local bootstrap (but I just have trunk lying around). cc1-checksum is copied to make the checksum the same on all stages. The flags are different between stage2 and stage3 to increase coverage of the same-code check (once with debug, once without) and to make the build faster (do less checking using the very slow stage1 compiler). The cc1-checksum is a source of difference between builds, at SUSE we carry a local patch to null that and instead use the linker build-id as checksum for PCH purposes.
[Bug target/101384] New: wrong code at -Og and above with vector shift/multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101384 Bug ID: 101384 Summary: wrong code at -Og and above with vector shift/multiply Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Target Milestone: --- Host: x86_64-pc-linux-gnu Target: powerpc64le-unknown-linux-gnu Created attachment 51121 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51121=edit reduced testcase Output: $ powerpc64le-unknown-linux-gnu-gcc -Og testcase.c -Wno-psabi -static $ qemu-ppc64le -- ./a.out qemu: uncaught target signal 6 (Aborted) - core dumped Aborted The vector is: 80808080808080808080808080808080 instead of 80ff80ff80ff80ff # testcase.c:13: } vspltisw 0,-1# tmp121 vslb 0,0,0 # tmp121, tmp121, tmp121 looks strange, but simply replacing vslb->vslw doesn't help, as another operand with 7s for the shift would be needed $ powerpc64le-unknown-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/repo/gcc-trunk/binary-latest-powerpc64le/bin/powerpc64le-unknown-linux-gnu-gcc COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-2137-20210708114755-g4c619132b3f-checking-yes-rtl-df-extra-powerpc64le/bin/../libexec/gcc/powerpc64le-unknown-linux-gnu/12.0.0/lto-wrapper Target: powerpc64le-unknown-linux-gnu Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++ --enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra --with-cloog --with-ppl --with-isl --with-sysroot=/usr/powerpc64le-unknown-linux-gnu --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --target=powerpc64le-unknown-linux-gnu --with-ld=/usr/bin/powerpc64le-unknown-linux-gnu-ld --with-as=/usr/bin/powerpc64le-unknown-linux-gnu-as --disable-libstdcxx-pch --prefix=/repo/gcc-trunk//binary-trunk-r12-2137-20210708114755-g4c619132b3f-checking-yes-rtl-df-extra-powerpc64le Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.0.0 20210708 (experimental) (GCC)
[Bug other/101383] New: GCC 11 Reproducibility Issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101383 Bug ID: 101383 Summary: GCC 11 Reproducibility Issue Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: toolybird at tuta dot io Target Milestone: --- Performing 2 consecutive runs of a normal 3-stage bootstrap results in differing cc1 and cc1plus binaries. This appears to be a regression since GCC 10 does not exhibit the problem. The issue can be pinpointed to cc1-checksum.c and cc1plus-checksum.c I know very little about this stuff but I suspect the root cause is due to the move to DWARF 5 Please note: This is a standard `make' which means default BOOT_CFLAGS of "-g -O2". Comparing the saved object files between runs with `readelf -w' reveals differences with GCC 11 whereas with GCC 10 they are identical. For example with GCC 11: $ cmp -lb gcc-build.1st/prev-gcc/c/c-lang.o gcc-build.2nd/prev-gcc/c/c-lang.o 1932 130 X114 L 1933 62 2 60 0 1934 171 y142 b 1935 127 W 71 9 1936 150 h153 k 1937 121 Q126 V 1943 130 X114 L 1944 62 2 60 0 1945 171 y142 b 1946 127 W 71 9 1947 150 h153 k 1948 121 Q126 V 2066 130 X114 L 2067 62 2 60 0 2068 171 y142 b 2069 127 W 71 9 2070 150 h153 k 2071 121 Q126 V $ readelf -w gcc-build.1st/prev-gcc/c/c-lang.o > 1.txt $ readelf -w gcc-build.2nd/prev-gcc/c/c-lang.o > 2.txt $ diff -u 1.txt 2.txt --- 1.txt 2021-07-09 17:20:09.504532430 +1000 +++ 2.txt 2021-07-09 17:20:26.174675615 +1000 @@ -34,8 +34,8 @@ The File Name Table (offset 0x30, lines 2, columns 2): EntryDir Name - 00 (indirect line string, offset: 0xa): ccX2yWhQ.s - 11 (indirect line string, offset: 0x15): ccX2yWhQ.s + 00 (indirect line string, offset: 0xa): ccL0b9kV.s + 11 (indirect line string, offset: 0x15): ccL0b9kV.s Line Number Statements: [0x003a] Extended opcode 2: set Address to 0x0 @@ -55,8 +55,8 @@ Contents of the .debug_line_str section: - 0x 2f746d70 002f746d 70006363 58327957 /tmp./tmp.ccX2yW - 0x0010 68512e73 00636358 32795768 512e7300 hQ.s.ccX2yWhQ.s. + 0x 2f746d70 002f746d 70006363 4c306239 /tmp./tmp.ccL0b9 + 0x0010 6b562e73 0063634c 3062396b 562e7300 kV.s.ccL0b9kV.s. <...snip...> >From looking at the Makefiles, it appears `cc1-checksum.c' is copied from the previous stage for some reason, which I think might be pertinent. It also seems like different flags are used between stages 2 and 3: -DIN_GCC_FRONTEND -g -O2 -fno-checking -gtoggle -DIN_GCC -DIN_GCC_FRONTEND -g -O2 -fchecking=1 -DIN_GCC Any comments? Thanks.
[Bug tree-optimization/101024] Missed min expression at phiopt1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101024 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #0) > You will notice this is not caught by phiopt1 even though it should be while > it is caught now (on the trunk) by phiopt2 (match-and-simplify). That is > the minmax_replacement does not handle the above case but match does. This is now caught after r12-2185 but we have not moved minmax_replacement yet, just got match-and-simplify working correctly on early phiopt (phiopt1).
[Bug ipa/101382] function declarations with identical asm label aliasing a target function does not compile with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101382 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||lto Component|lto |ipa Ever confirmed|0 |1 Last reconfirmed||2021-07-09 CC||hubicka at gcc dot gnu.org --- Comment #1 from Richard Biener --- Confirmed. I think that's some general issue in the IPA symtab. Without LTO we produce .globl x .setx,a .globl x .setx,a which an assembler might eventually reject.
[Bug sanitizer/101380] Segmentation fault in __asan_init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101380 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2021-07-09 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- It works for me (openSUSE Leap 15.3) using self-built GCC 11. I wonder if you can share more details on the crash by running inside gdb providing a backtrace and disassembly around the crash.
[Bug bootstrap/101379] libatomic arm build failure after r12-2132 due -Warray-bounds on a constant address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101379 Richard Biener changed: What|Removed |Added Version|9.0 |12.0 --- Comment #4 from Richard Biener --- As said elsewhere I don't think we should diagnose _constant_ address accesses.
[Bug target/100762] [mips+msa] ICE when comparing 64 bit vectors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100762 --- Comment #5 from CVS Commits --- The master branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:82625a42e652d52fc6bbe6070f8d0589d5e0c8ad commit r12-2183-g82625a42e652d52fc6bbe6070f8d0589d5e0c8ad Author: Xi Ruoyao Date: Fri Jun 18 20:11:42 2021 +0800 mips: check MSA support for vector modes [PR100760,PR100761,PR100762] Check if the vector mode is really supported by MSA in certain cases, instead of testing ISA_HAS_MSA. Simply testing ISA_HAS_MSA can cause ICE when MSA is enabled besides other MIPS SIMD extensions (notably, Loongson MMI). gcc/ PR target/100760 PR target/100761 PR target/100762 * config/mips/mips.c (mips_const_insns): Use MSA_SUPPORTED_MODE_P instead of ISA_HAS_MSA. (mips_expand_vec_unpack): Likewise. (mips_expand_vector_init): Likewise. gcc/testsuite/ PR target/100760 PR target/100761 PR target/100762 * gcc.target/mips/pr100760.c: New test. * gcc.target/mips/pr100761.c: New test. * gcc.target/mips/pr100762.c: New test.
[Bug target/100760] [mips + msa] ICE: maximum number of generated reload insns per insn achieved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100760 --- Comment #2 from CVS Commits --- The master branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:82625a42e652d52fc6bbe6070f8d0589d5e0c8ad commit r12-2183-g82625a42e652d52fc6bbe6070f8d0589d5e0c8ad Author: Xi Ruoyao Date: Fri Jun 18 20:11:42 2021 +0800 mips: check MSA support for vector modes [PR100760,PR100761,PR100762] Check if the vector mode is really supported by MSA in certain cases, instead of testing ISA_HAS_MSA. Simply testing ISA_HAS_MSA can cause ICE when MSA is enabled besides other MIPS SIMD extensions (notably, Loongson MMI). gcc/ PR target/100760 PR target/100761 PR target/100762 * config/mips/mips.c (mips_const_insns): Use MSA_SUPPORTED_MODE_P instead of ISA_HAS_MSA. (mips_expand_vec_unpack): Likewise. (mips_expand_vector_init): Likewise. gcc/testsuite/ PR target/100760 PR target/100761 PR target/100762 * gcc.target/mips/pr100760.c: New test. * gcc.target/mips/pr100761.c: New test. * gcc.target/mips/pr100762.c: New test.
[Bug target/100761] [mips+msa] ICE when using __builtin_convertvector to convert from u8x8 to u8x16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100761 --- Comment #2 from CVS Commits --- The master branch has been updated by Xi Ruoyao : https://gcc.gnu.org/g:82625a42e652d52fc6bbe6070f8d0589d5e0c8ad commit r12-2183-g82625a42e652d52fc6bbe6070f8d0589d5e0c8ad Author: Xi Ruoyao Date: Fri Jun 18 20:11:42 2021 +0800 mips: check MSA support for vector modes [PR100760,PR100761,PR100762] Check if the vector mode is really supported by MSA in certain cases, instead of testing ISA_HAS_MSA. Simply testing ISA_HAS_MSA can cause ICE when MSA is enabled besides other MIPS SIMD extensions (notably, Loongson MMI). gcc/ PR target/100760 PR target/100761 PR target/100762 * config/mips/mips.c (mips_const_insns): Use MSA_SUPPORTED_MODE_P instead of ISA_HAS_MSA. (mips_expand_vec_unpack): Likewise. (mips_expand_vector_init): Likewise. gcc/testsuite/ PR target/100760 PR target/100761 PR target/100762 * gcc.target/mips/pr100760.c: New test. * gcc.target/mips/pr100761.c: New test. * gcc.target/mips/pr100762.c: New test.
