[Bug libstdc++/99692] Lookup for operator<< skips global scope

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99692

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Right the problem is here (and not with the compiler itself if there is a
> problem):
> /home/ubuntu/upstream-gcc/include/c++/11.0.1/ostream:747:46: error: no match
> for ‘operator<<’ (operand types are ‘std::basic_ostream’ and ‘const
> std::vector’)
>   746 |__void_t()
>   |  
>   747 |  << declval _Tp&>())>>
>   |  ^~~~
> 
> 
> But by definition at this point operator << does not exist and is not
> considered as it is not found via ADL because both std::basic_ostream
> and std::vector are in the std namespace and the global namespace is
> not considered.
> 
> /home/ubuntu/upstream-gcc/include/c++/11.0.1/ostream:773:5:   required by
> substitution of ‘template typename
> std::enable_if >,
> std::__is_convertible_to_basic_ostream<_Ostream>,
> std::__is_insertable std::__is_convertible_to_basic_ostream<_Tp>::__ostream_type, const _Tp&,
> void> >::value, typename
> std::__is_convertible_to_basic_ostream<_Tp>::__ostream_type>::type
> std::operator<<(_Ostream&&, const _Tp&) [with _Ostream = CustomStream; _Tp =
> std::vector]’
> t78.cc:21:41:   required from here
>   template
> inline
> typename enable_if<__and_<__not_>,
>   __is_convertible_to_basic_ostream<_Ostream>,
>   __is_insertable<
> __rvalue_ostream_type<_Ostream>,
> const _Tp&>>::value,
>__rvalue_ostream_type<_Ostream>>::type
> operator<<(_Ostream&& __os, const _Tp& __x)
> 
> It is the __is_insertable in the above.
> So it might be the wrong type being used to check __is_insertable 

If anything it is the __rvalue_ostream_type<_Ostream> part if I am reading this
code correctly.

[Bug libstdc++/99692] Lookup for operator<< skips global scope

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99692

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |libstdc++

--- Comment #1 from Andrew Pinski  ---
Right the problem is here (and not with the compiler itself if there is a
problem):
/home/ubuntu/upstream-gcc/include/c++/11.0.1/ostream:747:46: error: no match
for ‘operator<<’ (operand types are ‘std::basic_ostream’ and ‘const
std::vector’)
  746 |__void_t()
  |  
  747 |  << declval())>>
  |  ^~~~


But by definition at this point operator << does not exist and is not
considered as it is not found via ADL because both std::basic_ostream and
std::vector are in the std namespace and the global namespace is not
considered.

/home/ubuntu/upstream-gcc/include/c++/11.0.1/ostream:773:5:   required by
substitution of ‘template typename
std::enable_if >,
std::__is_convertible_to_basic_ostream<_Ostream>, std::__is_insertable::__ostream_type, const _Tp&, void>
>::value, typename
std::__is_convertible_to_basic_ostream<_Tp>::__ostream_type>::type
std::operator<<(_Ostream&&, const _Tp&) [with _Ostream = CustomStream; _Tp =
std::vector]’
t78.cc:21:41:   required from here
  template
inline
typename enable_if<__and_<__not_>,
  __is_convertible_to_basic_ostream<_Ostream>,
  __is_insertable<
__rvalue_ostream_type<_Ostream>,
const _Tp&>>::value,
   __rvalue_ostream_type<_Ostream>>::type
operator<<(_Ostream&& __os, const _Tp& __x)

It is the __is_insertable in the above.
So it might be the wrong type being used to check __is_insertable 

[Bug tree-optimization/98736] [10/11 Regression] Wrong partition order generated in loop distribution pass since r10-619-g5879ab5fafedc8f6

[amker at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98736

--- Comment #4 from bin cheng  ---
(In reply to bin cheng from comment #3)
> hmm, seems topological order isn't enough for distributing a loop nest, we
> need topological order plus inner loop depth-first.

Well, not really.  In this case, problem is that rev-post order algorithm puts
"a[c] = d[3];" before the inner loop which violates the original program order. 

Seems that it can be fixed by inner loop depth-first order wrto how we
distribute inner loop, but I am not sure if this always preserves programming
order because loop has been reformed by various optimizers.

[Bug c++/99692] New: Lookup for operator<< skips global scope

[skaniskin at berkeley dot edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99692

Bug ID: 99692
   Summary: Lookup for operator<< skips global scope
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skaniskin at berkeley dot edu
  Target Milestone: ---

The following code is rejected by g++. 

#include 
#include 

struct CustomStream : std::ostream {};

std::ostream& operator<<(std::ostream& s, const std::vector&) 
{
return s;
}

CustomStream&& operator<<(CustomStream&& s, const std::vector& v)  
{
static_cast(s) << v;
return std::move(s);
}

int main() 
{
CustomStream() << std::vector{};
}

The problem is there with all recent versions of gcc and independent of
compiler flags

[Bug d/99691] New: OpenBSD support for GDC

[bcallah at protonmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99691

Bug ID: 99691
   Summary: OpenBSD support for GDC
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: bcallah at protonmail dot com
  Target Milestone: ---

Created attachment 50441
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50441=edit
OpenBSD support for GDC

Hello --

Provided here is a patch demonstrating OpenBSD support for GDC.

Some important notes and helps needed:

* Iain, you'll notice that my druntime is different from the DMD druntime diff
you saw on GitHub. I will do my best to sync the two, which will mean replacing
what I've done for DMD with what I've done here for GDC, to make all lives
easier.

* I cannot get a shared libgphobos to work on OpenBSD. I get random crashes
that I have not yet been able to track down. I do not know how to disable
--enable-shared in libphobos's configure.ac without disabling it for all of
gcc, which is not desirable. If that's a patch I have to carry until I can get
a working shared libgphobos, that's fine.

* I suspect libphobos will work on more than just x86_64 and i386 but as I've
only been able to test on x86_64, I kept libphobos to just those 2 archs. I
will submit further diffs for more platforms as I'm able to test.

* The port is otherwise fairly straightforward and I am using this in
production.

Thanks! Happy to work with you to get this in.

[Bug bootstrap/31235] Bootstrap comparison failure with -gstabs

[egallager at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31235

Eric Gallager  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=99457
 CC||egallager at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
Note that there has been discussion of deprecating stabs support recently:
https://gcc.gnu.org/pipermail/gcc-patches/2017-July/479552.html

[Bug target/71009] g++: ICE on modified gdb/valarith.c with -Ofast

[egallager at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71009

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
 Status|NEW |WAITING

--- Comment #14 from Eric Gallager  ---
Note that I can't reproduce my original bug anymore. Ryan, would you like to
keep this bug open for your variation on it, or are you going to open a
separate bug for it?

[Bug middle-end/99689] Initialized local variable becomes uninitialized after use

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99689

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |middle-end
   Keywords||wrong-code

--- Comment #2 from Andrew Pinski  ---
Works for me on the trunk:
GNU C++17 (GCC) version 11.0.1 20210314 (experimental) [master revision
553488851dd:9748870ecd0:87cbac2b7a78fdfda61a6accf13a1fd858f5ccfe]
(aarch64-unknown-linux-gnu)

[Bug fortran/99688] AddressSanitizer: stack-buffer-overflow on address at gfc_match_name(char*) gcc/fortran/match.c:685

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99688

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
I do not see the issue with valgrind, but does the following obvious patch
help?

diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 4d5890fd523..9941887453f 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -6634,7 +6634,7 @@ gfc_match_select_rank (void)
 {
   gfc_expr *expr1, *expr2 = NULL;
   match m;
-  char name[GFC_MAX_SYMBOL_LEN];
+  char name[GFC_MAX_SYMBOL_LEN + 1];
   gfc_symbol *sym, *sym2;
   gfc_namespace *ns = gfc_current_ns;
   gfc_array_spec *as = NULL;

There might be a similar issue with SELECT TYPE (gfc_match_select_type).

[Bug target/99690] New: gcc/config/m68k/t-mlibs doesn't allow extending MULTILIB_EXCEPTIONS

[miro.kropacek at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99690

Bug ID: 99690
   Summary: gcc/config/m68k/t-mlibs doesn't allow extending
MULTILIB_EXCEPTIONS
   Product: gcc
   Version: 7.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: miro.kropacek at gmail dot com
  Target Milestone: ---

gcc/config/m68k/t-mlibs nicely unifies various m68k options and mappings.
However it doesn't allow extending (or overriding) the MULTILIB_EXCEPTIONS
macro the same way the M68K_MLIB_DIRNAMES and M68K_MLIB_OPTIONS does:

# Add subtarget specific options & dirs.
MULTILIB_DIRNAMES += $(M68K_MLIB_DIRNAMES)
MULTILIB_OPTIONS += $(M68K_MLIB_OPTIONS)

Is there a reason for that?

[Bug fortran/97491] Wrong restriction for VALUE arguments of pure procedures

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97491

--- Comment #9 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:e016c286dae10ea1b037d149fee924bdd07e546a

commit r9-9298-ge016c286dae10ea1b037d149fee924bdd07e546a
Author: Harald Anlauf 
Date:   Tue Oct 27 20:25:23 2020 +0100

PR fortran/97491 - Wrong restriction for VALUE arguments of pure procedures

A dummy argument with the VALUE attribute may be redefined in a PURE or
ELEMENTAL procedure.  Adjust the associated purity check.

gcc/fortran/ChangeLog:

* resolve.c (gfc_impure_variable): A dummy argument with the VALUE
attribute may be redefined without making a procedure impure.

gcc/testsuite/ChangeLog:

* gfortran.dg/value_8.f90: New test.

(cherry picked from commit a764c40079a493826a3678174f908941a383644e)

[Bug c++/99689] Initialized local variable becomes uninitialized after use

[soren.soe at gonsoe dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99689

--- Comment #1 from Soren Soe  ---
Created attachment 50440
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50440=edit
source file

[Bug c++/99689] New: Initialized local variable becomes uninitialized after use

[soren.soe at gonsoe dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99689

Bug ID: 99689
   Summary: Initialized local variable becomes uninitialized after
use
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: soren.soe at gonsoe dot com
  Target Milestone: ---

Created attachment 50439
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50439=edit
preprocessed file (*.i*) that triggers the bug

% g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/9/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
9.3.0-17ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support
--enable-plugin --enable-default-pie --with-system-zlib
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release
--build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu
Thread model: posix
gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) 

% cat bug.cpp
#include 
#include 
#include 
#include 

using vec = std::vector>;

void
bad()
{
  vec v;
  v.emplace_back("abc", "def");
  v.emplace_back("abc", "def");
  v.emplace_back("abc", "def");
  v.emplace_back("abc", "def");
  v.emplace_back("abc", "def");

  unsigned int m = 0;
  for (auto& p : v)
m = std::max(m, p.first.length());

  assert(m == 3);
}

int main()
{
  bad();
  return 0;
}


% g++ -Wall -Wextra -O3 -std=c++14 bug.cpp 
% ./a.out 
a.out: bug.cpp:79: void bad(): Assertion `m == 3' failed.
Aborted (core dumped)

[Bug fortran/99688] AddressSanitizer: stack-buffer-overflow on address at gfc_match_name(char*) gcc/fortran/match.c:685

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99688

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-03-20
   Priority|P3  |P4
 Ever confirmed|0   |1
   Target Milestone|--- |11.0

[Bug fortran/99688] New: AddressSanitizer: stack-buffer-overflow on address at gfc_match_name(char*) gcc/fortran/match.c:685

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99688

Bug ID: 99688
   Summary: AddressSanitizer: stack-buffer-overflow on address at
gfc_match_name(char*) gcc/fortran/match.c:685
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
Blocks: 86656
  Target Milestone: ---

I see the following ASAN issue:

$ ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/pr95828.f90
-c
=
==28113==ERROR: AddressSanitizer: stack-buffer-overflow on address
0x7fffd3af at pc 0x00ba5a30 bp 0x7fffd080 sp 0x7fffd078
WRITE of size 1 at 0x7fffd3af thread T0
#0 0xba5a2f in gfc_match_name(char*)
/home/marxin/Programming/gcc2/gcc/fortran/match.c:685
#1 0xba7af8 in gfc_match(char const*, ...)
/home/marxin/Programming/gcc2/gcc/fortran/match.c:1186
#2 0xbc4846 in gfc_match_select_rank()
/home/marxin/Programming/gcc2/gcc/fortran/match.c:6654
#3 0xc3db48 in match_word
/home/marxin/Programming/gcc2/gcc/fortran/parse.c:65
#4 0xc3f4bd in decode_statement
/home/marxin/Programming/gcc2/gcc/fortran/parse.c:429
#5 0xc46cce in next_free
/home/marxin/Programming/gcc2/gcc/fortran/parse.c:1316
#6 0xc478b8 in next_statement
/home/marxin/Programming/gcc2/gcc/fortran/parse.c:1548
#7 0xc4fd5b in parse_spec
/home/marxin/Programming/gcc2/gcc/fortran/parse.c:3967
#8 0xc58f22 in parse_progunit
/home/marxin/Programming/gcc2/gcc/fortran/parse.c:5896
#9 0xc5851c in parse_contained
/home/marxin/Programming/gcc2/gcc/fortran/parse.c:5797
#10 0xc5a10c in parse_module
/home/marxin/Programming/gcc2/gcc/fortran/parse.c:6170
#11 0xc5c26c in gfc_parse_file()
/home/marxin/Programming/gcc2/gcc/fortran/parse.c:6465
#12 0xd76343 in gfc_be_parse_file
/home/marxin/Programming/gcc2/gcc/fortran/f95-lang.c:212
#13 0x229bd2e in compile_file
/home/marxin/Programming/gcc2/gcc/toplev.c:457
#14 0x22a50ef in do_compile /home/marxin/Programming/gcc2/gcc/toplev.c:2201
#15 0x22a5953 in toplev::main(int, char**)
/home/marxin/Programming/gcc2/gcc/toplev.c:2340
#16 0x4c85cad in main /home/marxin/Programming/gcc2/gcc/main.c:39
#17 0x77095b24 in __libc_start_main ../csu/libc-start.c:332
#18 0xa349ed in _start
(/home/marxin/Programming/gcc2/objdir/gcc/f951+0xa349ed)

Address 0x7fffd3af is located in stack of thread T0 at offset 191 in frame
#0 0xbc4644 in gfc_match_select_rank()
/home/marxin/Programming/gcc2/gcc/fortran/match.c:6634

  This frame has 4 object(s):
[32, 40) 'expr1' (line 6635)
[64, 72) 'expr2' (line 6635)
[96, 104) 'ns' (line 6639)
[128, 191) 'name' (line 6637) <== Memory access at offset 191 overflows
this variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-buffer-overflow
/home/marxin/Programming/gcc2/gcc/fortran/match.c:685 in gfc_match_name(char*)
Shadow bytes around the buggy address:
  0x10007fff7a20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
  0x10007fff7a30: f1 f1 00 00 f2 f2 00 00 00 f3 f3 f3 f3 f3 00 00
  0x10007fff7a40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007fff7a50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
  0x10007fff7a60: f1 f1 00 f2 f2 f2 00 f2 f2 f2 00 f2 f2 f2 00 00
=>0x10007fff7a70: 00 00 00 00 00[07]f3 f3 f3 f3 00 00 00 00 00 00
  0x10007fff7a80: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1
  0x10007fff7a90: 04 f2 04 f2 00 00 f3 f3 00 00 00 00 00 00 00 00
  0x10007fff7aa0: f1 f1 f1 f1 f1 f1 04 f2 04 f3 f3 f3 00 00 00 00
  0x10007fff7ab0: 00 00 00 00 f1 f1 f1 f1 00 00 f3 f3 00 00 00 00
  0x10007fff7ac0: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 f2
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
  Shadow gap:  cc
==28113==ABORTING


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656
[Bug 86656] [meta-bug] Issues found with -fsanitize=address

[Bug c++/99687] AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator delete) on 0x604000000d50

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99687

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug c++/99687] AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator delete) on 0x604000000d50

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99687

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug c++/99687] AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator delete) on 0x604000000d50

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99687

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-03-20
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #1 from Martin Liška  ---
I've git a patch candidate.

[Bug c++/99687] New: AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator delete) on 0x604000000d50

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99687

Bug ID: 99687
   Summary: AddressSanitizer: alloc-dealloc-mismatch (malloc vs
operator delete) on 0x60400d50
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
Blocks: 86656
  Target Milestone: ---

I noticed this issue:

$ ./xg++ -B.
/home/marxin/Programming/gcc2/gcc/testsuite/g++.dg/modules/keyword-1_a.C -c
-std=c++17  -fmodules-ts
=
==26209==ERROR: AddressSanitizer: alloc-dealloc-mismatch (malloc vs operator
delete) on 0x60400d50
#0 0x77674f47 in operator delete(void*, unsigned long)
(/usr/lib64/libasan.so.6+0xb3f47)
#1 0xf4cfd6 in fini_modules()
/home/marxin/Programming/gcc2/gcc/cp/module.cc:20012
#2 0xda5f20 in c_parse_final_cleanups()
/home/marxin/Programming/gcc2/gcc/cp/decl2.c:5239
#3 0x1493a37 in c_common_parse_file()
/home/marxin/Programming/gcc2/gcc/c-family/c-opts.c:1240
#4 0x27a4946 in compile_file /home/marxin/Programming/gcc2/gcc/toplev.c:457
#5 0x27add07 in do_compile /home/marxin/Programming/gcc2/gcc/toplev.c:2201
#6 0x27ae56b in toplev::main(int, char**)
/home/marxin/Programming/gcc2/gcc/toplev.c:2340
#7 0x5179dcb in main /home/marxin/Programming/gcc2/gcc/main.c:39
#8 0x77095b24 in __libc_start_main ../csu/libc-start.c:332
#9 0xab9c1d in _start
(/home/marxin/Programming/gcc2/objdir/gcc/cc1plus+0xab9c1d)

0x60400d50 is located 0 bytes inside of 40-byte region
[0x60400d50,0x60400d78)
allocated by thread T0 here:
#0 0x7767295f in __interceptor_malloc (/usr/lib64/libasan.so.6+0xb195f)
#1 0x53c4a47 in xrealloc
/home/marxin/Programming/gcc2/libiberty/xmalloc.c:177
#2 0xf64061 in void va_heap::reserve(vec*&, unsigned int, bool)
/home/marxin/Programming/gcc2/gcc/vec.h:290
#3 0xf5ac8d in bool vec_safe_reserve(vec*&, unsigned int, bool)
/home/marxin/Programming/gcc2/gcc/vec.h:698
#4 0xf4bbc0 in init_modules(cpp_reader*)
/home/marxin/Programming/gcc2/gcc/cp/module.cc:19779
#5 0xce903a in cxx_init_decl_processing()
/home/marxin/Programming/gcc2/gcc/cp/decl.c:4708
#6 0xe42537 in cxx_init() /home/marxin/Programming/gcc2/gcc/cp/lex.c:330
#7 0x27ac419 in lang_dependent_init
/home/marxin/Programming/gcc2/gcc/toplev.c:1889
#8 0x27adc03 in do_compile /home/marxin/Programming/gcc2/gcc/toplev.c:2186
#9 0x27ae56b in toplev::main(int, char**)
/home/marxin/Programming/gcc2/gcc/toplev.c:2340
#10 0x5179dcb in main /home/marxin/Programming/gcc2/gcc/main.c:39
#11 0x77095b24 in __libc_start_main ../csu/libc-start.c:332

SUMMARY: AddressSanitizer: alloc-dealloc-mismatch
(/usr/lib64/libasan.so.6+0xb3f47) in operator delete(void*, unsigned long)
==26209==HINT: if you don't care about these errors you may set
ASAN_OPTIONS=alloc_dealloc_mismatch=0
==26209==ABORTING


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656
[Bug 86656] [meta-bug] Issues found with -fsanitize=address

[Bug c++/99675] [11 Regression] ICE during template deduction since r10-5020-g1a291106384cabc7

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99675

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-03-20
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||jason at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
  Known to fail||11.0
Summary|internal compiler error |[11 Regression] ICE during
   |during template deduction   |template deduction since
   ||r10-5020-g1a291106384cabc7
  Known to work||10.2.0

--- Comment #1 from Martin Liška  ---
Reduced test-case:

namespace std {
template  struct common_type;
template 
using common_type_t = typename common_type<_Tp...>::type;
} // namespace std
template  class vec {
public:
  vec(T, T, T);
};
template 
vec() -> vec, sizeof...(Args)>;
template  using vec3 = vec;
void lala() { vec3(1, 2, 3); }

started with r10-5020-g1a291106384cabc7.

[Bug c++/99686] ICE when concepts on C++17 when providing both T&& and const T& specialization

[StevenSun2021 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686

--- Comment #1 from Steven Sun  ---
The compiler args are only "g++ -fconcepts -std=c++17"

It should choose the full specialization func(int &&), while the compiler
aborts during the instatiation of the partial specialization (using concepts).

If either the partial or the full specialzation is removed, it compiles.


New online compiler link: https://godbolt.org/z/fK5G61
-
template 
void func(T &)
{
}

template 
requires requires(T t) { ++t; }
void func(T &)
{
}

template <>
void func(int &)
{
}

int main()
{
func(1); // I am expecting func(int&&)
}
-

Error:
In instantiation of ‘void func(T&&) [with T = int]’:
internal compiler error: Segmentation fault
   11 | }
  | ^
Please submit a full bug report,

[Bug c++/99686] New: ICE when concepts on C++17 when providing both T&& and const T& specialization

[StevenSun2021 at hotmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99686

Bug ID: 99686
   Summary: ICE when concepts on C++17 when providing both T&& and
const T& specialization
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: StevenSun2021 at hotmail dot com
  Target Milestone: ---

This problem occurs only when using std=c++17 and -fconcepts. It compiles when
using std=c++20.


I also have an online compiler link for this. https://godbolt.org/z/W9r6Wx

-
template 
void func(T &)
{
}

template 
requires requires(T t) { ++t; }
void func(T &)
{
}

template <>
void func(int &)
{
}

template <>
void func(const int )
{
}

int main()
{
func(1); // I am expecting func(int&&)
}

[Bug testsuite/99685] New: gcc.target/powerpc/divkc3-1.c and mulkc3-1.c fails for 32 bits

[seurer at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99685

Bug ID: 99685
   Summary: gcc.target/powerpc/divkc3-1.c and mulkc3-1.c fails for
32 bits
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
powerpc.exp=gcc.target/powerpc/divkc3-1.c"
FAIL: gcc.target/powerpc/divkc3-1.c execution test
# of expected passes1
# of unexpected failures1

make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
powerpc.exp=gcc.target/powerpc/mulkc3-1.c"
FAIL: gcc.target/powerpc/mulkc3-1.c execution test
# of expected passes1
# of unexpected failures1


(gdb) run
Starting program: /home/seurer/gcc/git/build/gcc-10-test/./divkc3-1.exe 

Program received signal SIGABRT, Aborted.
0x0fd4b7c8 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:55
55return INLINE_SYSCALL (tgkill, 3, pid, selftid, sig);
(gdb) where
#0  0x0fd4b7c8 in __GI_raise (sig=sig@entry=6) at
../nptl/sysdeps/unix/sysv/linux/raise.c:55
#1  0x0fd4d584 in __GI_abort () at abort.c:90
#2  0x1650 in main () at
/home/seurer/gcc/git/gcc-10-test/gcc/testsuite/gcc.target/powerpc/divkc3-1.c:20


  z = divide (5.0q + 5.0jq, 2.0q + 1.0jq);
  a = 3.0q + 1.0jq;
  if (z != a)
abort ();  // line 20

These two tests both fail when compiled for 32 bits but work fine for 64 bits. 
Are they valid for 32 bits?

They also fail in gcc 10 but back in gcc 9 they were marked as unsupported.

[Bug c++/99684] New: [modules] std::visit fails to compile when is used as header unit

[wangsw.a at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99684

Bug ID: 99684
   Summary: [modules] std::visit fails to compile when 
is used as header unit
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wangsw.a at gmail dot com
  Target Milestone: ---

All invocations of std::visit on variants currently fail a static_assert, when
 is imported as a header unit.

Environment: gcc (GCC) 11.0.1 20210320 (experimental) [master branch],
configured with '--enable-languages=c,c++ --disable-multilib', built as docker
image on macOS 10.14.6
Dockerfile:
https://raw.githubusercontent.com/beanandbean/docker-gcc-cxx-modules/5fa616ae6c55bdb2c2961feff8d8ae5c51004961/Dockerfile
[with argument GCC_BRANCH=master]

 main.cpp 

import ;

int main() {
  std::variant a;
  std::visit([](auto&&) {}, a);
  return 0;
}

-- command line --

(in docker shell:)
root@1265897bf148:/project# g++ -std=c++20 -fmodules-ts -x c++-system-header
variant
root@1265897bf148:/project# g++ -std=c++20 -fmodules-ts -Wall -Wextra main.cpp
In module /usr/local/include/c++/11.0.1/variant, imported at main.cpp:1:
/usr/local/include/c++/11.0.1/variant: In instantiation of 'static constexpr
void
std::__detail::__variant::__gen_vtable_impl, std::integer_sequence >::_S_apply_single_alt(_Tp&, _Tp*) [with bool
__do_cookie = false; long unsigned int __index = 0; _Tp =
std::__detail::__variant::_Multi_array
(*)(main()::&&, std::variant&)>; _Result_type =
std::__detail::__variant::__deduce_visit_result; _Visitor =
main()::&&; long unsigned int ...__dimensions = {2};
_Variants = {std::variant&}; long unsigned int ...__indices = {}]':
/usr/local/include/c++/11.0.1/variant:944:48:   required from 'constexpr const
_Array_type
std::__detail::__variant::__gen_vtable,
main()::&&, std::variant&>::_S_vtable'
/usr/local/include/c++/11.0.1/variant:1711:45:   required from 'constexpr
decltype(auto) std::__do_visit(_Visitor&&, _Variants&& ...) [with _Result_type
= std::__detail::__variant::__deduce_visit_result; _Visitor =
main()::; _Variants = {std::variant&}]'
/usr/local/include/c++/11.0.1/variant:1764:34:   required from 'constexpr
decltype(auto) std::visit(_Visitor&&, _Variants&& ...) [with _Visitor =
main()::; _Variants = {std::variant&}]'
main.cpp:5:30:   required from here
/usr/local/include/c++/11.0.1/variant:1052:67:   in 'constexpr' expansion of
'std::__detail::__variant::__gen_vtable_impl
(*)(main()::&&, std::variant&), 2>,
std::integer_sequence >::_S_apply()'
/usr/local/include/c++/11.0.1/variant:929:19:   in 'constexpr' expansion of
'std::__detail::__variant::__gen_vtable_impl
(*)(main()::&&, std::variant&), 2>,
std::integer_sequence >::_S_apply_all_alts<0, 1>(__vtable,
(std::make_index_sequence<2>(), std::make_index_sequence<2>()))'
/usr/local/include/c++/11.0.1/variant:966:29: error: static assertion failed:
std::visit requires the visitor to have the same return type for all
alternatives of a variant
  966 |   static_assert(is_same_v<_Tp, decltype(__tmp_element)>,
  | ^~~
/usr/local/include/c++/11.0.1/variant:966:29: note:
'std::is_same_v
(*)(main()::&&, std::variant&)>,
std::__detail::__variant::_Multi_array
(*)(main()::&&, std::variant&)>&>' evaluates to
false
/usr/local/include/c++/11.0.1/variant: In instantiation of 'static constexpr
void
std::__detail::__variant::__gen_vtable_impl, std::integer_sequence >::_S_apply_single_alt(_Tp&, _Tp*) [with bool
__do_cookie = false; long unsigned int __index = 1; _Tp =
std::__detail::__variant::_Multi_array
(*)(main()::&&, std::variant&)>; _Result_type =
std::__detail::__variant::__deduce_visit_result; _Visitor =
main()::&&; long unsigned int ...__dimensions = {2};
_Variants = {std::variant&}; long unsigned int ...__indices = {}]':
/usr/local/include/c++/11.0.1/variant:944:48:   required from 'constexpr const
_Array_type
std::__detail::__variant::__gen_vtable,
main()::&&, std::variant&>::_S_vtable'
/usr/local/include/c++/11.0.1/variant:1711:45:   required from 'constexpr
decltype(auto) std::__do_visit(_Visitor&&, _Variants&& ...) [with _Result_type
= std::__detail::__variant::__deduce_visit_result; _Visitor =
main()::; _Variants = {std::variant&}]'
/usr/local/include/c++/11.0.1/variant:1764:34:   required from 'constexpr
decltype(auto) std::visit(_Visitor&&, _Variants&& ...) [with _Visitor =
main()::; _Variants = {std::variant&}]'
main.cpp:5:30:   required from here
/usr/local/include/c++/11.0.1/variant:1052:67:   in 'constexpr' ex

[Bug c++/99683] New: Deduction failure when using CTAD of CNTTP inside a deduction guide

[omer.rosler at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99683

Bug ID: 99683
   Summary: Deduction failure when using CTAD of CNTTP inside a
deduction guide
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: omer.rosler at gmail dot com
  Target Milestone: ---

The following code causes a deduction failure on gcc and is accepted by clang.
It happens when using a CTAD for a CNTTP inside an explicit deduction guide.
I'm pretty sure it is legal C++20.

https://godbolt.org/z/Y49T6P

[Bug target/99679] [11 Regression] ICE in construct_container at gcc/config/i386/i386.c:2571 since g:5e2eabe1eed1e53d39923517122d3c7de2013ad4

[hjl.tools at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99679

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from H.J. Lu  ---
Fixed.

[Bug target/99679] [11 Regression] ICE in construct_container at gcc/config/i386/i386.c:2571 since g:5e2eabe1eed1e53d39923517122d3c7de2013ad4

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99679

--- Comment #1 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:19ff0b0d816e6e7d7657a8559e9957d79dc1d77f

commit r11-7751-g19ff0b0d816e6e7d7657a8559e9957d79dc1d77f
Author: H.J. Lu 
Date:   Sat Mar 20 05:17:36 2021 -0700

x86: Check cfun != NULL before accessing silent_p

Since construct_container may be called with cfun == NULL, check
cfun != NULL before accessing silent_p.

gcc/

PR target/99679
* config/i386/i386.c (construct_container): Check cfun != NULL
before accessing silent_p.

gcc/testsuite/

PR target/99679
* g++.target/i386/pr99679-1.C: New test.
* g++.target/i386/pr99679-2.C: Likewise.

[Bug rtl-optimization/99680] [11 Regression] AddressSanitizer: global-buffer-overflow since g:04b4828c6dd2

[vmakarov at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99680

--- Comment #5 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #4)
> I was worried that letters that introduce multi-letter constraints followed
> by '\0' could be a problem too.  Or do we rely on those being dropped
> already earlier?
> Something like "=B" on x86_64 etc.  In what I've tried it was dropped during
> vregs pass though.
> And when cn already is CONSTRAINT__UNKNOWN, performing checks whether to set
> it to CONSTRAINT__UNKNOWN is just wasted time.

I like more direct approach.  Just looking at CONSTRAINT_LEN.  Multichracter
constraints returns their length, all others (including modifiers and '\0')
returns 1.  Using CONSTRAINT__UNKNOWN adds one more function
(lookup_constraint) in the decision chain.

If somebody uses starting character of multi-character constraint without all
constraint characters, a lot of things will be broken at least in RA.  If this
happens RA will read besides constraint string anyway in other RA code places
and also RA will also consider garbage after the string as additional
constraints and make unwanted reloads. Reading behind constraint string in
process_address_1 would have less serious consequences.

[Bug debug/99230] [11 Regression] gcc.dg/pr83527.c excess errors: '-fcompare-debug' failure (length)

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99230

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

https://gcc.gnu.org/g:9f59cb7cac009f3c6eba81eb09714699b9ac9f8d

commit r11-7750-g9f59cb7cac009f3c6eba81eb09714699b9ac9f8d
Author: Jakub Jelinek 
Date:   Sat Mar 20 17:02:06 2021 +0100

c-family: Fix PR94272 -fcompare-debug issue even for C [PR99230]

The following testcase results in -fcompare-debug failure.
The problem is the similar like in PR94272
https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542562.html
When genericizing, with -g0 we have just a TREE_SIDE_EFFECTS DO_STMT
in a branch of if, while with -g we have that wrapped into
TREE_SIDE_EFFECTS STATEMENT_LIST containing DEBUG_BEGIN_STMT and that
DO_STMT.
The do loop is empty with 0 condition, so c_genericize_control_stmt
turns it into an empty statement (without TREE_SIDE_EFFECTS).
For -g0 that means that suddenly the if branch doesn't have side effects
and is expanded differently.  But with -g we still have TREE_SIDE_EFFECTS
STATEMENT_LIST containing DEBUG_BEGIN_STMT and non-TREE_SIDE_EFFECTS stmt.
The following patch fixes that by detecting this case and removing
TREE_SIDE_EFFECTS.

And, so that we don't duplicate the same code, changes the C++ FE to
just call the c_genericize_control_stmt function that can now handle it.

2021-03-20  Jakub Jelinek  

PR debug/99230
* c-gimplify.c (c_genericize_control_stmt): Handle STATEMENT_LIST.

* cp-gimplify.c (cp_genericize_r) : Remove
special code, instead call c_genericize_control_stmt.

* gcc.dg/pr99230.c: New test.

[Bug rtl-optimization/99680] [11 Regression] AddressSanitizer: global-buffer-overflow since g:04b4828c6dd2

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99680

--- Comment #4 from Jakub Jelinek  ---
I was worried that letters that introduce multi-letter constraints followed by
'\0' could be a problem too.  Or do we rely on those being dropped already
earlier?
Something like "=B" on x86_64 etc.  In what I've tried it was dropped during
vregs pass though.
And when cn already is CONSTRAINT__UNKNOWN, performing checks whether to set it
to CONSTRAINT__UNKNOWN is just wasted time.

[Bug c++/99682] New: [modules] Module implementation unit is unable to indirectly import its corresponding interface unit

[ensadc at mailnesia dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99682

Bug ID: 99682
   Summary: [modules] Module implementation unit is unable to
indirectly import its corresponding interface unit
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ensadc at mailnesia dot com
  Target Milestone: ---

$ cat src/foo.cpp
export module foo;

$ cat src/bar.cpp
export module bar;
import foo;

$ cat src/foo-impl.cpp
module foo;
import bar;

$ g++ -fmodules-ts -c src/foo.cpp
$ g++ -fmodules-ts -c src/bar.cpp
$ g++ -fmodules-ts -c src/foo-impl.cpp
In module imported at src/foo-impl.cpp:2:1:
bar: error: cannot import module in its own purview
In module imported at src/foo-impl.cpp:1:1:
foo: note: module ‘foo’ declared here
In module imported at src/foo-impl.cpp:2:1:
bar: error: failed to read compiled module: Bad import dependency
bar: note: compiled module file is ‘gcm.cache/bar.gcm’
bar: fatal error: returning to the gate for a mechanical issue
compilation terminated.



AFAIK, although a module implementation unit cannot *directly* imports its
module interface unit (http://eel.is/c++draft/module.import#9 ), *indirect*
import should not be prohibited (and should probably be a no-op, because the
primary module interface unit has been imported by `module foo;`).

MSVC compiles this test case without any errors.

[Bug c++/97134] partial specialization not more specialized when using CNTTP

[omer.rosler at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97134

Omer Rosler  changed:

   What|Removed |Added

 CC||omer.rosler at gmail dot com

--- Comment #2 from Omer Rosler  ---
I encountered a similar problem, I think it's the same bug, so I won't open
another ticket.

Much simpler code fails to compile:

```c++
template
struct templ {};

template
struct wrapper {};

template
struct wrapper {};
```

[Bug rtl-optimization/99680] [11 Regression] AddressSanitizer: global-buffer-overflow since g:04b4828c6dd2

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99680

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Vladimir Makarov :

https://gcc.gnu.org/g:8bf983c71e42d5a9f9df8a7dc436b30cd9da42f5

commit r11-7748-g8bf983c71e42d5a9f9df8a7dc436b30cd9da42f5
Author: Vladimir N. Makarov 
Date:   Sat Mar 20 10:50:03 2021 -0400

[PR99680] Check empty constraint before using CONSTRAINT_LEN.

It seems CONSTRAINT_LEN treats constraint '\0' as one having length 1. 
Therefore we
read after the constraint string.  The patch fixes it.

gcc/ChangeLog:

PR rtl-optimization/99680
* lra-constraints.c (skip_contraint_modifiers): Rename to
skip_constraint_modifiers.
(process_address_1): Check empty constraint before using
CONSTRAINT_LEN.

[Bug rtl-optimization/99680] [11 Regression] AddressSanitizer: global-buffer-overflow since g:04b4828c6dd2

[vmakarov at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99680

--- Comment #2 from Vladimir Makarov  ---
Sorry for the troubles with my previous patch. I should have not be in hurry to
fix PR99663.

I'll fix it today.  Jakub's patch could be a candidate but I prefer check
constraint[0] on '\0'.

[Bug rtl-optimization/99680] [11 Regression] AddressSanitizer: global-buffer-overflow since g:04b4828c6dd2

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99680

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Created attachment 50438
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50438=edit
gcc11-pr99680.patch

Untested fix.

[Bug sanitizer/99673] [11 Regression] bogus -Wstringop-overread warning with address sanitizer due to member address substitution

[arnd at linaro dot org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99673

--- Comment #2 from Arnd Bergmann  ---
Thank you for the detailed analysis. This was the last such warning I get with
linux kernel randconfig build that I could not explain based on the earlier
discussion, so now I can submit the local workarounds and reference the bug
reports. Among the ten -Wstringop-overread warnings I got for this codebase,
around half should not have been a warning, the others are mostly harmless,
though the warning seems reasonable, while one or two seem to be actual bugs
but need to be confirmed.

Based on your explanation, is it safe to assume this can only affect the
diagnostic output and not lead to incorrect or misoptimized code being
generated?

[Bug target/99681] [11 Regression] ICE in print_shift_count_operand, at config/s390/s390.c:7630

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99681

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Martin Liška  ---
Fixed with g:d81019db099ad95febbb2d4b4afd8cbe95762062.

[Bug target/99681] New: [11 Regression] ICE in print_shift_count_operand, at config/s390/s390.c:7630

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99681

Bug ID: 99681
   Summary: [11 Regression] ICE in print_shift_count_operand, at
config/s390/s390.c:7630
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: s390x-linux-gnu

The following ICEs:

$ s390x-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr97459-2.c
-fno-tree-loop-optimize -O2 -c
during RTL pass: final
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr97459-2.c: In function
‘main’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr97459-2.c:57:1: internal
compiler error: in print_shift_count_operand, at config/s390/s390.c:7630
   57 | }
  | ^
0x5cc939 print_shift_count_operand
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/config/s390/s390.c:7630
0x5cc939 print_operand(_IO_FILE*, rtx_def*, int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/config/s390/s390.c:8104
0x819c41 output_operand(rtx_def*, int)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/final.c:4069
0x81a6b5 output_asm_insn(char const*, rtx_def**)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/final.c:3962
0x81da30 output_asm_insn(char const*, rtx_def**)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/final.c:3858
0x81da30 final_scan_insn_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/final.c:3125
0x81ddab final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/final.c:3171
0x81e094 final_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/final.c:2022
0x81e832 rest_of_handle_final
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/final.c:4676
0x81e832 execute
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-s390x/build/gcc/final.c:4754
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

It's a recent regression.

[Bug rtl-optimization/99680] [11 Regression] AddressSanitizer: global-buffer-overflow since g:04b4828c6dd2

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99680

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Priority|P3  |P1
   Target Milestone|--- |11.0
  Known to work||10.2.0
   Keywords||ice-on-valid-code
  Known to fail||11.0
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-03-20

[Bug rtl-optimization/99680] New: [11 Regression] AddressSanitizer: global-buffer-overflow since g:04b4828c6dd2

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99680

Bug ID: 99680
   Summary: [11 Regression] AddressSanitizer:
global-buffer-overflow since g:04b4828c6dd2
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: vmakarov at gcc dot gnu.org
  Target Milestone: ---

Since the revision I see the following ASAN error for:

$ cat /tmp/ice.i
int __negti2_u2;

int __negti2_u() {
  int uu_0_0 = __negti2_u2;
  __int128 w_1 = uu_0_0 > 0;
  return w_1;
}

$ /home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/objdir/./gcc/xgcc
-B/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/objdir/./gcc/ -O2
/tmp/ice.i -c
=
==5474==ERROR: AddressSanitizer: global-buffer-overflow on address
0x049fe0a1 at pc 0x0152ee4a bp 0x7fffb400 sp 0x7fffb3f8
READ of size 1 at 0x049fe0a1 thread T0
#0 0x152ee49 in skip_contraint_modifiers
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/lra-constraints.c:3401
#1 0x153cf3b in process_address_1
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/lra-constraints.c:3470
#2 0x1544432 in process_address
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/lra-constraints.c:3765
#3 0x1544432 in curr_insn_transform
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/lra-constraints.c:4080
#4 0x155681e in lra_constraints(bool)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/lra-constraints.c:5169
#5 0x151831e in lra(_IO_FILE*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/lra.c:2336
#6 0x141b206 in do_reload
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/ira.c:5834
#7 0x141b206 in execute
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/ira.c:6020
#8 0x177a7f1 in execute_one_pass(opt_pass*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/passes.c:2567
#9 0x177c1e3 in execute_pass_list_1
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/passes.c:2656
#10 0x177c209 in execute_pass_list_1
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/passes.c:2657
#11 0x177c27f in execute_pass_list(function*, opt_pass*)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/passes.c:2667
#12 0xc4051f in cgraph_node::expand()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/cgraphunit.c:1830
#13 0xc43756 in expand_all_functions
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/cgraphunit.c:1998
#14 0xc43756 in symbol_table::compile()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/cgraphunit.c:2362
#15 0xc4c4e6 in symbol_table::compile()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/cgraphunit.c:2275
#16 0xc4c4e6 in symbol_table::finalize_compilation_unit()
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/cgraphunit.c:2543
#17 0x1a638b1 in compile_file
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/toplev.c:482
#18 0x697a45 in do_compile
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/toplev.c:2201
#19 0x697a45 in toplev::main(int, char**)
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/toplev.c:2340
#20 0x6a454a in main
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/main.c:39
#21 0x77852b24 in __libc_start_main ../csu/libc-start.c:332
#22 0x6a584d in _start
(/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/objdir/gcc/cc1+0x6a584d)

0x049fe0a1 is located 63 bytes to the left of global variable '*.LC122'
defined in 'insn-output.c' (0x49fe0e0) of size 22
  '*.LC122' is ascii string 'knotw  {%1, %0|%0, %1}'
0x049fe0a1 is located 0 bytes to the right of global variable '*.LC121'
defined in 'insn-output.c' (0x49fe0a0) of size 1
  '*.LC121' is ascii string ''
SUMMARY: AddressSanitizer: global-buffer-overflow
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-asan/build/gcc/lra-constraints.c:3401
in skip_contraint_modifiers
Shadow bytes around the buggy address:
  0x80937bc0: f9 f9 f9 f9 00 00 00 00 00 00 05 f9 f9 f9 f9 f9
  0x80937bd0: 00 00 00 06 f9 f9 f9 f9 00 00 00 03 f9 f9 f9 f9
  0x80937be0: 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 00 01 f9 f9
  0x80937bf0: f9 f9 f9 f9 00 00 00 00 00 00 02 f9 f9 f9 f9 f9
  0x80937c00: 00 00 00 00 00 05 f9 f9 f9 f9 f9 f9 00 00 00 06
=>0x80937c10: f9 f9 f9 f9[01]f9 f9 f9 f9 f9 f9 f9 00 00 06 f9
  0x80937c20: f9 f9 f9 f9 00 00 06 f9 f9 f9 f9 f9 00 00 06 f9
  0x80937c30: f9 f9 f9 f9 00 00 06 f9 f9 f9 f9 f9 00 00 00 07
  

[Bug c++/99508] [11 Regression] Asm labels declared inside a function are ignored

[frank.mehnert at googlemail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99508

--- Comment #6 from Frank Mehnert  ---
Fix confirmed. Thanks guys!

[Bug target/99679] [11 Regression] ICE in construct_container at gcc/config/i386/i386.c:2571 since g:5e2eabe1eed1e53d39923517122d3c7de2013ad4

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99679

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2021-03-20
   Target Milestone|--- |11.0
  Known to fail||11.0
   Priority|P3  |P1
 Ever confirmed|0   |1
  Known to work||10.2.0
 Status|UNCONFIRMED |NEW

[Bug target/99679] New: [11 Regression] ICE in construct_container at gcc/config/i386/i386.c:2571 since g:5e2eabe1eed1e53d39923517122d3c7de2013ad4

[marxin at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99679

Bug ID: 99679
   Summary: [11 Regression] ICE in construct_container at
gcc/config/i386/i386.c:2571 since
g:5e2eabe1eed1e53d39923517122d3c7de2013ad4
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: hjl.tools at gmail dot com
  Target Milestone: ---

The following fails:

$ ./xgcc -B.
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/va-arg-pack-1.C -Ofast
-fipa-pta -mno-80387 -c
during IPA pass: pta
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/va-arg-pack-1.C:145:1:
internal compiler error: Segmentation fault
  145 | }
  | ^
0x172225c crash_signal
/home/marxin/Programming/gcc/gcc/toplev.c:327
0x7789452f ???
   
/usr/src/debug/glibc-2.33-4.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x1c2f379 construct_container
/home/marxin/Programming/gcc/gcc/config/i386/i386.c:2571
0x1c33420 function_value_64
/home/marxin/Programming/gcc/gcc/config/i386/i386.c:3970
0x1c33a11 ix86_function_value_1
/home/marxin/Programming/gcc/gcc/config/i386/i386.c:4055
0x1c33abc ix86_function_value
/home/marxin/Programming/gcc/gcc/config/i386/i386.c:4067
0x11a3cbf hard_function_value(tree_node const*, tree_node const*, tree_node
const*, int)
/home/marxin/Programming/gcc/gcc/explow.c:2244
0x126d89c aggregate_value_p(tree_node const*, tree_node const*)
/home/marxin/Programming/gcc/gcc/function.c:2122
0x1a15d33 find_func_aliases_for_call
/home/marxin/Programming/gcc/gcc/tree-ssa-structalias.c:4933
0x1a16107 find_func_aliases
/home/marxin/Programming/gcc/gcc/tree-ssa-structalias.c:5010
0x1a20068 ipa_pta_execute
/home/marxin/Programming/gcc/gcc/tree-ssa-structalias.c:8298
0x1a20f98 execute
/home/marxin/Programming/gcc/gcc/tree-ssa-structalias.c:8606
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ (gdb) bt
#0  construct_container (mode=E_XFmode, orig_mode=E_XFmode, type=, in_return=1, nintregs=6, nsseregs=8,
intreg=0x2c90220 , sse_regno=0) at
/home/marxin/Programming/gcc/gcc/config/i386/i386.c:2571
#1  0x01c33421 in function_value_64 (orig_mode=E_XFmode, mode=E_XFmode,
valtype=) at
/home/marxin/Programming/gcc/gcc/config/i386/i386.c:3970
#2  0x01c33a12 in ix86_function_value_1 (valtype=, fntype_or_decl=, orig_mode=E_XFmode,
mode=E_XFmode) at /home/marxin/Programming/gcc/gcc/config/i386/i386.c:4055
#3  0x01c33abd in ix86_function_value (valtype=, fntype_or_decl=) at
/home/marxin/Programming/gcc/gcc/config/i386/i386.c:4067
#4  0x011a3cc0 in hard_function_value (valtype=, func=, fntype=, outgoing=0) at
/home/marxin/Programming/gcc/gcc/explow.c:2244
#5  0x0126d89d in aggregate_value_p (exp=,
fntype=) at /home/marxin/Programming/gcc/gcc/function.c:2122
#6  0x01a15d34 in find_func_aliases_for_call (fn=0x777600b8,
t=0x7130) at
/home/marxin/Programming/gcc/gcc/tree-ssa-structalias.c:4933
#7  0x01a16108 in find_func_aliases (fn=0x777600b8,
origt=) at
/home/marxin/Programming/gcc/gcc/tree-ssa-structalias.c:5010
#8  0x01a20069 in ipa_pta_execute () at
/home/marxin/Programming/gcc/gcc/tree-ssa-structalias.c:8298
#9  0x01a20f99 in (anonymous namespace)::pass_ipa_pta::execute
(this=0x390ba30) at
/home/marxin/Programming/gcc/gcc/tree-ssa-structalias.c:8606
#10 0x015cf140 in execute_one_pass (pass=) at /home/marxin/Programming/gcc/gcc/passes.c:2567
#11 0x015d0251 in execute_ipa_pass_list (pass=) at /home/marxin/Programming/gcc/gcc/passes.c:2996
#12 0x010879be in symbol_table::compile (this=0x775e5000) at
/home/marxin/Programming/gcc/gcc/cgraphunit.c:2325
#13 0x01087e63 in symbol_table::finalize_compilation_unit
(this=0x775e5000) at /home/marxin/Programming/gcc/gcc/cgraphunit.c:2543
#14 0x017227ba in compile_file () at
/home/marxin/Programming/gcc/gcc/toplev.c:482
#15 0x01726475 in do_compile () at
/home/marxin/Programming/gcc/gcc/toplev.c:2201
#16 0x01726809 in toplev::main (this=0x7fffdc8e, argc=22,
argv=0x7fffdd98) at /home/marxin/Programming/gcc/gcc/toplev.c:2340
#17 0x0297caae in main (argc=22, argv=0x7fffdd98) at
/home/marxin/Programming/gcc/gcc/main.c:39
(gdb) p cfun
$1 = (function *) 0x0

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99334

--- Comment #7 from Jakub Jelinek  ---
#c6 reproduces even on current trunk with
-fno-tree-sink -O3 -fPIC -fomit-frame-pointer -fno-strict-aliasing
-mstackrealign

[Bug c++/99546] Weird return value of C++20 requires expression

[hewillk at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99546

--- Comment #4 from 康桓瑋  ---
same form, but this will trigger ICE:



struct S{
  constexpr static auto s = requires { []; };
};



:1:8: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in override_type_for_decl_p, at dwarf2out.c:23786
1 | struct S{
  |^
0x1cfa229 internal_error(char const*, ...)
???:0
0x67b5e5 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
???:0
0xf3666f rest_of_type_compilation(tree_node*, int)
???:0
0x70c969 finish_struct_1(tree_node*)
???:0
0x70e754 finish_struct(tree_node*, tree_node*)
???:0
0x8e121d c_parse_file()
???:0
0xa5f812 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/99563] [10 Regression] Code miscompilation caused by _mm256_zeroupper()

[andysem at mail dot ru via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99563

--- Comment #8 from andysem at mail dot ru ---
Thanks again.

[Bug testsuite/99636] [10 Regression] gcc.dg/strlenopt-80.c fails for 32 bits

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99636

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug testsuite/99626] [10 Regression] gcc.dg/strlenopt-73.c fails for 32 bits

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99626

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug target/99563] [10 Regression] Code miscompilation caused by _mm256_zeroupper()

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99563

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug target/99542] [9 Regression] ICE in exact_div, at poly-int.h:2219

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99542

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10 Regression] ICE in|[9 Regression] ICE in
   |exact_div, at   |exact_div, at
   |poly-int.h:2219 |poly-int.h:2219

--- Comment #10 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug ipa/99517] [10 Regression] __builtin_convertvector with casts

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99517

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug c++/99362] [10 Regression] invalid unused result

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99362

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug c/99324] [8/9 Regression] ICE in mark_addressable, at gimple-expr.c:918 since r6-314

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99324

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] ICE in  |[8/9 Regression] ICE in
   |mark_addressable, at|mark_addressable, at
   |gimple-expr.c:918 since |gimple-expr.c:918 since
   |r6-314  |r6-314

--- Comment #9 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug rtl-optimization/85099] [meta-bug] selective scheduling issues

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85099
Bug 85099 depends on bug 99085, which changed state.

Bug 99085 Summary: [10 Regression] ICE: verify_flow_info failed (error: 
multiple hot/cold transitions found)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99085

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug rtl-optimization/99085] [10 Regression] ICE: verify_flow_info failed (error: multiple hot/cold transitions found)

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99085

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug c++/95451] [8/9 regression] ICE for lambda capturing this and calling operator() since r8-2720-gf44a8dd56f5bfbd0

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95451

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10 regression] ICE for |[8/9 regression] ICE for
   |lambda capturing this and   |lambda capturing this and
   |calling operator() since|calling operator() since
   |r8-2720-gf44a8dd56f5bfbd0   |r8-2720-gf44a8dd56f5bfbd0

--- Comment #12 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug tree-optimization/99225] [8/9 Regression] ICE in wide_int_to_tree_1, at tree.c:1644

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99225

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] ICE in  |[8/9 Regression] ICE in
   |wide_int_to_tree_1, at  |wide_int_to_tree_1, at
   |tree.c:1644 |tree.c:1644

--- Comment #6 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug tree-optimization/99204] [8/9 Regression] ICE in fold_read_from_constant_string, at fold-const.c:15441

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99204

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] ICE in  |[8/9 Regression] ICE in
   |fold_read_from_constant_str |fold_read_from_constant_str
   |ing, at fold-const.c:15441  |ing, at fold-const.c:15441

--- Comment #10 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug ipa/99034] [9 Regression] error: EH landing pad label is not first in a sequence of labels in bb 6during GIMPLE pass: einline since r9-6254-gf86624d85f937e03

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99034

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10 Regression] error: EH |[9 Regression] error: EH
   |landing pad label  is   |landing pad label  is
   |not first in a sequence of  |not first in a sequence of
   |labels in bb 6during GIMPLE |labels in bb 6during GIMPLE
   |pass: einline since |pass: einline since
   |r9-6254-gf86624d85f937e03   |r9-6254-gf86624d85f937e03

--- Comment #9 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug sanitizer/99106] [9 Regression] ICE in tree_to_poly_int64, at tree.c:3091

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99106

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10 Regression] ICE in|[9 Regression] ICE in
   |tree_to_poly_int64, at  |tree_to_poly_int64, at
   |tree.c:3091 |tree.c:3091

--- Comment #5 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug tree-optimization/99079] [8/9 Regression] Maybe a wrong code since r6-1462-g4ab1e111ef0669bb

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99079

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] Maybe a |[8/9 Regression] Maybe a
   |wrong code since|wrong code since
   |r6-1462-g4ab1e111ef0669bb   |r6-1462-g4ab1e111ef0669bb

--- Comment #9 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug c++/97742] [10 Regression] endless loop with code reduced by creduce/cvise

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97742

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug c++/99033] [9 Regression] ICE in tree_to_poly_int64, at tree.c:3091

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99033

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10 Regression] ICE in|[9 Regression] ICE in
   |tree_to_poly_int64, at  |tree_to_poly_int64, at
   |tree.c:3091 |tree.c:3091

--- Comment #7 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug c++/99035] [9 Regression] ICE in declare_weak, at varasm.c:5930

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99035

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10 Regression] ICE in|[9 Regression] ICE in
   |declare_weak, at|declare_weak, at
   |varasm.c:5930   |varasm.c:5930

--- Comment #6 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug middle-end/99007] [8/9 Regression] ICE in dominated_by_p, at dominance.c:1124

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99007

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] ICE in  |[8/9 Regression] ICE in
   |dominated_by_p, at  |dominated_by_p, at
   |dominance.c:1124|dominance.c:1124

--- Comment #8 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug c++/97878] [8/9 Regression] ICE in cxx_eval_outermost_constant_expr, at cp/constexpr.c:6825

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97878

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] ICE in  |[8/9 Regression] ICE in
   |cxx_eval_outermost_constant |cxx_eval_outermost_constant
   |_expr, at   |_expr, at
   |cp/constexpr.c:6825 |cp/constexpr.c:6825

--- Comment #8 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug middle-end/97487] [8/9 Regression] ICE in expand_simple_binop, at optabs.c:939 since r8-3977

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97487

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] ICE in  |[8/9 Regression] ICE in
   |expand_simple_binop, at |expand_simple_binop, at
   |optabs.c:939 since r8-3977  |optabs.c:939 since r8-3977
   Target Milestone|10.3|8.5

--- Comment #8 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug middle-end/97971] [9 Regression] ICE in process_alt_operands, at lra-constraints.c:3110

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97971

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[9/10 Regression] ICE in|[9 Regression] ICE in
   |process_alt_operands, at|process_alt_operands, at
   |lra-constraints.c:3110  |lra-constraints.c:3110

--- Comment #6 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug rtl-optimization/98287] [10 Regression] ICE: in expand_expr_real_2, at expr.c:10000 with -O2 -fno-tree-ccp -fno-tree-forwprop

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98287

Jakub Jelinek  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #8 from Jakub Jelinek  ---
Fixed for 10.3 too.

[Bug c++/99677] [[gnu::const]] attribute does not prevent dead global variable gets emitted.

[unlvsur at live dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99677

--- Comment #4 from cqwrteur  ---
(In reply to Andrew Pinski from comment #3)
> I think this is a dup of bug 99456.

I do not think so because this has nothing to do with constexpr.

better @jakub to see whether he has some solutions.