[Bug tree-optimization/112376] [14 Regression] gcc.dg/tree-ssa/ssa-dom-thread-7.c missed threading in aarch64 case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112376 Tamar Christina changed: What|Removed |Added Last reconfirmed||2024-02-15 Summary|[14 Regression] |[14 Regression] |gcc.dg/tree-ssa/ssa-dom-thr |gcc.dg/tree-ssa/ssa-dom-thr |ead-7.c was not adjusted|ead-7.c missed threading in |for aarch64 case|aarch64 case Ever confirmed|0 |1 Keywords||missed-optimization Component|testsuite |tree-optimization Status|UNCONFIRMED |NEW CC||amacleod at redhat dot com, ||tnfchris at gcc dot gnu.org --- Comment #1 from Tamar Christina --- This is a jumpthreading regression caused by: commit g:0cfc9c953d0221ec3971a25e6509ebe1041f142e Author: Andrew MacLeod Date: Thu Aug 17 12:34:59 2023 -0400 Phi analyzer - Initialize with range instead of a tree. Rangers PHI analyzer currently only allows a single initializer to a group. This patch changes that to use an inialization range, which is cumulative of all integer constants, plus a single symbolic value. There is no other change to group functionality. This patch also changes the way PHI groups are printed so they show up in the listing as they are encountered, rather than as a list at the end. It was more difficult to see what was going on previously. We seem to miss one thread that we did previously in the testcase. The new code does look worse. Jumpthreading is outside my wheelhouse for now, so any Ideas Andrew?
[Bug c++/113920] Make -std=gnu++20 default for GCC 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113920 Richard Biener changed: What|Removed |Added Target Milestone|--- |15.0
[Bug fortran/107141] ICE: Segmentation fault (in contains_struct_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107141 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #4 from David Binderman --- Similar thing happens with file ./Lower/derived-type-finalization.f90 from the same test suite: test $ /home/dcb38/gcc/results.20240214.asan.ubsan/bin/gfortran -c -w ./Lower/derived-type-finalization.f90 ./Lower/derived-type-finalization.f90:227:37: 227 | allocate(up(10), source=copy(10)) | 1 internal compiler error: Segmentation fault 0xf55039 crash_signal(int) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/toplev.cc:317 0x87a0ab contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) ../../trunk.20210101/gcc/tree.h:3757
[Bug fortran/107143] ICE: 'verify_gimple' failed (Error: non-trivial conversion in 'mem_ref')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107143 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #2 from David Binderman --- (In reply to Arseny Solokha from comment #0) > gfortran 13.0.0 20220925 snapshot > (g:77bbf69d2981dafc2ef3e59bfbefb645d88bab9d) ICEs when compiling the > following testcase w/ -fchecking, reduced from > test/Lower/forall/array-pointer.f90 from the flang 15.0.1 test suite: I can confirm that this is still happening on recent gfortran. test $ /home/dcb38/gcc/results.20240214.asan.ubsan/bin/gfortran -c -w ./Lower/forall/array-pointer.f90 ./Lower/forall/array-pointer.f90:486:13: 486 | subroutine s5(x,y,z,n1,n2) | ^ Error: non-trivial conversion in ‘mem_ref’ struct array02_integer(kind=4) struct array01_integer(kind=4) parm.85 = *_86; ./Lower/forall/array-pointer.f90:486:13: internal compiler error: ‘verify_gimple’ failed
[Bug target/113926] New: `(vect128 int){1, 1, 0, 0}` could be generated via `movi vN.2s, 1`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113926
Bug ID: 113926
Summary: `(vect128 int){1, 1, 0, 0}` could be generated via
`movi vN.2s, 1`
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
Due to the way the d style instructions are defined by the ISA;
```
#define vect128 __attribute__((vector_size(16) ))
vect128 int f1(void)
{
return (vect128 int){1, 1, 0, 0};
}
```
can be done just via `movi v0.2s, 1` instruction.
We can also handle .4h and .4b and even just d0.
That is:
```
vect128 long long f2(void)
{
return (vect128 long long){1, 0};
}
```
is just: `movi d0, 1`
for little-endian:
```
#define vect64 __attribute__((vector_size(8) ))
vect64 int f0(void)
{
return (vect64 int){1, 0};
}
vect128 int f2(void)
{
return (vect128 int){1, 0, 0, 0};
}
```
is also just: `movi d0, 1`.
[Bug target/113856] `(vect64 float){1.0f, 0}` code generation could just be `fmov sN, 1.0f`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113856
--- Comment #2 from Andrew Pinski ---
Note for:
```
#define vect128 __attribute__((vector_size(16) ))
vect128 float f1()
{
return (vect64 float){1.0f, 1.0f, 0.0f, 0.0f};
}
```
Should also be able to do:
```
fmov v0.2s, 1.0
```
The instruction here does zero the upper parts of the register too.
I have a patch for that too.
[Bug target/113856] `(vect64 float){1.0f, 0}` code generation could just be `fmov sN, 1.0f`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113856 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2024-02-15 --- Comment #1 from Andrew Pinski --- I have a patch.
[Bug tree-optimization/113896] [12 Regression] Assigning array elements in the wrong order after floating point optimization since r12-8841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113896 --- Comment #9 from noobie-iv at mail dot ru --- I confirm that the original bug in the scantailor-experimental project was also fixed by commit 2f16c53558d01135f0f78cf78a2f722b774684d7.
[Bug sanitizer/102317] signed integer overflow sanitizer cannot work well with -fno-strict-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102317 Fangrui Song changed: What|Removed |Added CC||i at maskray dot me --- Comment #13 from Fangrui Song --- I see a Clang patch that proposes -fsanitize=signed-integer-wrap, which appears to be the same as signed-integer-overflow, but performs the check in the -fwrapv mode. I feel that it's better to make -fsanitize=signed-integer-overflow work with -fwrapv https://github.com/llvm/llvm-project/pull/80089#issuecomment-1945202620 --- Copying here for folks prefer not to read github This is a UI discussion about how command line options should behave. Some folks prefer simpler rules while some prefer smart rules (guessing user intention). A [-fwrapv](https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#index-fwrapv) user may either: * rely on the wraparound behavior * or prevent certain optimizations that would raise security concerns Our -fsanitize=signed-integer-overflow design have been assuming that -fwrapv users don't need the check. This PR suggests that an important user does want overflow checks and our guess has failed. It seems very confusing to have two options doing the same thing. https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html is clear that not all checks are undefined behavior in the standards. > Issues caught by this sanitizer are not undefined behavior, but are often > unintentional. Sure -fwrapv makes wraparound defined, but it doesn't prevent us from making -fsanitize=signed-integer-overflow useful. "-fwrapv => no signed-integer-overflow" is not a solid argument. I think we can try making -fsanitize=signed-integer-overflow effective even when -fwrapv if specified. -fsanitize=signed-integer-overflow is rare in the wild, probably rarer when combined with -fwrapv. There is a precedent that -fsanitize=undefined enables different checks for different targets. We could make -fsanitize=undefined not imply -fsanitize=signed-integer-overflow when -fwrapv is specified, if we do want to guess the user intention. Personally I'd prefer moving away from such behaviors and be more orthogonal.
[Bug c++/113916] gcc allows overriding a non-deleted private base class dtor with a defaulted dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113916 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Summary|gcc allows overriding a |gcc allows overriding a |non-deleted private base|non-deleted private base |class dtor with a deleted |class dtor with a defaulted |defaulted dtor |dtor Last reconfirmed||2024-02-15 Status|UNCONFIRMED |NEW Known to fail||4.4.7, 4.7.1 --- Comment #1 from Andrew Pinski --- Confirmed. Looks not to be a regression either.
[Bug c++/113925] static assert on requires clause with non-type bool template instantiated with immediately invoked consteval lambda is incorrectly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113925 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-02-15 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed. I thought I had saw this before but I can't seem to find it.
[Bug middle-end/113508] widen_ssumm3 documentation needs to mention which mode is m here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113508 --- Comment #3 from Andrew Pinski --- part 1 which just fixes some style issue: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645630.html part 2: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645631.html
[Bug fortran/105847] namelist-object-name can be a renamed host associated entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847 --- Comment #10 from GCC Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:8221201cc59870579b9dc451b173f94b8d8b0993 commit r14-8992-g8221201cc59870579b9dc451b173f94b8d8b0993 Author: Steve Kargl Date: Wed Feb 14 14:40:16 2024 -0800 Fortran: namelist-object-name renaming. PR fortran/105847 gcc/fortran/ChangeLog: * trans-io.cc (transfer_namelist_element): When building the namelist object name, if the use rename attribute is set, use the local name specified in the use statement. gcc/testsuite/ChangeLog: * gfortran.dg/pr105847.f90: New test.
[Bug fortran/105847] namelist-object-name can be a renamed host associated entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847 --- Comment #9 from Jerry DeLisle --- This seems to work: /* Build the namelist object name. */ - - string = gfc_build_cstring_const (var_name); + if (sym && !sym->attr.use_only && sym->attr.use_rename) +string = gfc_build_cstring_const (sym->ns->use_stmts->rename->local_name); + else +string = gfc_build_cstring_const (var_name); Evidently the processing of the 'only' takes care of the renaming before we get here. Without the attr.use_only part namelist_use_only.f90 fails. With these tweaks there are no regressions and the test case here passes.
[Bug c++/113925] New: static assert on requires clause with non-type bool template instantiated with immediately invoked consteval lambda is incorrectly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113925
Bug ID: 113925
Summary: static assert on requires clause with non-type bool
template instantiated with immediately invoked
consteval lambda is incorrectly rejected
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gieseanw+gcc at gmail dot com
Target Milestone: ---
template
struct b{};
static_assert(requires { b<([]()consteval{ return true; }())>{}; });
In gcc 13.2 and 14.0.1 this produces:
error: template argument 1 is invalid
3 | static_assert(requires { b<([]()consteval{ return true; }())>{}; });
| ^
Godbolt: https://godbolt.org/z/7dacc7rKr
StackOverflow: https://stackoverflow.com/a/77996234/27678
[Bug c++/113924] [11/12/13/14 Regression] worse diagnostic for invalid decltype since r10-5347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113924 Marek Polacek changed: What|Removed |Added Summary|worse diagnostic for|[11/12/13/14 Regression] |invalid decltype since |worse diagnostic for |r10-5347|invalid decltype since ||r10-5347 Target Milestone|--- |11.5 Keywords||diagnostic
[Bug c++/113924] New: worse diagnostic for invalid decltype since r10-5347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113924
Bug ID: 113924
Summary: worse diagnostic for invalid decltype since r10-5347
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
int m () = delete;
void
f (int i, int = decltype (m()){ })
{
}
void
f2 (int i, int = decltype(x){ })
{
}
used to say
/home/mpolacek/w.C:4:29: error: use of deleted function ‘int m()’
4 | f (int i, int = decltype (m()){ })
| ^
/home/mpolacek/w.C:1:5: note: declared here
1 | int m () = delete;
| ^
/home/mpolacek/w.C:4:29: error: use of deleted function ‘int m()’
4 | f (int i, int = decltype (m()){ })
| ^
/home/mpolacek/w.C:1:5: note: declared here
1 | int m () = delete;
| ^
/home/mpolacek/w.C:9:27: error: ‘x’ was not declared in this scope
9 | f2 (int i, int = decltype(x){ })
| ^
/home/mpolacek/w.C:9:27: error: ‘x’ was not declared in this scope
which still duplicated the errors, but now we say:
/home/mpolacek/w.C:4:29: error: use of deleted function ‘int m()’
4 | f (int i, int = decltype (m()){ })
| ^
/home/mpolacek/w.C:1:5: note: declared here
1 | int m () = delete;
| ^
/home/mpolacek/w.C:4:29: error: use of deleted function ‘int m()’
4 | f (int i, int = decltype (m()){ })
| ^
/home/mpolacek/w.C:1:5: note: declared here
1 | int m () = delete;
| ^
/home/mpolacek/w.C:4:17: error: expected primary-expression before ‘decltype’
4 | f (int i, int = decltype (m()){ })
| ^
/home/mpolacek/w.C:4:17: error: expected ‘,’ or ‘...’ before ‘decltype’
/home/mpolacek/w.C:4:34: error: expected unqualified-id before ‘)’ token
4 | f (int i, int = decltype (m()){ })
| ^
/home/mpolacek/w.C:9:27: error: ‘x’ was not declared in this scope
9 | f2 (int i, int = decltype(x){ })
| ^
/home/mpolacek/w.C:9:27: error: ‘x’ was not declared in this scope
/home/mpolacek/w.C:9:18: error: expected primary-expression before ‘decltype’
9 | f2 (int i, int = decltype(x){ })
| ^~
/home/mpolacek/w.C:9:18: error: expected ‘,’ or ‘...’ before ‘decltype’
/home/mpolacek/w.C:9:32: error: expected unqualified-id before ‘)’ token
9 | f2 (int i, int = decltype(x){ })
|^
and that's even worse.
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org
[Bug middle-end/113508] widen_ssumm3 documentation needs to mention which mode is m here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113508 --- Comment #2 from Andrew Pinski --- There are few other changes I am going to make too.
[Bug fortran/105847] namelist-object-name can be a renamed host associated entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847 --- Comment #8 from Jerry DeLisle --- There is an assert just above the patch that implies that sym can be NULL if c is not. With gdb I checked, and sure enough thats the failure point. I am testing with sym included in the condition.
[Bug libstdc++/113074] std::to_address should be SFINAE safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074 --- Comment #17 from Peter Kasting --- (In reply to Jonathan Wakely from comment #15) > (In reply to Peter Kasting from comment #14) > > And you are right, it's possible to reimplement concepts around "is this > > even legal to pass to to_address()", which is basically what we're doing to > > address this in Chromium. But that's pretty unfriendly to most usage; if > > you're in a context where you are reaching for to_address() to begin with, > > it's likely because you're templated and don't know that a simpler thing > > like `&*ptr` is valid. > > The reason to avoid &*ptr is because it's undefined behaviour on a > past-the-end iterator, not because it might be ill-formed for some template > argument types. That's the reason to avoid it in the specific case the library happened to make use of std::to_address(). That's not necessarily reasoning that applies to other uses of std::to_address(). > > That's fair, but isn't that implementable by simply making the definition of > > contiguous_iterator explicitly hard error in this case? That is, an > > SFINAE-friendly to_address() wouldn't prevent you from diagnosing this > > particular usage site as incorrect. > > The rationale for making it SFINAE-friendly in libc++ was to *not* give an > error for that case. Making it SFINAE-friendly but restoring the error in > that case would remove the reason to have made it SFINAE-friendly in the > first place. I'm not sure how many more ways I can say that my interest in this being SFINAE-friendly is completely unrelated to libc++'s (or any other STL's) handling of contiguous_iterator. The committee added a tool, used it one place, made it hard to hold other places, and (per your previous summaries) has avoided making it more useful other places due to only thinking about things through the lens of this specific contiguous_iterator usage. I'm not using it for that. > If you think this should change, please take that through WG21. I don't > think we should deviate from the standard here. Yes, precisely. Per comment 8: "libstdc++ is standards-compliant as-is. We'll fix our code. I do think libc++'s behavior is more usable and an LWG issue would be nice." I don't have any connection to WG21. I was hoping someone here had the experience necessary to pass on this request to the committee. If not, so be it, it will die.
[Bug fortran/105847] namelist-object-name can be a renamed host associated entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847 --- Comment #7 from Jerry DeLisle --- Steve, I am getting a boatload of regressions on this. I wonder if something in the sym structure needs to be guarded here. They appear to be segfaults. Can you take a look?
[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923 --- Comment #3 from David Malcolm --- (In reply to David Malcolm from comment #2) > are both non-NULL, which might catch the issue slightly early. ^ earlier
[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923 --- Comment #2 from David Malcolm --- inlined_call_event's ctor should probably assert that params tree apparent_callee_fndecl, tree apparent_caller_fndecl, are both non-NULL, which might catch the issue slightly early.
[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923
--- Comment #1 from David Malcolm ---
Reproducing that is going to be a challenge.
FWIW you can probably work around it via -fno-analyzer-undo-inlining.
For an inlined_call_event's m_apparent_caller_fndecl to be NULL, then when it
was created in checker_path::inject_any_inlined_call_events, cd.m_fndecl would
have to be NULL here:
310const chain_element = elements[element_idx];
311int stack_depth_adjustment
312 = (blocks_in_curr_event.elements () - element_idx) - 1;
313if (location_t callsite = BLOCK_SOURCE_LOCATION
(ce.m_block))
314 updated_events.safe_push
315(new inlined_call_event (callsite,
316 elements[element_idx -
1].m_fndecl,
317 ce.m_fndecl,
318 orig_stack_depth,
319 stack_depth_adjustment));
which comes from iter.get_fndecl () earlier in that function:
292for (inlining_iterator iter (curr_loc); !iter.done_p ();
iter.next ())
293 {
294chain_element ce;
295ce.m_block = iter.get_block ();
296ce.m_fndecl = iter.get_fndecl ();
297
298if (!blocks_in_prev_event.contains (ce.m_block))
299 elements.safe_push (ce);
300blocks_in_curr_event.add (ce.m_block);
301 }
inlining-iterator.h looks at FUNCTION_DECL, so maybe if you're using a
different code that could confuse it. But this is from libgccjit, so I'm not
sure.
[Bug tree-optimization/113922] -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922 Andrew Pinski changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=31383 --- Comment #8 from Andrew Pinski --- Moved to glibc issue: https://sourceware.org/bugzilla/show_bug.cgi?id=31383
[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 113922, which changed state.
Bug 113922 Summary: -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3}
generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |MOVED
[Bug tree-optimization/113922] -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922 --- Comment #7 from Sergio Durigan Junior --- Ah, OK, I'll let you file the bug, then. Thanks.
[Bug tree-optimization/113922] -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922 --- Comment #6 from Sergio Durigan Junior --- Thanks for the quick analysis. It seems that the following glibc commit dropped size hints from access when FORTIFY_SOURCE=3: https://sourceware.org/git/?p=glibc.git;a=commit;h=e938c02748402c50f60ba0eb983273e7b52937d1 I'll report a bug against glibc and mention this conversation. Thanks.
[Bug tree-optimization/113922] -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922 --- Comment #5 from Andrew Pinski --- extern ssize_t read (int __fd, void *__buf, size_t __nbytes) __wur __fortified_attr_access (__write_only__, 2, 3); ... /* For _FORTIFY_SOURCE == 3 we use __builtin_dynamic_object_size, which may use the access attribute to get object sizes from function definition arguments, so we can't use them on functions we fortify. Drop the object size hints for such functions. */ # if __USE_FORTIFY_LEVEL == 3 #define __fortified_attr_access(a, o, s) __attribute__ ((__access__ (a, o))) # else #define __fortified_attr_access(a, o, s) __attr_access ((a, o, s)) # endif Yes that is broken. Let me file the glibc issue.
[Bug analyzer/113923] New: Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923
Bug ID: 113923
Summary: Segfault in gcc/gcc/tree-diagnostic.cc:265
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: bouanto at zoho dot com
Target Milestone: ---
Hi.
I cannot easily produce a reproducer for this since I got this when compiling a
Rust project (librsvg) via rustc_codegen_gcc.
The project was compiled with this command:
path/to/rustc_codegen_gcc/y.sh cargo rustc -p librsvg --
-Cllvm-args=-fanalyzer
Here's the complete stacktrace:
Thread 8 "opt cgu.14" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x77add5c006c0 (LWP 7805)]
0x77ae3edea93d in default_tree_printer (pp=0x77a86437ea10,
text=0x77add5bf5540, spec=0x77a8b09c4241 "E", precision=0, wide=false,
set_locus=false, hash=false)
at ../../../gcc/gcc/tree-diagnostic.cc:265
265 if (TREE_CODE (t) == IDENTIFIER_NODE)
(gdb) bt
#0 0x77ae3edea93d in default_tree_printer (pp=0x77a86437ea10,
text=0x77add5bf5540, spec=0x77a8b09c4241 "E", precision=0, wide=false,
set_locus=false, hash=false)
at ../../../gcc/gcc/tree-diagnostic.cc:265
#1 0x77ae408a8ab2 in pp_format (pp=0x77a86437ea10, text=0x77add5bf5540,
urlifier=0x0) at ../../../gcc/gcc/pretty-print.cc:1704
#2 0x77ae407a6503 in make_label_text (can_colorize=false,
fmt=0x77ae40edd909 "inlined call to %qE from %qE") at
../../../gcc/gcc/analyzer/analyzer.cc:494
#3 0x77ae407bbf30 in ana::inlined_call_event::get_desc
(this=0x77a85fde16a0, can_colorize=false) at
../../../gcc/gcc/analyzer/checker-event.cc:1018
#4 0x77ae407b9d1a in ana::checker_event::prepare_for_emission
(this=0x77a85fde16a0, pd=0x77a88c2e07a0, emission_id=...)
at ../../../gcc/gcc/analyzer/checker-event.cc:230
#5 0x77ae407d83da in ana::checker_path::prepare_for_emission
(this=0x77add5bf5900, pd=0x77a88c2e07a0) at
../../../gcc/gcc/analyzer/checker-path.h:108
#6 0x77ae407d40ac in ana::diagnostic_manager::emit_saved_diagnostic
(this=0x77add5bf6210, eg=..., sd=...) at
../../../gcc/gcc/analyzer/diagnostic-manager.cc:1601
#7 0x77ae407d9742 in ana::dedupe_winners::emit_best (this=0x77add5bf5b40,
dm=0x77add5bf6210, eg=...) at
../../../gcc/gcc/analyzer/diagnostic-manager.cc:1472
#8 0x77ae407d3cf0 in ana::diagnostic_manager::emit_saved_diagnostics
(this=0x77add5bf6210, eg=...) at
../../../gcc/gcc/analyzer/diagnostic-manager.cc:1524
#9 0x77ae3f2031e9 in ana::impl_run_checkers (logger=0x0) at
../../../gcc/gcc/analyzer/engine.cc:6226
#10 0x77ae3f203582 in ana::run_checkers () at
../../../gcc/gcc/analyzer/engine.cc:6300
#11 0x77ae3f1f47bb in (anonymous namespace)::pass_analyzer::execute
(this=0x77add5201000) at ../../../gcc/gcc/analyzer/analyzer-pass.cc:87
#12 0x77ae3ec00e1f in execute_one_pass (pass=0x77add5201000) at
../../../gcc/gcc/passes.cc:2646
#13 0x77ae3ec02074 in execute_ipa_pass_list (pass=0x77add5201000) at
../../../gcc/gcc/passes.cc:3095
#14 0x77ae3e6f4c62 in ipa_passes () at ../../../gcc/gcc/cgraphunit.cc:2270
#15 0x77ae3e6f4e82 in symbol_table::compile (this=0x77a90e2ccf00) at
../../../gcc/gcc/cgraphunit.cc:2333
#16 0x77ae3e6f54f8 in symbol_table::finalize_compilation_unit
(this=0x77a90e2ccf00) at ../../../gcc/gcc/cgraphunit.cc:2585
#17 0x77ae3ed73932 in compile_file () at ../../../gcc/gcc/toplev.cc:474
#18 0x77ae3ed77568 in do_compile () at ../../../gcc/gcc/toplev.cc:2152
#19 0x77ae3ed77a1e in toplev::main (this=0x77add5bfb256, argc=20,
argv=0x77add520f1c8) at ../../../gcc/gcc/toplev.cc:2308
#20 0x77ae3e5ccecb in gcc::jit::playback::context::compile
(this=0x77add5bfb2f0) at ../../../gcc/gcc/jit/jit-playback.cc:2851
#21 0x77ae3e59f1e7 in gcc::jit::recording::context::compile_to_file
(this=0x77ae039f6080, output_kind=GCC_JIT_OUTPUT_KIND_OBJECT_FILE,
output_path=0x77add5216000
"/home/user/rustc_codegen_gcc/projects/librsvg/target/debug/deps/rsvg-85e1285dcdc7222b.rsvg.d0bf5dc3489ec5bd-cgu.14.rcgu.o")
at ../../../gcc/gcc/jit/jit-recording.cc:1650
#22 0x77ae3e5963fb in gcc_jit_context_compile_to_file (ctxt=0x77ae039f6080,
output_kind=GCC_JIT_OUTPUT_KIND_OBJECT_FILE,
output_path=0x77add5216000
"/home/user/rustc_codegen_gcc/projects/librsvg/target/debug/deps/rsvg-85e1285dcdc7222b.rsvg.d0bf5dc3489ec5bd-cgu.14.rcgu.o")
at ../../../gcc/gcc/jit/libgccjit.cc:3938
#23 0x77ae41b291eb in gccjit::context::Context::compile_to_file<>
(self=0x77add5bfca48, kind=gccjit::context::OutputKind::ObjectFile, file=...)
at
/home/user/.cargo/git/checkouts/gccjit.rs-13c2e290f2fb9e4d/e6109eb/src/context.rs:276
#24 0x77ae41dee137 in rustc_codegen_gcc::back::write::codegen
(cgcx=0x77add5bfdd38, diag_handler=0x77add5bfc7c0, module=...,
config=0x77ae0f1df1f0)
at src/back/write.rs:124
#25 0x77ae41e25dc0 in rustc_codegen_gcc::{impl#8}::codegen
[Bug tree-optimization/113922] -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922 --- Comment #4 from Andrew Pinski --- POSIX definition of read: https://pubs.opengroup.org/onlinepubs/009604599/functions/read.html >Before any action described below is taken, and if nbyte is zero, the read() >function may detect and return errors as described below. In the absence of >errors, or if error detection is not performed, the read() function shall >return zero and have no other results. So yes it does look like the use of write_only access is incorrect ...
[Bug tree-optimization/113922] -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922 --- Comment #3 from Andrew Pinski --- From https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-access-function-attribute : >When no size-index argument is specified, the pointer argument must be either >null or point to a space that is suitably aligned and large for at least one >object of the referenced type (this implies that a past-the-end pointer is not >a valid argument). I think this is a bug in glibc and its (mis)use of the access and write only attribute without a size. It has: __attribute__ ((__access__ (__write_only__, 2))) but the documentation for this attribute does not correspond with the above.
[Bug tree-optimization/113922] -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922 --- Comment #2 from Sergio Durigan Junior --- Created attachment 57431 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57431=edit Preprocessed source Sure thing. Here it is.
[Bug ada/113877] gnatchop -c puts gnat.adc in the current working directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113877 --- Comment #2 from simon at pushface dot org --- I came across -c in ACATS[1]. I do agree it’s an uncommon usage, and indeed I can’t think of other reasons to do it; perhaps it’s to support porting from other compilers? (if that’s something we should be concerned about still). At the moment, if I gnatchop -c foo.a -w foo_src gnatchop -c bar.a -w bar_src and both foo.a and bar.a contain a configuration-pragma-only section, then bar.a’s configuration pragmas are appended to foo.a’s in gnat.adc in the current working directory. If all configuration pragmas need to be partition-wide, that would justify the current design, but I don’t think that’s the case. I just don’t know what the original use case was, or whether there are users whose workflows would be disrupted by a change (one of those would _not_ be ACATS: it deletes gnatchopped files, including gnat.adc, after each test). [1] https://github.com/gcc-mirror/gcc/blob/2c2f57e4158924467afbf4c2fd3938e507287dab/gcc/testsuite/ada/acats/run_all.sh#L332
[Bug middle-end/113921] Output register of an "asm volatile goto" is incorrectly clobbered/discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #8 from Jakub Jelinek --- Created attachment 57430 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57430=edit gcc14-pr113921.patch Full untested trunk patch.
[Bug tree-optimization/113922] -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922 --- Comment #1 from Andrew Pinski --- Can you attach the preprocessed source since this depends on glibc's FORTIFY_SOURCE for value of 3 which is only included in newer glibc's?
[Bug tree-optimization/113922] New: -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3} generates a false positive for 0-sized structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113922
Bug ID: 113922
Summary: -Wstringop-overflow with FORTIFY_SOURCE=3 and O{1,2,3}
generates a false positive for 0-sized structs
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: sergiodj at sergiodj dot net
Target Milestone: ---
Hi,
Consider the following example program:
#include
#include
int main(void) {
struct test_st {};
int fd = 0;
int count = 0;
struct test_st test_info[16];
count = read(fd, test_info, sizeof(test_info));
return(0);
}
When compiling it with GCC 13.2 using -D_FORTIFY_SOURCE=3 and -O1, I see:
a.c: In function ‘main’:
a.c:15:13: warning: ‘read’ writing 1 byte into a region of size 0 overflows the
destination [-Wstringop-overflow=]
15 | count = read(fd, test_info, sizeof(test_info));
| ^~
a.c:10:20: note: destination object ‘test_info’ of size 0
10 | struct test_st test_info[16];
|^
In file included from /usr/include/unistd.h:1214,
from a.c:3:
/usr/include/x86_64-linux-gnu/bits/unistd.h:26:1: note: in a call to function
‘read’ declared with attribute ‘access (write_only, 2)’
26 | read (int __fd, void *__buf, size_t __nbytes)
| ^~~~
GCC allows empty structs on C code and they are correctly sized 0, but
-Wstringop-overflow still thinks the code is trying to read 1 byte into the
array, which is not correct.
I know there are a lot of false positives reported against -Wstringop-overflow,
but I couldn't find an exact duplicate of this one.
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576 --- Comment #56 from Uroš Bizjak --- The testcase is fixed with g:430c772be3382134886db33133ed466c02efc71c
[Bug middle-end/111156] [14 Regression] aarch64 aarch64/sve/mask_struct_store_4.c failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56
Tamar Christina changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #12 from Tamar Christina ---
The commit that caused it is:
commit g:a1558e9ad856938f165f838733955b331ebbec09
Author: Richard Biener
Date: Wed Aug 23 14:28:26 2023 +0200
tree-optimization/15 - SLP of masked stores
The following adds the capability to do SLP on .MASK_STORE, I do not
plan to add interleaving support.
specifically this change:
diff --git a/gcc/tree-vect-data-refs.cc b/gcc/tree-vect-data-refs.cc
index 3e9a284666c..a2caf6cb1c7 100644
--- a/gcc/tree-vect-data-refs.cc
+++ b/gcc/tree-vect-data-refs.cc
@@ -3048,8 +3048,7 @@ can_group_stmts_p (stmt_vec_info stmt1_info,
stmt_vec_info stmt2_info,
like those created by build_mask_conversion. */
tree mask1 = gimple_call_arg (call1, 2);
tree mask2 = gimple_call_arg (call2, 2);
- if (!operand_equal_p (mask1, mask2, 0)
- && (ifn == IFN_MASK_STORE || !allow_slp_p))
+ if (!operand_equal_p (mask1, mask2, 0) && !allow_slp_p)
{
mask1 = strip_conversion (mask1);
if (!mask1)
With the change it now incorrectly thinks that the two masks (a <=7, a > 2) are
the same which is why one of the masks go missing.
Part of it is that the boolean is used in a weird way. During
vect_analyze_data_ref_accesses where this difference is important we pass true
in the initial check. but the || before made it so that we checked the
MASK_STOREs still. Now it means during analysis we never check.
later on in the same method we check it again but with false as the argument
for determining STMT_VINFO_SLP_VECT_ONLY.
The debug statement there is weird btw, as it says:
if (dump_enabled_p () && STMT_VINFO_SLP_VECT_ONLY (stmtinfo_a))
dump_printf_loc (MSG_NOTE, vect_location,
"Load suitable for SLP vectorization only.\n");
but as far as I can see, stmtinfo_a can be a store too, based on the checks for
DR_IS_READ (dra) just slightly higher up.
The patch that added this check (g:997636716c5dde7d59d026726a6f58918069f122)
says it's because the vectorizer doesn't support SLP of masked loads, and I
can't tell if we do now.
If we do, the boolean should be dropped.. if we don't, we probably need the
check back to allow the check for stores. It looks like this check us being
used to disable STMT_VINFO_SLP_VECT_ONLY for loads, which is a bit counter
intuitive and feels like a hack rather than just doing:
STMT_VINFO_SLP_VECT_ONLY (stmtinfo_a)
- = !can_group_stmts_p (stmtinfo_a, stmtinfo_b, false);
+ = !can_group_stmts_p (stmtinfo_a, stmtinfo_b)
+ && DR_IS_WRITE (dra);
So I think the boolean should be dropped and just reject loads for
STMT_VINFO_SLP_VECT_ONLY...
This also seems to give much better codegen... in any case, richi?
[Bug tree-optimization/113910] [12/13 Regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910 --- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #14 from Richard Biener --- > The regression should be fixed, can you check we're now no longer slower on > trunk? (either use a release checking build or use -fno-checking which should > get you reasonably close) I've done a --enable-checking=release build on trunk and compare compile times of the -save-temps with g++ 11.4.0: $ time cc1plus -fpreprocessed AMDGPUDisassembler.cpp.ii -quiet -mcpu=v9 -O -std=c++17 -o AMDGPUDisassembler.cpp.s * 11.4.0: real2:04.33 user2:03.86 sys0.30 * 14.0.1: real2:17.58 user2:16.47 sys0.87
[Bug fortran/105847] namelist-object-name can be a renamed host associated entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847 --- Comment #6 from Jerry DeLisle --- I obviously did not get to this last May. Will try now.
[Bug libstdc++/113074] std::to_address should be SFINAE safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074 --- Comment #16 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #15) > The reason to avoid &*ptr is because it's undefined behaviour on a > past-the-end iterator, not because it might be ill-formed for some template > argument types. Hmm, actually void* is the one type where &*ptr isn't valid but std::to_address(ptr) still works. I don't think it's a common case though.
[Bug libfortran/99210] X editing for reading file with encoding='utf-8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Jerry DeLisle --- Fixed on main line. If someone needs a backport, let me know.
[Bug fortran/109358] Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Jerry DeLisle --- Fixed on trunk and 13
[Bug libstdc++/113074] std::to_address should be SFINAE safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #15 from Jonathan Wakely --- (In reply to Peter Kasting from comment #14) > And you are right, it's possible to reimplement concepts around "is this > even legal to pass to to_address()", which is basically what we're doing to > address this in Chromium. But that's pretty unfriendly to most usage; if > you're in a context where you are reaching for to_address() to begin with, > it's likely because you're templated and don't know that a simpler thing > like `&*ptr` is valid. The reason to avoid &*ptr is because it's undefined behaviour on a past-the-end iterator, not because it might be ill-formed for some template argument types. > That's fair, but isn't that implementable by simply making the definition of > contiguous_iterator explicitly hard error in this case? That is, an > SFINAE-friendly to_address() wouldn't prevent you from diagnosing this > particular usage site as incorrect. The rationale for making it SFINAE-friendly in libc++ was to *not* give an error for that case. Making it SFINAE-friendly but restoring the error in that case would remove the reason to have made it SFINAE-friendly in the first place. If you think this should change, please take that through WG21. I don't think we should deviate from the standard here.
[Bug target/113855] [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from H.J. Lu --- Fixed.
[Bug target/113855] [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855 --- Comment #8 from GCC Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:67ce5c97167a60cb845b9f3f55186c00fc5df078 commit r14-8990-g67ce5c97167a60cb845b9f3f55186c00fc5df078 Author: H.J. Lu Date: Tue Feb 13 08:40:52 2024 -0800 x86: Support x32 and IBT in heap trampoline Add x32 and IBT support to x86 heap trampoline implementation with a testcase. 2024-02-13 Jakub Jelinek H.J. Lu libgcc/ PR target/113855 * config/i386/heap-trampoline.c (trampoline_insns): Add IBT support and pad to the multiple of 4 bytes. Use movabsq instead of movabs in comments. Add -mx32 variant. gcc/testsuite/ PR target/113855 * gcc.dg/heap-trampoline-1.c: New test. * lib/target-supports.exp (check_effective_target_heap_trampoline): New.
[Bug target/113871] psrlq is not used for PERM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113871 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.0 Status|ASSIGNED|RESOLVED --- Comment #7 from Uroš Bizjak --- Implemented for gcc-14.
[Bug target/113871] psrlq is not used for PERM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113871
--- Comment #6 from GCC Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:2c2f57e4158924467afbf4c2fd3938e507287dab
commit r14-8989-g2c2f57e4158924467afbf4c2fd3938e507287dab
Author: Uros Bizjak
Date: Wed Feb 14 20:41:42 2024 +0100
i386: psrlq is not used for PERM [PR113871]
Introduce vec_shl_ and vec_shr_ expanders to improve
'*a = __builtin_shufflevector(*a, (vect64){0}, 1, 2, 3, 4);'
and
'*a = __builtin_shufflevector((vect64){0}, *a, 3, 4, 5, 6);'
shuffles. The generated code improves from:
movzwl 6(%rdi), %eax
movzwl 4(%rdi), %edx
salq$16, %rax
orq %rdx, %rax
movzwl 2(%rdi), %edx
salq$16, %rax
orq %rdx, %rax
movq%rax, (%rdi)
to:
movq(%rdi), %xmm0
psrlq $16, %xmm0
movq%xmm0, (%rdi)
and to:
movq(%rdi), %xmm0
psllq $16, %xmm0
movq%xmm0, (%rdi)
in the second case.
The patch handles 32-bit vectors as well and improves generated code from:
movd(%rdi), %xmm0
pxor%xmm1, %xmm1
punpcklwd %xmm1, %xmm0
pshuflw $230, %xmm0, %xmm0
movd%xmm0, (%rdi)
to:
movd(%rdi), %xmm0
psrld $16, %xmm0
movd%xmm0, (%rdi)
and to:
movd(%rdi), %xmm0
pslld $16, %xmm0
movd%xmm0, (%rdi)
PR target/113871
gcc/ChangeLog:
* config/i386/mmx.md (V248FI): New mode iterator.
(V24FI_32): DItto.
(vec_shl_): New expander.
(vec_shl_): Ditto.
(vec_shr_): Ditto.
(vec_shr_): Ditto.
* config/i386/sse.md (vec_shl_): Simplify expander.
(vec_shr_): Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/i386/pr113871-1a.c: New test.
* gcc.target/i386/pr113871-1b.c: New test.
* gcc.target/i386/pr113871-2a.c: New test.
* gcc.target/i386/pr113871-2b.c: New test.
* gcc.target/i386/pr113871-3a.c: New test.
* gcc.target/i386/pr113871-3b.c: New test.
* gcc.target/i386/pr113871-4a.c: New test.
[Bug other/113336] [14 Regression] libatomic (testsuite) regressions on arm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113336 --- Comment #8 from GCC Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:ea7675761226b42e2deb7b320e9cc680512f4090 commit r14-8988-gea7675761226b42e2deb7b320e9cc680512f4090 Author: Roger Sayle Date: Wed Feb 14 19:09:51 2024 + PR other/113336: Fix libatomic testsuite regressions on ARM. This patch is a revised version of the fix for PR other/113336. Bootstrapping GCC on arm-linux-gnueabihf with --with-arch=armv6 currently has a large number of FAILs in libatomic (regressions since last time I attempted this). The failure mode is related to IFUNC handling with the file tas_8_2_.o containing an unresolved reference to the function libat_test_and_set_1_i2. The following one line change, to build tas_1_2_.o when building tas_8_2_.o, resolves the problem for me and restores the libatomic testsuite to 44 expected passes and 5 unsupported tests [from 22 unexpected failures and 22 unresolved testcases]. ` 2024-02-14 Roger Sayle Victor Do Nascimento libatomic/ChangeLog PR other/113336 * Makefile.am: Build tas_1_2_.o on ARCH_ARM_LINUX * Makefile.in: Regenerate.
[Bug c++/113708] [modules] ICE in import_export_decl with non-trivially initialized inline variable in header module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113708 Nathaniel Shead changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||nshead at gcc dot gnu.org Target Milestone|--- |14.0 Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org --- Comment #2 from Nathaniel Shead --- Fixed for GCC 14.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 113708, which changed state. Bug 113708 Summary: [modules] ICE in import_export_decl with non-trivially initialized inline variable in header module https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113708 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/113708] [modules] ICE in import_export_decl with non-trivially initialized inline variable in header module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113708 --- Comment #1 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:dd9d14f7d53de07beff06004922a2bff20ece671 commit r14-8987-gdd9d14f7d53de07beff06004922a2bff20ece671 Author: Nathaniel Shead Date: Wed Feb 14 12:26:03 2024 +1100 c++: Defer emitting inline variables [PR113708] Inline variables are vague-linkage, and may or may not need to be emitted in any TU that they are part of, similarly to e.g. template instantiations. Currently 'import_export_decl' assumes that inline variables have already been emitted when it comes to end-of-TU processing, and so crashes when importing non-trivially-initialised variables from a module, as they have not yet been finalised. This patch fixes this by ensuring that inline variables are always deferred till end-of-TU processing, unifying the behaviour for module and non-module code. PR c++/113708 gcc/cp/ChangeLog: * decl.cc (make_rtl_for_nonlocal_decl): Defer inline variables. * decl2.cc (import_export_decl): Support inline variables. gcc/testsuite/ChangeLog: * g++.dg/debug/dwarf2/inline-var-1.C: Reference 'a' to ensure it is emitted. * g++.dg/debug/dwarf2/inline-var-3.C: Likewise. * g++.dg/modules/init-7_a.H: New test. * g++.dg/modules/init-7_b.C: New test. Signed-off-by: Nathaniel Shead
[Bug middle-end/113921] Output register of an "asm volatile goto" is incorrectly clobbered/discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2024-02-14
--- Comment #7 from Jakub Jelinek ---
So, GCC 11 version:
--- gcc/cfgexpand.c.jj 2023-05-09 12:59:04.381738365 +0200
+++ gcc/cfgexpand.c 2024-02-14 19:56:08.733150432 +0100
@@ -3639,7 +3639,16 @@ expand_asm_stmt (gasm *stmt)
emit_insn (copy_insn (PATTERN (curr)));
rtx_insn *copy = get_insns ();
end_sequence ();
- insert_insn_on_edge (copy, e);
+ if (rtx_insn *prev = e->insns.r)
+ {
+ /* Prepend copy before any other previously
+inserted insns on the edge rather than append. */
+ e->insns.r = NULL;
+ insert_insn_on_edge (copy, e);
+ insert_insn_on_edge (prev, e);
+ }
+ else
+ insert_insn_on_edge (copy, e);
}
}
}
changes the emitted assembler:
@@ -7328,7 +7328,7 @@ sync_vmcs02_to_vmcs12:
# 0 "" 2
#NO_APP
.L1127:
- xorl%r12d, %r12d
+ movq%rax, %r12
.L1083:
movq%r12, 240(%rbx)
jmp .L1047
@@ -29897,7 +29897,7 @@ nested_vmx_vmexit:
# 0 "" 2
#NO_APP
.L5187:
- xorl%r12d, %r12d
+ movq%rax, %r12
.L5113:
movq%r12, %rdx
movl$7, %esi
which is I believe exactly what we want.
For GCC trunk the patch would be
--- gcc/cfgexpand.cc.jj 2024-02-10 11:25:09.995474027 +0100
+++ gcc/cfgexpand.cc2024-02-14 19:54:30.811505882 +0100
@@ -3687,7 +3687,16 @@ expand_asm_stmt (gasm *stmt)
copy = get_insns ();
end_sequence ();
}
- insert_insn_on_edge (copy, e);
+ if (rtx_insn *prev = e->insns.r)
+ {
+ /* Prepend copy before any other previously
+inserted insns on the edge rather than append. */
+ e->insns.r = NULL;
+ insert_insn_on_edge (copy, e);
+ insert_insn_on_edge (prev, e);
+ }
+ else
+ insert_insn_on_edge (copy, e);
}
}
}
and with trunk it triggers (I mean the prev != NULL case) only on the
nested_vmx_vmexit
function and not the other one.
Guess one could try to build whole kernel with instrumented gcc (just add
FILE *f = fopen ("/tmp/asmgoto", "a");
fprintf (f, "%s %s\n", main_input_filename ? main_input_filename : "-",
current_function_name ());
fclose (f);
next to the e->insns.r = NULL; in the patch or so) to find out what else it
affects.
[Bug middle-end/113921] Output register of an "asm volatile goto" is incorrectly clobbered/discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 Jakub Jelinek changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- insn 49 above is inserted in #1 0x00d419db in emit_insn (x=0x7fffe6e921f8) at ../../gcc/emit-rtl.c:5106 #2 0x01895ab7 in ix86_expand_move (mode=E_DImode, operands=0x7fffd600) at ../../gcc/config/i386/i386-expand.c:368 #3 0x01de4226 in gen_movdi (operand0=0x7fffe6ec8108, operand1=0x7fffe6ec80f0) at ../../gcc/config/i386/i386.md:1935 #4 0x00db804f in insn_gen_fn::operator() (this=0x2c6cd48 ) at ../../gcc/recog.h:407 #5 0x00d8f394 in emit_move_insn_1 (x=0x7fffe6ec8108, y=0x7fffe6ec80f0) at ../../gcc/expr.c:3766 #6 0x00d8fe7a in emit_move_insn (x=0x7fffe6ec8108, y=0x7fffe6ec80f0) at ../../gcc/expr.c:3936 #7 0x013b8a75 in emit_partition_copy (dest=0x7fffe6ec8108, src=0x7fffe6ec80f0, unsignedsrcp=1, sizeexp=) at ../../gcc/tree-outof-ssa.c:259 #8 0x013b8c5b in insert_partition_copy_on_edge (e= 145)>, dest=72, src=71, locus=2147592841) at ../../gcc/tree-outof-ssa.c:293 #9 0x013b9f0b in elim_create (g=0x7fffd8e0, T=72) at ../../gcc/tree-outof-ssa.c:729 #10 0x013ba0ab in eliminate_phi (e= 145)>, g=0x7fffd8e0) at ../../gcc/tree-outof-ssa.c:771 #11 0x013baaa5 in expand_phi_nodes (sa=0x3169360 ) at ../../gcc/tree-outof-ssa.c:1024 later on insert_partition_copy_on_edge will insert_insn_on_edge on the 138 -> 145 edge, but the insertion remains uncommitted. Later on the asm goto expansion copies after_rtl_seq which contains (set (reg:DI 151) (reg:DI 385)) and calls insert_insn_on_edge on it too. But insert_insn_on_edge appends to the e->insns.r rather than prepends it which presumably is what we'd want for the asm goto case.
[Bug fortran/107071] gfortran.dg/ieee/modes_1.f90 fails on aarch64-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107071 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org --- Comment #12 from Tamar Christina --- Indeed, should we just xfail it on AArch64?
[Bug middle-end/113921] Output register of an "asm volatile goto" is incorrectly clobbered/discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921
--- Comment #5 from Linus Torvalds ---
(In reply to Linus Torvalds from comment #2)
>
> So we could make our workaround option be something like
>
>config GCC_ASM_GOTO_WORKAROUND
> def_bool y
> depends on CC_IS_GCC && GCC_VERSION < 120100
Replying to myself some more, since that kernel side workaround is actually in
two parts: it does the extra empty inline asm as an extra barrier, but it
*also* adds the 'volatile' to the asm with outputs to work around the other gcc
bug.
And that other fix ("Mark asm goto with outputs as volatile") is *not* in
gcc-12.1.0. It has only made it into gcc-13.2.0 (and it's pending in the gcc-12
release branch if I read things right).
I suspect that other bug doesn't affect Sean's kvm case, because the outputs
are always used, but it could affect other kernel code.
So we'd want to have at least gcc-13.2 to be safe.
Hmm.
We could make the "add volatile manually" be the default workaround, though,
since it shouldn't matter.
[Bug middle-end/113921] Output register of an "asm volatile goto" is incorrectly clobbered/discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921
--- Comment #4 from Jakub Jelinek ---
Bisection in the other direction doesn't make much sense, since asm goto with
output operands is only supported in GCC 11 and later.
Anyway, with gcc 11, I can see something fishy already during expansion:
(jump_insn 927 926 1285 191 (parallel [
(set (reg:DI 385 [ value ])
(asm_operands/v:DI ("1: vmread %1, %0
jna %l2
.pushsection "__ex_table","a"
.balign 4
.long (1b) - .
.long (%l3) - .
.long 1
.popsection
") ("=r") 0 [
(reg:DI 386)
]
[
(asm_input:DI ("r")
/home/sean/go/src/kernel.org/linux/arch/x86/kvm/vmx/vmx_ops.h:97)
]
[
(label_ref:DI 959)
(label_ref:DI 965)
]
/home/sean/go/src/kernel.org/linux/arch/x86/kvm/vmx/vmx_ops.h:97))
(clobber (reg:CC 17 flags))
]) "/home/sean/go/src/kernel.org/linux/arch/x86/kvm/vmx/vmx_ops.h":97:2
-1
(insn_list:REG_LABEL_TARGET 1253 (insn_list:REG_LABEL_TARGET 959 (nil)))
-> 965)
;; succ: 197 count:99052688 (estimated locally)
;; 198 count:99052688 (estimated locally)
;; 192 count:99052688 (estimated locally) (FALLTHRU)
;; basic block 192, loop depth 0, count 99052688 (estimated locally), maybe hot
;; prev block 191, next block 193, flags: (NEW, REACHABLE, RTL, MODIFIED)
;; pred: 191 count:99052688 (estimated locally) (FALLTHRU)
(note 1285 927 931 192 [bb 192] NOTE_INSN_BASIC_BLOCK)
(jump_insn 931 1285 932 192 (set (pc)
(label_ref:DI 1253))
"/home/sean/go/src/kernel.org/linux/arch/x86/kvm/vmx/vmx_ops.h":97:2 807 {jump}
(nil)
-> 1253)
;; succ: 199 [always] count:99052688 (estimated locally)
...
(code_label 1253 1251 1252 199 1127 (nil) [1 uses])
(note 1252 1253 49 199 [bb 199] NOTE_INSN_BASIC_BLOCK)
(insn 49 1252 930 199 (set (reg:DI 152 [ _241 ])
(reg/v:DI 151 [ value ]))
"/home/sean/go/src/kernel.org/linux/arch/x86/kvm/vmx/vmx_ops.h":107:9 -1
(nil))
(insn 930 49 968 199 (set (reg/v:DI 151 [ value ])
(reg:DI 385 [ value ]))
"/home/sean/go/src/kernel.org/linux/arch/x86/kvm/vmx/vmx_ops.h":97:2 -1
(nil))
;; succ: 200 [always] count:16508781 (estimated locally) (FALLTHRU)
(code_label 968 930 969 200 1083 (nil) [5 uses])
(note 969 968 970 200 [bb 200] NOTE_INSN_BASIC_BLOCK)
(insn 970 969 971 200 (set (mem:DI (plus:DI (reg/v/f:DI 283 [ vmcs12 ])
(const_int 240 [0xf0])) [19 vmcs12_30(D)->guest_pdptr3+0 S8
A8])
(reg:DI 152 [ _241 ]))
"/home/sean/go/src/kernel.org/linux/arch/x86/kvm/vmx/nested.c":4422:25 -1
(nil))
;; succ: 201 [always] count:55029271 (estimated locally) (FALLTHRU)
So, the asm goto sets pseudo 385 and in case it doesn't jump anywhere, it then
goes
into the 2 pseudo moves but they'd need to be reversed in order to store the
asm goto
output into gues_pdptr3.
[Bug middle-end/113921] Output register of an "asm volatile goto" is incorrectly clobbered/discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 --- Comment #3 from Linus Torvalds --- (In reply to Linus Torvalds from comment #2) > > So we could make our workaround option be something like > >config GCC_ASM_GOTO_WORKAROUND > def_bool y > depends on CC_IS_GCC && GCC_VERSION < 120100 Actually, rather than add a new kernel config option, I'll just make the workaround conditional in our header file. But I'll wait for confirmation from gcc people that Jakub's bisection makes sense, and is the real fix, rather than just a change that just happens to hide the issue.
[Bug middle-end/113921] Output register of an "asm volatile goto" is incorrectly clobbered/discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 --- Comment #2 from Linus Torvalds --- (In reply to Jakub Jelinek from comment #1) > Bisection points to r12-5301-g045206450386bcd774db3bde0c696828402361c6 > making the problem go away, Well, that certainly explains why I can't see the problem with my gcc 13.2.1. It looks like that commit is in gcc-12.1.o and later: git log --oneline --all --grep="tree-optimization/102880 - improve CD-DCE" only returns that one commit, and git name-rev --refs '*releases*' 045206450386b says "gcc-12.1.0~3038". So we could make our workaround option be something like config GCC_ASM_GOTO_WORKAROUND def_bool y depends on CC_IS_GCC && GCC_VERSION < 120100 but maybe there is some backporting policy with gcc that my quick git check missed?
[Bug testsuite/113861] c-c++-common/gomp/pr63328.c and gcc.dg/gomp/pr87895-2.c now XPASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113861 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #2 from Andrew Pinski --- Fixed.
[Bug testsuite/113861] c-c++-common/gomp/pr63328.c and gcc.dg/gomp/pr87895-2.c now XPASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113861 --- Comment #1 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:2b5e0c11a40865b33bc4424b3c344176eaecf104 commit r14-8986-g2b5e0c11a40865b33bc4424b3c344176eaecf104 Author: Andrew Pinski Date: Wed Feb 14 09:34:24 2024 -0800 aarch64/testsuite: Remove dg-excess-errors from c-c++-common/gomp/pr63328.c and gcc.dg/gomp/pr87895-2.c [PR113861] These now pass after r14-6416-gf5fc001a84a7db so let's remove the dg-excess-errors from them. Committed as obvious after a test for aarch64-linux-gnu. gcc/testsuite/ChangeLog: PR testsuite/113861 * c-c++-common/gomp/pr63328.c: Remove dg-excess-errors. * gcc.dg/gomp/pr87895-2.c: Likewise. Signed-off-by: Andrew Pinski
[Bug middle-end/113921] Output register of an "asm volatile goto" is incorrectly clobbered/discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Bisection points to r12-5301-g045206450386bcd774db3bde0c696828402361c6 making the problem go away, 3abc: b8 10 28 00 00 mov$0x2810,%eax 3ac1: 0f 78 c0vmread %rax,%rax 3ac4: 0f 86 1e 01 00 00 jbe3be8 3aca: 45 31 e4xor%r12d,%r12d 3acd: 4c 89 a3 f0 00 00 00mov%r12,0xf0(%rbx) to 3a4f: b8 10 28 00 00 mov$0x2810,%eax 3a54: 0f 78 c0vmread %rax,%rax 3a57: 0f 86 1b 01 00 00 jbe3b78 3a5d: 48 89 83 f0 00 00 00mov%rax,0xf0(%rbx)
[Bug ada/113781] Bug box on array initialisation with iterated aggregate component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113781 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-14 --- Comment #1 from Eric Botcazou --- Optimization is irrelevant, it"s an issue in the front-end.
[Bug ada/113862] error: "others" choice not allowed here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113862 Eric Botcazou changed: What|Removed |Added Status|NEW |SUSPENDED
[Bug ada/113862] error: "others" choice not allowed here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113862 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2024-02-14 Status|UNCONFIRMED |NEW --- Comment #1 from Eric Botcazou --- Not clear if there is much value in creating a PR for such a pathological case if it happens to be legal.
[Bug ada/113893] finalization issue with anonymous access object of local type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113893 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/113567] ICE: SSA corruption: Unable to coalesce ssa_names 1 and 3 which are marked as MUST COALESCE. with _BitInt() and computed goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113567 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Jakub Jelinek --- Created attachment 57429 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57429=edit gcc14-pr113567.patch Untested fix.
[Bug middle-end/113415] ICE: RTL check: -mstringop-strategy=byte_loop vs inline-asm goto with block copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113415 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug libstdc++/113074] std::to_address should be SFINAE safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074 --- Comment #14 from Peter Kasting --- (In reply to Jonathan Wakely from comment #13) > As I said in comment 7, LWG considered this case and it was pointed out that > the problem described can only occur if a type defines iterator_concept = > contiguous_iterator; but then fails to actually provide the operations > needed for a contiguous iterator (i.e. either a pointer_traits > specialization with to_address or a sane operator->()). That's fair. But that only considers the functionality of to_address() inside this specific library use of it. If this tool is to be usable in other contexts (which I argue it should be, or it shouldn't have been exposed to end users), then said contexts may have nothing to do with iterators. And you are right, it's possible to reimplement concepts around "is this even legal to pass to to_address()", which is basically what we're doing to address this in Chromium. But that's pretty unfriendly to most usage; if you're in a context where you are reaching for to_address() to begin with, it's likely because you're templated and don't know that a simpler thing like `&*ptr` is valid. In such cases, having to_address() be SFINAE-friendly makes it far easier to fall back to other handling for "not a pointer". > A SFINAE-friendly std::to_address as implemented in libc++ means that such > an iterator will fail to satisfy std::contiguous_iterator and will silently > degrade to satosfying std::random_access_iterator only. It's not at all > clear to me that silently degrading such an iterator (which very explicitly > claims to be a contiguous iterator by defining iterator_concept to say so) > would be an improvement. I'd rather get an error telling me the thing I > thought was a contiguous iterator was not actually. That's fair, but isn't that implementable by simply making the definition of contiguous_iterator explicitly hard error in this case? That is, an SFINAE-friendly to_address() wouldn't prevent you from diagnosing this particular usage site as incorrect.
[Bug rtl-optimization/103908] gcc miscompile asm goto for O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103908 Andrew Pinski changed: What|Removed |Added Known to fail|12.0|10.3.0, 11.2.0, 9.4.0 Known to work||10.4.0, 11.3.0, 9.5.0 Target Milestone|--- |9.5
[Bug c/113921] New: Output register of an "asm volatile goto" is incorrectly clobbered/discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921
Bug ID: 113921
Summary: Output register of an "asm volatile goto" is
incorrectly clobbered/discarded
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: seanjc at google dot com
CC: jakub at redhat dot com, ndesaulniers at google dot com,
torva...@linux-foundation.org, ubizjak at gmail dot com
Target Milestone: ---
Created attachment 57428
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57428=edit
Intermediate output of the miscompiled file
gcc-11 appears to have a bug that results in gcc incorrectly clobbering the
output register of an "asm volatile goto".
The failing asm blob is a sequence of VMREADs in the Linux kernel, with the
outputs stored into a dynamically allocated structure whose lifecycle is far
beyond the scope of the code in question:
vmcs12->guest_pdptr0 = vmcs_read64(GUEST_PDPTR0);
vmcs12->guest_pdptr1 = vmcs_read64(GUEST_PDPTR1);
vmcs12->guest_pdptr2 = vmcs_read64(GUEST_PDPTR2);
vmcs12->guest_pdptr3 = vmcs_read64(GUEST_PDPTR3);
where vmcs_read64() eventually becomes:
asm volatile goto("1: vmread %[field], %[output]\n\t"
"jna %l[do_fail]\n\t"
_ASM_EXTABLE(1b, %l[do_exception])
: [output] "=r" (value)
: [field] "r" (field)
: "cc"
: do_fail, do_exception);
return value;
do_fail:
instrumentation_begin();
vmread_error(field);
instrumentation_end();
return 0;
do_exception:
kvm_spurious_fault();
return 0;
The first three PDPTR VMREADs generate correctly, but the fourth effectively
gets ignored, and '0' is written to vmcs12->guest_pdptr3.
3597: mov$0x280a,%r13d
359d: vmread %r13,%r13
35a1: jbe3724
35a7: mov%r13,0xd8(%rbx)
35ae: jmp396b
35b3: mov$0x280c,%r13d
35b9: vmread %r13,%r13
35bd: jbe3705
35c3: mov%r13,0xe0(%rbx)
35ca: jmp393a
35cf: mov$0x280e,%r13d
35d5: vmread %r13,%r13
35d9: jbe36e6
35df: mov%r13,0xe8(%rbx)
35e6: jmp3909
35eb: mov$0x2810,%eax
35f0: vmread %rax,%rax<= VMREAD to nowhere
35f3: jbe36ca
35f9: xor%r12d,%r12d <= zeroing of output
35fc: mov%r12,0xf0(%rbx) <= store to vmcs12->guest_pdptr3
Replacing "asm volatile goto" with the following macro
#define asm_goto(x...) \
do { asm volatile goto(x); asm (""); } while (0)
to force a second barrier generates functional code, although the attempt to
miscompile the sequence is still evident, as the output of the affected VMREAD
is unnecessarily bounced through an extra register:
35f8: mov$0x280a,%r13d
35fe: vmread %r13,%r13
3602: jbe36b2
3608: mov%r13,0xd8(%rbx)
360f: jmp3925
3614: mov$0x280c,%r13d
361a: vmread %r13,%r13
361e: jbe3693
3620: mov%r13,0xe0(%rbx)
3627: jmp38f4
362c: mov$0x280e,%r13d
3632: vmread %r13,%r13
3636: jbe367a
3638: mov%r13,0xe8(%rbx)
363f: jmp38c3
3644: mov$0x2810,%eax
3649: vmread %rax,%rax
364c: jbe3664
364e: mov%rax,%r12
3651: mov%r12,0xf0(%rbx)
The bug reproduces with two different 11.4.0 builds, on three different systems
(Intel i7-9850H, Intel i7-13700K, AMD EPYC 7B12), all running Debian-based
Linux.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror
[Bug ipa/113291] [14 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291 --- Comment #6 from Jan Hubicka --- Created attachment 57427 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57427=edit patch The patch makes compilation to finish in reasonable time. I ended up in need to dropping DISREGARD_INLINE_LIMITS in late inlining for functions with self recursive always inlines, since these grow large quick and even non-recursive inlining is too slow. We also end up with quite ugly diagnostics of form: tt.c:13:1: error: inlining failed in call to ‘always_inline’ ‘f1’: --param max-inline-insns-auto limit reached 13 | f1 (void) | ^~ tt.c:17:3: note: called from here 17 | f1 (); | ^ tt.c:6:1: error: inlining failed in call to ‘always_inline’ ‘f0’: --param max-inline-insns-auto limit reached 6 | f0 (void) | ^~ tt.c:16:3: note: called from here 16 | f0 (); | ^ tt.c:13:1: error: inlining failed in call to ‘always_inline’ ‘f1’: --param max-inline-insns-auto limit reached 13 | f1 (void) | ^~ tt.c:15:3: note: called from here 15 | f1 (); | ^ In function ‘f1’, inlined from ‘f0’ at tt.c:8:3, which is quite large so I can not add it to a testuiste. I will see if I can reduce this even more.
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #10 from Jakub Jelinek --- Or convince Oracle to change it (again, an ABI break).
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #9 from Jonathan Wakely --- It's technically an ABI break, since void f(int8_t) would mangle differently. It probably wouldn't affect much in practice, but would still be a break.
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- (In reply to Jonathan Wakely from comment #7) > (In reply to Jonathan Wakely from comment #1) > > I assume that int8_t is char on Solaris, rather than signed char? > > This actually violates the C and C++ standards, which require that intN_t is > a signed integer type, and C 6.2.5 says "There are five standard signed > integer types, designated as signed char, short int, int, long int, and long > long int." So char isn't allowed, it should be signed char. > > I don't know if it's possible to fix that on Solaris. fixinc?
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #7 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > I assume that int8_t is char on Solaris, rather than signed char? This actually violates the C and C++ standards, which require that intN_t is a signed integer type, and C 6.2.5 says "There are five standard signed integer types, designated as signed char, short int, int, long int, and long long int." So char isn't allowed, it should be signed char. I don't know if it's possible to fix that on Solaris.
[Bug c++/113920] Make -std=gnu++20 default for GCC 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113920 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-02-14
[Bug c++/113920] New: Make -std=gnu++20 default for GCC 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113920 Bug ID: 113920 Summary: Make -std=gnu++20 default for GCC 15 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org Target Milestone: --- Once C++20 support in libstdc++ has been declared stable, we should probably switch the default from gnu++17 to gnu++20 in GCC 15. C++ modules will still be experimental though.
[Bug middle-end/111054] [14 Regression] ICE: in to_sreal, at profile-count.cc:472 with -O3 -fno-guess-branch-probability since r14-2967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111054 Jan Hubicka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jan Hubicka --- Fixed.
[Bug middle-end/111054] [14 Regression] ICE: in to_sreal, at profile-count.cc:472 with -O3 -fno-guess-branch-probability since r14-2967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111054 --- Comment #6 from GCC Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:8d51bfe0f97a27c749c36003867901338833340a commit r14-8985-g8d51bfe0f97a27c749c36003867901338833340a Author: Jan Hubicka Date: Wed Feb 14 17:37:34 2024 +0100 Fix ICE in loop splitting with -fno-guess-branch-probability PR tree-optimization/111054 gcc/ChangeLog: * tree-ssa-loop-split.cc (split_loop): Check for profile being present. gcc/testsuite/ChangeLog: * gcc.c-torture/compile/pr111054.c: New test.
[Bug c++/72751] anonymous union within an anonymous union accepted without diagnostic (i.e. add -Wnested-anon-types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72751 --- Comment #5 from Marek Polacek --- We should also make sure that __extension__ suppresses the -Wnested-anon-types diagnostic.
[Bug c++/72751] anonymous union within an anonymous union accepted without diagnostic (i.e. add -Wnested-anon-types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72751
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #4 from Marek Polacek ---
Test from Bug 113919:
struct _ {
union
{
union {
int __;
};
};
};
int main(){return 0;}
[Bug c++/113919] Nested anonymous unions should be prohibited in ISO C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113919 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Marek Polacek --- Ah, we have a dup. *** This bug has been marked as a duplicate of bug 72751 ***
[Bug c++/72751] anonymous union within an anonymous union accepted without diagnostic (i.e. add -Wnested-anon-types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72751 Marek Polacek changed: What|Removed |Added CC||tsqurt at outlook dot com --- Comment #3 from Marek Polacek --- *** Bug 113919 has been marked as a duplicate of this bug. ***
[Bug ipa/113291] [14 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291 --- Comment #5 from Jan Hubicka --- There is a cap in want_inline_self_recursive_call_p which gives up on inlining after reaching max recursive inlining depth of 8. Problem is that the tree here is too wide. After early inlining f0 contains 4 calls to f1 and 3 calls to f0. Similarly for f0, so we have something like (9+3*9)^8 as a cap on number of inlines that takes a while to converge. One may want to limit number of copies of function A within function B rather than depth, but that number can be large even for sane code. I am making patch to make inliner to ignore always_inline on all self-recrusive inline decisions.
[Bug ada/113893] finalization issue with anonymous access object of local type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113893 Eric Botcazou changed: What|Removed |Added Status|SUSPENDED |NEW --- Comment #3 from Eric Botcazou --- On second thoughts, some stopgap measure is probably in order.
[Bug ipa/113291] [14 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291 --- Comment #4 from Jan Hubicka --- There is a cap in want_inline_self_recursive_call_p which gives up on inlining after reaching max recursive inlining depth of 8. Problem is that the tree here is too wide. After early inlining f0 contains 4 calls to f1 and
[Bug c++/113919] Nested anonymous unions should be prohibited in ISO C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113919 --- Comment #3 from Marek Polacek --- clang++ has -Wnested-anon-types so I think we need that too.
[Bug libfortran/99210] X editing for reading file with encoding='utf-8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210 --- Comment #8 from GCC Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:b79d3e6a9284703b70688122f7d4955e7c50804a commit r14-8983-gb79d3e6a9284703b70688122f7d4955e7c50804a Author: Jerry DeLisle Date: Tue Feb 13 14:32:21 2024 -0800 Fortran: Implement read_x for UTF-8 encoded files. PR fortran/99210 libgfortran/ChangeLog: * io/read.c (read_x): If UTF-8 encoding is enabled, use read_utf8 to move one character over in the read buffer. gcc/testsuite/ChangeLog: * gfortran.dg/pr99210.f90: New test.
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #30 from Jakub Jelinek ---
Created attachment 57426
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57426=edit
gcc14-pr113907.patch
I've managed to come up with a small runtime testcase.
Now with a patch which does the resetting of SSA_NAME_{PTR,RANGE}_INFO for
!flag_wpa in ICF merged functions (in the hope that we regenerate it during
vrp1).
[Bug ada/113893] finalization issue with anonymous access object of local type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113893 Eric Botcazou changed: What|Removed |Added Status|NEW |SUSPENDED --- Comment #2 from Eric Botcazou --- No plan to fix this in the short term.
[Bug ada/113893] finalization issue with anonymous access object of local type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113893 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||ebotcazou at gcc dot gnu.org Summary|Finalization exception |finalization issue with |issue with anonymous access |anonymous access object of |object. |local type Last reconfirmed||2024-02-14 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- The problem is that the finalization routine of Float_Sanitized.Container is local to Test01 but is invoked indirectly from "its enclosing library unit" when the dynamically allocated object is finalized, namely the enclosing procedure. So it's a plain dangling reference and its effects depend on the phase of the moon, for example the mere presence of Test02. The workaround is of course to follow the advice of the warning or else to move the instantiation of Float_Sanitized to the enclosing procedure.
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #29 from Jan Hubicka --- Safest fix is to make equals_p to reject merging functions with different value ranges assigned to corresponding SSA names. I would hope that, since early opts are still mostly local, that does not lead to very large degradation. This is lame of course. If we go for smarter merging, we need to also handle ipa-prop jump functions. In that case I think equals_p needs to check if value range sin SSA_NAMES and jump functions differs and if so, keep that noted so the merging code can do corresponding update. I will check how hard it is to implement this. (Equality handling is Martin Liska's code, but if I recall right, each equivalence class has a leader, and we can keep track if there are some differences WRT that leader, but I do not recall how subdivision of equivalence classes is handled).
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #55 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #53)
> Comment on attachment 57424 [details]
> Proposed testsuite patch
>
> As skylake-avx512 is -mavx512{f,cd,bw,dq,vl}, requiring just avx512f
> effective target and testing it at runtime IMHO isn't enough.
> For dg-do run testcases I really think we should avoid those -march=
> options, because it means a lot of other stuff, BMI, LZCNT, ...
I think that addition of
+# if defined(__AVX512VL__)
+want_level = 7, want_b = bit_AVX512VL;
+# elif defined(__AVX512F__)
+want_level = 7, want_b = bit_AVX512F;
+# elif defined(__AVX2__)
to check_vect solves all current uses in gcc.dg/vect
[Bug c++/113919] Nested anonymous unions should be prohibited in ISO C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113919 --- Comment #2 from Marek Polacek --- I suppose this should fix it but there are testsuite FAILs. --- a/gcc/cp/decl.cc +++ b/gcc/cp/decl.cc @@ -5522,6 +5522,12 @@ fixup_anonymous_aggr (tree t) } } } + /* [class.union.anon]/1: Nested types, anonymous unions, and functions +shall not be declared within an anonymous union. */ + else if (ANON_UNION_TYPE_P (TREE_TYPE (probe))) + pedwarn (DECL_SOURCE_LOCATION (probe), OPT_Wpedantic, +"anonymous unions cannot be declared within an anonymous " +"union"); } /* Splice all functions out of CLASSTYPE_MEMBER_VEC. */
[Bug c++/113332] [12/13 regression] checking ICE when building fcitx-5.1.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113332 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/113908] [14 Regression] bogus access error with new-expr of current non-template class with implicitly deleted copy ctor since r14-557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113908 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Patrick Palka --- Fixed.
[Bug c++/113908] [14 Regression] bogus access error with new-expr of current non-template class with implicitly deleted copy ctor since r14-557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113908 --- Comment #1 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:9bc6b23d11697545e8a951ccd60691b1e58b98c2 commit r14-8981-g9bc6b23d11697545e8a951ccd60691b1e58b98c2 Author: Patrick Palka Date: Wed Feb 14 10:20:31 2024 -0500 c++: synthesized_method_walk context independence [PR113908] In the second testcase below, during ahead of time checking of the non-dependent new-expr we synthesize B's copy ctor, which we expect to get defined as deleted since A's copy ctor is inaccessible. But during access checking thereof, enforce_access incorrectly decides to defer it since we're in a template context according to current_template_parms (before r14-557 it checked processing_template_decl which got cleared from implicitly_declare_fn), which leads to the access check leaking out to the template context that triggered the synthesization, and B's copy ctor getting declared as non-deleted. This patch fixes this by using maybe_push_to_top_level to clear the context (including current_template_parms) before proceeding with the synthesization. We could do this from implicitly_declare_fn, but it's better to do it more generally from synthesized_method_walk for sake of its other callers. This turns out to fix PR113332 as well: there the lambda context triggering synthesization was causing maybe_dummy_object to misbehave, but now synthesization is sufficiently context-independent. PR c++/113908 PR c++/113332 gcc/cp/ChangeLog: * method.cc (synthesized_method_walk): Use maybe_push_to_top_level. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-nsdmi11.C: New test. * g++.dg/template/non-dependent31.C: New test. Reviewed-by: Jason Merrill
