[Bug c++/106713] [11/12/13 Regression] Coroutine regression in GCC 11.3.0: if (co_await ...) crashes with a jump to ud2 since r12-3529-g70ee703c479081ac

[gcc-bugzilla at decltype dot org via Gcc-bugs]

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

Pablo Busse  changed:

   What|Removed |Added

 CC||gcc-bugzilla at decltype dot 
org

--- Comment #4 from Pablo Busse  ---
Duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106188.

[Bug c++/106775] New: [11/12 regression] Subscipt operator with array rvalue inside brackets returns lvalue

[leduyquang753 at gmail dot com via Gcc-bugs]

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

Bug ID: 106775
   Summary: [11/12 regression] Subscipt operator with array rvalue
inside brackets returns lvalue
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: leduyquang753 at gmail dot com
  Target Milestone: ---

Created attachment 53519
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53519=edit
The command-line invocation of GCC, its verbose output and the preprocessed
source.

Using the built-in subscript operator with an array rvalue to the left (outside
brackets) and an integer to the right (inside brackets) returns an xvalue as
expected:

test.cpp:10:21: error: using rvalue as lvalue [-fpremissive]
   10 | getAnA().b[0] = 1;
  | ^

But reversing the two operands makes GCC give an lvalue:

0[getAnA().b] = 1;

No diagnostic with -Wall -Wextra -pedantic.

(Full preprocessed code attached.)

Test compiled using GCC 12.2.0 on Arch Linux and additionally on Windows and
Compiler explorer. Previous versions of GCC were tested on Compiler explorer
using x86-64 arch.

Other notes: MSVC in Visual studio 2022 seems to have the same issue while
Clang 14 doesn't.

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

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

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

Peter Bergner  changed:

   What|Removed |Added

  Known to fail||10.0, 11.0, 12.0, 13.0
 Status|ASSIGNED|RESOLVED
   Assignee|segher at gcc dot gnu.org  |bergner at gcc dot 
gnu.org
 Resolution|--- |FIXED

--- Comment #14 from Peter Bergner  ---
Fixed everywhere.

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Peter Bergner
:

https://gcc.gnu.org/g:3927bd9f9150576f2905c8930732c419f1850fca

commit r10-10966-g3927bd9f9150576f2905c8930732c419f1850fca
Author: Peter Bergner 
Date:   Sat Aug 27 19:44:16 2022 -0500

rs6000: Allow conversions of MMA pointer types [PR106017]

GCC incorrectly disables conversions between MMA pointer types, which
are allowed with clang.  The original intent was to disable conversions
between MMA types and other other types, but pointer conversions should
have been allowed.  The fix is to just remove the MMA pointer conversion
handling code altogether.

gcc/
PR target/106017
* config/rs6000/rs6000.c (rs6000_invalid_conversion): Remove
handling
of MMA pointer conversions.

gcc/testsuite/
PR target/106017
* gcc.target/powerpc/pr106017.c: New test.

(cherry picked from commit 1ae1325f24cea1698b56e4299d95446a1f7b90a2)

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

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

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

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

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

commit r11-10227-gf494a85f0bf653c3128b376c1abf821a27748c11
Author: Peter Bergner 
Date:   Sat Aug 27 19:44:16 2022 -0500

rs6000: Allow conversions of MMA pointer types [PR106017]

GCC incorrectly disables conversions between MMA pointer types, which
are allowed with clang.  The original intent was to disable conversions
between MMA types and other other types, but pointer conversions should
have been allowed.  The fix is to just remove the MMA pointer conversion
handling code altogether.

gcc/
PR target/106017
* config/rs6000/rs6000.c (rs6000_invalid_conversion): Remove
handling
of MMA pointer conversions.

gcc/testsuite/
PR target/106017
* gcc.target/powerpc/pr106017.c: New test.

(cherry picked from commit 1ae1325f24cea1698b56e4299d95446a1f7b90a2)

[Bug c++/106774] warning about comparison to true/false

[f.heckenbach--- via Gcc-bugs]

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

--- Comment #2 from Frank Heckenbach  ---
This should cover all cases mentioned:

void t (bool a, int i, float e, double f)
{
  // Boolean literal comparisons
  if (a == true)  // better: if (a)
return;
  if (a == false)  // better: if (!a)
return;
  if (a != true)  // better: if (!a)
return;
  if (a != false)  // better: if (a)
return;
  // also reversed to be sure
  if (true == a)  // better: if (a)
return;
  if (false != a)  // better: if (a)
return;

  // Integer comparisons to Boolean literals
  if (i == true)  // better: if (i == 1)
return;
  if (i == false)  // better: if (i == 0) or: if (!i)
return;  
  if (i != true)  // better: if (i != 1)
return;
  if (i != false)  // better: if (i != 0) or: if (i)
return;

  // Floating-point comparisons to Boolean literals
  if (e == true)  // very strange at all, if meant so, then better: if (e ==
1.0f)
return;
  if (f == false)  // very strange at all, if meant so, then better: if (f ==
0.0)
return;
}

[Bug c++/106774] warning about comparison to true/false

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Andrew Pinski  ---
Do you have an example?

[Bug c++/106774] New: warning about comparison to true/false

[f.heckenbach--- via Gcc-bugs]

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

Bug ID: 106774
   Summary: warning about comparison to true/false
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: f.heckenb...@fh-soft.de
  Target Milestone: ---

gcc has "-Wbool-compare" to warn about boolean expression compared with an
integer value different from true/false. This warning is enabled by -Wall.

However, a warning for comparisons with true and false may also be useful. The
former is redundant, the latter can be replaced with "!".

Actually, this warning may also be given when comparing a non-Boolean integral
expression with true or false. The former is not redundant, but may often not
be what's intended (if so, one should compare with 1). The latter is equivalent
to comparing with 0, but still strange style. And comparing non-integral (e.g.
floating-point) expressions with Boolean literals is certainly warning-worthy
(though it may be caught by "-Wfloat-equal" as well).

To sum up, a new warning about comparing any expression with true/false
literals. 

Maybe something like "-Wbool-compare=2" (which would not be enabled by -Wall, I
guess; maybe by -Wextra, but even if it must be given manually, I'd find it
useful).

[Bug c/60523] Warning flag for octal literals [-Woctal-literals]

[f.heckenbach--- via Gcc-bugs]

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

Frank Heckenbach  changed:

   What|Removed |Added

 CC||f.heckenb...@fh-soft.de

--- Comment #11 from Frank Heckenbach  ---
For file modes we have S_IXUSR etc., and most programs don't even need them
very often. So I think making it part of -Wextra seems reasonable these days,
but I'd welcome such a warning either way.

https://thedailywtf.com/articles/padded-mailers recently reminded me that
0-prefixed octals can cause real problems even for experienced programmers.

[Bug target/106017] [PowerPC] No array-to-pointer conversion for MMA accumulator

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

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

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

https://gcc.gnu.org/g:22ff125247ff5328ad4544aef939d491618d714d

commit r12-8726-g22ff125247ff5328ad4544aef939d491618d714d
Author: Peter Bergner 
Date:   Sat Aug 27 19:44:16 2022 -0500

rs6000: Allow conversions of MMA pointer types [PR106017]

GCC incorrectly disables conversions between MMA pointer types, which
are allowed with clang.  The original intent was to disable conversions
between MMA types and other other types, but pointer conversions should
have been allowed.  The fix is to just remove the MMA pointer conversion
handling code altogether.

gcc/
PR target/106017
* config/rs6000/rs6000.cc (rs6000_invalid_conversion): Remove
handling
of MMA pointer conversions.

gcc/testsuite/
PR target/106017
* gcc.target/powerpc/pr106017.c: New test.

(cherry picked from commit 1ae1325f24cea1698b56e4299d95446a1f7b90a2)

[Bug c/106773] New: libbpf: failed to find BTF info for global/extern symbol 'bpf_link_fops'

[james.hilliard1 at gmail dot com via Gcc-bugs]

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

Bug ID: 106773
   Summary: libbpf: failed to find BTF info for global/extern
symbol 'bpf_link_fops'
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: james.hilliard1 at gmail dot com
  Target Milestone: ---

GCC BTF Generation appears to not be working correctly for bpf_link_fops in the
bpf test test_ksyms.c

See:
https://github.com/torvalds/linux/blob/v6.0-rc3/tools/testing/selftests/bpf/progs/test_ksyms.c

GCC gen object failure:
$ /home/buildroot/bpf-next-test/tools/testing/selftests/bpf/tools/sbin/bpftool
--debug gen object
/home/buildroot/bpf-next-test/tools/testing/selftests/bpf/bpf_gcc/test_ksyms.linked1.o
/home/buildroot/bpf-next-test/tools/testing/selftests/bpf/bpf_gcc/test_ksyms.o
libbpf: linker: adding object file
'/home/buildroot/bpf-next-test/tools/testing/selftests/bpf/bpf_gcc/test_ksyms.o'...
libbpf: failed to find BTF info for global/extern symbol 'bpf_link_fops'
Error: failed to link
'/home/buildroot/bpf-next-test/tools/testing/selftests/bpf/bpf_gcc/test_ksyms.o':
Unknown error -2 (-2)

GCC BTF dump:
$ /home/buildroot/bpf-next-test/tools/testing/selftests/bpf/tools/sbin/bpftool
--debug btf dump file
/home/buildroot/bpf-next-test/tools/testing/selftests/bpf/bpf_gcc/test_ksyms.o
format raw
[1] INT 'signed char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED
[2] INT 'unsigned char' size=1 bits_offset=0 nr_bits=8 encoding=(none)
[3] TYPEDEF '__u8' type_id=2
[4] INT 'short int' size=2 bits_offset=0 nr_bits=16 encoding=SIGNED
[5] INT 'short unsigned int' size=2 bits_offset=0 nr_bits=16 encoding=(none)
[6] TYPEDEF '__u16' type_id=5
[7] INT 'int' size=4 bits_offset=0 nr_bits=32 encoding=SIGNED
[8] TYPEDEF '__s32' type_id=7
[9] INT 'unsigned int' size=4 bits_offset=0 nr_bits=32 encoding=(none)
[10] TYPEDEF '__u32' type_id=9
[11] INT 'long long int' size=8 bits_offset=0 nr_bits=64 encoding=SIGNED
[12] TYPEDEF '__s64' type_id=11
[13] INT 'long long unsigned int' size=8 bits_offset=0 nr_bits=64
encoding=(none)
[14] TYPEDEF '__u64' type_id=13
[15] TYPEDEF '__be16' type_id=6
[16] TYPEDEF '__be32' type_id=10
[17] TYPEDEF '__wsum' type_id=10
[18] INT 'long unsigned int' size=8 bits_offset=0 nr_bits=64 encoding=(none)
[19] INT 'char' size=1 bits_offset=0 nr_bits=8 encoding=SIGNED
[20] CONST '(anon)' type_id=19
[21] UNION '(anon)' size=8 vlen=1
'flow_keys' type_id=27 bits_offset=0
[22] STRUCT 'bpf_flow_keys' size=56 vlen=13
'nhoff' type_id=6 bits_offset=0
'thoff' type_id=6 bits_offset=16
'addr_proto' type_id=6 bits_offset=32
'is_frag' type_id=3 bits_offset=48
'is_first_frag' type_id=3 bits_offset=56
'is_encap' type_id=3 bits_offset=64
'ip_proto' type_id=3 bits_offset=72
'n_proto' type_id=15 bits_offset=80
'sport' type_id=15 bits_offset=96
'dport' type_id=15 bits_offset=112
'(anon)' type_id=23 bits_offset=128
'flags' type_id=10 bits_offset=384
'flow_label' type_id=16 bits_offset=416
[23] UNION '(anon)' size=32 vlen=2
'(anon)' type_id=24 bits_offset=0
'(anon)' type_id=25 bits_offset=0
[24] STRUCT '(anon)' size=8 vlen=2
'ipv4_src' type_id=16 bits_offset=0
'ipv4_dst' type_id=16 bits_offset=32
[25] STRUCT '(anon)' size=32 vlen=2
'ipv6_src' type_id=26 bits_offset=0
'ipv6_dst' type_id=26 bits_offset=128
[26] ARRAY '(anon)' type_id=10 index_type_id=18 nr_elems=4
[27] PTR '(anon)' type_id=22
[28] UNION '(anon)' size=8 vlen=1
'sk' type_id=30 bits_offset=0
[29] STRUCT 'bpf_sock' size=80 vlen=14
'bound_dev_if' type_id=10 bits_offset=0
'family' type_id=10 bits_offset=32
'type' type_id=10 bits_offset=64
'protocol' type_id=10 bits_offset=96
'mark' type_id=10 bits_offset=128
'priority' type_id=10 bits_offset=160
'src_ip4' type_id=10 bits_offset=192
'src_ip6' type_id=26 bits_offset=224
'src_port' type_id=10 bits_offset=352
'dst_port' type_id=15 bits_offset=384
'dst_ip4' type_id=10 bits_offset=416
'dst_ip6' type_id=26 bits_offset=448
'state' type_id=10 bits_offset=576
'rx_queue_mapping' type_id=8 bits_offset=608
[30] PTR '(anon)' type_id=29
[31] STRUCT '__sk_buff' size=192 vlen=34
'len' type_id=10 bits_offset=0
'pkt_type' type_id=10 bits_offset=32
'mark' type_id=10 bits_offset=64
'queue_mapping' type_id=10 bits_offset=96
'protocol' type_id=10 bits_offset=128
'vlan_present' type_id=10 bits_offset=160
'vlan_tci' type_id=10 bits_offset=192
'vlan_proto' type_id=10 bits_offset=224
'priority' type_id=10 bits_offset=256
'ingress_ifindex' type_id=10 bits_offset=288
'ifindex' type_id=10 bits_offset=320

[Bug c++/106712] Incorrect propagation of C++11 attributes to subsequent function declarations

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c++/106712] Incorrect propagation of C++11 attributes to subsequent function declarations

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

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

--- Comment #3 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:98973354b8690f01e06b9f36106e786fd94ac7a3

commit r13-2256-g98973354b8690f01e06b9f36106e786fd94ac7a3
Author: Marek Polacek 
Date:   Fri Aug 26 18:03:53 2022 -0400

c++: Fix C++11 attribute propagation [PR106712]

When we have

  [[noreturn]] int fn1 [[nodiscard]](), fn2();

"noreturn" should apply to both fn1 and fn2 but "nodiscard" only to fn1:
[dcl.pre]/3: "The attribute-specifier-seq appertains to each of
the entities declared by the declarators of the init-declarator-list."
[dcl.spec.general]: "The attribute-specifier-seq affects the type
only for the declaration it appears in, not other declarations involving
the same type."

As Ed Catmur correctly analyzed, this is because, for the test above,
we call start_decl with prefix_attributes=noreturn, but this line:

  attributes = attr_chainon (attributes, prefix_attributes);

results in attributes == prefix_attributes, because chainon sees
that attributes is null so it just returns prefix_attributes.  Then
in grokdeclarator we reach

  *attrlist = attr_chainon (*attrlist, declarator->std_attributes);

which modifies prefix_attributes so now it's "noreturn, nodiscard"
and so fn2 is wrongly marked nodiscard as well.  Fixed by reversing
the order of arguments to attr_chainon.  That way, we tack the prefix
attributes onto ->std_attributes, avoiding modifying prefix_attributes.

PR c++/106712

gcc/cp/ChangeLog:

* decl.cc (grokdeclarator): Reverse the order of arguments to
attr_chainon.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/gen-attrs-77.C: New test.

[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.

[matoro_gcc_bugzilla at matoro dot tk via Gcc-bugs]

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

--- Comment #16 from matoro  ---
I also observed this issue on alpha-unknown-linux-gnu, with gcc 12.2.

[Bug target/106745] segfault in bpf_core_get_sou_member_index

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Faust :

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

commit r13-2255-gb504149d2c92ddfcfab62ea6d1ed49ae72493e38
Author: David Faust 
Date:   Mon Aug 29 11:21:52 2022 -0700

bpf: handle anonymous members in CO-RE reloc [PR106745]

The old method for computing a member index for a CO-RE relocation
relied on a name comparison, which could SEGV if the member in question
is itself part of an anonymous inner struct or union.

This patch changes the index computation to not rely on a name, while
maintaining the ability to account for other sibling fields which may
not have a representation in BTF.

gcc/ChangeLog:

PR target/106745
* config/bpf/coreout.cc (bpf_core_get_sou_member_index): Fix
computation of index for anonymous members.

gcc/testsuite/ChangeLog:

PR target/106745
* gcc.target/bpf/core-pr106745.c: New test.

[Bug libstdc++/106766] zip_view::_Iterator/_Sentinel's operator- use make_unsigned_t

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

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

Patrick Palka  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-29
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||ppalka at gcc dot gnu.org

[Bug fortran/106771] [OOP] ICE with PACK intrinsic, in gfc_conv_expr_descriptor, at fortran/trans-array.c:7328

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to federico from comment #3)
> Right: here is a version where the object is initialized: 
> 
> https://godbolt.org/z/o566cPG8P
> 
> I also see that for the versions that compile (e.g., 11.1.0), there's a
> weird SEGFAULT error at this line: 
> 
> 
> elemental logical function isa(this,i)
>class(t), intent(in) :: this
>integer, intent(in) :: i
>integer :: n
>n = merge(size(this%iloc),0,allocated(this%iloc))
>if (i>0 .and. i<=n) then ! Segmentation fault here 
>   isa = this%iloc(i)>0
>else
>   isa = .false.
>endif  
> end function isa
> 
> So it at least compiles, but apparently the bug is hidden somewhere else?

Well, the following might be the reason for failure:

   ilocs = pack(this%iloc(IDs),this%is_active(ilocs))

Here ilocs is not allocated, it is the function result.

Also Intel does not like it.

Replacing these lines with

   ilocs = pack(this%iloc(IDs),this%is_active(IDs))

makes the code run successfully for gcc versions listed under "known to work".

User error?

[Bug fortran/106771] [OOP] ICE with PACK intrinsic, in gfc_conv_expr_descriptor, at fortran/trans-array.c:7328

[federico.perini at gmail dot com via Gcc-bugs]

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

--- Comment #3 from federico  ---
Right: here is a version where the object is initialized: 

https://godbolt.org/z/o566cPG8P

I also see that for the versions that compile (e.g., 11.1.0), there's a weird
SEGFAULT error at this line: 


elemental logical function isa(this,i)
   class(t), intent(in) :: this
   integer, intent(in) :: i
   integer :: n
   n = merge(size(this%iloc),0,allocated(this%iloc))
   if (i>0 .and. i<=n) then ! Segmentation fault here 
  isa = this%iloc(i)>0
   else
  isa = .false.
   endif  
end function isa

So it at least compiles, but apparently the bug is hidden somewhere else?

[Bug fortran/106771] [OOP] ICE with PACK intrinsic, in gfc_conv_expr_descriptor, at fortran/trans-array.c:7328

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
Playing a little, I found that the issue might be related to the elemental
function isa.

The following dumb replacement

  function isa(this,i)
class(t), intent(in) :: this
integer,  intent(in) :: i(:)
logical  :: isa(size(i))
integer :: j
do j = 1, size(i)
   if (i(j)>0 .and. i(j)<=merge(size(this%iloc),0,allocated(this%iloc)))
then
  isa(j) = this%iloc(i(j))>0
   else
  isa(j) = .false.
   end if
end do
  end function isa

also avoids the ICE.

[Bug fortran/106771] [OOP] ICE with PACK intrinsic, in gfc_conv_expr_descriptor, at fortran/trans-array.c:7328

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org
  Known to fail||8.5.0
  Known to work||10.4.0, 11.3.0, 12.2.0,
   ||9.5.0
   Last reconfirmed||2022-08-29
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Keywords||ice-on-valid-code

--- Comment #1 from anlauf at gcc dot gnu.org ---
Funny.  Replacing

   ilocs = pack(this%iloc(IDs),this%is_active(ilocs))

by

   ilocs = pack(this%iloc(IDs),[this%is_active(ilocs)])

seems to be a workaround for gcc-8 - at least as far as the ICE is concerned.
(The testcase crashes at runtime with any compiler I tried, so I guess
it was reduced too much for this.)

I don't see any issues on mainline, even when running under valgrind,
so I guess the issue was fixed.

Does anybody want to do a bisection to find the commit which fixed it?

[Bug middle-end/91213] Missed optimization: (sub X Y) -> (xor X Y) when Y <= X and isPowerOf2(X + 1)

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to rdapp from comment #6)
> What's the mechanism to get range information at RTL level? The only related
> thing I saw in (e.g.) simplify-rtx.cc is nonzero_bits and this does not seem
> to be propagated from gimple.

You can get it at expand time, is that enough? Which I think the patch I had.

As far as nonzero_bits there is a project being working by Segher but I don't
know the status of it.

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

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

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

Thomas Rodgers  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Rodgers  ---
This is not a bug. The size of the waiter pool, not withstanding, the point is
you want to determine if a notify is likely to notify anything, to avoid the
very expensive (by comparison) syscall to wake the futex.

[Bug target/106748] [13 Regression] ICE in ix86_avx256_split_vector_move_misalign, at config/i386/i386-expand.cc:743 since r13-2111-g6910cad55ffc330d

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

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

H.J. Lu  changed:

   What|Removed |Added

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

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

[Bug target/106714] Incorrect casts in macros in amxtileintrin.h

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

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

H.J. Lu  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |12.3

--- Comment #3 from H.J. Lu  ---
Fixed for GCC 13 and 12.3.

[Bug target/106748] [13 Regression] ICE in ix86_avx256_split_vector_move_misalign, at config/i386/i386-expand.cc:743 since r13-2111-g6910cad55ffc330d

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

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

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

https://gcc.gnu.org/g:60d1d296b42b22b08d4eaa38bea02100c07261ac

commit r13-2253-g60d1d296b42b22b08d4eaa38bea02100c07261ac
Author: H.J. Lu 
Date:   Fri Aug 26 10:26:06 2022 -0700

x86: Handle V16BF in ix86_avx256_split_vector_move_misalign

Handle E_V16BFmode in ix86_avx256_split_vector_move_misalign and add
V16BF to V_256H iterator.

gcc/

PR target/106748
* config/i386/i386-expand.cc
(ix86_avx256_split_vector_move_misalign): Handle E_V16BFmode.
* config/i386/sse.md (V_256H): Add V16BF.

gcc/testsuite/

PR target/106748
* gcc.target/i386/pr106748.c: New test.

[Bug target/106714] Incorrect casts in macros in amxtileintrin.h

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

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-12 branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:511df912133f56dbd460326b5df1e15e06204e4e

commit r12-8725-g511df912133f56dbd460326b5df1e15e06204e4e
Author: H.J. Lu 
Date:   Thu Aug 18 14:17:33 2022 -0700

x86: Cast stride to __PTRDIFF_TYPE__ in AMX intrinsics

On 64-bit Windows, long is 32 bits and can't be used as stride in memory
operand when base is a pointer which is 64 bits.  Cast stride to
__PTRDIFF_TYPE__, instead of long.

PR target/106714
* config/i386/amxtileintrin.h (_tile_loadd_internal): Cast to
__PTRDIFF_TYPE__.
(_tile_stream_loadd_internal): Likewise.
(_tile_stored_internal): Likewise.

(cherry picked from commit aeb9b58225916bc84a0cd02c6fc77bbb92167e53)

[Bug c++/106761] [13 regression] g++.dg/modules/xtreme-header-*_b.C test cases fails after r13-2158-g02f6b405f0e9dc

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 CC||hp at gcc dot gnu.org

--- Comment #2 from Hans-Peter Nilsson  ---
Global I guess.  At least cris-elf too.

[Bug tree-optimization/61677] False positive with -Wmaybe-uninitialized (predicate analysis, VRP)

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||13.0
   Last reconfirmed|2014-07-03 00:00:00 |2022-8-29
   Keywords||needs-reduction

--- Comment #9 from Richard Biener  ---
Reconfirmed with the original testcase.

[Bug c/106765] [12/13 Regression] ICE (invalid code) in tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc since r12-7222-g3f10e0d50b5e3b3f

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.3
   Priority|P3  |P4

[Bug tree-optimization/56654] uninit warning behaves erratically (always executed block, "is" vs "may", order when walking uses)

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
We do now diagnose "is used uninitialized", the ordering issue remains and I
have a patch for that that sorts after RPO but doesn't sort within the block if
there is more than one candidate.

[Bug tree-optimization/54554] fails to warn for uninitialized var within loop always taken at -O0

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||13.0
   Last reconfirmed|2012-09-12 00:00:00 |2022-8-29

--- Comment #11 from Richard Biener  ---
Re-confirmed.

[Bug tree-optimization/47386] Wrong warning: ‘w.dim[2].stride’ may be used uninitialized in this function [-Wuninitialized]

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||12.2.0

--- Comment #4 from Richard Biener  ---
Re-confirmed with GCC 12 and trunk.  We diagnose a use of w.dim[1].ubound
conditional on ubound.1 > 0 && ll == 0.  I believe we're jump-threading
if (ll) around the T = 0 stmt and then mixing up paths.  -fno-thread-jumps
fixes
the thing.

[Bug c/106764] ICE on invalid code in tree check: expected function_type or method_type, have error_mark in gimplify_call_expr, at gimplify.cc

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||roger at nextmovesoftware dot 
com
   Last reconfirmed||2022-08-29
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Started with r12-3278-g823685221de986af.

[Bug c/106765] [12/13 Regression] ICE (invalid code) in tree check: expected class 'type', have 'exceptional' (error_mark) in create_tmp_from_val, at gimplify.cc since r12-7222-g3f10e0d50b5e3b3f

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-29
 Ever confirmed|0   |1
Summary|ICE (invalid code) in tree  |[12/13 Regression] ICE
   |check: expected class   |(invalid code) in tree
   |'type', have 'exceptional'  |check: expected class
   |(error_mark) in |'type', have 'exceptional'
   |create_tmp_from_val, at |(error_mark) in
   |gimplify.cc |create_tmp_from_val, at
   ||gimplify.cc since
   ||r12-7222-g3f10e0d50b5e3b3f
 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with r12-7222-g3f10e0d50b5e3b3f.

[Bug c++/106760] ICE: tree check: expected function_decl, have template_decl in get_fndecl_argument_location, at cp/call.cc:7801

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-29
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Started with r12-3346-g47543e5f9d1fc502.

[Bug middle-end/47307] Uninitialized in this function: warning for initialized, no warning for uninitialized

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
The convrt thing is now working, the lopt diagnostic is given at -O0, the read
is indeed eliminated with optimization.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 47307 Summary: Uninitialized in this function: warning for initialized, no 
warning for uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47307

   What|Removed |Added

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

[Bug tree-optimization/101573] uninitialized warning could not appear correclty in -O0 optimisation level

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||phresnel at gmail dot com

--- Comment #5 from Richard Biener  ---
*** Bug 43361 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/43361] missing uninitialized warning without optimization (-O0) (PHI in always_executed basic block)

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #16 from Richard Biener  ---
Note GCC 12 now diagnoses this at -O0, reporting the first use:

> ../../obj-gcc12-g/gcc/cc1 -quiet t.c -Wall
t.c: In function 'main':
t.c:5:13: warning: variable 'array' set but not used
[-Wunused-but-set-variable]
5 | int array[10];
  | ^
t.c:6:17: warning: 'i' is used uninitialized [-Wuninitialized]
6 | for (; i<10; ++i) { // no warning
  |~^~~
t.c:4:13: note: 'i' was declared here
4 | int i;
  | ^

PR101573 is a "duplicate" we have a testcase for now.

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

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 43361 Summary: missing uninitialized warning without optimization (-O0) 
(PHI in always_executed basic block)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43361

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 34721 Summary: Output statements fool the -Wuninitialized option
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34721

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug fortran/34721] Output statements fool the -Wuninitialized option

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #6 from Richard Biener  ---
really duplicate of PR19430

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

[Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM)

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||dominiq at lps dot ens.fr

--- Comment #38 from Richard Biener  ---
*** Bug 34721 has been marked as a duplicate of this bug. ***

[Bug fortran/31279] Uninitialized warning for call-by-reference arguments with known intent(in)

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

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

--- Comment #8 from Richard Biener  ---
The original testcase hides everything behind array descriptors, even with
unrolling and vectorization disabled we end up with

   [local count: 214748368]:
  parm.0.data = [0];
  parm.0.offset = -1;
  parm.0.dtype.elem_len = 4;
  MEM  [(void *) + 24B] = 1103806595072;
  parm.0.span = 4;
  parm.0.dim[0].stride = 1;
  parm.0.dim[0].lbound = 1;
  parm.0.dim[0].ubound = 4;
  atmp.1.data = 
  atmp.1.offset = 0;
  atmp.1.dtype.elem_len = 4;
  MEM  [(void *) + 24B] = 1103806595072;
  atmp.1.span = 4;
  atmp.1.dim[0].stride = 1;
  atmp.1.dim[0].lbound = 0;
  atmp.1.dim[0].ubound = 3;
  _gfortran_cshift0_4 (, , , 0B);

the frontend might set the fnspec correctly to r (read-only, even transitively)
which we might use here but then the actual use is the intrinsic and the
fnspec does not say that the function acrually reads from the uninitialized
storage.

[Bug middle-end/19430] taking address of a var causes missing uninitialized warning (virtual PHI with MEM)

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed|2005-05-03 18:04:44 |2022-8-29

--- Comment #37 from Richard Biener  ---
Re-confirmed for the original testcase.  The issue is that while we now try to
perform uninitialized diagnostics for memory we do not perform the maybe-uninit
analysis via PHIs we do for non-memory.  We see

   [local count: 1073741824]:
  # .MEM_5 = VDEF <.MEM_3(D)>
  _1 = bar (i_4(D));
  if (_1 != 0)
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 719407024]:
  goto ; [100.00%]

   [local count: 354334800]:
  # .MEM_6 = VDEF <.MEM_5>
  baz ();

   [local count: 1073741824]:
  # .MEM_2 = PHI <.MEM_5(5), .MEM_6(3)>
  # VUSE <.MEM_2>
  _7 = j;

so when we are walking and looking for defs of 'j' by means of
walk_aliased_vdefs but that will simply process MEM_6 "unordered"
and record that as possible definition.  We are not properly forking
the walk to discover a path where 'j' is not initialized nor are
we trying to compute predicates which guard the use.

[Bug target/106768] lto1.exe: internal compiler error: in dwarf2out_finifsh, at dwarf2out.c:31350

[johann.taferl at gmx dot at via Gcc-bugs]

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

--- Comment #2 from Johann Taferl  ---
I'm very sorry, but I do not know how to debug the compiler it self.
I only download the toolchain form the ARM homepage. I was glad to get all work
as it is.

Any suggestions how I might be of help?

[Bug libstdc++/106772] atomic::wait shouldn't touch waiter pool if used platform wait

[valera.mironow at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Mkkt Bkkt  ---
libc++ implementation do it.
msvc stl of course too.

[Bug libstdc++/106772] New: atomic::wait shouldn't touch waiter pool if used platform wait

[valera.mironow at gmail dot com via Gcc-bugs]

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

Bug ID: 106772
   Summary: atomic::wait shouldn't touch waiter pool if used
platform wait
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: valera.mironow at gmail dot com
  Target Milestone: ---

atomic::wait shouldn't touch waiter pool if used platform wait.

Because otherwise it affected by waiter pool bugs.
And performance can degrade on machine with many cores, because waiter pool
have only 16 cells.
Also it makes fetch_add with seq_cst, that can hide synchronization issue

[Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:87a07e96dc4e6849ab6ac0b1ceeb5a19aebee9d6

commit r12-8724-g87a07e96dc4e6849ab6ac0b1ceeb5a19aebee9d6
Author: Jakub Jelinek 
Date:   Fri Aug 26 09:56:19 2022 +0200

fortran: Expand ieee_arithmetic module's ieee_value inline [PR106579]

The following patch expands IEEE_VALUE function inline in the FE,
but only for the powerpc64le-linux IEEE quad real(kind=16) case.

2022-08-26  Jakub Jelinek  

PR fortran/106579
* trans-intrinsic.cc: Include realmpfr.h.
(conv_intrinsic_ieee_value): New function.
(gfc_conv_ieee_arithmetic_function): Handle ieee_value.

(cherry picked from commit 0c2d6aa1be2ea85e751852834986ae52d58134d3)

[Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:

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

commit r12-8723-gc5d4e67e764fb157404142cfc8d2bc4436fcf0f5
Author: Jakub Jelinek 
Date:   Fri Aug 26 09:52:02 2022 +0200

fortran: Expand ieee_arithmetic module's ieee_class inline [PR106579]

The following patch expands IEEE_CLASS inline in the FE but only for the
powerpc64le-linux IEEE quad real(kind=16), using the __builtin_fpclassify
builtin and explicit check of the MSB mantissa bit in place of missing
__builtin_signbit builtin.

2022-08-26  Jakub Jelinek  

PR fortran/106579
gcc/fortran/
* f95-lang.cc (gfc_init_builtin_functions): Initialize
BUILT_IN_FPCLASSIFY.
* libgfortran.h (IEEE_OTHER_VALUE, IEEE_SIGNALING_NAN,
IEEE_QUIET_NAN, IEEE_NEGATIVE_INF, IEEE_NEGATIVE_NORMAL,
IEEE_NEGATIVE_DENORMAL, IEEE_NEGATIVE_SUBNORMAL,
IEEE_NEGATIVE_ZERO, IEEE_POSITIVE_ZERO, IEEE_POSITIVE_DENORMAL,
IEEE_POSITIVE_SUBNORMAL, IEEE_POSITIVE_NORMAL, IEEE_POSITIVE_INF):
New enum.
* trans-intrinsic.cc (conv_intrinsic_ieee_class): New function.
(gfc_conv_ieee_arithmetic_function): Handle ieee_class.
libgfortran/
* ieee/ieee_helper.c (IEEE_OTHER_VALUE, IEEE_SIGNALING_NAN,
IEEE_QUIET_NAN, IEEE_NEGATIVE_INF, IEEE_NEGATIVE_NORMAL,
IEEE_NEGATIVE_DENORMAL, IEEE_NEGATIVE_SUBNORMAL,
IEEE_NEGATIVE_ZERO, IEEE_POSITIVE_ZERO, IEEE_POSITIVE_DENORMAL,
IEEE_POSITIVE_SUBNORMAL, IEEE_POSITIVE_NORMAL, IEEE_POSITIVE_INF):
Move to gcc/fortran/libgfortran.h.

(cherry picked from commit db630423a97ec6690a8eb0e5c3cb186c91e3740d)

[Bug target/106721] Error: invalid character '<' in mnemonic since r13-2122-g86c0d98620ee3a

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:0784ef5e2a7ea72614aa600dccb29e926e46bab6

commit r12-8722-g0784ef5e2a7ea72614aa600dccb29e926e46bab6
Author: Jakub Jelinek 
Date:   Wed Aug 24 09:57:09 2022 +0200

i386: Fix up mode iterators that weren't expanded [PR106721]

Currently, when md file reader sees  and something is valid mode
(or code) attribute but which doesn't include case for the current mode
(or code), it just keeps the  untouched.
I went through all cases matching <[a-zA-Z] in tmp-mddump.md after make
mddump.
One of the cases was related to the V*HF mode additions and there was one
typo.

2022-08-24  Jakub Jelinek  

PR target/106721
* config/i386/sse.md (i128vldq): Add V16HF entry.
(avx512er_vmrcp28): Fix typo,
mask_opernad3 -> mask_operand3.

(cherry picked from commit 846e5c009e360f0c4fe58ff0d3aee03ebe3ca1a9)

[Bug rtl-optimization/106590] [12/13 Regression] x86-64 miscompilation starting with r12-8233-g1ceddd7497e15d w/ mtune=skylake

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

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

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

https://gcc.gnu.org/g:030063c43f30a2335d3c03182df0beb82d003816

commit r12-8720-g030063c43f30a2335d3c03182df0beb82d003816
Author: Jakub Jelinek 
Date:   Mon Aug 15 13:56:57 2022 +0200

ifcvt: Fix up noce_convert_multiple_sets [PR106590]

The following testcase is miscompiled on x86_64-linux.
The problem is in the noce_convert_multiple_sets optimization.
We essentially have:
if (g == 1)
  {
g = 1;
f = 23;
  }
else
  {
g = 2;
f = 20;
  }
and for each insn try to create a conditional move sequence.
There is code to detect overlap with the regs used in the condition
and the destinations, so we actually try to construct:
tmp_g = g == 1 ? 1 : 2;
f = g == 1 ? 23 : 20;
g = tmp_g;
which is fine.  But, we actually try to create two different
conditional move sequences in each case, seq1 with the whole
(eq (reg/v:HI 82 [ g ]) (const_int 1 [0x1]))
condition and seq2 with cc_cmp
(eq (reg:CCZ 17 flags) (const_int 0 [0]))
to rely on the earlier present comparison.  In each case, we
compare the rtx costs and choose the cheaper sequence (seq1 if both
have the same cost).
The problem is that with the skylake tuning,
tmp_g = g == 1 ? 1 : 2;
is actually expanded as
tmp_g = (g == 1) + 1;
in seq1 (which clobbers (reg 17 flags)) and as a cmov in seq2
(which doesn't).  The tuning says both have the same cost, so we
pick seq1.  Next we check sequences for
f = g == 1 ? 23 : 20; and here the seq2 cmov is cheaper, but it
uses (reg 17 flags) which has been clobbered earlier.

The following patch fixes that by detecting if we in the chosen
sequence clobber some register mentioned in cc_cmp or rev_cc_cmp,
and if yes, arranges for only seq1 (i.e. sequences that emit the
comparison itself) to be used after that.

2022-08-15  Jakub Jelinek  

PR rtl-optimization/106590
* ifcvt.cc (check_for_cc_cmp_clobbers): New function.
(noce_convert_multiple_sets_1): If SEQ sets or clobbers any regs
mentioned in cc_cmp or rev_cc_cmp, don't consider seq2 for any
further conditional moves.

* gcc.dg/torture/pr106590.c: New test.

(cherry picked from commit 3a74a7bf62f47ed0d19866576378724be932ee17)

[Bug fortran/106771] New: [OOP] ICE with PACK intrinsic, in gfc_conv_expr_descriptor, at fortran/trans-array.c:7328

[federico.perini at gmail dot com via Gcc-bugs]

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

Bug ID: 106771
   Summary: [OOP] ICE with PACK intrinsic, in
gfc_conv_expr_descriptor, at
fortran/trans-array.c:7328
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: federico.perini at gmail dot com
  Target Milestone: ---

I'm getting an ICE using the PACK intrinsic from within a polymorphic entity.
There are several similar bugs reported, but none seems to address PACK, so I'm
opening a new ticket. BTW: I've tested it on godbolt (try here:
https://godbolt.org/z/cnj6PzqKz)
And it looks like: 

WORKS on: 10.4.0, 11 (all), 12 (all)
ICE   on: 4.9, 5-8 (all), 9 (all), 10.1, 10.2, 10.3

The mask is created from a polymorphic elemental function on the object
Here's a minimal example: 

module test
implicit none

type::t
   integer, allocatable :: iloc(:)
   contains 
  procedure :: is_active => isa
  procedure :: list2loc => myfun_poly
end type t

contains

elemental logical function isa(this,i)
   class(t), intent(in) :: this
   integer, intent(in) :: i
   if (i>0 .and. i<=merge(size(this%iloc),0,allocated(this%iloc))) then 
  isa = this%iloc(i)>0
   else
  isa = .false.
   endif  
end function isa

! internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:7328
function myfun_poly(this,IDs) result (ilocs)
class(t), intent(in) :: this
integer, intent(in) :: IDs(:)
integer, allocatable :: ilocs(:)
if (size(IDs)<=0) then
   allocate(ilocs(0))
else
   ilocs = pack(this%iloc(IDs),this%is_active(ilocs))
endif
end function myfun_poly

! WORKS
function myfun(this,IDs) result (ilocs)
type(t), intent(in) :: this
integer, intent(in) :: IDs(:)
integer, allocatable :: ilocs(:)
if (size(IDs)<=0) then
   allocate(ilocs(0))
else
   ilocs = pack(this%iloc(IDs),this%is_active(ilocs))
endif
end function myfun
end module test

program testp
   use test
   implicit none

   type(t) :: a

   integer :: rnd(100)
   real :: x(100)
   integer, allocatable :: list(:)

   call random_number(x); rnd = ceiling(x*100)

   ! Works
   list = myfun(a,rnd)
   ! ICE
   list = a%list2loc(rnd)

   print *, 'list=',list

end program testp


Hope this helps,
federico

[Bug target/106770] PPCLE: Unnecessary xxpermdi before mfvsrd

[jens.seifert at de dot ibm.com via Gcc-bugs]

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

--- Comment #2 from Jens Seifert  ---
vec_extract(vr, 1) should extract the left element. But xxpermdi x,x,x,3
extracts the right element.
Looks like a bug in vec_extract for PPCLE and not a problem regarding
unnecessary xxpermdi.

Using assembly for the subtract:
int cmp3(double a, double b)
{
vector double va = vec_promote(a, 0);
vector double vb = vec_promote(b, 0);
vector long long vlt = (vector long long)vec_cmplt(va, vb);
vector long long vgt = (vector long long)vec_cmplt(vb, va);
vector signed long long vr;
__asm__ volatile("vsubudm %0,%1,%2":"=v"(vr):"v"(vlt),"v"(vgt):);
//vector signed long long vr = vec_sub(vlt, vgt);

return vec_extract(vr, 1);
}

generates:

_Z4cmp3dd:
.LFB2:
.cfi_startproc
xxpermdi 1,1,1,0
xxpermdi 2,2,2,0
xvcmpgtdp 32,2,1
xvcmpgtdp 33,1,2
#APP
 # 34 "cmpdouble.C" 1
vsubudm 0,0,1
 # 0 "" 2
#NO_APP
mfvsrd 3,32
extsw 3,3
"

Looks like the compile knows about the vec_promote doing splat and at the end
extracts the non-preferred right element instead of the expected left element.

[Bug preprocessor/106767] Failure to detect recursive macro calls due to _Pragma(pop_macro)

[izbyshev at ispras dot ru via Gcc-bugs]

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

--- Comment #5 from Alexey Izbyshev  ---
(In reply to Richard Biener from comment #4)
> Is there a public specification of the Microsoft extension and how it is
> supposed to behave with recursion or is the recursion behavior specified
> by the C standard?

I would be surprised if anything that could be called "a public specification"
exists. The Clang patch[1] from 2010 cites only the rudimentary MSDN
documentation[2].

I've modified the first test case to be compilable to assembler to avoid
relying on broken /E:

#define P(x) _Pragma(#x)
#define f() P(push_macro("f")) P(pop_macro("f")) f()
int f() {
return 42;
}

and have checked that:

* All x64 MSVC versions supporting C99 _Pragma and available at godbolt
(19.25-19.33/latest) successfully compile it (with and without /Zc:preprocessor
option which enables standard-conforming preprocessor, where it's supported).
The only exception is 19.26 with /Zc:preprocessor: it emits strange syntax
errors, but that's likely a bug in the new preprocessor (19.26 is the first
version supporting it).

* All x64 MSVC versions available at godbolt (19.0, 19.10, 19.14-19.33/latest)
successfully compile the same test case with _Pragma(#x) replaced with
MSVC-specific __pragma(x) equivalent (again, with and without /Zc:preprocessor
where supported).

This suggests that push/pop_macro isn't supposed to interfere with recursion
detection.

[1]
https://github.com/llvm/llvm-project/commit/c0a585d63c6cf700ea01f1fe30c9f4cd51c1e97b
[2] https://docs.microsoft.com/en-us/cpp/preprocessor/push-macro

[Bug target/100869] z13: Inefficient code for vec_reve(vector double)

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Robin Dapp :

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

commit r13-2248-g8cdebe087619329facf19ba849d4d489a9a933e2
Author: Robin Dapp 
Date:   Fri Jun 24 15:15:14 2022 +0200

s390: Use vpdi and verllg in vec_reve.

Swapping the two elements of a V2DImode or V2DFmode vector can be done
with vpdi instead of using the generic way of loading a permutation mask
from the literal pool and vperm.

Analogous to the V2DI/V2DF case reversing the elements of a four-element
vector can be done by first swapping the elements of the first
doubleword as well the ones of the second one and subsequently rotate
the doublewords by 32 bits.

gcc/ChangeLog:

PR target/100869
* config/s390/vector.md (@vpdi4_2): New pattern.
(rotl3_di): New pattern.
* config/s390/vx-builtins.md: Use vpdi and verll for reversing
elements.

gcc/testsuite/ChangeLog:

* gcc.target/s390/zvector/vec-reve-int-long.c: New test.

[Bug testsuite/106680] Test gcc.target/powerpc/bswap64-4.c fails on 32-bit BE

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

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

Kewen Lin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
   Last reconfirmed||2022-08-29

--- Comment #2 from Kewen Lin  ---
Confirmed, I can reproduce it with cfarm machine gcc110, the issue is exactly
like what its comment describes. I have a patch.

[Bug target/106768] lto1.exe: internal compiler error: in dwarf2out_finifsh, at dwarf2out.c:31350

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
  Component|c++ |target
  Known to work||9.2.1
 Ever confirmed|0   |1
   Last reconfirmed||2022-08-29
 Target||arm-none-eabi
  Known to fail||10.3.1, 11.2.1

--- Comment #1 from Richard Biener  ---
Likely a target issue.  The lines of the 11.2.1 ICE may match up

  /* We shouldn't have any symbols with delayed asm names for
 DIEs generated after early finish.  */
  gcc_assert (deferred_asm_name == NULL);

but to be sure we'd need a reproducer.  Maybe you can debug this a bit yourself
and check what, after dwarf2out_early_finish, makes deferred_asm_name non-NULL
(if that is indeed the ICE)

[Bug preprocessor/106767] Failure to detect recursive macro calls due to _Pragma(pop_macro)

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org,
   ||ktietz at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-08-29

--- Comment #4 from Richard Biener  ---
Not sure if Kai is still active but he contributed push/pop_macro support.

Is there a public specification of the Microsoft extension and how it is
supposed to behave with recursion or is the recursion behavior specified
by the C standard?

[Bug c/106764] ICE on invalid code in tree check: expected function_type or method_type, have error_mark in gimplify_call_expr, at gimplify.cc

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

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

--- Comment #1 from Richard Biener  ---
fuzzing source is going to turn up a lot of error-recovery cases - while
somewhat interesting they will inevitably be very low priority since GCC has
mechanisms to present the user with a nicer error message in such case for
production builds.

So yes, they are interesting - they would be even more interesting if you
provide fixes alongside with the bugreports ;)

(you can search bugzilla for ice-on-invalid-code + error-recovery)

More interesting are ICEs that do not report an error before.

[Bug c/106762] incorrect array bounds warning (-Warray-bounds) at -O2 on memset()

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2022-08-29
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
GCC diagnoses

(gdb) p debug_gimple_stmt (call)
# .MEM_11 = VDEF <.MEM_5(D)>
memset (8B, 255, 8);

which it carefully isolated:

 [local count: 1073741824]:
_1 = ary_6(D)->objcnt;
if (_1 != 0)
  goto ; [100.00%]
else
  goto ; [0.00%]

 [local count: 536870913]:
_2 = ary_6(D)->objary;
_3 = &_2->field1;
memset (_3, 255, 8);
_2->field0 = 0;
return;

 [count: 0]:
memset (8B, 255, 8);
MEM[(struct obj_t *)0B].field0 ={v} 0;
__builtin_trap ();

that is, your code, if ary->objcnt == 0, calls memset (>field1, 0xff, 8).

But maybe you over-reduced the testcase?  If not then GCC is certainly
correct here and your code is bogus.

[Bug c++/106761] [13 regression] g++.dg/modules/xtreme-header-*_b.C test cases fails after r13-2158-g02f6b405f0e9dc

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-29
   Target Milestone|--- |13.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
I've also seen this on x86_64-linux.

[Bug tree-optimization/106757] [12/13 Regression] Incorrect "writing 1 byte into a region of size 0" on a vectorized loop

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

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

--- Comment #2 from Richard Biener  ---
The unroller has code to put unreachable()s in paths like those but it's
imperfect.

[Bug c++/106756] [13 Regression] Overbroad friendship for nested classes

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
Summary|Overbroad friendship for|[13 Regression] Overbroad
   |nested classes  |friendship for nested
   ||classes

[Bug target/106682] Powerpc test gcc.target/powerpc/pr86731-fwrapv-longlong.c fails on power8, passes on power9/power10

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

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

Kewen Lin  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |linkw at gcc dot gnu.org
 CC||linkw at gcc dot gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2022-08-29

--- Comment #1 from Kewen Lin  ---
Confirmed, it's a test issue.

On Power8 the assembly uses lvx instead of lxv (Power9 specific) by making the
storage aligned. It's due to r12-2266, which was meant to change lxv but leave
lvx unchanged, so a typo.

[Bug target/106770] PPCLE: Unnecessary xxpermdi before mfvsrd

[jens.seifert at de dot ibm.com via Gcc-bugs]

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

--- Comment #1 from Jens Seifert  ---
vec_extract(vr, 1) should extract the left element. But xxpermdi x,x,x,3
extracts the right element.
Looks like a bug in vec_extract for PPCLE and not a problem regarding
unnecessary xxpermdi.

[Bug target/106770] New: PPCLE: Unnecessary xxpermdi before mfvsrd

[jens.seifert at de dot ibm.com via Gcc-bugs]

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

Bug ID: 106770
   Summary: PPCLE: Unnecessary xxpermdi before mfvsrd
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.seifert at de dot ibm.com
  Target Milestone: ---

#include 

int cmp2(double a, double b)
{
vector double va = vec_promote(a, 1);
vector double vb = vec_promote(b, 1);
vector long long vlt = (vector long long)vec_cmplt(va, vb);
vector long long vgt = (vector long long)vec_cmplt(vb, va);
vector signed long long vr = vec_sub(vlt, vgt);

return vec_extract(vr, 1);
}

Generates:

_Z4cmp2dd:
.LFB1:
.cfi_startproc
xxpermdi 1,1,1,0
xxpermdi 2,2,2,0
xvcmpgtdp 33,2,1
xvcmpgtdp 32,1,2
vsubudm 0,1,0
xxpermdi 0,32,32,3
mfvsrd 3,0
extsw 3,3
blr

The unnecessary xxpermdi for vec_promote are already reported in another
bugzilla case.

mfvsrd can access all 64 vector registers directly and xxpermdi is not
required.
mfvsrd 3,32 expected instead xxpermdi 0,32,32,3 + mfvsrd 3,0

[Bug middle-end/91213] Missed optimization: (sub X Y) -> (xor X Y) when Y <= X and isPowerOf2(X + 1)

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

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

rdapp at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rdapp at gcc dot gnu.org

--- Comment #6 from rdapp at gcc dot gnu.org ---
What's the mechanism to get range information at RTL level? The only related
thing I saw in (e.g.) simplify-rtx.cc is nonzero_bits and this does not seem to
be propagated from gimple.

[Bug target/106769] New: PPCLE: vec_extract(vector unsigned int) unnecessary rldicl after mfvsrwz

[jens.seifert at de dot ibm.com via Gcc-bugs]

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

Bug ID: 106769
   Summary: PPCLE: vec_extract(vector unsigned int) unnecessary
rldicl after mfvsrwz
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.seifert at de dot ibm.com
  Target Milestone: ---

#include 

unsigned int extr(vector unsigned int v)
{
   return vec_extract(v, 2);
}

Generates:

_Z4extrDv4_j:
.LFB1:
.cfi_startproc
mfvsrwz 3,34
rldicl 3,3,0,32
blr
.long 0
.byte 0,9,0,0,0,0,0,0
.cfi_endproc


The rldicl is not necessary as mfvsrwz already wiped out the upper 32 bits of
the register.

[Bug c++/106768] New: lto1.exe: internal compiler error: in dwarf2out_finifsh, at dwarf2out.c:31350

[johann.taferl at gmx dot at via Gcc-bugs]

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

Bug ID: 106768
   Summary: lto1.exe: internal compiler error: in
dwarf2out_finifsh, at dwarf2out.c:31350
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johann.taferl at gmx dot at
  Target Milestone: ---

I am using the
- GNU Arm Embedded Toolchain in version 10.3-2021.10 (GCC 10.3.1) and 
- CMake 3.17.0 on
- Windows 10 Enterprise Build 19044.1889

Compiled with -Wall -Wextra and the compiler states not one warning in the
whole project.

Building in MinSizeRel.

GNU Arm Embedded Toolchain in version 9-2019-q4 (GCC 9.2.1) works fine.
Same Problem with gcc-arm-11.2-2022.02-mingw-w64-i686-arm-none-eabi (GCC
11.2.1)

Not allowed to add sources.

Command line output GCC 10.3.1:

[build] 
c:/projects/et-software/p536-macolock/fw/btmodule_v2.x/devtools/gcc-arm-none-eabi-10.3-2021.10-win32/lib/gcc/arm-none-eabi/10.3.1/lto1.exe
-quiet -dumpdir ./ -dumpbase BTModule_App.elf.ltrans2 -mfloat-abi=soft -mthumb
-mcpu=cortex-m4 -mfloat-abi=soft -mlibarch=armv7e-m -march=armv7e-m
-auxbase-strip
C:\Users\tajo\AppData\Local\Temp\BTModule_App.elf.OB7v3j.ltrans2.ltrans.o -g
-O2 -Os -Wno-psabi -Wpedantic -Wextra -Wno-unused-parameter -version
-fno-openmp -fno-openacc -fno-pie -fcf-protection=none -fabi-version=6
-fno-exceptions -fdata-sections -ffunction-sections -fltrans
@C:\Users\tajo\AppData\Local\Temp\cc1WE0zi -o
C:\Users\tajo\AppData\Local\Temp\ccO9nf4q.s
[build] GNU GIMPLE (GNU Arm Embedded Toolchain 10.3-2021.10) version 10.3.1
20210824 (release) (arm-none-eabi)
[build] compiled by GNU C version 7.3-win32 20180312, GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP
[build] 
[build] GGC heuristics: --param ggc-min-expand=100 --param
ggc-min-heapsize=131072
[build] GNU GIMPLE (GNU Arm Embedded Toolchain 10.3-2021.10) version 10.3.1
20210824 (release) (arm-none-eabi)
[build] compiled by GNU C version 7.3-win32 20180312, GMP version
6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP
[build] 
[build] GGC heuristics: --param ggc-min-expand=100 --param
ggc-min-heapsize=131072
[build] lto1.exe: internal compiler error: in dwarf2out_finish, at
dwarf2out.c:31350
[build] Please submit a full bug report,
[build] with preprocessed source if appropriate.
[build] See  for instructions.
[build] lto-wrapper.exe: fatal error:
c:\Projects\ET-Software\P536-MacoLock\FW\BTModule_V2.x\devtools\gcc-arm-none-eabi-10.3-2021.10-win32\bin\arm-none-eabi-g++.exe
returned 1 exit status
[build] compilation terminated.
[build] libdeLibraryCpp.a@0x20 ../deLibraryCpp/libdeLibraryCpp.a@0x394274
../deLibraryCpp/libdeLibraryCpp.a@0x479730
../deLibraryCpp/libdeLibraryCpp.a@0x4d9124
../deLibraryCpp/libdeLibraryCpp.a@0x4da704
../deLibraryCpp/libdeLibraryCpp.a@0x4e4398
../deLibraryCpp/libdeLibraryCpp.a@0x4e84c0
../deLibraryCpp/libdeLibraryCpp.a@0x4e9148
../deLibraryCpp/libdeLibraryCpp.a@0x517e04
../deLibraryCpp/libdeLibraryCpp.a@0x536bd8
../deLibraryCpp/libdeLibraryCpp.a@0x544d78
../deLibraryCpp/libdeLibraryCpp.a@0x55e280
../deLibraryCpp/libdeLibraryCpp.a@0x57daac
../deLibraryCpp/libdeLibraryCpp.a@0x5ac63c
../deLibraryCpp/libdeLibraryCpp.a@0x5d6d0c
../deLibraryCpp/libdeLibraryCpp.a@0x5ea014
../deLibraryCpp/libdeLibraryCpp.a@0x60b8b0
../deLibraryCpp/libdeLibraryCpp.a@0x61dba0
../deLibraryCpp/libdeLibraryCpp.a@0x639ffc
../deLibraryCpp/libdeLibraryCpp.a@0x685a2c
../deLibraryCpp/libdeLibraryCpp.a@0x6ad700
../deLibraryCpp/libdeLibraryCpp.a@0x9f29f4
../deLibraryCpp/libdeLibraryCpp.a@0xa04eac
../deLibraryCpp/libdeLibraryCpp.a@0xa289d4
../deLibraryCpp/libdeLibraryCpp.a@0xa7fd34
../deLibraryCpp/libdeLibraryCpp.a@0xa9ec80
../deLibraryCpp/libdeLibraryCpp.a@0xabe988
../deLibraryCpp/libdeLibraryCpp.a@0xade1d8
../deLibraryCpp/libdeLibraryCpp.a@0xb1bd0c
../deLibraryCpp/libdeLibraryCpp.a@0xb3feac
../deLibraryCpp/libdeLibraryCpp.a@0xb99684
../deLibraryCpp/libdeLibraryCpp.a@0xba74e4
../deLibraryCpp/libdeLibraryCpp.a@0xbbdcc8
../deLibraryCpp/libdeLibraryCpp.a@0xbcee94
../deLibraryCpp/libdeLibraryCpp.a@0xbd9e78
../deLibraryCpp/libdeLibraryCpp.a@0xcac31c
../deLibraryCpp/libdeLibraryCpp.a@0xcc1888
../deLibraryCpp/libdeLibraryCpp.a@0xcc69d8
../deLibraryCpp/libdeLibraryCpp.a@0xce2ad8
../deLibraryCpp/libdeLibraryCpp.a@0xce8ff0
../deLibraryCpp/libdeLibraryCpp.a@0xd2e52c
../deLibraryCpp/libdeLibraryCpp.a@0xd360fc
../deLibraryCpp/libdeLibraryCpp.a@0x8ff64
../deLibraryCpp/libdeLibraryCpp.a@0xf05ec
../deLibraryCpp/libdeLibraryCpp.a@0xfa5b8
../deLibraryCpp/libdeLibraryCpp.a@0x112aec
../deLibraryCpp/libdeLibraryCpp.a@0x12b6b8
../deLibraryCpp/libdeLibraryCpp.a@0xa8bf0
../BTModule_Common/libBTModule_Common.a@0x1ba4
../BTModule_Common/libBTModule_Common.a@0x205cc
../BTModule_Common/libBTModule_Common.a@0x2293c 
[build]