[Bug target/103842] [12 regression] ICE on ilmbase-2.5.7: during RTL pass: expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103842 --- Comment #6 from Uroš Bizjak --- (In reply to Jakub Jelinek from comment #5) > Created attachment 52068 [details] > gcc12-pr103842.patch > > Untested fix. The patch is OK. Thanks, Uros.
[Bug c++/103849] New: std::hash specializations with distinct concepts fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103849
Bug ID: 103849
Summary: std::hash specializations with distinct concepts fails
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
The two specialization of std::hash with distinct concepts:
```
#include
#include
template T>
struct std::hash {};
template U>
struct std::hash {};
int main() {}
```
fails to compile in GCC with the error:
```
error: redefinition of 'struct std::hash<_Tp>'
8 | struct std::hash {};
```
Clang and MSVC have no problem with it. Demo:
https://gcc.godbolt.org/z/z4f3o6bdo
Related discussion: https://stackoverflow.com/q/68885697/7325599
[Bug tree-optimization/51964] Missed tail merging opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51964 Andrew Pinski changed: What|Removed |Added Status|NEW |ASSIGNED
[Bug tree-optimization/51964] Missed tail merging opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51964 Andrew Pinski changed: What|Removed |Added Depends on||13563 Status|ASSIGNED|NEW --- Comment #4 from Andrew Pinski --- PR 13563 is really similar. The only difference is the call is both operands of 7 here while in that case it is 0/1. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13563 [Bug 13563] if-conversion not agressive enough
[Bug tree-optimization/51964] Missed tail merging opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51964 Andrew Pinski changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Last reconfirmed|2016-08-14 00:00:00 |2021-12-27 Status|NEW |ASSIGNED CC||pinskia at gcc dot gnu.org --- Comment #3 from Andrew Pinski --- I thought there was another bug for this same thing.
[Bug tree-optimization/65426] Recognize byte-swaps when writing to buffers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65426 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Target Milestone|--- |10.0 Known to fail||7.1.0 Known to work||10.1.0, 12.0 Resolution|--- |FIXED --- Comment #4 from Andrew Pinski --- All functions are detected and fixed in GCC 10+. A few were fixed in GCC 8 and GCC 9 even.
[Bug tree-optimization/68694] SLP loads should be permuted until supported if possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68694 Andrew Pinski changed: What|Removed |Added Known to work||10.1.0, 9.3.0 Known to fail||9.2.0 Target Milestone|--- |9.3 --- Comment #1 from Andrew Pinski --- Looks to be fixed in GCC 9.3.0 and GCC 10+.
[Bug target/86693] inefficient atomic_fetch_xor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86693
--- Comment #6 from Hongtao.liu ---
(In reply to H.J. Lu from comment #5)
> (In reply to Hongtao.liu from comment #4)
> > Change testcase a little bit, gcc now can generate lock btc
> >
> >
> > void func1();
> >
> > void func(unsigned long *counter)
> > {
> > if (__atomic_fetch_xor(counter, 1, __ATOMIC_ACQ_REL) & 1) {
> > func1();
> > }
> > }
> >
> >
> > func(unsigned long*):
> > lock btcQWORD PTR [rdi], 0
> > jc .L4
> > ret
> > .L4:
> > jmp func1()
>
> We should rewrite the original test to the canonical form, similar to
> r12-5102.
> Hongtao, can you do that?
The orginal testcase is not equal to btc, __atomic_fetch_xor(counter, 1,
__ATOMIC_ACQ_REL) == 1 require other bits of *counter is 0. And as #c1 said, we
don't have instructions to keep the old or new value of xor or ior in a
register.
I can't find a way to optimize off the exchangeloop.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 57169, which changed state. Bug 57169 Summary: fully unrolled matrix multiplication not vectorized https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57169 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/57169] fully unrolled matrix multiplication not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57169 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |10.0 Known to work||10.1.0, 12.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Andrew Pinski --- GCC 6-9 vectorizes both but matmul uses scalar loads until GCC 10. So all fixed in GCC 10+.
[Bug ipa/86132] Failure to elide condition known to be non-null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86132 --- Comment #3 from Andrew Pinski --- https://gcc.gnu.org/legacy-ml/gcc/2012-10/msg00024.html
[Bug c++/99968] ICE on remove_const_t in requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99968 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug tree-optimization/53044] completely peel loops that do not run a constant time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53044 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > Complete peeling was done by r0-119587-gb7442c2fe0e28 . So all fixed. Note the testcases for this case were added with r0-119617-gc8379865b38e7 .
[Bug tree-optimization/53044] completely peel loops that do not run a constant time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53044 Andrew Pinski changed: What|Removed |Added Known to work||4.8.1, 4.9.2, 5.1.0, 6.1.0, ||7.1.0, 8.1.0 Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Target Milestone|--- |4.8.0 Known to fail||4.7.4 --- Comment #1 from Andrew Pinski --- Complete peeling was done by r0-119587-gb7442c2fe0e28 . So all fixed.
[Bug c++/98401] coroutines: Temporaries passed to co_await sometimes cause an extraneous call to destructor at incorrect address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98401
--- Comment #8 from Milo Brandt ---
I was trying to fix this and, from my work, I have a precise diagnosis of the
bug and a hack that *mostly* fixes things, but leaves a more subtle bug
unfixed. Debugging this is getting over my head, but the descriptions below
should suffice to describe fairly precisely how the bug operates and what
behavior needs to be changed to patch it - perhaps someone more capable with
this codebase will find this helpful. Apologies for the length of this comment,
but the issue is very particular.
The bugs reported here arise from the following behavior of the code that
morphs functions to coroutines: when a temporary is created by aggregate
initialization and has its lifetime extended across a suspension point, the
members of the temporary are constructed out of place, then effectively
memcpy'd into the slots for the members of the constructed aggregate. After the
suspend point, both the temporary itself and the members that were constructed
out of place are destroyed.
This is incorrect behavior. The expected behavior is that the temporary gets
its lifetime extended, but that its members are initialized in place. Only the
temporary itself should be cleaned up. The current behavior can lead to serious
problems in generated code - for instance, if the aggregate initialized struct
had a unique_ptr as a member, the current behavior will delete that pointer
twice, almost certainly causing correct code to crash at runtime when compiled
with gcc.
As a particular example, if we had "struct Pair { X x; Y y; };" and wished to
write a line of code such as "Pair{}, co_await /*awaitable*/;", the existing
code allocates a slot in the coroutine frame for values of type Pair, X, and Y.
It initializes the slots for X and Y via constructor calls, then copies the
memory from these slots to the members of the Pair slot, then call destructors
for each of the three promoted temporaries.
This behavior is implemented in gcc/cp/coroutines.cc and principally involves
the functions maybe_promote_temps and flatten_await_stmt, which are responsible
for finding temporaries in expressions involving co_await and promoting them to
values in the coroutine's frame. At present, to flatten a sub-expression such
as Pair{} appearing in a co_await statement, it will detect three expressions
of interest: one representing the Pair itself, then two as sub-nodes of the
CONSTRUCT node for that Pair, corresponding to the two members. These are
identified by find_interesting_subtree, which calls tmp_target_expr_p, which
selects TARGET_EXPRs that are artificial (from the compiler) and which are not
associated to a named variable. All three TARGET_EXPRs meet these criteria, and
hence get promoted, even though only the outermost one actually *should* be
promoted.
This can largely be fixed by adding the following lines to tmp_target_expr_p:
+ if (TREE_CODE (TREE_OPERAND (t, 1)) == AGGR_INIT_EXPR)
+return false;
Adding these lines doesn't harm any existing tests and resolves the problem
reported here - they ensure that a temporary that is aggregate initialized, but
has its lifetime extended over a suspension point will have its members
constructed in place and not have their destructors called spuriously. This is
kind of a hack, but it does fix the problem reported in this thread and doesn't
seem to create any new problems.
However, this patch fails to fix a more subtle bug that is intimately tied to
the one it fixes: if there is a suspension point *during* aggregate
initialization, the initializers for the aggregate will be executed in the
wrong order even though the standard guarantees their execution order will be
from first to last. For instance, code such as "Pair{.x{}, .y=(co_await
std::suspend_always{}, 1)};" acts incorrectly by first calling the awaiter's
await_ready and await_suspend functions, then, upon resumption, constructing
the .x member via X::X(), *then* calling the awaiter's await_resume,
constructing .y, and calling Pair::~Pair(). I believe that the only correct
behavior for this line is to construct .x via X::X(), then call await_ready and
await_suspend, then, upon resumption, calling await_resume immediately, then
constructing the .y member and calling Pair::~Pair() to clean up (the only
difference being that X::X() must be called before await_ready). If the
coroutine is destroyed instead, we should destroy the .x member via X::~X()
(or, similarly, we must call X::~X() if the call to Y::Y(int) throws an
exception after resumption). An example that prints out the ordering of these
functions is here: https://godbolt.org/z/dz1818naf (though note that none of
gcc, clang nor MSVC correctly handle this code).
I believe that the correct way to patch this problem is as follows:
1. The function flatten_await_stmt must look specifically for CONSTRUCTOR nodes
in the tree and, if any initializer other than the first contains a co_await
statement, this CONSTRU
[Bug c++/98401] coroutines: Temporaries passed to co_await sometimes cause an extraneous call to destructor at incorrect address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98401 --- Comment #7 from Milo Brandt --- Created attachment 52075 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52075&action=edit A proposed testcase for a more subtle variant of the same bug.
[Bug c++/98401] coroutines: Temporaries passed to co_await sometimes cause an extraneous call to destructor at incorrect address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98401 --- Comment #6 from Milo Brandt --- Created attachment 52074 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52074&action=edit A proposed testcase for the original bug.
[Bug ipa/46228] code produced for STL container is worse in 4.5.1 than in 4.4.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46228 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED CC||marxin at gcc dot gnu.org Component|tree-optimization |ipa Target Milestone|--- |4.8.0 Resolution|--- |FIXED --- Comment #17 from Andrew Pinski --- Fixed in GCC 4.8.0. There has been many many inlining changes since then even and it looks like it stayed fixed too.
[Bug tree-optimization/59859] [meta-bug] GRAPHITE issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 Bug 59859 depends on bug 90200, which changed state. Bug 90200 Summary: [graphite] ICE: Segmentation fault (in apply_schedule_on_deps) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90200 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/90200] [graphite] ICE: Segmentation fault (in apply_schedule_on_deps)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90200 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Target Milestone|--- |10.0 Resolution|--- |FIXED --- Comment #2 from Andrew Pinski --- Reporter reports it is fixed so closing as fixed. I can't reproduce it with GCC 9.1.0 either on x86_64.
[Bug libstdc++/103848] [11/12 Regression] std::deque<>::iterator operator- uses "0" for nullptr check, triggers "zero-as-null-pointer-constant" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103848 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-12-28 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||diagnostic Summary|std::deque<>::iterator |[11/12 Regression] |operator- uses "0" for |std::deque<>::iterator |nullptr check, triggers |operator- uses "0" for |"zero-as-null-pointer-const |nullptr check, triggers |ant" warning|"zero-as-null-pointer-const ||ant" warning Target Milestone|--- |11.0 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/103845] ICE in execute, at gimple-harden-conditionals.cc:552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103845 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-12-28 --- Comment #1 from Andrew Pinski --- Confirmed. 552 gcc_checking_assert (single_succ_p (gsi_bb (gsi_split))); ;; basic block 5, loop depth 0, count 1073312329 (estimated locally), maybe hot ;;prev block 4, next block 6, flags: (NEW, REACHABLE, IRREDUCIBLE_LOOP, VISITED) ;;pred: 3 [100.0% (guessed)] count:1073312328 (estimated locally) (FALLTHRU,IRREDUCIBLE_LOOP,EXECUTABLE) _2 = _11 != 0; ;;succ: 6 [100.0% (guessed)] count:1072883005 (estimated locally) (FALLTHRU,EXECUTABLE) ;;4 [0.0% (guessed)] count:429324 (estimated locally) (ABNORMAL,IRREDUCIBLE_LOOP,EXECUTABLE)
[Bug libstdc++/103848] New: std::deque<>::operator- uses "0" for nullptr check, triggers "zero-as-null-pointer-constant"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103848 Bug ID: 103848 Summary: std::deque<>::operator- uses "0" for nullptr check, triggers "zero-as-null-pointer-constant" Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: stefan.bru...@rwth-aachen.de Target Milestone: --- Since https://github.com/gcc-mirror/gcc/commit/f6be5d6ee31b76838e242704782938bc9745659c using `operator-` may fail: ``` [ 346s] In file included from /usr/include/c++/11/deque:67, [ 346s] from /usr/include/c++/11/queue:60, ... [ 346s] /usr/include/c++/11/bits/stl_deque.h:356:58: error: zero as null pointer constant [-Werror=zero-as-null-pointer-constant] [ 346s] 356 | * (__x._M_node - __y._M_node - int(__x._M_node != 0)) [ 346s] | ^~~~ [ 346s] cc1plus: some warnings being treated as errors ```
[Bug c++/96943] incomplete type for template for self named using an enum value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96943 Andrew Pinski changed: What|Removed |Added Known to fail||4.1.2 Last reconfirmed||2021-12-28 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Summary|incomplete type used in |incomplete type for |nested name specifier |template for self named ||using an enum value --- Comment #1 from Andrew Pinski --- Confirmed, not a regression.
[Bug go/68931] gccgo fails to build using MUSL libc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68931 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Status|UNCONFIRMED |RESOLVED Keywords||build Resolution|--- |FIXED --- Comment #6 from Andrew Pinski --- I think this is all fixed on the trunk after r12-5979 so closing as fixed.
[Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847 --- Comment #3 from matoro --- Oh, and just for reference, I did confirm that these crashes do not occur on amd64.
[Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847 --- Comment #2 from matoro --- Created attachment 52073 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52073&action=edit build-without-network.log
[Bug go/103847] gccgo SIGSEGV in libgo standard library on sparc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847 matoro changed: What|Removed |Added CC||matoro_gcc_bugzilla@matoro. ||tk --- Comment #1 from matoro --- Created attachment 52072 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52072&action=edit build-with-network.log
[Bug go/103847] New: gccgo SIGSEGV in libgo standard library on sparc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103847 Bug ID: 103847 Summary: gccgo SIGSEGV in libgo standard library on sparc64 Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: matoro_gcc_bugzilla at matoro dot tk CC: cmang at google dot com Target Milestone: --- $ go version go version go1.16.5 gccgo (Gentoo 11.2.1_p20211127 p2) 11.2.1 20211127 linux/sparc64 $ gccgo -v Using built-in specs. COLLECT_GCC=gccgo COLLECT_LTO_WRAPPER=/usr/libexec/gcc/sparc64-unknown-linux-gnu/11.2.1/lto-wrapper Target: sparc64-unknown-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-11.2.1_p20211127/work/gcc-11-20211127/configure --host=sparc64-unknown-linux-gnu --build=sparc64-unknown-linux-gnu --prefix=/usr --bindir=/usr/sparc64-unknown-linux-gnu/gcc-bin/11.2.1 --includedir=/usr/lib/gcc/sparc64-unknown-linux-gnu/11.2.1/include --datadir=/usr/share/gcc-data/sparc64-unknown-linux-gnu/11.2.1 --mandir=/usr/share/gcc-data/sparc64-unknown-linux-gnu/11.2.1/man --infodir=/usr/share/gcc-data/sparc64-unknown-linux-gnu/11.2.1/info --with-gxx-include-dir=/usr/lib/gcc/sparc64-unknown-linux-gnu/11.2.1/include/g++-v11 --with-python-dir=/share/gcc-data/sparc64-unknown-linux-gnu/11.2.1/python --enable-languages=c,c++,go --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --disable-libunwind-exceptions --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 11.2.1_p20211127 p2' --disable-esp --enable-libstdcxx-time --with-build-config=bootstrap-lto --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libssp --disable-libada --disable-cet --disable-systemtap --disable-valgrind-annotations --disable-vtable-verify --disable-libvtv --without-zstd --enable-lto --with-isl --disable-isl-version-check --enable-default-pie --enable-default-ssp Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.2.1 20211127 (Gentoo 11.2.1_p20211127 p2) $ uname -a Linux 5.15.11-gentoo-sparc64 #1 SMP sparc64 sun4v UltraSparc T4 (Niagara4) GNU/Linux I am attempting to build a simple go application using gccgo on this sparc64 host, but keep getting compiler SEGV inside the libgo standard library. This is happening for pretty much all commands except for simple version checks. When trying to build from a fresh clone, the crash seem to be in network related code as dependencies are pulled down. When trying to build in an environment where dependencies are pre-downloaded, the crash seems to be in semaphore synchronization. Both runs were done with GOMAXPROCS=1 in order to make the traceback logs deterministic. I also attempted to bootstrap the gc compiler using gcc, but got the same results. I've attached the crash logs from the two different types of builds I attempted as build-with-network.log and build-without-network.log, respectively.
[Bug fortran/102332] ICE in select_type_set_tmp, at fortran/match.c:6366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102332 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Priority|P3 |P4 Status|NEW |ASSIGNED --- Comment #3 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2021-December/057228.html
[Bug tree-optimization/103815] IVCann/IVOPTs changes induction variable so it is an addition but the need for shift is there and the result could have used for the (loop) exit compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103815 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug libfortran/98076] Increase speed of integer I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98076 --- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #11 from Francois-Xavier Coudert > --- > Hi Rainer, > > Apologies for that, apparently I got confused between the keyword and the > macro > form. Can you confirm that bootstrapped is fixed if you change it to > > static_assert(sizeof(GFC_UINTEGER_LARGEST) <= 2 * sizeof(uint64_t), >"integer too large"); > > ? If so, I will commit the patch to fix it immediately. I've had an equivalent patch in my tree which just completed the build successfully and is into make check. So I'd say the patch is good to go. Thanks. Rainer
[Bug fortran/102332] ICE in select_type_set_tmp, at fortran/match.c:6366
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102332 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- Created attachment 52071 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52071&action=edit Tentative patch There are several NULL pointer dereferences exhibited by the various testcases which are addressed by this patch.
[Bug fortran/103418] random_number() does not accept pointer, intent(in) array argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Priority|P3 |P4 Target Milestone|--- |10.4 --- Comment #16 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and on 11- and 10-branch. Closing. Thanks for the report!
[Bug fortran/103418] random_number() does not accept pointer, intent(in) array argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103418 --- Comment #15 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:f8486c9fd71c08f30273e1a98b86e35a679ca229 commit r10-10364-gf8486c9fd71c08f30273e1a98b86e35a679ca229 Author: Harald Anlauf Date: Thu Dec 9 22:57:13 2021 +0100 Fortran: fix check for pointer dummy arguments with INTENT(IN) gcc/fortran/ChangeLog: PR fortran/103418 * check.c (variable_check): Replace previous check of procedure dummy arguments with INTENT(IN) attribute when passed to intrinsic procedures by gfc_check_vardef_context. * expr.c (gfc_check_vardef_context): Correct check of INTENT(IN) dummy arguments for the case of sub-components of a CLASS pointer. gcc/testsuite/ChangeLog: PR fortran/103418 * gfortran.dg/move_alloc_8.f90: Adjust error messages. * gfortran.dg/pointer_intent_9.f90: New test. (cherry picked from commit bb6a1ebb8585b85879735d0d6df9535885fad165)
[Bug libfortran/98076] Increase speed of integer I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98076 --- Comment #11 from Francois-Xavier Coudert --- Hi Rainer, Apologies for that, apparently I got confused between the keyword and the macro form. Can you confirm that bootstrapped is fixed if you change it to static_assert(sizeof(GFC_UINTEGER_LARGEST) <= 2 * sizeof(uint64_t), "integer too large"); ? If so, I will commit the patch to fix it immediately.
[Bug fortran/103776] ICE in gfc_compare_string, at fortran/arith.c:1118
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103776 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:3c830e6d17b12aff2875b6e80e4404f09153 commit r11-9419-g3c830e6d17b12aff2875b6e80e4404f09153 Author: Harald Anlauf Date: Mon Dec 20 22:01:05 2021 +0100 Fortran: CASE selector expressions must be scalar gcc/fortran/ChangeLog: PR fortran/103776 * match.c (match_case_selector): Reject expressions in CASE selector which are not scalar. gcc/testsuite/ChangeLog: PR fortran/103776 * gfortran.dg/select_10.f90: New test. (cherry picked from commit 5474092c9afbd76cbd457facce3757d8d2fad07b)
[Bug libfortran/103634] Runtime crash with PACK on zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103634 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.5 --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on all open branches.
[Bug libfortran/98076] Increase speed of integer I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98076 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #10 from Rainer Orth --- This patch broke (at least) Solaris bootstrap: /vol/gcc/src/hg/master/local/libgfortran/runtime/string.c: In function 'gfc_itoa': /vol/gcc/src/hg/master/local/libgfortran/runtime/string.c:245:73: error: macro "static_assert" requires 2 arguments, but only 1 given 245 | static_assert(sizeof(GFC_UINTEGER_LARGEST) <= 2 * sizeof(uint64_t)); | ^ In file included from /vol/gcc/src/hg/master/local/libgfortran/runtime/string.c:26: /usr/include/assert.h:25: note: macro "static_assert" defined here 25 | #define static_assert(a, b) _Static_assert(a, b) | /vol/gcc/src/hg/master/local/libgfortran/runtime/string.c:245:7: error: 'static_assert' undeclared (first use in this function) 245 | static_assert(sizeof(GFC_UINTEGER_LARGEST) <= 2 * sizeof(uint64_t)); | ^ /vol/gcc/src/hg/master/local/libgfortran/runtime/string.c:245:7: note: each undeclared identifier is reported only once for each function it appears in make[6]: *** [Makefile:2765: string.lo] Error 1 According to https://en.cppreference.com/w/c/language/_Static_assert, the one-arg form of _Static_assert/static_assert is new since C23, while Solaris only supports the two-arg form.
[Bug libfortran/103634] Runtime crash with PACK on zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103634 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:5b3587012951655d8e06dcfe683801862d3979de commit r9-9889-g5b3587012951655d8e06dcfe683801862d3979de Author: Harald Anlauf Date: Mon Dec 13 20:50:19 2021 +0100 Fortran: PACK intrinsic should not try to read from zero-sized array libgfortran/ChangeLog: PR libfortran/103634 * intrinsics/pack_generic.c (pack_internal): Handle case when the array argument of PACK has one or more extents of size zero to avoid invalid reads. gcc/testsuite/ChangeLog: PR libfortran/103634 * gfortran.dg/intrinsic_pack_6.f90: New test. (cherry picked from commit 1c613165a55b212c59a83796b20a1d555e096504)
[Bug libfortran/103634] Runtime crash with PACK on zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103634 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:39264acd7daaff4659fefa005ec02bccf685447d commit r10-10363-g39264acd7daaff4659fefa005ec02bccf685447d Author: Harald Anlauf Date: Mon Dec 13 20:50:19 2021 +0100 Fortran: PACK intrinsic should not try to read from zero-sized array libgfortran/ChangeLog: PR libfortran/103634 * intrinsics/pack_generic.c (pack_internal): Handle case when the array argument of PACK has one or more extents of size zero to avoid invalid reads. gcc/testsuite/ChangeLog: PR libfortran/103634 * gfortran.dg/intrinsic_pack_6.f90: New test. (cherry picked from commit 1c613165a55b212c59a83796b20a1d555e096504)
[Bug fortran/103778] [10/11/12 Regression] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103778 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |10.4 Priority|P3 |P4 --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed on affected branches. Closing. Thanks for the report!
[Bug fortran/103778] [10/11/12 Regression] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103778 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:715842b02f8828f28affdbb5e164013c172a3fb9 commit r10-10362-g715842b02f8828f28affdbb5e164013c172a3fb9 Author: Harald Anlauf Date: Mon Dec 20 22:12:33 2021 +0100 Fortran: BOZ literal constants are not interoperable gcc/fortran/ChangeLog: PR fortran/103778 * check.c (is_c_interoperable): A BOZ literal constant is not interoperable. gcc/testsuite/ChangeLog: PR fortran/103778 * gfortran.dg/illegal_boz_arg_3.f90: New test. (cherry picked from commit ff0ad4b5e16b8828a6147ae2d5fec8068ef0778e)
[Bug fortran/101329] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101329 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:93c066f568822680506811d0de9c57c8a7a4e5d2 commit r10-10361-g93c066f568822680506811d0de9c57c8a7a4e5d2 Author: Harald Anlauf Date: Wed Nov 17 22:21:24 2021 +0100 Fortran: NULL() is not interoperable gcc/fortran/ChangeLog: PR fortran/101329 * check.c (is_c_interoperable): Reject NULL() as it is not interoperable. gcc/testsuite/ChangeLog: PR fortran/101329 * gfortran.dg/pr101329.f90: New test. Co-authored-by: Steven G. Kargl (cherry picked from commit 3535be6c6f440909798d1c78e862a657f7adaf63)
[Bug fortran/103778] [10/11/12 Regression] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103778 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:e6dcc14640105d2daf9c7f279980543470be7866 commit r11-9418-ge6dcc14640105d2daf9c7f279980543470be7866 Author: Harald Anlauf Date: Mon Dec 20 22:12:33 2021 +0100 Fortran: BOZ literal constants are not interoperable gcc/fortran/ChangeLog: PR fortran/103778 * check.c (is_c_interoperable): A BOZ literal constant is not interoperable. gcc/testsuite/ChangeLog: PR fortran/103778 * gfortran.dg/illegal_boz_arg_3.f90: New test. (cherry picked from commit ff0ad4b5e16b8828a6147ae2d5fec8068ef0778e)
[Bug fortran/101329] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101329 --- Comment #5 from CVS Commits --- The releases/gcc-11 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:a25bfec3aacc34be624a620b00a72719ac03092f commit r11-9417-ga25bfec3aacc34be624a620b00a72719ac03092f Author: Harald Anlauf Date: Wed Nov 17 22:21:24 2021 +0100 Fortran: NULL() is not interoperable gcc/fortran/ChangeLog: PR fortran/101329 * check.c (is_c_interoperable): Reject NULL() as it is not interoperable. gcc/testsuite/ChangeLog: PR fortran/101329 * gfortran.dg/pr101329.f90: New test. Co-authored-by: Steven G. Kargl (cherry picked from commit 3535be6c6f440909798d1c78e862a657f7adaf63)
[Bug c++/103832] vectorized code segfaults due to misaligned access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103832 --- Comment #2 from Joakim Rosqvist --- Ok, may I then suggest that the docs at https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes for the aligned attribute be augmented with a mention that if you typedef float aligned_float __attribute__ ((aligned (64))); and then make an array of aligned_float, then every single element of that array will be assumed to have the specified alignment, which may not be what one intended.
[Bug target/103773] wrong code at -Oz due to sign extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103773 Roger Sayle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #6 from Roger Sayle --- This shoud now be fixed on mainline.
[Bug middle-end/103813] [11/12 Regression] Crash in decompose, at wide-int.h:984 fold-const since r11-5271-g4866b2f5db117f9e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103813 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 52070 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52070&action=edit gcc12-pr103813.patch Untested fix.
[Bug c++/103843] Direct call to Desctructor is optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103843 --- Comment #8 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #7) > Also, this is an automatic (i.e. stack) variable, so the destructor will run > at the end of the block, meaning it will be settled twice. Sorry, auto-correct changed "destroyed" to "settled"
[Bug c++/103843] Direct call to Desctructor is optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103843 --- Comment #7 from Jonathan Wakely --- Also, this is an automatic (i.e. stack) variable, so the destructor will run at the end of the block, meaning it will be settled twice. So another form of undefined behaviour. The program is just broken, in multiple ways. You cannot expect sensible behaviour from garbage code.
[Bug target/100985] [9 Regression] Aarch64 acle.h "extern "C" {" mismatch "}" in 9.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100985 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- This should be fixed for gcc-9.5.0
[Bug target/100985] [9 Regression] Aarch64 acle.h "extern "C" {" mismatch "}" in 9.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100985 --- Comment #3 from CVS Commits --- The releases/gcc-9 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:8c92fcb13a4979232787f0476bf7469ccbb03617 commit r9-9888-g8c92fcb13a4979232787f0476bf7469ccbb03617 Author: Jonathan Wakely Date: Mon Dec 27 16:20:24 2021 + aarch64: Fix mismatched extern "C" block [PR100985] gcc/ChangeLog: PR target/100985 * config/aarch64/arm_acle.h: Remove unclosed extern "C" block.
[Bug ipa/103830] [12 Regression] null pointer access optimized away by removing function call at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103830 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- The analysis, why not. But perhaps we shouldn't DCE const or pure functions are -Og, or CSE them etc.
[Bug target/100985] [9 Regression] Aarch64 acle.h "extern "C" {" mismatch "}" in 9.4.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100985 Jonathan Wakely changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #2 from Jonathan Wakely --- *** Bug 103846 has been marked as a duplicate of this bug. ***
[Bug target/103846] [9 Regression] unmatched extern "C" block in aarch64/arm_acle.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103846 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- Sorry, this is a dup *** This bug has been marked as a duplicate of bug 100985 ***
[Bug target/103846] New: [9 Regression] unmatched extern "C" block in aarch64/arm_acle.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103846
Bug ID: 103846
Summary: [9 Regression] unmatched extern "C" block in
aarch64/arm_acle.h
Product: gcc
Version: 9.4.1
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
CC: ktkachov at gcc dot gnu.org
Target Milestone: ---
g:6f06be1769d45359940c60517f9d55bedd3cb1f4 added
+#ifdef __cplusplus
+extern "C" {
+#endif
without a corresponding closing brace.
[Bug libstdc++/100415] runtime error: reference binding to null pointer of type 'const struct __forced_unwind'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100415 --- Comment #2 from Marc Mutz --- Confirmed with $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/d/gcc/11/libexec/gcc/x86_64-pc-linux-gnu/11.2.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc/configure --prefix=/d/gcc/11 --enable-languages=c,c++,objc,fortran,obj-c++ --enable-release --disable-multilib --program-suffix=-11 : (reconfigured) ../gcc/configure --prefix=/d/gcc/11 --enable-languages=c,c++,objc,fortran,obj-c++ --enable-release --disable-multilib --program-suffix=-11 Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.2.1 20211211 (GCC) Work-around: https://stackoverflow.com/questions/70378204/how-to-catch-abi-forced-unwind-while-keeping-ubsan-happy
[Bug tree-optimization/103835] Bogus sprintf warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103835 --- Comment #2 from lavr at ncbi dot nlm.nih.gov --- Irrespective of whether atoi() is known, printing an "int" (or two) will never produce this many characters... This, however, also seems to have triggered some weird logic that took the entire size of buf[] as a possible size of "pfx" on output; hence, the warning noted 1000+ characters to be printed.
[Bug libstdc++/101236] [12 Regression] bits/unique_ptr.h:658:48: error: invalid use of incomplete type ‘class llvm::APFloat’ since r12-1778-g17bc3848e065c0980523e1a1592f2f03b24b4f1c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101236 Bug 101236 depends on bug 101239, which changed state. Bug 101239 Summary: "Internal compiler error: Error reporting routines re-entered." in size_in_bytes_loc https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101239 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/101239] "Internal compiler error: Error reporting routines re-entered." in size_in_bytes_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101239 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Target Milestone|--- |12.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #7 from Patrick Palka --- Fixed for GCC 12.
[Bug c++/101239] "Internal compiler error: Error reporting routines re-entered." in size_in_bytes_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101239 --- Comment #6 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:916ec36d0a3ef3fe44c1657746922a5f18b60326 commit r12-6124-g916ec36d0a3ef3fe44c1657746922a5f18b60326 Author: Patrick Palka Date: Mon Dec 27 10:01:42 2021 -0500 c++: Add testcase for SFINAE w/ p[N] and incomplete type [PR101239] The r12-6123 fix for SFINAE with p+N and incomplete type also fixed the analogous issue with p[N]. PR c++/101239 gcc/testsuite/ChangeLog: * g++.dg/template/sfinae32a.C: New test.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 103700, which changed state. Bug 103700 Summary: Incomplete type not causing constraints to fail https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103700 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/103700] Incomplete type not causing constraints to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103700 Patrick Palka changed: What|Removed |Added Target Milestone|11.3|12.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Patrick Palka --- Fixed for GCC 12. Not backporting to 11.3 since this isn't a regression and can be worked around using sizeof I think.
[Bug c++/103700] Incomplete type not causing constraints to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103700 --- Comment #6 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:88cdcb5c18d73bfc9960d774c678f0e8103b8031 commit r12-6123-g88cdcb5c18d73bfc9960d774c678f0e8103b8031 Author: Patrick Palka Date: Mon Dec 27 09:05:17 2021 -0500 c++: hard error w/ ptr+N and incomplete type [PR103700] In pointer_int_sum when called from a SFINAE context, we need to avoid calling size_in_bytes_loc on an incomplete pointed-to type since this latter function isn't SFINAE-enabled and always emits an error on such input. PR c++/103700 gcc/c-family/ChangeLog: * c-common.c (pointer_int_sum): When quiet, return error_mark_node for an incomplete pointed-to type and don't call size_in_bytes_loc. gcc/testsuite/ChangeLog: * g++.dg/template/sfinae32.C: New test.
[Bug target/101324] powerpc64le: hashst appears before mflr at -O1 or higher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101324 --- Comment #24 from Raoni Fassina Firmino --- (In reply to Peter Bergner from comment #21) > Fixed on trunk. I tested gcc trunk with glibc master and I confirm that it fix the problem with __memmove_ppc. I tested both running glibc check with a custom kernel with rop enable and doing a visual check of the disassembled function. The exact versions I used were: - binutils 2.36.1 build from binutils-2_36_1 (f35674005e60) - gcc (future 12) build from master (b7815aa9108) - glibc (future 2.35) build from master (268d812c19)
[Bug tree-optimization/57245] Floating-point constant truncation ignores -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57245 Bug 57245 depends on bug 103735, which changed state. Bug 103735 Summary: [12 Regression] Extra glibc "make check" failures by r12-4764 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103735 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED
[Bug middle-end/103735] [12 Regression] Extra glibc "make check" failures by r12-4764
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103735 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #3 from H.J. Lu --- Moved to https://sourceware.org/bugzilla/show_bug.cgi?id=28713
[Bug target/103762] [12 Regression] glibc master branch is miscompiled by r12-897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103762 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #13 from H.J. Lu --- Fixed.
[Bug target/103762] [12 Regression] glibc master branch is miscompiled by r12-897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103762 --- Comment #12 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:9407058a430316db5299bc7867e4a31f900cd197 commit r12-6122-g9407058a430316db5299bc7867e4a31f900cd197 Author: H.J. Lu Date: Sun Dec 19 08:47:03 2021 -0800 ix86: Don't use the 'm' constraint for x86_64_general_operand The 'm' constraint is defined with define_memory_constraint which allows LRA to convert the operand to the form '(mem (reg X))', where X is a base register. To prevent LRA from generating '(mem (reg X))' from a register: 1. Add a 'BM' constraint which is similar to the 'm' constraint, but is defined with define_constraint. 2. Add a 'm' mode attribute which is mapped to the 'm' constraint for general_operand and the 'BM' constraint for x86_64_general_operand. 3. Replace the 'm' constraint on with the '' constraint. 4. Replace the 'm' constraint on x86_64_general_operand with the 'BM' constraint. gcc/ PR target/103762 * config/i386/constraints.md (BM): New constraint. * config/i386/i386.md (m): New mode attribute. Replace the 'm' constraint on with the '' constraint. Replace the 'm' constraint on x86_64_general_operand with the 'BM' constraint. gcc/testsuite/ * gcc.target/i386/pr103762-1a.c: New test. * gcc.target/i386/pr103762-1b.c: Likewise. * gcc.target/i386/pr103762-1c.c: Likewise.
[Bug debug/103836] '-fcompare-debug' failure (length) w/ -fopenacc --param openacc-kernels=decompose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103836
Jakub Jelinek changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org,
||jakub at gcc dot gnu.org,
||tschwinge at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2021-12-27
--- Comment #1 from Jakub Jelinek ---
void foo ()
{
+ # DEBUG BEGIN_STMT
#pragma omp target oacc_kernels
{
int i.0;
+ # DEBUG BEGIN_STMT
+ # DEBUG BEGIN_STMT
#pragma acc loop private(i.0) private(i)
for (i.0 = 0; i.0 < 2; i.0 = i.0 + 1)
{
i = i.0;
+ # DEBUG BEGIN_STMT
}
}
}
difference at gimplification time is ok, but
void foo ()
{
+ # DEBUG BEGIN_STMT
#pragma omp target oacc_data_kernels
{
try
@@ -10,12 +11,18 @@ void foo ()
{
int i.0;
+#pragma omp target oacc_parallel_kernels_gang_single async(-1)
num_gangs(1)
+ {
+# DEBUG BEGIN_STMT
+# DEBUG BEGIN_STMT
+ }
#pragma omp target oacc_kernels async(-1)
{
#pragma acc loop private(i.0) private(i)
for (i.0 = 0; i.0 < 2; i.0 = i.0 + 1)
{
i = i.0;
+# DEBUG BEGIN_STMT
}
}
__builtin_GOACC_wait (-2, 0);
from omp_oacc_kernels_decompose is not. Debug stmts shouldn't affect
code-generation decisions.
[Bug rtl-optimization/103837] [9/10/11/12 Regression] '-fcompare-debug' failure (length) w/ -Og -fmove-loop-invariants -fnon-call-exceptions -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103837 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from Jakub Jelinek --- Created attachment 52069 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52069&action=edit gcc12-pr103837.patch Untested fix.
[Bug tree-optimization/103837] [9/10/11/12 Regression] '-fcompare-debug' failure (length) w/ -Og -fmove-loop-invariants -fnon-call-exceptions -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103837
--- Comment #4 from Jakub Jelinek ---
The loop body is:
(code_label 10026 4 10019 3 4 (nil) [0 uses])
(note 10019 10026 5 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(debug_insn 5 10019 6 3 (var_location:DF a (reg/v:DF 84 [ a ])) -1
(nil))
(debug_insn 6 5 7 3 (debug_marker) "pr103837.c":8:3 -1
(nil))
(debug_insn 7 6 17 3 (debug_marker) "pr103837.c":10:7 -1
(nil))
(debug_insn 17 7 16 3 (var_location:SI D#6 (fix:SI (reg/v:DF 84 [ a ]))) -1
(nil))
(debug_insn 16 17 15 3 (var_location:SI D#5 (debug_expr:SI D#6)) -1
(nil))
(debug_insn 15 16 14 3 (var_location:CCZ D#4 (compare:CCZ (debug_expr:SI D#5)
(const_int 0 [0]))) -1
(nil))
(debug_insn 14 15 13 3 (var_location:QI D#3 (ne:QI (debug_expr:CCZ D#4)
(const_int 0 [0]))) -1
(nil))
(debug_insn 13 14 12 3 (var_location:QI D#2 (debug_expr:QI D#3)) -1
(nil))
(debug_insn 12 13 8 3 (var_location:SI D#1 (zero_extend:SI (debug_expr:QI
D#2))) -1
(nil))
(debug_insn 8 12 9 3 (var_location:SI b (debug_expr:SI D#1)) "pr103837.c":10:9
-1
(nil))
(debug_insn 9 8 10025 3 (debug_marker) "pr103837.c":11:7 -1
(nil))
(insn 10025 9 10 3 (set (reg/v:DF 84 [ a ])
(float:DF (reg/v:SI 88 [ x ]))) "pr103837.c":11:9 207 {*floatsidf2}
(nil))
(debug_insn 10 10025 11 3 (var_location:DF a (reg/v:DF 84 [ a ]))
"pr103837.c":11:9 -1
(nil))
(debug_insn 11 10 0 3 (debug_marker) "pr103837.c":8:3 -1
(nil))
and because of the uninitialized a there is a DEBUG_INSN use of pseudo 84 e.g.
in insns 5 and 17 before it is actually initialized in insn 10025.
Ignoring DEBUG_INSNs in can_move_invariant_reg in the for (use =
DF_REG_USE_CHAIN (dest_regno); use; use = DF_REF_NEXT_REG (use)) loop is
trivial, the big question is what shall we do with those debug insns.
For this particular case where it is uninitialized, I bet either resetting or
keeping them as is would be fine.
But my understanding of can_move_invariant_reg is that we could have:
pseudo = whatever1;
loop_header
debug_insn use pseudo;
pseudo = whatever2;
use pseudo;
loop_end
and in that case moving the invariant without resetting the debug insns would
be wrong:
pseudo = whatever1;
pseudo = whatever2;
loop_header
debug_insn use pseudo;
use pseudo;
loop_end
[Bug c++/103843] Direct call to Desctructor is optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103843 Jakub Jelinek changed: What|Removed |Added Resolution|FIXED |INVALID CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- Accessing the member after the containing variable has been destructed is undefined behavior in C++, so when you do it, anything can happen, it can format your disk, do nothing, crash, ...
[Bug c++/103843] Direct call to Desctructor is optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103843
Georgii.Shagov changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #5 from Georgii.Shagov ---
> No, the destructor is not just a function in C++, it terminates the object
> being alive (not de-allocated though). You can then reuse the space for
> another object, either the same type or a different type by using the
> inplacement new.
>
> > Why the content of the class had been re-initialized?
>
> It was not re-initialized rather the store was removed.
>
> > IMU: there should be not such obvious difference between optimized and
> > non-optimized code
>
> why not, it is undefined code.
I really appreciate and value your Reply, Andrew.
I have modified the code a little bit:
#include
class S {
public:
S() = default;
~S() { i=10; }
void foo() { this->~S(); }
int getI() const { return i; }
private:
int i{100};
};
int main()
{
S s;
do {
std::cout << "Before foo: " << s.getI();
s.foo();
std::cout << "; After: " << s.getI() << std::endl;
} while (false);
return 0;
}
$g++ -O3 ./d.cpp
$./a.out
Before foo: 100; After: 0
$g++ -O0 ./d.cpp
$./a.out
Before foo: 100; After: 10
> No, the destructor is not just a function in C++, it terminates the object
> being alive (not de-allocated though).
I do understand your point, yet I would not feel comfortable in sharing one.
- It is not clear: what function/code has reset S::i value to 0 after a Direct
call to Destructor?
- Why 0? :-?
- In order to avoid misleading I have allocated the object on the stack as you
can see. So, no-memory mgmt is not involved
- Does it mean gcc implants some code, being called after Destructor call,
resetting the content of the class Instance to 0? ::memset??
- Is there any agreement unto this? I would be happy to learn more about this.
Thnx in advance,
Yours truly, George
[Bug tree-optimization/103837] [9/10/11/12 Regression] '-fcompare-debug' failure (length) w/ -Og -fmove-loop-invariants -fnon-call-exceptions -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103837 --- Comment #3 from Jakub Jelinek --- Yeah, exactly, looking into that now.
[Bug tree-optimization/103837] [9/10/11/12 Regression] '-fcompare-debug' failure (length) w/ -Og -fmove-loop-invariants -fnon-call-exceptions -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103837 --- Comment #2 from Andrew Pinski --- It looks like can_move_invariant_reg is not ignoring debug insns.
[Bug tree-optimization/103837] [9/10/11/12 Regression] '-fcompare-debug' failure (length) w/ -Og -fmove-loop-invariants -fnon-call-exceptions -fno-tree-dce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103837 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2021-12-27 CC||jakub at gcc dot gnu.org Summary|[12 Regression] |[9/10/11/12 Regression] |'-fcompare-debug' failure |'-fcompare-debug' failure |(length) w/ -Og |(length) w/ -Og |-fmove-loop-invariants |-fmove-loop-invariants |-fnon-call-exceptions |-fnon-call-exceptions |-fno-tree-dce |-fno-tree-dce Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- With the above options it started with r12-3221-g1313111fdec0d0de4228b5e839ca728b3e4b106e If I add -fexceptions, it started with r12-2307-gb15e301748f0e042379909e32b3ade439dd8f8f9 With additional -fdelete-dead-exceptions it started with r6-701-gaa953e2fc52e2196d62b9669a69c9e82de43dc3c
[Bug middle-end/103839] __builtin_clear_padding doesn't zero alignment holes of unions with fields that overlap padding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103839 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- The right fix is IMHO to add #define CONSTRUCTOR_ZERO_PADDING(NODE) \ (CONSTRUCTOR_CHECK (NODE)->base.protected_flag) and handle that during gimplification etc. This is needed both for C++ where https://eel.is/c++draft/dcl.init#general-6 requires that zero initialization clears padding bits, so the FE should set it for zero initialization ctors, and I bet for D as well. gimplification should then ensure vars initialized by such CONSTRUCTORs have the padding bits cleared in whatever way is most efficient.
[Bug target/103842] [12 regression] ICE on ilmbase-2.5.7: during RTL pass: expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103842 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 52068 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52068&action=edit gcc12-pr103842.patch Untested fix.
[Bug tree-optimization/103845] New: ICE in execute, at gimple-harden-conditionals.cc:552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103845
Bug ID: 103845
Summary: ICE in execute, at gimple-harden-conditionals.cc:552
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
CC: aoliva at gcc dot gnu.org
Target Milestone: ---
gcc 12.0.0 20211226 snapshot (g:d87483015d476a95f521f0c9dcf6988ca889063b) ICEs
when compiling the following testcase w/ -O1 -fharden-compares
-fno-ipa-pure-const:
int
baz (void);
__attribute__ ((returns_twice)) void
bar (void)
{
}
int
quux (int y, int z)
{
return (y || z >= 0) ? y : z;
}
int
foo (int x)
{
int a = 0, b = x == a;
bar ();
if (!!baz () < quux (b, a))
++x;
return x;
}
% gcc-12.0.0 -O1 -fharden-compares -fno-ipa-pure-const -c sys89o7m.c
during GIMPLE pass: hardcmp
sys89o7m.c: In function 'foo':
sys89o7m.c:16:1: internal compiler error: in execute, at
gimple-harden-conditionals.cc:552
16 | foo (int x)
| ^~~
0x8122e4 execute
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211226/work/gcc-12-20211226/gcc/gimple-harden-conditionals.cc:552
[Bug debug/103838] [11/12 Regression] '-fcompare-debug' failure (length) w/ -O2 --param max-early-inliner-iterations=0 --param max-inline-insns-auto=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103838 --- Comment #2 from Jakub Jelinek --- Created attachment 52067 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52067&action=edit gcc12-pr103838.patch Untested fix.
[Bug debug/103838] [11/12 Regression] '-fcompare-debug' failure (length) w/ -O2 --param max-early-inliner-iterations=0 --param max-inline-insns-auto=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103838 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/103843] Direct call to Desctructor is optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103843 Andrew Pinski changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #4 from Andrew Pinski --- (In reply to Georgii.Shagov from comment #3) > (In reply to Andrew Pinski from comment #2) > > This is undefined code. The object is officially not live after you call the > > deconstructor so GCC is able to remove the store from the deconstructor as > > being dead. > > I appreciate your reply. But this is confusing. The object was NOT released > (de-allocated). In essence Destructor is just a function. No, the destructor is not just a function in C++, it terminates the object being alive (not de-allocated though). You can then reuse the space for another object, either the same type or a different type by using the inplacement new. > Why the content of the class had been re-initialized? It was not re-initialized rather the store was removed. > IMU: there should be not such obvious difference between optimized and > non-optimized code why not, it is undefined code.
[Bug c++/103843] Direct call to Desctructor is optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103843 Georgii.Shagov changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #3 from Georgii.Shagov --- (In reply to Andrew Pinski from comment #2) > This is undefined code. The object is officially not live after you call the > deconstructor so GCC is able to remove the store from the deconstructor as > being dead. I appreciate your reply. But this is confusing. The object was NOT released (de-allocated). In essence Destructor is just a function. Why the content of the class had been re-initialized? IMU: there should be not such obvious difference between optimized and non-optimized code thnx in advance.
[Bug c++/103844] New: [modules] ICE when exporting shared_ptr alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103844
Bug ID: 103844
Summary: [modules] ICE when exporting shared_ptr alias
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tim152 at tgf dot pw
Target Milestone: ---
Created attachment 52066
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52066&action=edit
preprocessed module source
Exporting an alias to shared_ptr causes a compiler segfault on usage.
This also breaks with unique_ptr, but works for other types.
mod.cpp:
module;
#include
export module tree;
export template
using p = std::shared_ptr;
(mod.ii attached)
main.cpp:
import tree;
int main() {
p t;
}
% gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211226 (experimental) (GCC)
```
Compiled using
% g++ mod.cpp -c -fmodules-ts -std=c++20 -Wall -Wextra
(no output)
% g++ main.cpp -c -fmodules-ts -std=c++20 -Wall -Wextra
In file included from /usr/local/include/c++/12.0.0/bits/shared_ptr.h:53,
from /usr/local/include/c++/12.0.0/memory:77,
from mod.cpp:2,
of module tree, imported at main.cpp:1:
/usr/local/include/c++/12.0.0/bits/shared_ptr_base.h: In instantiation of
‘class std::__shared_ptr@tree’:
/usr/local/include/c++/12.0.0/bits/shared_ptr.h:124:11: required from ‘class
std::shared_ptr@tree’
main.cpp:4:11: required from here
Segmentation fault
1442 | struct __has_esft_base
|^~~
0x1180abf crash_signal
../../gcc/toplev.c:322
0xa88d16 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/tree.h:3563
0xa88d16 get_originating_module_decl(tree_node*)
../../gcc/cp/module.cc:18339
0xa88e97 get_originating_module(tree_node*, bool)
../../gcc/cp/module.cc:18378
0xa301ef dump_module_suffix
../../gcc/cp/error.c:205
0xa301ef dump_module_suffix
../../gcc/cp/error.c:185
0xa30593 dump_aggr_type
../../gcc/cp/error.c:846
0xa3a352 decl_to_string
../../gcc/cp/error.c:3225
0xa3a352 cp_printer
../../gcc/cp/error.c:4396
0x20a99fa pp_format(pretty_printer*, text_info*)
../../gcc/pretty-print.c:1475
0x208be8b diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
../../gcc/diagnostic.c:1346
0x208c3b8 diagnostic_impl
../../gcc/diagnostic.c:1508
0x208ccfa error_at(unsigned int, char const*, ...)
../../gcc/diagnostic.c:1831
0xa01d80 duplicate_decls(tree_node*, tree_node*, bool, bool)
../../gcc/cp/decl.c:1795
0xabb1ca check_module_override
../../gcc/cp/name-lookup.c:3586
0xabb1ca pushdecl(tree_node*, bool)
../../gcc/cp/name-lookup.c:3724
0xabd54c do_pushdecl_with_scope
../../gcc/cp/name-lookup.c:4767
0xabd77a pushdecl_namespace_level(tree_node*, bool)
../../gcc/cp/name-lookup.c:6088
0xb6e95f tsubst_friend_class
../../gcc/cp/pt.c:11444
0xb6e95f instantiate_class_template_1
../../gcc/cp/pt.c:12171
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/103843] Direct call to Desctructor is optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103843 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- This is undefined code. The object is officially not live after you call the deconstructor so GCC is able to remove the store from the deconstructor as being dead.
[Bug debug/103838] [11/12 Regression] '-fcompare-debug' failure (length) w/ -O2 --param max-early-inliner-iterations=0 --param max-inline-insns-auto=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103838 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Priority|P3 |P2 CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-12-27 Keywords|needs-bisection | --- Comment #1 from Jakub Jelinek --- Started with my r11-5648-g037fe26ee1ac18581bf0ad646d48591c97d10bd3
[Bug target/103842] [12 regression] ICE on ilmbase-2.5.7: during RTL pass: expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103842 --- Comment #4 from Andrew Pinski --- (gdb) n 534 rtx op1 = lowpart_subreg (V4SFmode, operands[1], 1: debug_rtx(operands[1]) = (subreg:V2SF (reg:DI 123) 0) void (gdb) n 536 rtx op2 = gen_rtx_VEC_CONCAT (V4SFmode, operands[2], 1: debug_rtx(operands[1]) = (subreg:V2SF (reg:DI 123) 0) void (gdb) p op1 $7 = (rtx) 0x0
[Bug c++/103843] Direct call to Desctructor is optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103843
--- Comment #1 from Georgii.Shagov ---
>From experiments, I would guess that in case of -O3 the call to destructor was
substituted by initializer:
This works fine:
cat ./d.cpp
#include
class S {
public:
S() : i{1} {}
~S() { i=0; }
void foo() { this->~S(); }
int getI() const { return i; }
private:
int i{0};
};
int main()
{
S s;
do {
std::cout << "Before foo: " << s.getI();
s.foo();
std::cout << "; After: " << s.getI() << std::endl;
} while (false);
return 0;
}
g++ ./d.cpp
$./a.out
Before foo: 1; After: 0
$g++ -O3 ./d.cpp
$./a.out
Before foo: 1; After: 0
g++ --version
g++ (GCC) 10.2.1 20210130 (Red Hat 10.2.1-11)
[Bug target/103842] [12 regression] ICE on ilmbase-2.5.7: during RTL pass: expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103842 --- Comment #3 from Andrew Pinski --- (insn 56 55 57 (set (subreg:V4SF (reg:V2SF 124 [ vect__35.17 ]) 0) (div:V4SF (nil) (reg:V4SF 126))) "t.c":18:23 -1 (nil)) Yes that nill there is wrong.
[Bug target/103842] [12 regression] ICE on ilmbase-2.5.7: during RTL pass: expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103842 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-12-27 Keywords||ice-on-valid-code Target Milestone|--- |12.0
[Bug target/103842] [12 regression] ICE on ilmbase-2.5.7: during RTL pass: expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103842 --- Comment #2 from Andrew Pinski --- This was exposed/caused by r12-6113 as far as I can tell. We didn't do SLP of the divide before and now we do and it caused the ICE somehow.
[Bug target/103842] [12 regression] ICE on ilmbase-2.5.7: during RTL pass: expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103842 --- Comment #1 from Sergei Trofimovich --- Created attachment 52065 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52065&action=edit bug.cpp.cpp.orig.gz bug.cpp.cpp.orig.gz - unreduced file (had to compress to get past 1MB limit)
[Bug c++/103843] New: Direct call to Desctructor is optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103843
Bug ID: 103843
Summary: Direct call to Desctructor is optimized out
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: georgii.sha...@be-tse.de
Target Milestone: ---
cat ./d.cpp
#include
class S {
public:
S() = default;
~S() { i=10; }
void foo() { this->~S(); }
int getI() const { return i; }
private:
int i{0};
};
int main()
{
S s;
do {
std::cout << "Before foo: " << s.getI();
s.foo();
std::cout << "; After: " << s.getI() << std::endl;
} while (false);
return 0;
}
g++ -O0 ./d.cpp
$./a.out
Before foo: 0; After: 10
g++ -O3 ./d.cpp
georgii@ltgscosvm:~/prj/test$./a.out
Before foo: 0; After: 0
gcc --version
gcc (GCC) 10.2.1 20210130 (Red Hat 10.2.1-11)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
hostnamectl
Static hostname: ltgscosvm.be-tse01.de
Icon name: computer-vm
Chassis: vm
Machine ID: fb944a0ffb46449f9b639e589d00b598
Boot ID: 433e59a4db5c419a9081cc6968e4e590
Virtualization: microsoft
Operating System: CentOS Linux 7 (Core)
CPE OS Name: cpe:/o:centos:centos:7
Kernel: Linux 3.10.0-1160.45.1.el7.x86_64
Architecture: x86-64
uname -a
Linux ltgscosvm.be-tse01.de 3.10.0-1160.45.1.el7.x86_64 #1 SMP Wed Oct 13
17:20:51 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
[Bug target/103842] New: [12 regression] ICE on ilmbase-2.5.7: during RTL pass: expand
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103842
Bug ID: 103842
Summary: [12 regression] ICE on ilmbase-2.5.7: during RTL pass:
expand
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-unknown-linux-gnu
Noticed new ICE on this week's gcc snapshot on ilmbase-2.5.7. Here is minimized
source:
void abs(float *);
struct Matrix33 {
float x[3][3];
float *operator[](int i) { return x[i]; }
Matrix33();
Matrix33(float f, float g) {
x[1][0] = x[1][1] = x[1][2] = f;
x[2][0] = g;
}
void equalWithAbsError();
Matrix33 inverse() {
Matrix33 s(x[1][2] - x[1][2], x[1][1] - x[1][1]);
float r = s[2][0];
if (r)
for (int i = 0; i < 3; ++i)
for (int j = 0; j < 3; ++j)
s[i][j] /= r;
for (int i = 0;;) {
float *__trans_tmp_2 = s[i];
abs(__trans_tmp_2);
}
}
};
void __assert_fail() {
Matrix33 m, inv1 = m.inverse(), ident1 = inv1;
ident1.equalWithAbsError();
}
$ g++-12.0.0 -O3 -c bug.cpp.cpp
during RTL pass: expand
bug.cpp.cpp: In function 'void __assert_fail()':
bug.cpp.cpp:27:5: internal compiler error: Segmentation fault
27 | }
| ^
0x21196c6 internal_error(char const*, ...)
???:0
$ g++-12.0.0 -v
Using built-in specs.
COLLECT_GCC=/nix/store/hw64v14l9lzircg596kmj1bjiy76wcih-gcc-12.0.0/bin/g++
COLLECT_LTO_WRAPPER=/nix/store/hw64v14l9lzircg596kmj1bjiy76wcih-gcc-12.0.0/libexec/gcc/x86_64-unknown-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211226 (experimental) (GCC)
Also attaching the unminimized preprocessed file in case it introduced
unrelated uninitialized values as `bug.cpp.cpp.orig`.
[Bug testsuite/103823] g++.dg/torture/pr31863.C fails on darwin with "using serial compilation of 2 LTRANS jobs"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103823 --- Comment #10 from Francois-Xavier Coudert --- Posted at https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587376.html
[Bug target/95046] Vectorize V2SFmode operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95046 --- Comment #16 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:e078de24eae8253fd4f24342f65166b525dd99c6 commit r12-6121-ge078de24eae8253fd4f24342f65166b525dd99c6 Author: Uros Bizjak Date: Mon Dec 27 10:00:28 2021 +0100 testsuite: Avoid unwanted vecorization [PR95046] 2021-12-27 Uroš Bizjak gcc/testsuite/ChangeLog: PR target/95046 * gfortran.dg/extract_recip_1.f: Adjust testcase.
[Bug demangler/98886] stack overflow in cxxfilt, demangle_type, rust-demangle.c:854
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98886 Andrew Pinski changed: What|Removed |Added CC||rding at gatech dot edu --- Comment #9 from Andrew Pinski --- *** Bug 100105 has been marked as a duplicate of this bug. ***
[Bug demangler/100105] stack exhaust by recursion in cxxfilt demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100105 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup of bug 98886. *** This bug has been marked as a duplicate of bug 98886 ***
