[Bug c++/105098] ICE: endless recursion during auto deduction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105098 --- Comment #5 from Azat --- >Seems to be fixed on trunk by r12-3906-g51018dd1395c72. Indeed, thanks! Will it be backported to gcc-11?

[Bug c++/105098] ICE: endless recursion during auto deduction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105098 --- Comment #2 from Azat --- Created attachment 52713 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52713&action=edit original file generated with -save-temps And here is the original pre-processed temporary file.

[Bug c++/105098] ICE: endless recursion during auto deduction

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105098 --- Comment #1 from Azat --- Created attachment 52712 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52712&action=edit reduced Here is reduced file, that had been created with the following test for creduce: #!/usr/bin/env bash

[Bug c++/105098] New: ICE: endless recursion during auto deduction

: c++ Assignee: unassigned at gcc dot gnu.org Reporter: a3at.mail at gmail dot com Target Milestone: --- Created attachment 52711 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52711&action=edit original cpp code While switching to libcxx from llvm-14 (actually

[Bug c/98252] gcc 10 unaligned copy (with tree-loop-vectorize) produce wrong result

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98252 --- Comment #2 from Azat --- >If you compile your testcase with -fsanitize=undefined, you'll see that it >invokes UB. Jakub, Indeed I saw them, but is there any explanation (except "UB") why it does copy by 16 if the memory overlaps?

[Bug c/98252] New: gcc 10 unaligned copy (with tree-loop-vectorize) produce wrong result

Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: a3at.mail at gmail dot com Target Milestone: --- Created attachment 49750 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49750&action=edit test case In the attachment t

[Bug c++/89552] odr namespace

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89552 Azat changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug c++/89552] New: odr namespace

at gcc dot gnu.org Reporter: a3at.mail at gmail dot com Target Milestone: ---

[Bug c++/86094] [8/9 Regression] Call ABI changed for small objects with defaulted ctor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86094 Azat changed: What|Removed |Added CC||a3at.mail at gmail dot com --- Comment #12 from

[Bug lto/81004] [7/8 Regression] linking failed with -flto and static libboost_program_options

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81004 --- Comment #12 from Azat --- > Started with r238959. If you revert this then it fixes some of problems (even though this is a temporary solution), but there are more, and now this is *only without -flto* (i.e. -Wall "-Werror -Wunknown-pragmas -

[Bug lto/81004] linking failed with -flto

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81004 --- Comment #2 from Azat --- > Does it fail when not using gold? Yes > Also which binutils version? 2.28.0.20170506 P.S. octoploid in #gcc helps to reduce it further

[Bug lto/81004] New: linking failed with -flto

: unassigned at gcc dot gnu.org Reporter: a3at.mail at gmail dot com CC: marxin at gcc dot gnu.org Target Milestone: --- After upgrading to gcc 7.1 -flto build failed during linking, I tried to reduce amount of involved sources, but this is what I got: https

[Bug c++/64369] New: Wreturn-local-addr for const argument with packed attribute

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: a3at.mail at gmail dot com Created attachment 34306 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34306&action=edit Werror=return-local-addr Here is simple test case (also in att

[Bug c/64332] wrong location for Wattributes warning

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332 --- Comment #5 from Azat --- On Tue, Dec 16, 2014 at 05:16:41PM +, manu at gcc dot gnu.org wrote: > The C FE does not point to __constructor (3:1 vs 3:19), thus it doesn't > realize > this comes from a macro expansion, thus (in your testcase

[Bug c++/64332] gcc/g++ handles system_header differently

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332 --- Comment #3 from Azat --- On Tue, Dec 16, 2014 at 07:50:48PM +0300, Azat Khuzhin wrote: > > --- Comment #1 from Andrew Pinski --- > > I don't think it is system header which is being handled differently, > > rather I > > think it is warning

[Bug c++/64332] gcc/g++ handles system_header differently

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332 --- Comment #2 from Azat --- On Tue, Dec 16, 2014 at 04:46:28PM +, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64332 > > --- Comment #1 from Andrew Pinski --- > I don't think it is system header which is

[Bug c++/64332] New: gcc/g++ handles system_header differently

++ Assignee: unassigned at gcc dot gnu.org Reporter: a3at.mail at gmail dot com Created attachment 34292 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34292&action=edit warning-constructor-attribute-ignored.tgz Digging through one or compilation errors, after doi

[Bug c/60907] New: Can't break inside empty loop (without any optimization)

ormal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: a3at.mail at gmail dot com It is very useful to break inside empty loops for debugging with gdb. But unfortunately code generated by gcc don't allow to do this, unlike clang (3.4-2)