[Bug tree-optimization/108091] '-Wformat-overflow' determines incorrect size when printing strings from an array of structs

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
(In reply to Connor Clark from comment #0)
> In the above example, I'd expect gcc to know that the values are never
> re-assigned

That is an incorrect expectation.  list is a global variable, so it could be
changed
from any other translation unit, e.g. from __attribute__((constructor)) code or
C++ constructor of a namespace variable.

Though yes, making it const or as in PR106559 a static array allows the
compiler to see it isn't changed and it does warn anyway.

[Bug ipa/106072] [13 Regression] Bogus -Wnonnull warning breaks rust bootstrap

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

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

--- Comment #12 from Iain Sandoe  ---
hmm:
  std::unique_ptr type = nullptr;
  if (lexer.peek_token ()->get_id () == COLON)
{
  lexer.skip_token ();

  // parse type, which is now required
  type = parse_type ();
  if (type == nullptr)
{
  Error error (lexer.peek_token ()->get_locus (),
   "failed to parse type in closure parameter");
  add_error (std::move (error));

  // skip somewhere?
  return AST::ClosureParam::create_error ();
}
}

if lexer.peek_token ()->get_id () != COLON, then type *will be* nullptr.
(I don't know the rust impl. at all so cannot tell whether that's syntactically
valid).

[Bug sanitizer/108085] gcc trunk's ASAN at -O3 missed a stack-use-after-scope

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

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Last reconfirmed||2022-12-14
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I can take a look.

Note I can't reproduce it with Clang with any of -O1+ options:

$ clang pr108085.c -fsanitize=address -w && ./a.out
=
==20150==ERROR: AddressSanitizer: stack-use-after-scope on address
0x75e00030 at pc 0x5566a2aa bp 0x7fffd510 sp 0x7fffd508
READ of size 4 at 0x75e00030 thread T0
#0 0x5566a2a9 in main pr108085.c
#1 0x77ca35af in __libc_start_call_main (/lib64/libc.so.6+0x275af)
(BuildId: 3f7f40d4302fa8a9568a057065c023bf137fceb7)
#2 0x77ca3678 in __libc_start_main@GLIBC_2.2.5
(/lib64/libc.so.6+0x27678) (BuildId: 3f7f40d4302fa8a9568a057065c023bf137fceb7)
#3 0x555a9d64 in _start
/home/abuild/rpmbuild/BUILD/glibc-2.36/csu/../sysdeps/x86_64/start.S:115

Address 0x75e00030 is located in stack of thread T0 at offset 48 in frame
#0 0x5566a11f in main pr108085.c

  This frame has 2 object(s):
[32, 36) 'd'
[48, 52) 'f' <== Memory access at offset 48 is inside 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-use-after-scope pr108085.c in main
Shadow bytes around the buggy address:
  0x10007ebb7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007ebb7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007ebb7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007ebb7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007ebb7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x10007ebb8000: f1 f1 f1 f1 04 f2[f8]f3 00 00 00 00 00 00 00 00
  0x10007ebb8010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007ebb8020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007ebb8030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007ebb8040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x10007ebb8050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
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
==20150==ABORTING

$ clang pr108085.c -fsanitize=address -w -O1 && ./a.out
(no output)

[Bug sanitizer/108085] gcc trunk's ASAN at -O3 missed a stack-use-after-scope

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

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

--- Comment #2 from Richard Biener  ---
I bet we unroll the loop and then elide f[] at -O3.

[Bug rtl-optimization/108086] internal compiler error: in set_accesses, at rtl-ssa/internals.inl:449

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-14
 CC||rsandifo at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
Confirmed with 12.2.0

during RTL pass: fwprop1
main.cpp: In function ‘int main()’:
main.cpp:230:1: internal compiler error: in set_accesses, at
rtl-ssa/internals.inl:449
0x6ca5e3 rtl_ssa::insn_info::set_accesses(rtl_ssa::access_info**, unsigned int,
unsigned int)
/space/rguenther/src/gcc-12-branch/gcc/rtl-ssa/internals.inl:449
0x6ca5e3 rtl_ssa::insn_info::set_accesses(rtl_ssa::access_info**, unsigned int,
unsigned int)
/space/rguenther/src/gcc-12-branch/gcc/rtl-ssa/internals.inl:444
0x6ca5e3 rtl_ssa::function_info::finish_insn_accesses(rtl_ssa::insn_info*)
/space/rguenther/src/gcc-12-branch/gcc/rtl-ssa/insns.cc:407
0x1b0cabc
rtl_ssa::function_info::start_block(rtl_ssa::function_info::build_info&,
rtl_ssa::bb_info*)
/space/rguenther/src/gcc-12-branch/gcc/rtl-ssa/blocks.cc:1022
0x1b0cb5f
rtl_ssa::function_info::bb_walker::before_dom_children(basic_block_def*)
/space/rguenther/src/gcc-12-branch/gcc/rtl-ssa/blocks.cc:129
0x195216e dom_walker::walk(basic_block_def*)
/space/rguenther/src/gcc-12-branch/gcc/domwalk.cc:309
0x1b0d871 rtl_ssa::function_info::process_all_blocks()
/space/rguenther/src/gcc-12-branch/gcc/rtl-ssa/blocks.cc:1252
0x1a83ba1 rtl_ssa::function_info::function_info(function*)
/space/rguenther/src/gcc-12-branch/gcc/rtl-ssa/functions.cc:50
0x1961033 fwprop_init
/space/rguenther/src/gcc-12-branch/gcc/fwprop.cc:906
0x1961033 fwprop
/space/rguenther/src/gcc-12-branch/gcc/fwprop.cc:976

we have

// Change the list of instruction accesses to ACCESSES, which contains
// NUM_DEFS definitions followed by NUM_USES uses.
inline void
insn_info::set_accesses (access_info **accesses,
 unsigned int num_defs, unsigned int num_uses)
{
  m_accesses = accesses;
  m_num_defs = num_defs;
  gcc_assert (num_defs == m_num_defs);

that's a strange assert ...

[Bug bootstrap/108092] libstdc++ and all other gcc libraries installed incorrectly installed $PREFIX/lib32 for crossback compilation

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build

--- Comment #2 from Richard Biener  ---
Please specify exactly how you configure the cross compiler from
x86_64-w64-mingw32 to x86_64-w64-mingw32

[Bug rtl-optimization/108086] internal compiler error: in set_accesses, at rtl-ssa/internals.inl:449

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

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

--- Comment #5 from Richard Biener  ---
Ick.

gcc/rtl-ssa/insns.h:  unsigned int m_num_defs : 16;

(gdb) p num_defs
$1 = 86149
(gdb) p m_num_defs
$2 = 20613

(gdb) p m_rtl
$3 = (rtx_insn *) 0x0
(gdb) p is_phi ()
$4 = false
(gdb) p is_bb_head ()
$5 = false
(gdb) p is_artificial ()
$7 = true

m_bb is for ENTRY and for some reason that has a very big live-out bitmap?!

There might be a conservative way to handle this and not blow up where
it does right now?

[Bug rust/108087] -Wodr warnings in rust/rust-lang.cc (lang_type)

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org
   Last reconfirmed||2022-12-14
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
Yes, I think it's a real issue.

[Bug ipa/106072] [13 Regression] Bogus -Wnonnull warning breaks rust bootstrap

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #13 from Jakub Jelinek  ---
No, that is not the problem.
The problem is solely in the:
  return AST::ClosureParam (std::move (pattern), pattern->get_locus (),
std::move (type), std::move (outer_attrs));
line.
pattern is a unique_ptr, std::move (pattern) will:
  _GLIBCXX23_CONSTEXPR
  __uniq_ptr_impl(__uniq_ptr_impl&& __u) noexcept
  : _M_t(std::move(__u._M_t))
  { __u._M_ptr() = nullptr; }
and so once std::move (pattern) is done, pattern is nullptr.  And then it calls
pattern->get_locus (), already on the nullptr.

[Bug c++/108093] New: Quadratic error lines printed with missing include for template

[denis.campredon at gmail dot com via Gcc-bugs]

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

Bug ID: 108093
   Summary: Quadratic error lines printed with missing include for
template
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.campredon at gmail dot com
  Target Milestone: ---

Compiled with -std=c++20, who has only missing includes, the following code
prints way too much lines of error.
Adding or removing one template level drastically changes the number or error
lines.


using namespace std;
vector>> foo;



with std=c++17 only one line is printed :
'vector' does not name a type

Ideally, both invocations should print 1 error per unknown type and add
fix-hints for the missing includes.

[Bug sanitizer/108094] New: gcc trunk's ASAN at -O2 and above did not report a stack-use-after-return

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 108094
   Summary: gcc trunk's ASAN at -O2 and above did not report a
stack-use-after-return
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

ASAN at -O0/1 reported the stack-use-after-return bug, however -O2 and above
only reported SEGV. I checked the pointer addresses and noted this may due to
over-optimization of UB behavior, i.e., variable a is optimized to NULL. Not
sure if this is an issue or not.

Clang can detect it at all optimization levels.

Compiler explorer: https://godbolt.org/z/bYPxe31Mx

% cat a.c
int *a;
int d;
int *e() {
  int b[1]={0};
  __builtin_printf("&b[0]=%p\n", &b[0]);
  int *c = &b[0];
  __builtin_printf("c=%p\n", c);
  return c;
}
int main() {
  a = e();
  __builtin_printf("a=%p\n", a);
  d = *a;
  return d;
}
% gcc-tk -O0 -fsanitize=address a.c -g
% AN_OPTIONS=detect_stack_use_after_return=1 ./a.out 
&b[0]=0x7fe7cc20
c=0x7fe7cc20
a=0x7fe7cc20
=
==1645405==ERROR: AddressSanitizer: stack-use-after-return on address
0x7fe7cc20 at pc 0x00401325 bp 0x7ffe8e2fe990 sp 0x7ffe8e2fe988
READ of size 4 at 0x7fe7cc20 thread T0
#0 0x401324 in main /a.c:13
#1 0x7fe7cea78082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x4010dd in _start (/a.out+0x4010dd)

Address 0x7fe7cc20 is located in stack of thread T0 at offset 32 in frame
#0 0x4011a5 in e /a.c:3

  This frame has 1 object(s):
[32, 36) 'b' (line 4) <== Memory access at offset 32 is inside this
variable
...
%
% gcc-tk -O2 -fsanitize=address a.c -g
% AN_OPTIONS=detect_stack_use_after_return=1 ./a.out 
&b[0]=0x7f3f2a100020
c=0x7f3f2a100020
a=(nil)
AddressSanitizer:DEADLYSIGNAL
=
==1885716==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x00401107 bp 0x sp 0x7fff49942b00 T0)
==1885716==The signal is caused by a READ memory access.
==1885716==Hint: address points to the zero page.
#0 0x401107 in main /a.c:13
#1 0x7f3f2cb26082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#2 0x40117d in _start (/a.out+0x40117d)
...
%

[Bug rust/106072] [13 Regression] Bogus -Wnonnull warning breaks rust bootstrap

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

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

--- Comment #14 from Jakub Jelinek  ---
Created attachment 54084
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54084&action=edit
gcc13-pr106072.patch

Untested fix.

[Bug tree-optimization/108095] New: powerpc-linux / powerpc64-linux: ICEs when building Linux's arch/powerpc/kernel/align.c (asm goto)

[jbglaw--- via Gcc-bugs]

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

Bug ID: 108095
   Summary: powerpc-linux / powerpc64-linux: ICEs when building
Linux's arch/powerpc/kernel/align.c (asm goto)
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jbg...@lug-owl.de
  Target Milestone: ---

Created attachment 54085
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54085&action=edit
Minimized testcase

For a number of ppc32 builds (using various Linux kernel defconfig
configurations) as well as for one 64bit build, I get these:

[mk all 2022-12-11 21:36:22]   powerpc64-linux-gcc
-Wp,-MMD,arch/powerpc/kernel/.align.o.d -nostdinc -I./arch/powerpc/include
-I./arch/powerpc/include/generated  -I./include -I./arch/powerpc/include/uapi
-I./arch/powerpc/include/generated/uapi -I./include/uapi
-I./include/generated/uapi -include ./include/linux/compiler-version.h -include
./include/linux/kconfig.h -include ./include/linux/compiler_types.h
-D__KERNEL__ -I ./arch/powerpc -DHAVE_AS_ATHIGH=1 -fmacro-prefix-map=./= -Wall
-Wundef -Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -fshort-wchar -fno-PIE -Werror=implicit-function-declaration
-Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu11
-mbig-endian -m64 -msoft-float -pipe -mtraceback=no -mabi=elfv1 -mcall-aixdesc
-mcmodel=medium -mno-pointers-to-nested-functions -mcpu=cell -mno-prefixed
-mno-pcrel -mno-altivec -mno-vsx -mno-mma -fno-asynchronous-unwind-tables
-mno-string -Wa,-maltivec -Wa,-mpower4 -Wa,-many -mabi=elfv1 -mcall-aixdesc
-mbig-endian -mstack-protector-guard=tls -mstack-protector-guard-reg=r13
-fno-delete-null-pointer-checks -Wno-frame-address -Wno-format-truncation
-Wno-format-overflow -Wno-address-of-packed-member -Os
-fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong
-Wno-main -Wno-unused-but-set-variable -Wno-unused-const-variable
-Wno-dangling-pointer -fomit-frame-pointer -ftrivial-auto-var-init=zero
-fno-stack-clash-protection -Wdeclaration-after-statement -Wvla
-Wno-pointer-sign -Wcast-function-type -Wno-stringop-truncation
-Wno-stringop-overflow -Wno-restrict -Wno-maybe-uninitialized
-Wno-alloc-size-larger-than -Wimplicit-fallthrough=5 -fno-strict-overflow
-fno-stack-check -fconserve-stack -Werror=date-time
-Werror=incompatible-pointer-types -Werror=designated-init
-Wno-packed-not-aligned -g -mstack-protector-guard-offset=752 -Werror   
-DKBUILD_MODFILE='"arch/powerpc/kernel/align"' -DKBUILD_BASENAME='"align"'
-DKBUILD_MODNAME='"align"' -D__KBUILD_MODNAME=kmod_align -c -o
arch/powerpc/kernel/align.o arch/powerpc/kernel/align.c  
[mk all 2022-12-11 21:36:23] during GIMPLE pass: ccp
[mk all 2022-12-11 21:36:23] arch/powerpc/kernel/align.c: In function
'__copy_inst_from_kernel_nofault':
[mk all 2022-12-11 21:36:23] arch/powerpc/kernel/align.c:364:1: internal
compiler error: in maybe_register_def, at tree-into-ssa.cc:1948
[mk all 2022-12-11 21:36:23]   364 | }
[mk all 2022-12-11 21:36:23]   | ^
[mk all 2022-12-11 21:36:23] 0x19f12c6 internal_error(char const*, ...)
[mk all 2022-12-11 21:36:23]???:0
[mk all 2022-12-11 21:36:23] 0x7be8e0 fancy_abort(char const*, int, char
const*)
[mk all 2022-12-11 21:36:23]???:0
[mk all 2022-12-11 21:36:23] 0x17a985e dom_walker::walk(basic_block_def*)
[mk all 2022-12-11 21:36:23]???:0
[mk all 2022-12-11 21:36:23] 0xe99460 update_ssa(unsigned int)
[mk all 2022-12-11 21:36:23]???:0
[mk all 2022-12-11 21:36:23] 0x1041df9 execute_update_addresses_taken()
[mk all 2022-12-11 21:36:23]???:0
[mk all 2022-12-11 21:36:23] Please submit a full bug report, with preprocessed
source (by using -freport-bug).
[mk all 2022-12-11 21:36:23] Please include the complete backtrace with any bug
report.
[mk all 2022-12-11 21:36:23] See  for instructions.


This seems to be also an asm goto issue, but it is _not_ fixed with the
7676235f690e624b7e commit. (This issue can still be reproduced with
2dc5d6b1e7e.)

Minimum command line to produce the ICE is: `powerpc64-linux-gcc -Os -g -c -o
align.o align.i`. Removing either `-Os` or `-g` silences it.

[Bug sanitizer/108094] gcc trunk's ASAN at -O2 and above did not report a stack-use-after-return

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

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

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Martin Liška  ---
gcc pr108094.c -g -Wall -Werror -O2
pr108094.c: In function ‘e’:
pr108094.c:8:10: error: function returns address of local variable
[-Werror=return-local-addr]
8 |   return c;
  |  ^
pr108094.c:4:7: note: declared here
4 |   int b[1]={0};
  |   ^
cc1: all warnings being treated as errors

The warning is quite obvious and should not be ignored.

[Bug rust/108087] -Wodr warnings in rust/rust-lang.cc (lang_type)

[arthur.cohen at embecosm dot com via Gcc-bugs]

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

Arthur Cohen  changed:

   What|Removed |Added

 CC||arthur.cohen at embecosm dot 
com

--- Comment #4 from Arthur Cohen  ---
Thanks everyone, this is indeed a real issue and a mishap on our part. It's due
to our const evaluator, which was ported over from the C++ frontend, defining
another lang_type struct similar to what is the C++ one. I'm working on fixing
it. I've opened up https://github.com/Rust-GCC/gccrs/issues/1702 and will
report progress

[Bug bootstrap/108092] libstdc++ and all other gcc libraries installed incorrectly installed $PREFIX/lib32 for crossback compilation

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #3 from cqwrteur  ---
Created attachment 54086
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54086&action=edit
here is my build script

[Bug bootstrap/108092] libstdc++ and all other gcc libraries installed incorrectly installed $PREFIX/lib32 for crossback compilation

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #4 from cqwrteur  ---
(In reply to Richard Biener from comment #2)
> Please specify exactly how you configure the cross compiler from
> x86_64-w64-mingw32 to x86_64-w64-mingw32

from x86_64-pc-linux-gnu to x86_64-w64-mingw32 to x86_64-pc-linux-gnu

[Bug tree-optimization/108095] powerpc-linux / powerpc64-linux: ICEs when building Linux's arch/powerpc/kernel/align.c (asm goto)

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
> 
> This seems to be also an asm goto issue, but it is _not_ fixed with the
> 7676235f690e624b7e commit. (This issue can still be reproduced with
> 2dc5d6b1e7e.)

g:7676235f690e624b7e
g:2dc5d6b1e7e

[Bug bootstrap/108092] libstdc++ and all other gcc libraries installed incorrectly installed $PREFIX/lib32 for crossback compilation

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #5 from cqwrteur  ---
Created attachment 54087
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54087&action=edit
no it should be this one

crossback sh

[Bug tree-optimization/108095] powerpc-linux / powerpc64-linux: ICEs when building Linux's arch/powerpc/kernel/align.c (asm goto)

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-12-14

--- Comment #2 from Martin Liška  ---
Confirmed.

[Bug bootstrap/108092] libstdc++ and all other gcc libraries installed incorrectly installed $PREFIX/lib32 for crossback compilation

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #6 from cqwrteur  ---
(In reply to Andrew Pinski from comment #1)
> Why do you not use a sysroot?

sysroot messed up even worse for crossback compilation

[Bug rust/108084] AArch64 Linux bootstrap failure in rust

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||gcc-rust at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org
   Keywords|diagnostic  |
  Component|c++ |rust
   See Also|https://gcc.gnu.org/bugzill |
   |a/show_bug.cgi?id=106072|

--- Comment #9 from Thomas Schwinge  ---
Per PR106072, this actually is a GCC/Rust issue, not C++ diagnostic.

[Bug tree-optimization/108095] powerpc-linux / powerpc64-linux: ICEs when building Linux's arch/powerpc/kernel/align.c (asm goto)

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Started with r11-5002-ge3b3b59683c1e7, where it was rejected before the
revision:

/tmp/ice.i: In function ‘__copy_inst_from_kernel_nofault’:
/tmp/ice.i:5:16: error: expected ‘:’ before string constant
5 |   asm goto("" : "=r"(*(u32 *)&suffix) : : : Efault);

[Bug rust/106072] [13 Regression] -Wnonnull warning breaks rust bootstrap

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   See Also||https://github.com/Rust-GCC
   ||/gccrs/pull/1619
 CC||tschwinge at gcc dot gnu.org
 Blocks|95507   |
Summary|[13 Regression] Bogus   |[13 Regression] -Wnonnull
   |-Wnonnull warning breaks|warning breaks rust
   |rust bootstrap  |bootstrap
   Keywords|diagnostic  |

--- Comment #15 from Thomas Schwinge  ---
Thanks, Jakub!

So, an actual GCC/Rust issue, not PR95507 "(Wnonnull) - [meta-bug]
bogus/missing -Wnonnull".


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507
[Bug 95507] [meta-bug] bogus/missing -Wnonnull

[Bug sanitizer/108094] gcc trunk's ASAN at -O2 and above did not report a stack-use-after-return

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

--- Comment #2 from Li Shaohua  ---
(In reply to Martin Liška from comment #1)
> gcc pr108094.c -g -Wall -Werror -O2
> pr108094.c: In function ‘e’:
> pr108094.c:8:10: error: function returns address of local variable
> [-Werror=return-local-addr]
> 8 |   return c;
>   |  ^
> pr108094.c:4:7: note: declared here
> 4 |   int b[1]={0};
>   |   ^
> cc1: all warnings being treated as errors
> 
> The warning is quite obvious and should not be ignored.

So there is indeed a stack-use-after-return, but gcc's ASAN just does not
report it at -O2?

[Bug sanitizer/108094] gcc trunk's ASAN at -O2 and above did not report a stack-use-after-return

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

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

--- Comment #3 from Martin Liška  ---
The compiler optimizes it out as it's UBSAN and provides you a reasonable
warning.

[Bug tree-optimization/107997] [10/11/12/13 Regression] r13-4389-gfd8dd6c0384969 probably uncovered an issue building the Linux kernel

[jbglaw--- via Gcc-bugs]

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

Jan-Benedict Glaw  changed:

   What|Removed |Added

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

--- Comment #12 from Jan-Benedict Glaw  ---
Fixed with that commit. There is a similar unrelated (PR108095), but that's got
its own ticket.

[Bug rust/106072] [13 Regression] -Wnonnull warning breaks rust bootstrap

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

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

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

https://gcc.gnu.org/g:95dc11475dac06b5eecd904079de8aa94827a36a

commit r13-4697-g95dc11475dac06b5eecd904079de8aa94827a36a
Author: Jakub Jelinek 
Date:   Wed Dec 14 11:35:22 2022 +0100

rust: Fix up aarch64-linux bootstrap [PR106072]

Bootstrap fails on aarch64-linux and some other arches with:
.../gcc/rust/parse/rust-parse-impl.h: In member function
âRust::AST::ClosureParam
Rust::Parser::parse_closure_param() [with
ManagedTokenSource = Rust::Lexer]â:
.../gcc/rust/parse/rust-parse-impl.h:8916:49: error: âthisâ pointer is
null [-Werror=nonnull]
The problem is that while say on x86_64-linux the side-effects in the
arguments are evaluated from last argument to first, on aarch64-linux
it is the other way around, from first to last.  The C++ I believe even
in C++17 makes the evaluation of those side-effects unordered
(indeterminately sequenced with no interleaving), so that is fine.
But, when the call in return statement is evaluated from first to
last, std::move (pattern) happens before pattern->get_locus () and
the former will make pattern (std::unique_ptr) a wrapper object around
nullptr, so dereferencing it later to call get_locus () on it is invalid.

2022-12-14  Jakub Jelinek  

PR rust/106072
* parse/rust-parse-impl.h (parse_closure_param): Store
pattern->get_locus () in a temporary before std::move (pattern) is
invoked.

[Bug rtl-optimization/108086] internal compiler error: in set_accesses, at rtl-ssa/internals.inl:449

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

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

--- Comment #6 from Martin Liška  ---
Starts with r11-6188-g0b76990a9d75d97b. It's almost impossible to reduce the
test-case as it depends on always_inline :/

[Bug c++/108096] New: [13 regression] libreoffice build failure #2

[manuel.lauss at googlemail dot com via Gcc-bugs]

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

Bug ID: 108096
   Summary: [13 regression] libreoffice build failure #2
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manuel.lauss at googlemail dot com
  Target Milestone: ---

Created attachment 54088
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54088&action=edit
comrpessed preprocessed source

This is a followup to PR108071.

With todays gcc-trunk (g:693638252aae9b36b5b928d7195df6d28bf409d7), libreoffice
build fails with another new error:

# g++ -c backupfilehelper.i
backupfilehelper.i: In instantiation of 'constexpr bool
std::__check_constructible() [with _ValueType = rtl::OUString; _Tp = const
char* const&]':
backupfilehelper.i:25254:119:   required from '_ForwardIterator
std::uninitialized_copy(_InputIterator, _InputIterator, _ForwardIterator) [with
_InputIterator = const char* const*; _ForwardIterator = rtl::OUString*]'
backupfilehelper.i:25380:37:   required from '_ForwardIterator
std::__uninitialized_copy_a(_InputIterator, _InputIterator, _ForwardIterator,
allocator<_Tp>&) [with _InputIterator = const char* const*; _ForwardIterator =
rtl::OUString*; _Tp = rtl::OUString]'
backupfilehelper.i:40712:33:   required from 'void std::vector<_Tp,
_Alloc>::_M_range_initialize(_ForwardIterator, _ForwardIterator,
std::forward_iterator_tag) [with _ForwardIterator = const char* const*; _Tp =
rtl::OUString; _Alloc = std::allocator]'
backupfilehelper.i:40361:23:   required from 'std::vector<_Tp,
_Alloc>::vector(_InputIterator, _InputIterator, const allocator_type&) [with
_InputIterator = const char* const*;  = void; _Tp =
rtl::OUString; _Alloc = std::allocator; allocator_type =
std::allocator]'
backupfilehelper.i:62388:9:   required from here
backupfilehelper.i:25201:56: error: static assertion failed: result type must
be constructible from input type
25201 |   static_assert(is_constructible<_ValueType, _Tp>::value,
  |^
backupfilehelper.i:25201:56: note: 'std::integral_constant::value'
evaluates to false


The offending code is:

const std::vector< OUString >& f()
{
static std::vector< OUString > aDirNames =
{
"config",
"registry",
"psprint",
"store",
"temp",
"pack"
};
return aDirNames;
}


Find attached the compressed preprocessed source.

Thank you!
 Manuel

[Bug c++/108096] [13 regression] libreoffice build failure #2 since r13-4564

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2022-12-14
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||redi at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
Summary|[13 regression] libreoffice |[13 regression] libreoffice
   |build failure #2|build failure #2 since
   ||r13-4564
   Priority|P3  |P1
   Target Milestone|--- |13.0

--- Comment #1 from Jakub Jelinek  ---
This one started with r13-4564-gd081807d8d70e3e87eae41e1560e54d503f4d465

[Bug c++/108096] [13 regression] libreoffice build failure #2 since r13-4564

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

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

--- Comment #2 from Jonathan Wakely  ---
Similar problem to PR 108071. The OUString type can only be constructed from
char(&)[N] and const char(&)[N], not from const char*. The original code
constructs initializer_list and so each element is initialized
directly from an array. The new code decays the arrays to
initializer_list and then fails to construct OUString objects from
const char* const values.

[Bug c++/108096] [13 regression] libreoffice build failure #2 since r13-4564

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

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

--- Comment #3 from Jonathan Wakely  ---
Reduced:

#include 

template struct enable_if { };
template<> struct enable_if { using type = void; };

template constexpr bool is_array_v = false;
template constexpr bool is_array_v = true;

struct OUString
{
  template>::type>
  OUString(T&) { }
};

struct vector
{
  vector(std::initializer_list) { }
  template
  vector(Iter i, Iter j) { if (i != j) OUString(*i); }
};

vector v = { "" };

[Bug tree-optimization/108095] powerpc-linux / powerpc64-linux: ICEs when building Linux's arch/powerpc/kernel/align.c (asm goto)

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

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

--- Comment #4 from Jakub Jelinek  ---
Slightly cleaned up, ICEs also on x86_64-linux, -Os -g:
int v;
typedef unsigned T;

void
foo (void)
{
  unsigned s;
  asm goto ("" : "=r" (*(T *) &s) : : : lab);
  v = 0;
lab:
}

[Bug libstdc++/108097] New: std::stacktrace AddressSanitizer: new-delete-type-mismatch on 0x615000000080 in thread T0

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 108097
   Summary: std::stacktrace AddressSanitizer:
new-delete-type-mismatch on 0x61500080 in thread
T0
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 54089
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54089&action=edit
stacktrace sanitizer stderr

I try to crossback compiling stacktrace from windows to linux
D:\hg\fast_io\.wunao>x86_64-pc-linux-gnu-g++ -o stacktrace stacktrace.cc -Ofast
-std=c++23 -g -march=native -I../include -lstdc++_libbacktrace
-fsanitize=address,undefined

$ ./stacktrace 2>err.txt
 at D:\hg\fast_io\.wunao/stacktrace.cc:6
 at :0
 at :0
 at :0

[Bug libstdc++/108097] std::stacktrace AddressSanitizer: new-delete-type-mismatch on 0x615000000080 in thread T0

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
#include
#include

int main()
{
for(auto const & e : std::stacktrace::current())
{
println(std::to_string(e));
}
}

[Bug libstdc++/108097] std::stacktrace AddressSanitizer: new-delete-type-mismatch on 0x615000000080 in thread T0

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #2 from cqwrteur  ---
(In reply to cqwrteur from comment #1)
> #include
> #include
> 
> int main()
> {
>   for(auto const & e : std::stacktrace::current())
>   {
>   println(std::to_string(e));
>   }
> }

btw windows support for std::stacktrace when? libbacktrace does support Windows
but libstdc++ does not.

[Bug libstdc++/108097] std::stacktrace AddressSanitizer: new-delete-type-mismatch on 0x615000000080 in thread T0

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to cqwrteur from comment #1)
> #include

Please provide testcases that don't depend on your own headers. There's
absolutely no reason this can't use printf or std::cout.

Asan is wrong, operator delete(void*, size_t) can be used to delete memory from
operator new(size_t, nothrow_t).

[Bug libstdc++/108097] std::stacktrace AddressSanitizer: new-delete-type-mismatch on 0x615000000080 in thread T0

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to cqwrteur from comment #2)
> btw windows support for std::stacktrace when? libbacktrace does support
> Windows but libstdc++ does not.

There are patches posted for review.

[Bug libgomp/108098] New: OpenMP/nvptx reverse offload execution test FAILs

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

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

Bug ID: 108098
   Summary: OpenMP/nvptx reverse offload execution test FAILs
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org,
vries at gcc dot gnu.org
  Target Milestone: ---

With commit r13-4593-gea4b23d9c82d9be3b982c3519fe5e8e9d833a6a8 "libgomp: Handle
OpenMP's reverse offloads", I'm seeing PASSes for a number of testing
configurations (see below), but regressions/FAILs on others:

PASS: libgomp.c/../libgomp.c-c++-common/reverse-offload-1.c (test for
excess errors)
[-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/reverse-offload-1.c
execution test

libgomp: cuCtxSynchronize error: unspecified launch failure (perhaps abort
was called)

Or:

libgomp: cuCtxSynchronize error: an illegal instruction was encountered

Same for C++.

PASS: libgomp.c/../libgomp.c-c++-common/reverse-offload-2.c (test for
excess errors)
[-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/reverse-offload-2.c
execution test

libgomp: cuModuleGetFunction error: named symbol not found

Same for C++.

PASS: libgomp.fortran/reverse-offload-1.f90   -O0  (test for excess errors)
[-PASS:-]{+FAIL:+} libgomp.fortran/reverse-offload-1.f90   -O0  execution
test

STOP 2

libgomp: cuCtxSynchronize error: unspecified launch failure (perhaps abort
was called)

Or:

libgomp: cuCtxSynchronize error: an illegal instruction was encountered

Same for other torture testing flags.

..., and for the new test cases:

+PASS: libgomp.fortran/reverse-offload-2.f90   -O  (test for excess errors)
+FAIL: libgomp.fortran/reverse-offload-2.f90   -O  execution test

+PASS: libgomp.fortran/reverse-offload-3.f90   -O  (test for excess errors)
+FAIL: libgomp.fortran/reverse-offload-3.f90   -O  execution test

+PASS: libgomp.fortran/reverse-offload-4.f90   -O  (test for excess errors)
+FAIL: libgomp.fortran/reverse-offload-4.f90   -O  execution test

+PASS: libgomp.fortran/reverse-offload-5.f90   -O  (test for excess errors)
+XFAIL: libgomp.fortran/reverse-offload-5.f90   -O  execution test

+PASS: libgomp.fortran/reverse-offload-5a.f90   -O  (test for excess
errors)
+FAIL: libgomp.fortran/reverse-offload-5a.f90   -O  execution test

These fail with different host-side or device-side STOP codes.

I haven't analyzed further.

That's with standard option on a system with:

$ nvidia-smi
[...]
| NVIDIA-SMI 440.33.01Driver Version: 440.33.01CUDA Version: 10.2
[...]
|   0  Tesla K80  [...]
[...]
|   1  Tesla K80  [...]

... as well as (separately tested):

|   2  GeForce GTX 1080  [...]

..., and with '-foffload-options=nvptx-none=-mptx=3.1' on a system with:

$ nvidia-smi
[...]
| NVIDIA-SMI 361.93.02  Driver Version: 361.93.02
[...]
|   0  Tesla K20c  [...]

These test cases PASS on a system with:

$ nvidia-smi
[...]
| NVIDIA-SMI 455.38   Driver Version: 455.38   CUDA Version: 11.1
[...]
|   0  Tesla K20c  [...]

... as well as (separately tested):

|   1  Tesla K40c  [...]

..., and:

$ nvidia-smi
[...]
| NVIDIA-SMI 455.23.05Driver Version: 455.23.05CUDA Version: 11.1
[...]
|   0  TITAN V  [...]

Is maybe CUDA 11 (or rather, corresponding Nvidia Driver version) a hard
requirement, and if yes, how to deal with that?

[Bug libstdc++/108097] std::stacktrace AddressSanitizer: new-delete-type-mismatch on 0x615000000080 in thread T0

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #5 from cqwrteur  ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to cqwrteur from comment #1)
> > #include
> 
> Please provide testcases that don't depend on your own headers. There's
> absolutely no reason this can't use printf or std::cout.
> 
> Asan is wrong, operator delete(void*, size_t) can be used to delete memory
> from operator new(size_t, nothrow_t).

#include
#include

int main()
{
for(auto const & e : std::stacktrace::current())
{
std::cout<

[Bug libstdc++/108097] std::stacktrace AddressSanitizer: new-delete-type-mismatch on 0x615000000080 in thread T0

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #6 from cqwrteur  ---
> > Please provide testcases that don't depend on your own headers. There's
> > absolutely no reason this can't use printf or std::cout.

std::cout and stdio bloat my binary.

[Bug libstdc++/108097] std::stacktrace AddressSanitizer: new-delete-type-mismatch on 0x615000000080 in thread T0

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to cqwrteur from comment #5)
> Still crashing by replacing with std::cout

Yes, of course, which is why you should have used that in the first place. Your
own fast_io.h is irrelevant to the problem.

(In reply to cqwrteur from comment #6)
> std::cout and stdio bloat my binary.

Yes, I know, you never stop going on about it. You don't need to optimize the
binary size of reproducers posted in bugzilla though, do you? The point should
be to demonstrate the problem effectively, not minimise binary size.

Nobody is going to download your fast_io.h to reproduce a bug.

[Bug c++/108099] New: ICE when parsing signed __int128_t typedef

[moritz.klammler at cetitec dot com via Gcc-bugs]

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

Bug ID: 108099
   Summary: ICE when parsing signed __int128_t typedef
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: moritz.klammler at cetitec dot com
  Target Milestone: ---

There seems to be a problem in the parser regarding typedefs involving
__int128_t prefixed with the signed keyword.

$ cat test.ii
using i128 = signed __int128_t;

$ g++ -v -c test.ii
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/cc1plus -fpreprocessed test.ii -quiet
-dumpbase test.ii -dumpbase-ext .ii -mtune=generic -march=x86-64 -version -o
/tmp/ccn4pU5h.s
GNU C++17 (GCC) version 12.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version isl-0.25-GMP

warning: MPFR header version 4.1.0-p13 differs from library version 4.1.1-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (GCC) version 12.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version isl-0.25-GMP

warning: MPFR header version 4.1.0-p13 differs from library version 4.1.1-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 402ce889a414e2a3abbbe3146fa0a6cb
test.ii:1:21: internal compiler error: Segmentation fault
1 | using i128 = signed __int128_t;
  | ^~
0x19eab38 internal_error(char const*, ...)
???:0
0x6f5f81 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
???:0
0x6fc532 groktypename(cp_decl_specifier_seq*, cp_declarator const*, bool)
???:0
0x7c7a9c c_parse_file()
???:0
0x8dcedd c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

Interestingly, std::make_signed_t<__int128_t> is compiled fine.

I have also tried a few variations in C and while a similar issue seems to
exist, no segfault happened.

$ cat test.i
typedef unsigned __int128_t number;
typedef   signed __int128_t number;

$ gcc -v -c test.i
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-build-config=bootstrap-lto --with-linker-hash-style=gnu
--with-system-zlib --enable-__cxa_atexit --enable-cet=auto
--enable-checking=release --enable-clocale=gnu --enable-default-pie
--enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object
--enable-libstdcxx-backtrace --enable-link-serialization=1
--enable-linker-build-id --enable-lto --enable-multilib --enable-plugin
--enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-werror
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/12.2.0/cc1 -fpreprocessed test.i -quiet
-dumpbase test.i -dumpbase-ext .i -mtune=generic -march=x86-64 -version -o
/tmp/ccdh1Nyr.s
GNU C17 (GCC) version 12.2.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 12.2.0, GMP version 6.2.1, MPFR version
4.1.0-p13, MPC version 1.2.1, isl version isl-0.25-GMP

warning: MPFR header version 4.1.0-p13 differs from library version 4.1.1-p1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 12.2.0 (x

[Bug libstdc++/108097] std::stacktrace AddressSanitizer: new-delete-type-mismatch on 0x615000000080 in thread T0

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-12-14

--- Comment #8 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #3)
> Asan is wrong, operator delete(void*, size_t) can be used to delete memory
> from operator new(size_t, nothrow_t).

Oh it's complaining about the size, not the form of operator delete.

[Bug libstdc++/108097] std::stacktrace AddressSanitizer: new-delete-type-mismatch on 0x615000000080 in thread T0

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

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

--- Comment #9 from Jonathan Wakely  ---
--- a/libstdc++-v3/include/std/stacktrace
+++ b/libstdc++-v3/include/std/stacktrace
@@ -608,8 +608,8 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
  if constexpr (is_same_v>)
{
- __n *= sizeof(value_type);
- void* const __p = _GLIBCXX_OPERATOR_NEW (__n, nothrow_t{});
+ size_t __n2 = __n * sizeof(value_type);
+ void* const __p = _GLIBCXX_OPERATOR_NEW (__n2, nothrow_t{});
  if (__p == nullptr) [[unlikely]]
return nullptr;
  _M_frames = static_cast(__p);

[Bug analyzer/108100] New: GCC Static Analyzer does not know "(a || b) == true" in the true branch of "if (a || b) "

[geoffreydgr at icloud dot com via Gcc-bugs]

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

Bug ID: 108100
   Summary: GCC Static Analyzer does not know "(a || b) == true"
in the true branch of "if (a || b) "
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: geoffreydgr at icloud dot com
  Target Milestone: ---

I found a problem that GCC static analyzer does not know "(a||b) == true" in
the true branch of "if (a || b) "，and takes the 'true' branch of `if (!a)` and
the 'true' branch of `if (!b)` at the same time  (which is contradictory),
resulting in the wrong report of NPD warning. 
I think GCC Static Analyer may not handle '||' operator well. Please take a
look.

I run gcc (trunk) with options `-fanalyzer -O0`
https://godbolt.org/z/4Y41j1GfW

Input:
```c
#include 

int foo(bool a, bool b) {
int *c = 0;
int *d = 0;
if (a || b){
__analyzer_eval(a);
__analyzer_eval(b);
__analyzer_eval(a||b);
__analyzer_eval((a||b) == true);

if (!a){
if (!b){
__analyzer_eval(a||b);
*d = 0;
}
}
}
}

```
Output:
```bash
: In function 'foo':
:7:9: warning: implicit declaration of function '__analyzer_eval'
[-Wimplicit-function-declaration]
7 | __analyzer_eval(a);
  | ^~~
:7:9: warning: UNKNOWN
7 | __analyzer_eval(a);
  | ^~
:8:9: warning: UNKNOWN
8 | __analyzer_eval(b);
  | ^~
:9:9: warning: UNKNOWN
9 | __analyzer_eval(a||b);
  | ^
:10:9: warning: UNKNOWN
   10 | __analyzer_eval((a||b) == true);
  | ^~~
:14:17: warning: UNKNOWN
   14 | __analyzer_eval(a||b);
  | ^
:15:20: warning: dereference of NULL 'd' [CWE-476]
[-Wanalyzer-null-dereference]
   15 | *d = 0;
  | ~~~^~~
  'foo': events 1-7
|
|4 | int *c = 0;
|  |  ^
|  |  |
|  |  (1) 'c' is NULL
|5 | int *d = 0;
|  |  ~
|  |  |
|  |  (2) 'c' is NULL
|..
|   12 | if (!a){
|  |~
|  ||
|  |(3) following 'true' branch...
|   13 | if (!b){
|  |~~~
|  |||
|  ||(4) ...to here
|  |(5) following 'true' branch...
|   14 | __analyzer_eval(a||b);
|  | ~
|  | |
|  | (6) ...to here
|   15 | *d = 0;
|  | ~~
|  ||
|  |(7) dereference of NULL 'd'
|
Compiler returned: 0
```

[Bug c++/108099] ICE when parsing signed __int128_t typedef

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

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

--- Comment #1 from Jonathan Wakely  ---
__int128_t is already a typedef, so you can't add a signed or unsigned
qualifier to it.

std::make_signed_t<__int128_t> works because that doesn't just add the 'signed'
keyword to it.

The keyword for the type is __int128 not __int128_t, so you can say signed
__int128 and unsigned __int128.

[Bug c++/108099] ICE when parsing signed __int128_t typedef

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||ice-on-invalid-code
   Last reconfirmed||2022-12-14
 Status|UNCONFIRMED |NEW

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> __int128_t is already a typedef, so you can't add a signed or unsigned
> qualifier to it.

i.e. the same reason this doesn't work:

using I = int;
signed I i = 0;

> std::make_signed_t<__int128_t> works because that doesn't just add the
> 'signed' keyword to it.

i.e. the same reason this works:

using I = int;
std::make_signed_t i = 0;


It shouldn't ICE though.

[Bug c++/108099] ICE when parsing signed __int128_t typedef

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Jonathan Wakely from comment #1)
> > __int128_t is already a typedef, so you can't add a signed or unsigned
> > qualifier to it.
> 
> i.e. the same reason this doesn't work:
> 
> using I = int;
> signed I i = 0;

Hmm, actually g++ *does* allow this, unless you use -pedantic-errors:

using I = int;
using II = signed I;

It's not valid C++ though.

[Bug c++/108096] [13 regression] libreoffice build failure #2 since r13-4564

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/105464] '-fcompare-debug' failure (length) w/ -Og -fharden-compares -fno-tree-dce

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #2 from Arseny Solokha  ---
Indeed I cannot reproduce it w/ the current gcc 13.0.0 20221211 snapshot.

[Bug c++/108099] ICE when parsing signed __int128_t typedef

[moritz.klammler at cetitec dot com via Gcc-bugs]

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

--- Comment #4 from Moritz Klammler  ---
I see, sorry for wasting your time. I forgot that there is a differently
spelled keyword in addition to the builtin(?) typedef. Since 'unsigned' got
accepted even with the typedef, it didn't occur to me now either...

A compiler error that's not a segfault sure would be nice but I shouldn't be
writing this borderline invalid code in the first place then.

[Bug preprocessor/108101] New: "#pragma once" causes other files not be included

[terra at gnome dot org via Gcc-bugs]

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

Bug ID: 108101
   Summary: "#pragma once" causes other files not be included
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terra at gnome dot org
  Target Milestone: ---

# (echo '#pragma once'; echo 'Killroy was here') > a.h
# (echo '#pragma once'; echo 'Killroy was here') > b.h
# (echo '#include "a.h"'; echo '#include "b.h"') > c.c
# gcc -E c.c | grep Killroy
1
# clang -E c.c | grep Killroy
2

According to gcc, Killroy was only there once.  Clang is keeping better track
and spots him there twice.

This seems to be version independent: tried 7.5.0 and 12.1.0

[Bug libstdc++/106477] With -fno-exception operator new(nothrow) aborts instead of returning null

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

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

--- Comment #5 from Jonathan Wakely  ---
A partial solution, but needs better preprocessor checks around it:

diff --git a/libstdc++-v3/libsupc++/new_op.cc
b/libstdc++-v3/libsupc++/new_op.cc
index 3a6540a3cd9..b1f31bac7e8 100644
--- a/libstdc++-v3/libsupc++/new_op.cc
+++ b/libstdc++-v3/libsupc++/new_op.cc
@@ -57,3 +57,16 @@ operator new (std::size_t sz) _GLIBCXX_THROW
(std::bad_alloc)

   return p;
 }
+
+#if _GLIBCXX_SHARED && __pic__ && defined _GLIBCXX_MANGLE_SIZE_T \
+  && __has_cpp_attribute(gnu::alias) && __has_cpp_attribute(gnu::visibility)
+namespace __gnu_cxx
+{
+#define STR_(A) #A
+#define STR(A) STR_(A)
+#define OP_NEW "_Znw" STR(_GLIBCXX_MANGLE_SIZE_T)
+
+  [[gnu::alias(OP_NEW), gnu::visibility("hidden")]]
+  void * __default_op_new (std::size_t sz) _GLIBCXX_THROW (std::bad_alloc);
+}
+#endif
diff --git a/libstdc++-v3/libsupc++/new_opnt.cc
b/libstdc++-v3/libsupc++/new_opnt.cc
index 3822e04c8cf..23e9981a958 100644
--- a/libstdc++-v3/libsupc++/new_opnt.cc
+++ b/libstdc++-v3/libsupc++/new_opnt.cc
@@ -26,11 +26,43 @@
 #include 
 #include "new"

+
+#if _GLIBCXX_SHARED && __pic__
 extern "C" void *malloc (std::size_t);
+namespace __gnu_cxx { void * __default_op_new (std::size_t sz); }
+#endif

 _GLIBCXX_WEAK_DEFINITION void *
 operator new (std::size_t sz, const std::nothrow_t&) noexcept
 {
+  // TODO: Only do this for libstdc++.so not libstdc++.a
+  // TODO: Need proper checks that alias + visibility works correctly.
+#if _GLIBCXX_SHARED && __pic__ && defined _GLIBCXX_MANGLE_SIZE_T \
+  && __has_cpp_attribute(gnu::alias) && __has_cpp_attribute(gnu::visibility)
+  void* (*op_new)(std::size_t) = &::operator new;
+  if (op_new == __gnu_cxx::__default_op_new)
+{
+  // We know that operator new(size_t) has not been replaced,
+  // and we know that the default version just uses malloc.
+  // So we can implement this directly, without the overhead
+  // of handling bad_alloc exceptions.
+
+  /* malloc (0) is unpredictable; avoid it.  */
+  if (__builtin_expect (sz == 0, false))
+   sz = 1;
+
+  void *p;
+  while ((p = malloc (sz)) == 0)
+   {
+ std::new_handler handler = std::get_new_handler ();
+ if (! handler)
+   return nullptr;
+ handler ();
+   }
+  return p;
+}
+#endif
+
   // _GLIBCXX_RESOLVE_LIB_DEFECTS
   // 206. operator new(size_t, nothrow) may become unlinked to ordinary
   // operator new if ordinary version replaced

[Bug preprocessor/108101] "#pragma once" causes other files not be included

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

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

--- Comment #1 from Andrew Pinski  ---
Iirc pragma once uses a hash of the content and that is what is going on here.
That or the underlying file system is using some inode being the same and copy
on write.

[Bug preprocessor/108101] "#pragma once" causes other files not be included

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Andrew Pinski  ---
Dup of bug 52566

*** This bug has been marked as a duplicate of bug 52566 ***

[Bug preprocessor/52566] #include with #pragma once and files' contents is the same

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||terra at gnome dot org

--- Comment #4 from Andrew Pinski  ---
*** Bug 108101 has been marked as a duplicate of this bug. ***

[Bug preprocessor/108101] "#pragma once" causes other files not be included

[terra at gnome dot org via Gcc-bugs]

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

--- Comment #3 from M Welinder  ---
Note also:

# gcc -MM c.c
c.o: c.c a.h

No b.h present!

[Bug preprocessor/52566] #include with #pragma once and files' contents is the same

[terra at gnome dot org via Gcc-bugs]

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

--- Comment #5 from M Welinder  ---
>From 108101:

Note also:

# gcc -MM c.c
c.o: c.c a.h

No b.h present!

I.e., Makefiles built with this will not pick up changes to the second file.

[Bug rust/107633] [13 regression] Bootstrap failure due to -Werror=unused-parameter and -Werror=dangling-reference

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 Target|i386-pc-solaris2.11 |
  Build|i386-pc-solaris2.11 |
   Host|i386-pc-solaris2.11 |
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 CC||tschwinge at gcc dot gnu.org
   See Also||https://github.com/Rust-GCC
   ||/gccrs/pull/1703

--- Comment #10 from Thomas Schwinge  ---
(In reply to Marek Polacek from comment #3)
> I thought this had been fixed by
> 
> commit 32a06ce38a38bf37db468f0e6c83520fcc221534
> Author: Marek Polacek 
> Date:   Tue Nov 1 17:05:52 2022 -0400
> 
> c++: Quash -Wdangling-reference for member operator* [PR107488]

ACK; .

[Bug gcov-profile/107537] gcov skips throw/fallthrough annotations for 'never executed' branches

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

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

--- Comment #3 from Martin Liška  ---
Hello. Sorry for the delay.

> Is there any reason why gcov skips throw/fallthrough annotations for
> branches which were never executed?

No. Your patch is fine and pre-approved, please include the PR entry in
ChangeLog and send it to gcc-patches. Once doing that, you can commit it (if
you have a copyright assignment and git write access?).

[Bug tree-optimization/108095] powerpc-linux / powerpc64-linux: ICEs when building Linux's arch/powerpc/kernel/align.c (asm goto)

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

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

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 54090
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54090&action=edit
gcc13-pr108095.patch

Untested fix.  The addition of phi_nodes check was done because otherwise
gsi_insert_on_edge_immediate could split the edge, which is highly undesirable
for -fcompare-debug purposes.

[Bug target/107988] [13 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) on aarch64-unknown-linux-gnu

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Tamar Christina :

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

commit r13-4699-g8c2451ba4601739654e2ea4907d6fa2a00d660aa
Author: Tamar Christina 
Date:   Wed Dec 14 13:54:28 2022 +

AArch64: div-by-255, ensure that arguments are registers. [PR107988]

At -O0 (as opposed to e.g. volatile) we can get into the situation where
the
in0 and result RTL arguments passed to the division function are memory
locations instead of registers.  I think we could reject these early on by
checking that the gimple values are GIMPLE registers, but I think it's
better to
handle it.

As such I force them to registers and emit a move to the memory locations
and
leave it up to reload to handle.  This fixes the ICE and still allows the
optimization in these cases,  which improves the code quality a lot.

gcc/ChangeLog:

PR target/107988
* config/aarch64/aarch64.cc
(aarch64_vectorize_can_special_div_by_constant): Ensure input and
output
RTL are registers.

gcc/testsuite/ChangeLog:

PR target/107988
* gcc.target/aarch64/pr107988-1.c: New test.

[Bug target/107988] [13 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) on aarch64-unknown-linux-gnu

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #4 from Tamar Christina  ---
Fixed, thanks for the report.

[Bug libstdc++/108097] std::stacktrace AddressSanitizer: new-delete-type-mismatch on 0x615000000080 in thread T0

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:881c6cabce5d0b27285ed41bd6dabdf48848cce7

commit r13-4701-g881c6cabce5d0b27285ed41bd6dabdf48848cce7
Author: Jonathan Wakely 
Date:   Wed Dec 14 11:58:05 2022 +

libstdc++: Fix size passed to operator delete [PR108097]

The number of elements gets stored in _M_capacity so use a separate
variable for the number of bytes to allocate.

libstdc++-v3/ChangeLog:

PR libstdc++/108097
* include/std/stacktrace (basic_stracktrace::_Impl): Do not
multiply N by sizeof(value_type) when allocating.

[Bug fortran/107214] [13 Regression] ICE: base pointer cycle detected since r13-2661-gb57abd072dd319a7

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Julian Brown :

https://gcc.gnu.org/g:330b9a8d87dd73e10539da618496ad4964fee26d

commit r13-4703-g330b9a8d87dd73e10539da618496ad4964fee26d
Author: Julian Brown 
Date:   Tue Dec 6 23:10:58 2022 +

OpenMP: Duplicate checking for map clauses in Fortran (PR107214)

This patch adds duplicate checking for OpenMP "map" clauses, taking some
cues from the implementation for C in c-typeck.cc:c_finish_omp_clauses
(and similar for C++).

In addition to the existing use of the "mark" and "comp_mark" bitfields
in the gfc_symbol structure, the patch adds several new bits handling
duplicate checking within various categories of clause types.  If "mark"
is being used for map clauses, we need to use different bits for other
clauses for cases where "map" and some other clause can refer to the
same symbol (e.g. "map(n) shared(n)").

2022-12-06  Julian Brown  

gcc/fortran/
PR fortran/107214
* gfortran.h (gfc_symbol): Add data_mark, dev_mark, gen_mark and
reduc_mark bitfields.
* openmp.cc (resolve_omp_clauses): Use above bitfields to improve
duplicate clause detection.

gcc/testsuite/
PR fortran/107214
* gfortran.dg/gomp/pr107214.f90: New test.
* gfortran.dg/gomp/pr107214-2.f90: New test.
* gfortran.dg/gomp/pr107214-3.f90: New test.
* gfortran.dg/gomp/pr107214-4.f90: New test.
* gfortran.dg/gomp/pr107214-5.f90: New test.
* gfortran.dg/gomp/pr107214-6.f90: New test.
* gfortran.dg/gomp/pr107214-7.f90: New test.
* gfortran.dg/gomp/pr107214-8.f90: New test.

[Bug libstdc++/108097] std::stacktrace AddressSanitizer: new-delete-type-mismatch on 0x615000000080 in thread T0

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |12.4
   Keywords||wrong-code

[Bug libstdc++/108097] std::stacktrace AddressSanitizer: new-delete-type-mismatch on 0x615000000080 in thread T0

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:

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

commit r12-8985-ge9d58614b0b8eebd64d568fa22cd31faaa5f8dce
Author: Jonathan Wakely 
Date:   Wed Dec 14 11:58:05 2022 +

libstdc++: Fix size passed to operator delete [PR108097]

The number of elements gets stored in _M_capacity so use a separate
variable for the number of bytes to allocate.

libstdc++-v3/ChangeLog:

PR libstdc++/108097
* include/std/stacktrace (basic_stracktrace::_Impl): Do not
multiply N by sizeof(value_type) when allocating.

(cherry picked from commit 881c6cabce5d0b27285ed41bd6dabdf48848cce7)

[Bug libstdc++/108097] std::stacktrace AddressSanitizer: new-delete-type-mismatch on 0x615000000080 in thread T0

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|12.4|12.3
 Status|NEW |RESOLVED

--- Comment #12 from Jonathan Wakely  ---
Fixed for 12.3

[Bug fortran/95947] PACK intrinsic returns blank strings when an allocatable character array with allocatable length is used

[urbanjost at comcast dot net via Gcc-bugs]

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

--- Comment #4 from urbanjost at comcast dot net ---
FYI: Still occurs in 12.2.0.

[Bug rust/107633] [13 regression] Bootstrap failure due to -Werror=unused-parameter and -Werror=dangling-reference

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   See Also||https://github.com/Rust-GCC
   ||/gccrs/pull/1701

--- Comment #11 from Thomas Schwinge  ---
(In reply to Rainer Orth from comment #0)
> hundreds of instances of -Werror=unused-parameter

For the record, these were "fixed" ;-) with
 "Standardize warning flags".

[Bug rust/108087] -Wodr warnings in rust/rust-lang.cc (lang_type)

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

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

Arthur Cohen  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

[Bug tree-optimization/108095] powerpc-linux / powerpc64-linux: ICEs when building Linux's arch/powerpc/kernel/align.c (asm goto)

[jbglaw--- via Gcc-bugs]

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

--- Comment #6 from Jan-Benedict Glaw  ---
I'll give that patch a spin, build the cross-compilers and try to build the
affected Linux configurations.

[Bug analyzer/108028] Misleading -fanalyzer messages at -O2 and above

[mengli.ming at outlook dot com via Gcc-bugs]

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

--- Comment #3 from ming mengli  ---
(In reply to David Malcolm from comment #1)
> Thanks for filing this bug.
> 
> There are several things going on here.
> 
> (A): the analyzer is considering the function "f" as called standalone, as
> well as the case where it's called from "main", rather than merely
> considering it when it's called from "main".  There are a few other bug
> reports about that; it's not clear to me what we should do for this case; is
> it expected that such functions are only ever called from main?
> 
> The situation is clearer if we simply delete "main" from the reproducer. 
> With that, we see:
> 
>   'f': events 1-3
> |
> |7 | if (p && (0 == q))
> |  |^
> |  ||
> |  |(1) following 'true' branch...
> |8 | {
> |9 | __analyzer_eval(p && (0 == q));
> |  | ~~~
> |  | |
> |  | (2) ...to here
> |..
> |   14 | *q = 1;
> |  | ~~
> |  ||
> |  |(3) dereference of NULL '0'
> |
> 
> 
> (B) arguably the CFG event (1) to (2) is poorly worded; at (1) we have
> "following 'true' branch...", which suggests it always follows the 'true'
> branch, whereas it's merely considering what happens *if* we take the 'true'
> branch.
> 
> If it read: e.g.:
> 
>   'f': events 1-3
> |
> |7 | if (p && (0 == q))
> |  |^
> |  ||
> |  |(1) considering following 'true' branch (implying that
> 'q' is NULL)...
> |8 | {
> |9 | __analyzer_eval(p && (0 == q));
> |  | ~~~
> |  | |
> |  | (2) ...to here
> |..
> |   14 | *q = 1;
> |  | ~~
> |  ||
> |  |(3) dereference of NULL '0'
> |
> 
> the analyzer would be more obviously correct and useful.
> 
> Or even "considering when 'q' is NULL; following 'true' branch..."
> 
> I've been experimenting with making the wording here clearer
> (i): should make a distinction between when the analyzer chooses one of
> several paths to consider, versus when the choice of execution path is
> already determined by previous choices
> (ii): would be nice to capture that q's nullness is the most interesting
> property at the "if" statement with respect to the warning, and express that
> to the user.
> 
> 
> (C) The analyzer runs relatively late compared to most static analyzers, so
> the optimization levels affect things.  In particular, consider the gimple
> IR seen by -fanalyzer for the assignment:
>  *q = 1;
> in the block guarded by (0 == q).
> 
> At -O1 we have:
>  *q_10(D) = 1;
> but at -O2 it converts it to:
>  MEM[(int *)0B] = 1;
> 
> Arguably it's a bug here that we only warn at -O2 and above; analyzing "f"
> standalone, we ought to be complaining about the null dereference without
> needing -O2.
> (specifically, at -O2 -fanalyzer sees a deref of NULL, whereas at -O1 it
> merely sees a deref of INIT_VAL(q), whilst knowing the constraint that
> INIT_VAL(q) is NULL.
> The __analyzer_eval results are also due to gimple IR differences caused by
> the optimizer.
> 
> Also, perhaps we should run earlier; I probably ought to file a bug about
> that, it's a big can of worms.

Thanks a lot for your explanation of this bug, it helps a lot. I think it's
perfectly feasible to consider both cases for that such functions to be
analyzed standalone and from the main function, sorry I didn't express myself
clearly on that point. Feel free to let us know if we could do anything to help
with these. We hope gcc static analyzer will get better.

[Bug rust/107633] Bootstrap failure due to -Werror=unused-parameter and -Werror=dangling-reference

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||build
Version|13.0|rust/master
Summary|[13 regression] Bootstrap   |Bootstrap failure due to
   |failure due to  |-Werror=unused-parameter
   |-Werror=unused-parameter|and
   |and |-Werror=dangling-reference
   |-Werror=dangling-reference  |

--- Comment #12 from Thomas Schwinge  ---
(In reply to Marc Poulhiès from comment #7)
> Arthur already has a pending change that should fix this, see: 
> 
>  https://github.com/Rust-GCC/gccrs/pull/1635

... which has later been reverted; needs some more attention.

---

However, all issues reported here (as far as I understand) have now been
addressed individually in GCC/Rust master branch.  (At least,
x86_64-pc-linux-gnu bootstrap is now again "green" in my testing.)

[Bug tree-optimization/107561] [13 Regression] g++.dg/pr71488.C and [g++.dg/warn/Warray-bounds-16.C -m32] regression due to -Wstringop-overflow problem

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

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

John David Anglin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-12-14
 CC||danglin at gcc dot gnu.org

[Bug testsuite/106120] [13 regression] g++.dg/warn/Wstringop-overflow-4.C fails since r13-1268-g8c99e307b20c50

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

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

John David Anglin  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-14
 Ever confirmed|0   |1
 Target|powerpc64-linux-gnu |powerpc64-linux-gnu
   ||hppa-unknown-linux-gnu
 Status|UNCONFIRMED |NEW
 CC||danglin at gcc dot gnu.org
   Host|powerpc64-linux-gnu |powerpc64-linux-gnu
   ||hppa-unknown-linux-gnu
  Build|powerpc64-linux-gnu |powerpc64-linux-gnu
   ||hppa-unknown-linux-gnu

[Bug target/108038] GCC generates poor code for select of consecutive constants on riscv-64

[rzinsly at ventanamicro dot com via Gcc-bugs]

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

--- Comment #1 from Raphael M Zinsly  ---
(In reply to Jeffrey A. Law from comment #0)
> testGT:
> sgt a0,a0,a1# 25[c=4 l=4]  *sgt_didi
> xoria0,a0,1 # 27[c=4 l=4]  xordi3/1
> addia0,a0,2 # 16[c=4 l=4]  adddi3/1
> ret # 35[c=0 l=4]  simple_return
> 
> 
> But ISTM we could generate this instead:
> 
> testGT:
> sgt a0,a1,a0# 24[c=4 l=4]  *riscv.md:2535
> addia0,a0,2 # 16[c=4 l=4]  adddi3/1
> ret # 32[c=0 l=4]  simple_return
Unless I'm missing something this seems wrong: 'sgt a0,a0,a1' with 'xori
a0,a0,1' would be equivalent to 'sge a0,a1,a0' or to 'sle a0,a0,a1' and not to
'sgt a0,a1,a0'.
For x == y the result would be 2 with your asm.

> We can invert the condition and swap the operands with something like this:
> 
> (define_insn ""
>   [(set (match_operand:GPR   0 "register_operand" "=r")
> (any_le:GPR (match_operand:X 1 "register_operand" " r")
> (match_operand:X 2 "register_operand" "r")))]
>   ""
>   "sgt\t%0,%2,%1"
>   [(set_attr "type" "slt")
>(set_attr "mode" "")])
This works as you intended. However, I think the right patter should be:

(define_insn "*sge__inv"
  [(set (match_operand:GPR 0 "register_operand" "=r")
(any_le:GPR (match_operand:X 1 "register_operand" " r")
(match_operand:X 2 "register_operand" "r")))]
  ""
  "sge\t%0,%2,%1"
  [(set_attr "type" "slt")
   (set_attr "mode" "")])

It produces the output:

testGT:
sge a0,a1,a0# 24[c=4 l=4]  *sge_didi_inv
addia0,a0,2 # 16[c=4 l=4]  adddi3/1
ret # 32[c=0 l=4]  simple_return

[Bug debug/107231] [13 Regression] c-c++-common/goacc/kernels-loop-g.c: '-fcompare-debug' failure (length)

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

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

John David Anglin  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-14
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||danglin at gcc dot gnu.org

[Bug rust/108102] New: rust bootstrap comparison failure on s390x-linux-gnu

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

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

Bug ID: 108102
   Summary: rust bootstrap comparison failure on s390x-linux-gnu
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rust
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org
  Target Milestone: ---

seen with trunk 20221214 on s390x-linux-gnu:

make[5]: Leaving directory '/<>/build'
Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/rust/rust-hir-trait-resolve.o differs
make[4]: *** [Makefile:31113: compare] Error 1

full build log at
https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test/+build/24937231

[Bug c++/108103] New: c++tools remains after make distclean

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

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

Bug ID: 108103
   Summary: c++tools remains after make distclean
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

$ ll c++tools/   
total 3688
-rw-rw-r-- 1 segher segher4840 Nov 25 19:46 Makefile
-rw-rw-r-- 1 segher segher4998 Oct 21 03:51 config.cache
-rw-rw-r-- 1 segher segher2168 Oct 21 03:51 config.h
-rw-rw-r-- 1 segher segher   62826 Nov 25 19:46 config.log
-rwxrwxr-x 1 segher segher   33722 Oct 21 03:51 config.status
-rwxrwxr-x 1 segher segher 2537088 Oct 21 03:51 g++-mapper-server
-rw-rw-r-- 1 segher segher1319 Oct 21 03:51 resolver.d
-rw-rw-r-- 1 segher segher  601080 Oct 21 03:51 resolver.o
-rw-rw-r-- 1 segher segher2020 Oct 21 03:51 server.d
-rw-rw-r-- 1 segher segher  524168 Oct 21 03:51 server.o

[Bug testsuite/95706] New test case gfortran.dg/pr95690.f90 fails

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

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

John David Anglin  changed:

   What|Removed |Added

 Target|powerpc64*-linux-gnu,   |powerpc64*-linux-gnu,
   |sparc-sun-solaris2.11   |sparc-sun-solaris2.11,
   ||hppa-unknown-linux-gnu
   Last reconfirmed|2020-07-02 00:00:00 |2022-12-14
  Build|powerpc64*-linux-gnu,   |powerpc64*-linux-gnu,
   |sparc-sun-solaris2.11   |sparc-sun-solaris2.11,
   ||hppa-unknown-linux-gnu
   Host|powerpc64*-linux-gnu,   |powerpc64*-linux-gnu,
   |sparc-sun-solaris2.11   |sparc-sun-solaris2.11,
   ||hppa-unknown-linux-gnu
 CC||danglin at gcc dot gnu.org

--- Comment #13 from John David Anglin  ---
On hppa-unknown-linux-gnu, error is also on line 5:

/home/dave/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/pr95690.f90:5:21: Error:
initializer for floating value is not a floating constant

[Bug c++/108103] c++tools remains after make distclean

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andrew Pinski  ---
Dup of bug 101834.

*** This bug has been marked as a duplicate of bug 101834 ***

[Bug bootstrap/101834] make distclean forgets ./c++tools/

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from Andrew Pinski  ---
*** Bug 108103 has been marked as a duplicate of this bug. ***

[Bug c++/108104] New: ICE in unify, at cp/pt.c:24333 with template partial specialization

[gawain.bolton at free dot fr via Gcc-bugs]

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

Bug ID: 108104
   Summary: ICE in unify, at cp/pt.c:24333 with template partial
specialization
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gawain.bolton at free dot fr
  Target Milestone: ---

Created attachment 54091
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54091&action=edit
ICE with template partial specialization - No issue if WITH_STATE is 0 i.e. if
the State parameter is absent

Please see attached file which causes an internal compiler error.

Note that there is no issue if the "State" template argument is removed as can
be shown if you set WITH_STATE to 0.

No issue found with clang >= v13.0

ICE found with all versions of GCC I tried (from GCC v4.9.4 to GCC v12.2)

[Bug libstdc++/108105] New: std::is_sorted(std::execution::par, ...) giving incorrect result

[thomas.jollans at dentsplysirona dot com via Gcc-bugs]

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

Bug ID: 108105
   Summary: std::is_sorted(std::execution::par, ...) giving
incorrect result
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.jollans at dentsplysirona dot com
  Target Milestone: ---

For the sequence
{
1, 23, 33, 48, 49, 65, 89, 0, 1, 2, 10, 11, 12, 12, 13, 14, 22, 23, 24,
32, 33, 34, 22, 23, 24, 32, 33, 34, 42, 43, 44, 37, 38, 39, 47, 48, 49,
57, 58, 59, 38, 39, 40, 48, 49, 50, 58, 59, 60, 54, 55, 56, 64, 65, 66,
74, 75, 76, 78, 79, 80, 88, 89
}

(which, as you can see, is not sorted), is_sorted sometimes reports true when
called with the parallel execution policy. Without an execution policy,
is_sorted works as expected, and returns false.

(The sequence was not created to have any special properties, but comes a
real-world case)

Minimal test case:

// BEGIN TEST CODE

#include 
#include 
#include 

int constexpr REPEAT = 10;

int main()
{
std::vector nums = {
1, 23, 33, 48, 49, 65, 89, 0, 1, 2, 10, 11, 12, 12, 13, 14, 22, 23, 24,
32, 33, 34, 22, 23, 24, 32, 33, 34, 42, 43, 44, 37, 38, 39, 47, 48, 49,
57, 58, 59, 38, 39, 40, 48, 49, 50, 58, 59, 60, 54, 55, 56, 64, 65, 66,
74, 75, 76, 78, 79, 80, 88, 89
};

int sorted_seq_count = 0;
for (int i{}; i < REPEAT; ++i) {
if (std::is_sorted(begin(nums), end(nums))) ++sorted_seq_count;
}
std::cout << "Sequential std::is_sorted: " << sorted_seq_count << " times
\"sorted\" out of " << REPEAT << '\n';

int sorted_par_count = 0;
for (int i{}; i < REPEAT; ++i) {
if (std::is_sorted(std::execution::par, begin(nums), end(nums)))
++sorted_par_count;
}
std::cout << "Parallel std::is_sorted: " << sorted_par_count << " times
\"sorted\" out of " << REPEAT << '\n';

return sorted_par_count == sorted_seq_count ? 0 : 1;
}

// END TEST CODE

This produces output similar to the following on x86_64 Linux (via
WSL2/Windows):

Sequential std::is_sorted: 0 times "sorted" out of 10
Parallel std::is_sorted: 71233 times "sorted" out of 10

I've observed this problem both
 * on GCC 11.3.0 running on (and provided by) Ubuntu 22.04 LTS
 * on GCC 12.2.0 running on (and provided by) Ubuntu 22.10 running in Docker
for reproducibility

   docker run --rm -i --tty ubuntu:22.10
   ( in container ) # apt update && apt upgrade && apt install g++ libtbb-dev

Output of gcc -v:

root@02a06f558cd5:~# g++ -v -save-temps -std=c++20 -ois_sorted_test
is_sorted_test.cpp -ltbb
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 12.2.0-3ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-U8K4Qv/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-U8K4Qv/gcc-12-12.2.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (Ubuntu 12.2.0-3ubuntu1)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++20' '-o' 'is_sorted_test'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/12/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE is_sorted_test.cpp -mtune=generic -march=x86-64
-std=c++20 -fpch-preprocess -fasynchronous-unwind-tables
-fstack-protector-strong -Wformat -Wformat-security -fstack-clash-protection
-fcf-protection -o is_sorted_test.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/12"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-linux-gnu/12/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/

[Bug sanitizer/108106] New: [13 Regression] /usr/bin/ld: .libs/hwasan_setjmp_x86_64.o: relocation R_X86_64_PC32 against symbol `__interceptor_sigsetjmp' can not be used when making a shared object; re

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

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

Bug ID: 108106
   Summary: [13 Regression] /usr/bin/ld:
.libs/hwasan_setjmp_x86_64.o: relocation R_X86_64_PC32
against symbol `__interceptor_sigsetjmp' can not be
used when making a shared object; recompile with -fPIC
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org,
liuhongt at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
 Build: x86_64-pc-linux-gnu

Doing a standard native x86_64-pc-linux-gnu bootstrap using an oldish Ubuntu
14.04.6 '/usr/bin/ld' ("GNU ld (GNU Binutils for Ubuntu) 2.24"), I'm getting a
build failure as of recent commit
r13-4576-g2996b5c053d38d4543c9491258b051d6c032a011 "Enable hwasan for x86-64":

/usr/bin/ld: .libs/hwasan_setjmp_x86_64.o: relocation R_X86_64_PC32 against
symbol `__interceptor_sigsetjmp' can not be used when making a shared object;
recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: error: ld returned 1 exit status
make[4]: *** [libhwasan.la] Error 1
make[4]: Leaving directory
`[...]/build-gcc/x86_64-pc-linux-gnu/libsanitizer/hwasan'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory
`[...]/build-gcc/x86_64-pc-linux-gnu/libsanitizer'
make[2]: *** [all] Error 2
make[2]: Leaving directory
`[...]/build-gcc/x86_64-pc-linux-gnu/libsanitizer'
make[1]: *** [all-target-libsanitizer] Error 2

[Bug rust/108102] rust bootstrap comparison failure on s390x-linux-gnu

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
So what are the differences in
stage2-gcc/rust/rust-hir-trait-resolve.o
vs.
stage3-gcc/rust/rust-hir-trait-resolve.o
(or prev-gcc/ vs. gcc/ if it was moved back already)?

[Bug libstdc++/108107] New: FAIL: libstdc++-prettyprinters/debug.cc print sstream

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

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

Bug ID: 108107
   Summary: FAIL: libstdc++-prettyprinters/debug.cc print sstream
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa*-*-linux*
Target: hppa*-*-linux*
 Build: hppa*-*-linux*

PASS: libstdc++-prettyprinters/debug.cc execution test
Spawning: gdb -nw -nx -quiet -batch -ex "python print(gdb.type_printers)"
spawn gdb -nw -nx -quiet -batch -ex python print(gdb.type_printers)
[]
spawn gdb -nx -nw -quiet -batch -x debug.gdb
Breakpoint 1 at 0x14e60: file
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/libstdc++-prettyprinters/debug.cc,
line 129.
skipping: Breakpoint 1 at 0x14e60: file
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/libstdc++-prettyprinters/debug.cc,
line 129.
warning: Unable to find libthread_db matching inferior's thread library, thread
debugging will not be available.
skipping: warning: Unable to find libthread_db matching inferior's thread
library, thread debugging will not be available.


skipping:

Breakpoint 1, main () at
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/libstdc++-prettyprinters/debug.cc:129
129   return 0; // Mark SPOT
skipping: Breakpoint 1, main () at
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/libstdc++-prettyprinters/debug.cc:129
skipping: 129 return 0; // Mark SPOT
>FromTo  Syms Read   Shared Object Library
0xf994af90  0xf9970d14  Yes /lib/ld.so.1
0xf9444080  0xf95994c0  Yes
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs/libstdc++.so.6
0xf8d59744  0xf8d8e1d4  Yes /lib/hppa-linux-gnu/libm.so.6
0xf8bb3fe0  0xf8bc52a8  Yes /home/dave/gnu/gcc/objdir/gcc/libgcc_s.so.4
0xf8977950  0xf8acde14  Yes /lib/hppa-linux-gnu/libc.so.6
skipping: FromTo  Syms Read   Shared Object Library
skipping: 0xf994af90  0xf9970d14  Yes /lib/ld.so.1
skipping: 0xf9444080  0xf95994c0  Yes
/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs/libstdc++.so.6
skipping: 0xf8d59744  0xf8d8e1d4  Yes /lib/hppa-linux-gnu/libm.so.6
skipping: 0xf8bb3fe0  0xf8bc52a8  Yes
/home/dave/gnu/gcc/objdir/gcc/libgcc_s.so.4
skipping: 0xf8977950  0xf8acde14  Yes /lib/hppa-linux-gnu/libc.so.6
$1 = "zardoz"
$2 = std::__debug::bitset = {[0] = 1, [5] = 1, [7] = 1}
$3 = std::__debug::deque with 2 elements = {"one", "two"}
$4 = "one"
got: $1 = "zardoz"
PASS: libstdc++-prettyprinters/debug.cc print str
got: $2 = std::__debug::bitset = {[0] = 1, [5] = 1, [7] = 1}
PASS: libstdc++-prettyprinters/debug.cc print bs
got: $3 = std::__debug::deque with 2 elements = {"one", "two"}
PASS: libstdc++-prettyprinters/debug.cc print deq
got: $4 = "one"
PASS: libstdc++-prettyprinters/debug.cc print deqiter
$5 = std::__debug::list = {[0] = "one", [1] = "two"}
got: $5 = std::__debug::list = {[0] = "one", [1] = "two"}
PASS: libstdc++-prettyprinters/debug.cc print lst
$6 = "one"
got: $6 = "one"
PASS: libstdc++-prettyprinters/debug.cc print lstiter
$7 = "one"
got: $7 = "one"
PASS: libstdc++-prettyprinters/debug.cc print lstciter
$8 = std::__debug::map with 1 element = {["zardoz"] = 23}
got: $8 = std::__debug::map with 1 element = {["zardoz"] = 23}
PASS: libstdc++-prettyprinters/debug.cc print mp
$9 = {first = "zardoz", second = 23}
got: $9 = {first = "zardoz", second = 23}
PASS: libstdc++-prettyprinters/debug.cc print mpiter
$10 = std::__debug::set with 2 elements = {[0] = 2, [1] = 3}
got: $10 = std::__debug::set with 2 elements = {[0] = 2, [1] = 3}
PASS: libstdc++-prettyprinters/debug.cc print const_intset
$11 = std::__debug::set with 2 elements = {[0] = "barrel", [1] = "clownfish"}
got: $11 = std::__debug::set with 2 elements = {[0] = "barrel", [1] =
"clownfish"}
PASS: libstdc++-prettyprinters/debug.cc print sp
$12 = "barrel"
got: $12 = "barrel"
PASS: libstdc++-prettyprinters/debug.cc print spciter
$13 = __gnu_cxx::slist = {[0] = 47, [1] = 23}
got: $13 = __gnu_cxx::slist = {[0] = 47, [1] = 23}
PASS: libstdc++-prettyprinters/debug.cc print sll
$14 = non-dereferenceable iterator for std::vector
got: $14 = non-dereferenceable iterator for std::vector
PASS: libstdc++-prettyprinters/debug.cc print viter0
$15 = std::__debug::vector of length 1, capacity 2 = {2}
$16 = invalid iterator
$17 = invalid iterator
$18 = 2
got: $15 = std::__debug::vector of length 1, capacity 2 = {2}
PASS: libstdc++-prettyprinters/debug.cc print v
got: $16 = invalid iterator
PASS: libstdc++-prettyprinters/debug.cc print viter1
got: $17 = invalid iterator
PASS: libstdc++-prettyprinters/debug.cc print viter2
got: $18 = 2
PASS: libstdc++-prettyprinters/debug.cc print viter3
$19 = 47
got: $19 = 47
PASS: libstdc++-prettyprinters/debug.cc print

[Bug bootstrap/101834] make distclean forgets ./c++tools/

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

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

--- Comment #3 from Segher Boessenkool  ---
I never build in the source tree.  I use distclean a lot.

[Bug c++/108099] ICE with type alias with `signed __int_128_t`

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE when parsing signed |ICE with type alias with
   |__int128_t typedef  |`signed __int_128_t`

--- Comment #5 from Andrew Pinski  ---
This is interesting:
```
typedef __int128_t t;
using i128 = signed t;
//using i128_1 = signed __int128_t;
```
The above does not cause an ICE only a direct use of __int128_t causes the ICE
(with -pedantic we do warn about signed being used with the typedef though).

[Bug tree-optimization/108095] powerpc-linux / powerpc64-linux: ICEs when building Linux's arch/powerpc/kernel/align.c (asm goto)

[jbglaw--- via Gcc-bugs]

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

--- Comment #7 from Jan-Benedict Glaw  ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 54090 [details]
> gcc13-pr108095.patch

Compiler builds for me and the ICE went away for all affected Linux
configurations. Though I cannot verify whether or not the generated code is
correct.

[Bug c++/108099] ICE with type alias with `signed __int128_t`

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

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

--- Comment #6 from Andrew Pinski  ---
I forgot to mention we do reject:
```
typedef signed __int128_t t;
```
already too.

[Bug c++/108099] [12/13 Regression] ICE with type alias with `signed __int128_t`

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||11.3.0
   Target Milestone|--- |11.4
  Known to fail||12.1.0
Summary|ICE with type alias with|[12/13 Regression] ICE with
   |`signed __int128_t` |type alias with `signed
   ||__int128_t`

--- Comment #7 from Andrew Pinski  ---
The ICE is a regression from GCC 11 where we accepted the code with a pedwarn:
:1:14: warning: 'signed' specified with '__int128' [-Wpedantic]
1 | using i128 = signed __int128_t;
  |  ^~

[Bug other/108108] New: "gcc -MM" fails to list all dependencies

[terra at gnome dot org via Gcc-bugs]

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

Bug ID: 108108
   Summary: "gcc -MM" fails to list all dependencies
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terra at gnome dot org
  Target Milestone: ---

This is a spin-off from bug 52566


#!/bin/sh

rm -f a.h b.h c.c c.o Makefile
(echo '#pragma once'; echo '// Killroy was here') > a.h
cp -p a.h b.h
# or even "ln a.h b.h"
(echo '#include "a.h"'; echo '#include "b.h"') > c.c
gcc -MM c.c > Makefile
echo "--The Makefile:"
cat Makefile

echo "--Compiling first time:"
make CC=gcc c.o 

rm b.h
echo '#error "this file was changed"' >b.h
echo "--Compiling second time:"
make CC=gcc c.o 


The output I get is

--The Makefile:
c.o: c.c a.h
--Compiling first time:
gcc-c -o c.o c.c
--Compiling second time:
make: 'c.o' is up to date.


Notice that the second compilation does nothing.  That's quite wrong.  Make has
not been told that c.0 depends on b.h

As seen in bug 52566, this comes down to "#pragma once" deciding that a.h and
b.h are the same file.  One could certainly take that point of view for the
purposes of a single compilation.  I wouldn't, but fine.

However, "gcc -MM" involves the future.  It is not reasonable to assume that
a.h and b.h remain the same file forever.  I think it is reasonable to expect
that any quoted #include string will show up as a dependency with no
de-duplication.


Tested on gcc 7.5.0 (opensuse) and 12.1.0 (self-built).

[Bug preprocessor/108108] "gcc -MM" fails to list all dependencies

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|other   |preprocessor

--- Comment #1 from Andrew Pinski  ---
>This is a spin-off from bug 52566

I don't think this is different issue from that bug.
The preprocessor decided it was the same file.

This is why '#pragma once' should not be used.

[Bug preprocessor/108108] "gcc -MM" fails to list all dependencies

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

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

--- Comment #2 from Andrew Pinski  ---
From: https://gcc.gnu.org/onlinedocs/gcc-12.2.0/cpp/Pragmas.html#Pragmas
"that file will never be read again, no matter what."

https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Preprocessor-Options.html#index-M
"The preprocessor outputs one make rule containing the object file name for
that source file, a colon, and the names of all the included files, including
those coming from -include or -imacros command-line options."

Since it was not read again, the file is not considered included ...

[Bug preprocessor/108108] "gcc -MM" fails to list all dependencies

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

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

--- Comment #3 from Andrew Pinski  ---
Really #pragma once should just emit a warning just like #import does ...

[Bug c++/108099] [12/13 Regression] ICE with type alias with `signed __int128_t`

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
Started with r12-8173-ge580f81d22d61153564959f08d9a6d3bcc7fd386
For
using u128 = unsigned __int128_t;
auto a = sizeof (u128);
it doesn't ICE but changes behavior, before that commit a was 16, now it is 4.
The reason for the ICE as well as 4 in there is because r12-8173 does:
+ type = DECL_ORIGINAL_TYPE (typedef_decl);
+ typedef_decl = NULL_TREE;
which is fine for user typedefs, but for the internally created typedefs like
__int128_t, __uint128_t, __builtin_va_list, dunno if others too
DECL_ORIGINAL_TYPE
is NULL.
So, the question is if we should fix it by tweaking c-common.cc so that instead
of say:
  if (targetm.scalar_mode_supported_p (TImode))
lang_hooks.decls.pushdecl (build_decl (UNKNOWN_LOCATION,
   TYPE_DECL,
   get_identifier ("__int128_t"),
   intTI_type_node));
do
  if (targetm.scalar_mode_supported_p (TImode))
{
  tree decl = build_decl (UNKNOWN_LOCATION, TYPE_DECL,
  get_identifier ("__int128_t"),
  intTI_type_node);
  DECL_ORIGINAL_TYPE (decl) = intTI_type_node;
  lang_hooks.decls.pushdecl (decl);
}
etc., or if it wouldn't be better or at least easier to:
--- gcc/cp/decl.cc.jj   2022-12-05 11:10:37.528674260 +0100
+++ gcc/cp/decl.cc  2022-12-14 19:16:40.242926374 +0100
@@ -12442,7 +12442,8 @@ grokdeclarator (const cp_declarator *dec
  pedwarn (loc, OPT_Wpedantic, "%qs specified with %qT",
   key, type);
  ok = !flag_pedantic_errors;
- type = DECL_ORIGINAL_TYPE (typedef_decl);
+ if (DECL_ORIGINAL_TYPE (typedef_decl))
+   type = DECL_ORIGINAL_TYPE (typedef_decl);
  typedef_decl = NULL_TREE;
}
  else if (declspecs->decltype_p)
I'm going to test the latter.