[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org
   Priority|P1  |P3

--- Comment #24 from Xi Ruoyao  ---
So no longer a P1.

[Bug target/109091] AIX: thread_local is not being internally linked

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
dup.

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

[Bug target/93146] C++ TLS init function not generated on AIX

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

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

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

[Bug target/100641] Link error when using extern thread_local variables on AIX

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Dup.

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

[Bug target/93146] C++ TLS init function not generated on AIX

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||miladfarca at gmail dot com

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

[Bug c++/87090] Constexpr variables in functions are not optimized correctly

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org
   Severity|normal  |enhancement

[Bug c++/78160] explicit template instantation with hidden symbols fails

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Keywords||visibility
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
This is the correct behavior for visibility.

Since base_spec_uint8 is hidden, that means the type in the shared library and
the main program are considered 2 different types.

In the case of you explictly instantiate var_t (which
instantiates var_t::alloc) but that has a hidden visibility as
base_spec_uint8 has a hidden visbility. so var_t::alloc will
be hidden in the shared object too and not exported.

>From the .s generated from .cc file of the library (passed through the
demangler):
.hidden var_t::alloc()

So if you create a share object, well that is going to be hidden inside that
shared object and not exported.

This behavior is described in the manual even:
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Common-Function-Attributes.html
In C++, if a template argument has limited visibility, this restriction is
implicitly propagated to the template instantiation. Otherwise, template
instantiations and specializations default to the visibility of their template.

If both the template and enclosing class have explicit visibility, the
visibility from the template is used.

[Bug c++/62192] Segmentation fault when linking with Qt libraries

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #1 from Andrew Pinski  ---
Without a self-contained testcase it is hard to debug this. Especially when it
needs a libQT. Also this could have been a freebsd libc/ld.so issue too.

[Bug c++/65608] [meta-bug] friend issues

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

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

Bug 51757 Summary: friend defined inside class and declared inside main linker 
error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51757

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug c++/51757] friend defined inside class and declared inside main linker error

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #7 from Andrew Pinski  ---
Fixed by r11-3699-g4e62aca0e0520e4e .

[Bug fortran/114618] New: Format produces incorrect output when contains 1x, ok when uses " "

[urbanjost at comcast dot net via Gcc-bugs]

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

Bug ID: 114618
   Summary: Format produces incorrect output when contains 1x, ok
when uses " "
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: urbanjost at comcast dot net
  Target Milestone: ---

The format gen2 does what I would expect the format gen1 does,
but get very strange output when use 1x (in gen1)  instead of space character
(in gen2).

program tryit
   implicit none
   integer, parameter :: wp = kind(0d0)
   real(kind=wp) :: pi  =
3.14159265358979323846264338327950288419716939937510582097494459230_wp
   character(len=*), parameter:: gen1 = '(19("."),t1,g0,1x,t21,g0)'
   character(len=*), parameter:: gen2 = '(19("."),t1,g0," ",t21,g0)'
   character(len=:), allocatable :: fmt
   integer :: i, j
   do i=1,2
  select case(i)
  case(1); fmt=gen1
  case(2); fmt=gen2
  end select
  do j=1,2
 write (*, fmt) 'PI', pi
 write (*, fmt) 'REAL(PI)', real(pi)
 write (*, fmt) 'DBLE(PI)', dble(pi)
 write (*, fmt) 'RADIX', radix(pi)
 write (*, fmt) 'RANGE', range(pi)
 write (*, fmt) 'PRECISION', precision(pi)
 write (*,'(80("-"))')
  enddo
   enddo
end program tryit

PI.^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ 3.1415926535897931
REAL(PI)...^@^@^@^@^@^@^@^@^@^@^@ 3.14159274
DBLE(PI)...^@^@^@^@^@^@^@^@^@^@^@ 3.1415926535897931
RADIX..^@^@^@^@^@^@^@^@^@^@^@ 3. 2
RANGE..^@^@^@^@^@^@^@^@^@^@^@ 3. 307
PRECISION..^@^@^@^@^@^@^@^@^@^@ 15

PI.- 3.1415926535897931
REAL(PI)...--- 3.14159274
DBLE(PI)...--- 3.1415926535897931
RADIX..--- 3. 2
RANGE..--- 3. 307
PRECISION..-- 15

PI  3.1415926535897931
REAL(PI) .. 3.14159274
DBLE(PI) .. 3.1415926535897931
RADIX . 2
RANGE . 307
PRECISION . 15

PI  3.1415926535897931
REAL(PI) .. 3.14159274
DBLE(PI) .. 3.1415926535897931
RADIX . 2
RANGE . 307
PRECISION . 15

[Bug modula2/114617] gm2 is unable to resolve const expression using relative operators ICE

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

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

--- Comment #2 from Gaius Mulley  ---
Created attachment 57891
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57891&action=edit
Proposed fix

Here is a proposed fix which stores the result of the relop as a constant.
The fix requires M2Quads to mark a const expression relop and M2GenGCC to
evaluate the relop and then to remove the redundant quadruples.

[Bug modula2/114617] gm2 is unable to resolve const expression using relative operators ICE

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

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

Gaius Mulley  changed:

   What|Removed |Added

   Last reconfirmed||2024-04-06
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Gaius Mulley  ---
Confirmed.

[Bug modula2/114617] New: gm2 is unable to resolve const expression using relative operators ICE

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

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

Bug ID: 114617
   Summary: gm2 is unable to resolve const expression using
relative operators ICE
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

For example, it appears to occur if a constant expression has a relop.  The
result of the relop is stored in a variable and is not resolved at compile
time.


$ gm2 -g -c BasicFileSys.mod
-I../../../../Sandpit/gm2-outside-tree-tests/build/source/m2pp/src/ 
terminate called after throwing an instance of 'unsigned int'
cc1gm2: internal compiler error: Aborted
0x178a0e3 crash_signal
../../gcc/toplev.cc:319
0x8f590990 __pthread_kill_implementation
./nptl/pthread_kill.c:44
0x8f54a76b __GI_raise
../sysdeps/posix/raise.c:26
0x8f5374bb __GI_abort
./stdlib/abort.c:79
0xf1a64f InvokeHandler
m2/gm2-libs-boot/RTExceptions.c:484
0xf1b1ff RTExceptions_Raise
m2/gm2-libs-boot/RTExceptions.c:946
0xf1ac33 invalidloc
m2/gm2-libs-boot/RTExceptions.c:755
0xf211a3 sigbusDespatcher
../../gcc/m2/gm2-libs-ch/SysExceptions.c:125
0x11fce74 fold(tree_node*)
../../gcc/fold-const.cc:13798
0xde8bd7 m2convert_BuildConvert
../../gcc/m2/gm2-gcc/m2convert.cc:439
0xdf1f33 m2expr_BuildIndirect
../../gcc/m2/gm2-gcc/m2expr.cc:3520
0xe5802b CodeXIndr
m2/gm2-compiler-boot/M2GenGCC.c:9350
0xe47cd3 CodeStatement
m2/gm2-compiler-boot/M2GenGCC.c:2062
0xe58177 M2GenGCC_ConvertQuadsToTree
m2/gm2-compiler-boot/M2GenGCC.c:9380
0xe939af M2Scope_ForeachScopeBlockDo2
m2/gm2-compiler-boot/M2Scope.c:675
0xe33783 M2Code_CodeBlock
m2/gm2-compiler-boot/M2Code.c:529
0xe33027 DoCodeBlock
m2/gm2-compiler-boot/M2Code.c:292
0xe336b3 M2Code_Code
m2/gm2-compiler-boot/M2Code.c:467
0xe33c53 Compile
m2/gm2-compiler-boot/M2Comp.c:469
0xe359a3 M2Comp_compile
m2/gm2-compiler-boot/M2Comp.c:1592


The variable used to contain the result of the relop constant expression can be
seen in:

MODULE constbool3 ;


CONST
   AddressableBits = 32 ;
   MaxBits = 16 ;

   BitsInUse = ORD(AddressableBits > MaxBits) * MaxBits + ORD(AddressableBits
<= MaxBits) * AddressableBits;

BEGIN

END constbool3.

$ gm2 -fiso constbool3.mod 
constbool3.mod:8:36: error: In program module 'constbool3': the procedure
function 'ORD' is being called from within a constant expression and therefore
the parameter must be a constant, seen a expression
8 |BitsInUse = ORD(AddressableBits > MaxBits) * MaxBits +
ORD(AddressableBits <= MaxBits) * AddressableBits;
  |^
constbool3.mod:8:79: error: the procedure function 'ORD' is being called from
within a constant expression and therefore the parameter must be a constant,
seen a expression
8 |BitsInUse = ORD(AddressableBits > MaxBits) * MaxBits +
ORD(AddressableBits <= MaxBits) * AddressableBits;
  |  
^~
constbool3.mod:8:14: error: in assignment, cannot assign a variable to a
constant 'BitsInUse'
8 |BitsInUse = ORD(AddressableBits > MaxBits) * MaxBits +
ORD(AddressableBits <= MaxBits) * AddressableBits;
  |   
~~^~
constbool3.mod:8:4: error: designator 'BitsInUse' is declared as a CONST
8 |BitsInUse = ORD(AddressableBits > MaxBits) * MaxBits +
ORD(AddressableBits <= MaxBits) * AddressableBits;
  |^

[Bug c++/91798] Compiler rejects code due to template specialization of auto parameter value.

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||60679

--- Comment #6 from Andrew Pinski  ---
PR 60679 is the PR about the defect report too.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60679
[Bug 60679] [DR1647] class specialization not instantiated even though it is a
better match than the primary template

[Bug c++/91798] Compiler rejects code due to template specialization of auto parameter value.

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |SUSPENDED

--- Comment #5 from Andrew Pinski  ---
https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1647

And maybe others.

Note my other testcase was a full specialization rather than a partial.
Here is one with a partial which removes the variadic :
```
//Get type parameter at given index.
template
struct param
{
static_assert(i > 0, "Index into parameter pack cannot be negative!");
using type = typename param::type;
};

template
struct param<0, T>
{
using type = T;
};

int main()
{
typename param<0u, int>::type x = 'a';
static_cast(x);
}
```

Both GCC and EDG agree on this while clang and MSVC disagree. This is
definitely DR 1647 then. 

So suspended as the defect report is still active.

[Bug c++/91798] Compiler rejects code due to template specialization of auto parameter value.

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

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

--- Comment #4 from Andrew Pinski  ---
Actually maybe GCC is correct here.
Remove the variadic template:
```
//Get type parameter at given index.
template
struct param
{
static_assert(i > 0, "Index into parameter pack cannot be negative!");
using type = typename param::type;
};

template<>
struct param<0>
{
using type = int;
};

int main()
{
typename param<0u>::type x = 'a';
static_cast(x);
}
```

Every compiler (EDG, GCC, clang and MSVC) I tried rejects this.

Note the original code,  EDG rejects it for the same reason as GCC.

The reason why is 0 is different 0u as they have different types as they should
not match.

Though I think there is a defect report in that area ...

[Bug c++/85612] ADL lookup with parameter pack and defaulted argument not considered ambiguous

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.2
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=67928,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80871

--- Comment #2 from Andrew Pinski  ---
Fixed for GCC 10.2.0.

[Bug rtl-optimization/113951] regression redundant load (-fschedule-insns)

[absoler at smail dot nju.edu.cn via Gcc-bugs]

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

--- Comment #2 from absoler at smail dot nju.edu.cn ---
after sched1 modified the code, ce3 introduced this extra load. un-sched1 code
would not be pessimised by ce3

[Bug c++/72481] Compile error for varadic template

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to work||14.0
  Known to fail||13.2.0

--- Comment #1 from Andrew Pinski  ---
Looks fixed on the trunk for GCC 14.

[Bug c++/90085] c++17 template argument deduction results in missed optimization

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||13.1.0
  Known to fail||12.3.0

--- Comment #2 from Andrew Pinski  ---
Looks to be fixed in GCC 13.

easiest way to see the difference is:
.section   
.data._ZN6Colors5namesE,"awG",@progbits,_ZN6Colors5namesE,comdat


vs

.section   
.rodata._ZN6Colors5namesE,"aG",@progbits,_ZN6Colors5namesE,comdat


at -O0.

[Bug c++/56908] Spurious warning when XOR-ing uint8_t values

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |10.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=91993

--- Comment #2 from Andrew Pinski  ---
Fixed in GCC 10.

[Bug analyzer/114616] New: RFE: show type and possible ranges of size in -Wanalyzer-tainted-size and -Wanalyzer-tainted-allocation-size

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

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

Bug ID: 114616
   Summary: RFE: show type and possible ranges of size in
-Wanalyzer-tainted-size and
-Wanalyzer-tainted-allocation-size
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

It's really helpful when triaging analyzer reports from -Wanalyzer-tainted-size
and -Wanalyzer-tainted-allocation-size to know more about the size in use.

e.g. if it's come from uint8_t then an allocation of that size is unlikely to
be problematic even if it's "unsanitized" (probably should have a param for the
threshold above which we complain).

Probably should add notes/events describing more about the value and the
sanitization/type converstions that happen to it.

[Bug c++/99281] internal compiler error: in assign_temp, at function.c:984

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |11.0

--- Comment #5 from Andrew Pinski  ---
GCC 10.x has long been closed for new patches so closing as fixed for GCC 11.

[Bug c++/44520] improve diagnostic for ambiguous base class lookup

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
Summary|improve diagnostic for  |improve diagnostic for
   |ambiguous lookup|ambiguous base class lookup
   Last reconfirmed|2017-08-17 00:00:00 |2024-4-5

[Bug c++/67928] Ambiguous call not diagnosed

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80871
   Target Milestone|--- |10.2
 Status|NEW |RESOLVED

--- Comment #3 from Andrew Pinski  ---
Fixed in GCC 10.2.0 and GCC 11+.

[Bug c++/98543] fails to diagnose unnecessary functions

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2021-01-07 00:00:00 |2024-4-5

--- Comment #2 from Andrew Pinski  ---
Note clang's warning here is not with -Wunused either but with a different
option (and has been that way since at least clang 3.0):
```
:2:13: warning: function 'f' is not needed and will not be emitted
[-Wunneeded-internal-declaration]
2 | static void f()
  | ^
```

[Bug target/114615] spurious warning on mingw-w64: 'memcpy' reading 4 or more bytes from a region of size 2 with std::wstring{L""} and -flto -O1 [Wstringop-overread]

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||x86_64-w64-mingw32
  Component|tree-optimization   |target

--- Comment #1 from Andrew Pinski  ---
-municode defines UNICODE .

Maybe there is some mismatching of wchar_t somewhere ...

[Bug tree-optimization/114615] New: spurious warning on mingw-w64: 'memcpy' reading 4 or more bytes from a region of size 2 with std::wstring{L""} and -flto -O1 [Wstringop-overread]

[bugzilla.gcc.simon at arlott dot org via Gcc-bugs]

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

Bug ID: 114615
   Summary: spurious warning on mingw-w64: 'memcpy' reading 4 or
more bytes from a region of size 2 with
std::wstring{L""} and -flto -O1 [Wstringop-overread]
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugzilla.gcc.simon at arlott dot org
  Target Milestone: ---

This only happens on MinGW, when compiling with -flto, -municode and
optimisations. I get a spurious warning and it fails to optimise away the
constructor/destructor:

$ x86_64-w64-mingw32-g++ -o test.exe test.cc -flto -municode -O1
In function ‘wmemcpy’,
inlined from ‘copy’ at
/usr/lib/gcc/x86_64-w64-mingw32/12-win32/include/c++/bits/char_traits.h:558:16,
inlined from ‘_S_copy’ at
/usr/lib/gcc/x86_64-w64-mingw32/12-win32/include/c++/bits/basic_string.h:423:21,
inlined from ‘_S_copy_chars’ at
/usr/lib/gcc/x86_64-w64-mingw32/12-win32/include/c++/bits/basic_string.h:477:16,
inlined from ‘_M_construct’ at
/usr/lib/gcc/x86_64-w64-mingw32/12-win32/include/c++/bits/basic_string.tcc:243:21,
inlined from ‘__ct_comp ’ at
/usr/lib/gcc/x86_64-w64-mingw32/12-win32/include/c++/bits/basic_string.h:642:14,
inlined from ‘wmain’ at test.cc:5:23:
/usr/share/mingw-w64/include/wchar.h:1502:31: warning: ‘memcpy’ reading 4 or
more bytes from a region of size 2 [-Wstringop-overread]
 1502 | return (wchar_t *) memcpy (_S1,_S2,_N*sizeof(wchar_t));
  |   ^

test.cc:
#include 
#include 

int wmain(int argc, wchar_t *argv[], wchar_t *envp[]) {
std::wstring test{L""};
return 0;
}

I can reproduce it here on MinGW GCC 12.1.0 and 12.2.0:
https://godbolt.org/z/dv7Pb8nx4 (the MinGW GCC 13 compiler on there is
currently not working at all)

MinGW GCC 11.3.0 is ok.

[Bug c++/66028] false positive, unused loop variable

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #3 from Andrew Pinski  ---
(In reply to ncm from comment #2)
> This bug appears not to manifest in g++-10.2.

The warning is still there for me. Maybe you forgot to test with -Wall (or
-Wunused).

[Bug c++/97814] Copy constructor deletion not recognized in initialization list with -std=c++17

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Just for reference, C++17 includes what is called Prvalue semantics (some call
it guaranteed copy elision). Unlike previous versions of C++, where moves (and
copies) that are elisioned, also require access to the copy/move constructor,
prvalue semantics has no requirement for that as there are no tempories that
happens in this case in C++17.

You can read up more here (note this is a summary of what the standard says and
not exactly the standard but it does a decent job in talking about it):
https://en.cppreference.com/w/cpp/language/copy_elision

[Bug c++/86373] Destructor shall not be instantiated in C++17 mode for prvalue

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

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

--- Comment #2 from Andrew Pinski  ---
>Clang compiles both of the above examples.


While MSVC rejects both examples. 
And EDG rejects the first (can't test the second one though).

Note also EDG, and MSVC also reject the example in the Defect report linked
here while GCC and clang accept it.

So 

[Bug testsuite/114614] New: New test case gcc.misc-tests/gcov-20.c from r14-9789-g08a52331803f66 fails

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

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

Bug ID: 114614
   Summary: New test case gcc.misc-tests/gcov-20.c from
r14-9789-g08a52331803f66 fails
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:08a52331803f66a4aaeaedd278436ca8eac57b50, r14-9789-g08a52331803f66

I am seeing this on a BE machine for -m32.

Running target unix/-m32
FAIL: gcc.misc-tests/gcov-20.c (test for excess errors)

/home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.misc-tests/gcov-20.c:20:1:
warning: target does not support atomic profile update, single mode is selected


commit 08a52331803f66a4aaeaedd278436ca8eac57b50 (HEAD)
Author: Jrgen Kvalsvik 
Date:   Tue Dec 5 12:59:40 2023 +0100

Add condition coverage (MC/DC)

[Bug fortran/114613] New: ALLOCATE with SOURCE forgets to finalize temporary instances

[vterzi1996 at gmail dot com via Gcc-bugs]

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

Bug ID: 114613
   Summary: ALLOCATE with SOURCE forgets to finalize temporary
instances
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vterzi1996 at gmail dot com
  Target Milestone: ---

Consider the following minimal example:
```
module lib
private
type,public::list
contains
final::list_final
end type
interface list
procedure list_new
end interface
contains
function list_new()result(this)
type(list)::this
print*,'list_new'
end
subroutine list_final(this)
type(list),intent(inout)::this
print*,'list_final'
end
end


program prog
use lib
type(list),allocatable::obj
allocate(obj,source=list())  ! obj=list()
end
```

Only `list_new` is printed, since `list_final` is never called to finalize the
temporary `list()` instance after the `allocate` statement, what can lead to a
memory leak. This issue can be fixed by replacing `allocate(obj,source=list())`
with `obj=list()`.

A larger example was already discussed here:
https://stackoverflow.com/questions/78279925/right-way-to-allocate-type-instances-containing-pointers-in-fortran
and one of the experienced Stack Overflow users thinks that it is a bug of
gfortran.

[Bug fortran/114612] New: Deep copy missing for allocatable derived type components

[vterzi1996 at gmail dot com via Gcc-bugs]

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

Bug ID: 114612
   Summary: Deep copy missing for allocatable derived type
components
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vterzi1996 at gmail dot com
  Target Milestone: ---

Consider the following minimal example:
```
program prog
type node
integer::val
type(node),allocatable::next
end type
type(node)::a,b
allocate(a%next)
a%val=1
a%next%val=2
print*,a%val,a%next%val
b=a
b%val=3
b%next%val=4
print*,a%val,a%next%val
deallocate(b%next)
print*,a%val,a%next%val
end
```
The output of the code compiled with the GNU (gfortran-13.1.0) compiler is as
follows:
```
   1   2
   1   4
   1   0
```
While the output of the code compiled with the Intel (ifx-2024.1.0) or NAG
(nagfor-7.1) compiler is different:
```
   1   2
   1   2
   1   2
```

It seems like gfortran treats allocatable derived type components somewhat as
pointers: after assignment `b=a`, the memory addresses of `a%next` and `b%next`
are the same, and you can change `a%next%val` by changing `b%next%val`.
However, deallocation of `b%next` will not deallocate `a%next` and will only
change its content.

In contrast to this behavior, the Intel and NAG compilers perform a deep copy
in the assignment `b=a` allocating new memory for elements of b.

The question to this example was asked here:
https://stackoverflow.com/questions/78282004/are-allocatable-derived-type-components-just-pointers-for-gnu-compiler?noredirect=1#comment138008854_78282004
and received an answer that this result is a bug of `gfortran`.

[Bug testsuite/114034] Failure of tests gcov-dump-{1,2}.C

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Iain D Sandoe
:

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

commit r13-8589-ga040eea6b65456625443dcfbf6b21913f2003c8b
Author: Iain Sandoe 
Date:   Sun Mar 31 11:22:58 2024 +0100

testsuite: Remove duplicate -lgcov [PR114034]

Duplicate library entries now cause linker warnings with newer linker
versions on Darwin which leads to these tests regressing.  The library
is already added by the test flags so there is no need to put an extra
one in the options.

PR testsuite/114034

gcc/testsuite/ChangeLog:

* g++.dg/gcov/gcov-dump-1.C: Remove extra -lgcov.
* g++.dg/gcov/gcov-dump-2.C: Likewise.

Signed-off-by: Iain Sandoe 
(cherry picked from commit 799a056cf804f433ce0050a5a6bf900f7a01ecb1)

[Bug fortran/114611] New: H edit descriptor should flag as error with -std-f95 (or higher)

[w6ws at earthlink dot net via Gcc-bugs]

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

Bug ID: 114611
   Summary: H edit descriptor should flag as error with -std-f95
(or higher)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: w6ws at earthlink dot net
  Target Milestone: ---

When an H edit descriptor is used in a format, only a warning is given when
-std=f95 (or higher) is specified.  It should be an error, as are other ancient
features that were deleted in F95 such as PAUSE and ASSIGN/assigned GO TO.

Note in the following example that PAUSE gives an error, whereas use of the H
edit descriptor is only a warning:

wws@w6ws-4:/tmp/wws$ cat fmt1.f90
program fmt1
  implicit none

  pause 13

  print 100
100 format (1H ,"Hello World")
end program
wws@w6ws-4:/tmp/wws$ gfortran -std=f95 fmt1.f90
fmt1.f90:4:10:

4 |   pause 13
  |  1
Error: Deleted feature: PAUSE statement at (1)
fmt1.f90:7:17:

7 | 100 format (1H ,"Hello World")
  | 1
Warning: The H format specifier at (1) is a Fortran 95 deleted feature
wws@w6ws-4:/tmp/wws$ 
wws@w6ws-4:/tmp/wws$ gfortran --version
GNU Fortran (GCC) 14.0.1 20240115 (experimental)
Copyright (C) 2024 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

wws@w6ws-4:/tmp/wws$

[Bug analyzer/114610] New: -Wanalyzer-memory-leak reports often far too verbose

[BenBE at geshi dot org via Gcc-bugs]

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

Bug ID: 114610
   Summary: -Wanalyzer-memory-leak reports often far too verbose
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: BenBE at geshi dot org
  Target Milestone: ---

When building htop with GCC14 + LTO + -fanalyzer, several potential
memory-leaks are reporte (related to xRealloc, cf. #114594).

One (of several reports) looks like the following:

```
XUtils.c: In function ‘xRealloc’:
XUtils.c:67:7: warning: leak of ‘realloc (ptr_4(D), size_1(D))’ [CWE-401]
[-Wanalyzer-malloc-leak]
   67 |if (!data) {
  |   ^
  ‘Platform_actionSetIOPriority’: events 1-4
|
|linux/Platform.c:154:22:
|  154 | static Htop_Reaction Platform_actionSetIOPriority(State* st) {
|  |  ^
|  |  |
|  |  (1) entry to ‘Platform_actionSetIOPriority’
|  155 |if (Settings_isReadonly())
|  |   ~   
|  |   |
|  |   (2) following ‘false’ branch...
|..
|  158 |const LinuxProcess* p = (const LinuxProcess*)
Panel_getSelected((Panel*)st->mainPanel);
|  |  ~
  ~
|  |  |
  |
|  |  |
  (3) ...to here
|  |  (4) calling
‘Panel_getSelected’ from ‘Platform_actionSetIOPriority’
|
+--> ‘Panel_getSelected’: events 5-7
   |
   |Panel.c:158:9:
   |  158 | Object* Panel_getSelected(Panel* this) {
   |  | ^
   |  | |
   |  | (5) entry to ‘Panel_getSelected’
   |  159 |assert (this != NULL);
   |  160 |if (Vector_size(this->items) > 0) {
   |  |   ~  
   |  |   |
   |  |   (6) following ‘true’ branch...
   |  161 |   return Vector_get(this->items, this->selected);
   |  |  ~
   |  |  |
   |  |  (7) ...to here
   |
<--+
|
  ‘Platform_actionSetIOPriority’: events 8-11
|
|linux/Platform.c:158:50:
|  158 |const LinuxProcess* p = (const LinuxProcess*)
Panel_getSelected((Panel*)st->mainPanel);
|  |  ^
|  |  |
|  |  (8) returning to
‘Platform_actionSetIOPriority’ from ‘Panel_getSelected’
|  159 |if (!p)
|  |   ~   
|  |   |
|  |   (9) following ‘false’ branch (when ‘p_13’ is non-NULL)...
|..
|  162 |IOPriority ioprio1 = p->ioPriority;
|  |   ~   
|  |   |
|  |   (10) ...to here
|  163 |Panel* ioprioPanel = IOPriorityPanel_new(ioprio1);
|  | ~ 
|  | |
|  | (11) calling ‘IOPriorityPanel_new’ from
‘Platform_actionSetIOPriority’
|
+--> ‘IOPriorityPanel_new’: events 12-13
   |
   |linux/IOPriorityPanel.c:22:8:
   |   22 | Panel* IOPriorityPanel_new(IOPriority currPrio) {
   |  |^
   |  ||
   |  |(12) entry to ‘IOPriorityPanel_new’
   |   23 |Panel* this = Panel_new(1, 1, 1, 1, Class(ListItem),
true, FunctionBar_newEnterEsc("Set", "Cancel "));
   |  |  ~
   |  |  |
   |  |  (13) calling ‘FunctionBar_newEnterEsc’
from ‘IOPriorityPanel_new’
   |
   +--> ‘FunctionBar_newEnterEsc’: events 14-15
  |
  |FunctionBar.c:32:14:
  |   32 | FunctionBar* FunctionBar_newEnterEsc(const char*
enter, const char* esc) {
  |  |  ^
  |  |  |
  |  |  (14) entry to ‘FunctionBar_newEnterEsc’
  |   33 |const char* functions[] = {enter, esc, NULL};
  |   34 |return FunctionBar_new(functions,
FunctionBar_EnterEscKeys, FunctionBar_EnterEscEvents);
  |  |   ~   
  |  |   |
  |  |   (15) calling ‘FunctionBar_new’ from
‘FunctionBar_newEnterEsc’
  

[Bug analyzer/114588] Analyzer buffer overflow ASCII art hardcodes "RED" and "GREEN" as the terminal colors

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:4b02dd48f531ea88587edd2b75b6e5243b4389e8

commit r14-9817-g4b02dd48f531ea88587edd2b75b6e5243b4389e8
Author: David Malcolm 
Date:   Fri Apr 5 14:49:53 2024 -0400

analyzer: respect GCC_COLORS in out-of-bounds diagrams [PR114588]

gcc/analyzer/ChangeLog:
PR analyzer/114588
* access-diagram.cc (access_diagram_impl::access_diagram_impl):
Replace hardcoded colors for valid_style and invalid_style with
calls to text_art::get_style_from_color_cap_name.

gcc/ChangeLog:
PR analyzer/114588
* diagnostic-color.cc (color_dict): Add "valid" and "invalid" as
color capability names.
* doc/invoke.texi: Document them in description of GCC_COLORS.
* text-art/style.cc: Include "diagnostic-color.h".
(text_art::get_style_from_color_cap_name): New.
* text-art/types.h (get_style_from_color_cap_name): New decl.

Signed-off-by: David Malcolm 

[Bug c/114609] -Waddress false positive

[arnaud.lb at gmail dot com via Gcc-bugs]

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

--- Comment #2 from arnaud.lb at gmail dot com ---
I can not think of any location where this warning would make sense for this
code. The warning behaves as if we did this:

```
(&state)->member == 1 ? (_Bool)&state : (_Bool)0) ? 2 : 3;
```

In this case it would make sense as (_Bool)&state will indeed always be true.

The original code looks more like this:

```
struct {
_Bool valid;
} state;

int effect;

#define getState() ((&state)->valid == 1 ? &state : 0)

void f(void) {
effect = getState() ? 2 : 3;
}
```

The warning is unfortunate because the code is not explicitly testing the
address of `state`.

[Bug middle-end/114579] RTL expansion add_scope_conflicts is slow

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-04-05
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed.

[Bug c++/114537] bit_cast does not work NSDMI of bitfields

[fchelnokov at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Fedor Chelnokov  ---
Sorry, in above example I had to use `unsigned char` type:

```
#include 

struct A { unsigned char a : 7; };

static_assert( std::bit_cast(std::bit_cast(A{1})).a == 1 );
```

This program even after the fix in trunk, prints the same error as in the
original post:
:5:32:   in 'constexpr' expansion of 'std::bit_cast(std::bit_cast(A{1}))'
/opt/compiler-explorer/gcc-trunk-20240405/include/c++/14.0.1/bit:94:33: sorry,
unimplemented: '__builtin_bit_cast' cannot be constant evaluated because the
argument cannot be encoded
   94 |   return __builtin_bit_cast(_To, __from);

Online demo: https://gcc.godbolt.org/z/eqrsfGEnT

[Bug preprocessor/87299] #pragma GCC target behaves differently when using -save-temps

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
(In reply to Gwenole Beauchesne from comment #8)
> Hi, can you please consider a backport to GCC 13 branch? The patch applies
> cleanly as is, but causes regressions that are further fixed with e45c564e
> (for PR pch/112319).
> 
> GCC 13 is the first and most complete compiler for modern C++ (>= C++20)
> support and readily available, or soon available, as the system compiler for
> major distributions. This is useful to C++ projects that (debately) use
> multiple wrappers for SIMD support (xsimd, simde, mipp, etc.), but without
> correct support for runtime dispatching. So, using #pragma GCC target is a
> handy solution for that.

No, this certainly shouldn't be backported, it is a significant behavior change
which is something that shouldn't be done on release branches.
E.g. it breaks simdutf, see https://github.com/simdutf/simdutf/issues/391

[Bug c++/88371] Gratuitous (?) warning regarding an implicit conversion in pointer arithmetic

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

--- Comment #4 from Andrew Pinski  ---
(In reply to Eric Gallager from comment #3)
> (In reply to Eyal Rozenberg from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > Looks to be fixed in GCC 10+.
> > 
> > Indeed... mark this as RESOLVED FIXED perhaps?
> 
> OK.

I was actually waiting to see what fixed it before closing it as fixed but
either way that is ok.

[Bug c++/88371] Gratuitous (?) warning regarding an implicit conversion in pointer arithmetic

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

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
 CC||egallager at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
(In reply to Eyal Rozenberg from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Looks to be fixed in GCC 10+.
> 
> Indeed... mark this as RESOLVED FIXED perhaps?

OK.

[Bug c/110402] Bogus -Waddress warning that pointer comparison is always true

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
Oh the location for the diagnostic is in the wrong spot. So a dup of bug
102967.

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

[Bug c/102967] confusing location in -Waddress for a subexpression of a ternary expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||lsof at mailbox dot org

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

[Bug c/102967] confusing location in -Waddress for a subexpression of a ternary expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||arnaud.lb at gmail dot com

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

[Bug c/114609] -Waddress false positive

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
No this warning is on purpose. 

The problem is the diagnostic location is wrong. See PR 102967 for more details
on why.

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

[Bug analyzer/114588] Analyzer buffer overflow ASCII art hardcodes "RED" and "GREEN" as the terminal colors

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #1)
> Confirmed. I should note that Red/Green is the opposite meaning in some
> places than western cultures. That is Red is good and Green is bad. Most of
> China is where that is true.
> 
> See
> https://graphicdesign.stackexchange.com/questions/6982/except-china-which-
> country-will-use-red-for-up-and-green-for-down also.

Japan, too, it's why the 📈 (chart with upwards trend) emoji uses red, and the 📉
(chart with downwards trend) emoji uses blue, because they were originally from
Japan. Red = "heating up" (which is good for shares of a stock) and blue =
"cooling off" (which is bad for shares of a stock)

[Bug c/114609] New: -Waddress false positive

[arnaud.lb at gmail dot com via Gcc-bugs]

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

Bug ID: 114609
   Summary: -Waddress false positive
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnaud.lb at gmail dot com
  Target Milestone: ---

The following code:

```
struct {
int member;
} state;

int effect;

void f(void) {
effect = ((&state)->member == 1 ? &state : 0) ? 2 : 3;
}
```

When compiled with:

```
gcc -c test.c -Waddress
```

Results in the following warning:

```
: In function 'f':
:8:51: warning: the address of 'state' will always evaluate as 'true'
[-Waddress]
8 | effect = ((&state)->member == 1 ? &state : 0) ? 2 : 3;
  |   ^
Compiler returned: 0
```

I believe this is a false positive, and no warning should be emitted.

GCC version: 13.2.1 20240316 (Red Hat 13.2.1-7)

[Bug debug/114608] [14 Regression] Undefined reference in output asm with -fipa-reference -fipa-reference-addressable -fsection-anchors -gbtf

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 Target|riscv*-*-* x86_64-*-*   |
   Keywords||btf-debug

[Bug c++/112490] infinite meta error in reverse_iterator::iterator>>

[barry.revzin at gmail dot com via Gcc-bugs]

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

Barry Revzin  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

--- Comment #3 from Barry Revzin  ---
I ran into this also in a different direction, have been trying to reduce:

#include 

template  concept my_partially_ordered_with = requires (T t,
U u) { t < u; };
template  concept my_totally_ordered = my_partially_ordered_with;
template  concept my_totally_ordered_with =
my_totally_ordered && my_totally_ordered && my_partially_ordered_with;

template class basic_const_iterator;

namespace __detail
{
template
inline constexpr bool __is_const_iterator = false;

template
inline constexpr bool __is_const_iterator> =
true;

template
concept __not_a_const_iterator = !__is_const_iterator<_Tp>;

} // namespace detail

template
class basic_const_iterator
{
#ifdef MAKE_THIS_PUBLIC
public:
#endif
int m;

public:
template <__detail::__not_a_const_iterator _It2>
friend bool operator<(const _It2& __x, const basic_const_iterator& __y)
requires my_totally_ordered_with<_It, _It2> { return true; }
};

template 
struct wrapped
{
Iter iter;
constexpr std::strong_ordering operator<=>(const wrapped& rhs) const
noexcept;
};

bool check(wrapped> x) {
return x < x;
}


gcc rejects this with constraint recursion. clang and MSVC accept. Oddly, if
you make _M_current public, gcc trunk accepts (even though no code even
references this) while gcc 13.2 still rejects. On compiler explorer:
https://godbolt.org/z/zfvxdGneK

Trunk's rejection message is also incomplete:

: In substitution of 'template  requires 
__not_a_const_iterator<_It2> bool operator<(const _It2&, const
basic_const_iterator&) requires  my_totally_ordered_with<_It, _It2> [with
_It2 = int*]':
:3:89:   required by substitution of 'template  requires 
__not_a_const_iterator<_It2> bool operator<(const _It2&, const
basic_const_iterator&) requires  my_totally_ordered_with<_It, _It2> [with
_It2 = int*]'
3 | template  concept my_partially_ordered_with =
requires (T t, U u) { t < u; };
  |
  ~~^~~
:43:16:   required from here
   43 | return x < x;
  |^

It tells you _It2=int*, but not what _It is. 

In this case, we're comparing two objects of type
wrapped> with <, so we should have two candidates:

1. wrapped's <=>, which has no constraints
2. basic_const_iterator's friend operator<, which we start instantiating
with _It=int* and _It2=wrapped>. 

(2) requires checking if _It and _It2 can be ordered, which I think recursively
instantiates itself.

Assuming that's correct (hopefully?), I think CWG 2369 should actually cause
this to be accepted - since wrapped> is not
convertible to basic_const_iterator, that should cause (2) to be rejected
before we even consider constraints since it's not viable. 

I have no idea what the public-ness of the member changes.

[Bug c++/91079] [DR 1881] Standard-layout classes and unnamed bit-fields

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

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/94404] [meta-bug] C++ core issues

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

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

Bug 91079 Summary: [DR 1881] Standard-layout classes and unnamed bit-fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91079

   What|Removed |Added

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

[Bug debug/114608] [14 Regression] Undefined reference in output asm with -fipa-reference -fipa-reference-addressable -fsection-anchors -gbtf

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #2 from Patrick O'Neill  ---
(.BTF+0x88): undefined reference to `a'
^ This is the interesting failure line

[Bug c++/91079] [DR 1881] Standard-layout classes and unnamed bit-fields

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

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

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

https://gcc.gnu.org/g:2b2d3a135a43cbafadd8957e0b2543f38c390437

commit r14-9815-g2b2d3a135a43cbafadd8957e0b2543f38c390437
Author: Marek Polacek 
Date:   Fri Apr 5 13:40:33 2024 -0400

c++: add fixed test [PR91079]

Fixed by r12-2975.

PR c++/91079
DR 1881

gcc/testsuite/ChangeLog:

* g++.dg/ext/is_std_layout5.C: New test.

[Bug debug/114608] [14 Regression] Undefined reference in output asm with -fipa-reference -fipa-reference-addressable -fsection-anchors -gbtf

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #1 from Patrick O'Neill  ---
Command:
> /scratch/tc-testing/tc-apr-4/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -fipa-reference -fipa-reference-addressable -fsection-anchors -gbtf red.c -o 
> rv64gcv.out
/scratch/tc-testing/tc-apr-4/build-rv64gcv/lib/gcc/riscv64-unknown-linux-gnu/14.0.1/../../../../riscv64-unknown-linux-gnu/bin/ld:
/scratch/tc-testing/tc-apr-4/build-rv64gcv/sysroot/usr/lib64/lp64d/crt1.o: in
function `_start':
(.text+0x22): undefined reference to `main'
/scratch/tc-testing/tc-apr-4/build-rv64gcv/lib/gcc/riscv64-unknown-linux-gnu/14.0.1/../../../../riscv64-unknown-linux-gnu/bin/ld:
/scratch/tmp/ccI7WX4y.o:(.BTF+0x88): undefined reference to `a'
collect2: error: ld returned 1 exit status

[Bug debug/114608] New: [14 Regression] Undefined reference in output asm with -fipa-reference -fipa-reference-addressable -fsection-anchors -gbtf

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 114608
   Summary: [14 Regression] Undefined reference in output asm with
-fipa-reference -fipa-reference-addressable
-fsection-anchors -gbtf
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Program:
static short a[7];
void b() { a[6] = 0; }

Compiler flags:
-fipa-reference -fipa-reference-addressable -fsection-anchors -gbtf

Godbolt diff between 13.2 and 14.0:
RISC-V: https://godbolt.org/z/7d1nodoMz
X86: https://godbolt.org/z/YGdej7Y7c

Godbolt showing failure:
RISCV: https://godbolt.org/z/fd3cKP6jM
X86: https://godbolt.org/z/h3WhzK4nG

Found via fuzzer.

[Bug fortran/106500] ICE on function as an argument to c_sizeof()

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 CC||anlauf at gcc dot gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
I've looked some time into this and have the impression we have the checks
wrong.

E.g. testcase gfortran.dg/c_sizeof_6.f90 expects as error:

gcc/testsuite/gfortran.dg/c_sizeof_6.f90:11:16:

   11 |i = c_sizeof(str2(1:3)) ! { dg-error "must be an interoperable data"
}
  |1
Error: 'x' argument of 'c_sizeof' intrinsic at (1) must be an interoperable
data entity: Only whole-arrays are interoperable


First, other compilers accept the code (Intel, NAG, Nvidia, flang), and also
the other testcases in the PR, plus they give the expected answers.

Second, the standard has:

! F2023:18.2.3.8  C_SIZEOF (X)
!
! X shall be a data entity with interoperable type and type parameters,
! and shall not be an assumed-size array, an assumed-rank array that
! is associated with an assumed-size array, an unallocated allocatable
! variable, or a pointer that is not associated.

and

! 3.41 data entity
! data object, result of the evaluation of an expression, or the
! result of the execution of a function reference

So, array sections could be interoperable, expressions, function results.

What is unclear to me: when is an expression interoperable?
Or rather when is it *not*?

(Note that the standard text has not essentially changed since F2008,
so we got this too strict from the beginning.)

[Bug fortran/89925] [11 Regression] Wrong array bounds from ALLOCATE with SOURCE or MOLD

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

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

--- Comment #16 from anlauf at gcc dot gnu.org ---
BTW: r12-5767 backports cleanly to 11-branch and regtests cleanly.

I could push it if there are no objections, so that we can finally close
this one.

[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

[nicolas at debian dot org via Gcc-bugs]

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

--- Comment #16 from Nicolas Boulenguez  ---
This 3rd attempt does the requested split.
It fixes all build errors on Debian/amd64.
The new Ada.Calendar.Clock returns sensible results.
In other words, it seems ready for review.

[Bug ada/114065] gnat build with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 fails on 32bit archs

[nicolas at debian dot org via Gcc-bugs]

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

Nicolas Boulenguez  changed:

   What|Removed |Added

  Attachment #57866|0   |1
is obsolete||
  Attachment #57867|0   |1
is obsolete||
  Attachment #57868|0   |1
is obsolete||
  Attachment #57869|0   |1
is obsolete||
  Attachment #57876|0   |1
is obsolete||

--- Comment #15 from Nicolas Boulenguez  ---
Created attachment 57890
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57890&action=edit
eight commits isolating the definition of C time types

[Bug ipa/114247] RISC-V: miscompile at -O3 and IPA SRA

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

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

--- Comment #9 from Martin Jambor  ---
On master this has been fixed by r14-9813-g8cd0d29270d4ed where I
unfortunately copy-pasted a wrong bug number :-/

I assume this needs backporting to at least gcc-13 and gcc-12. I'll do
that in a week or two.

[Bug tree-optimization/113964] [11/12/13/14/15 Regression] repeat copy of struct

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

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

--- Comment #4 from Martin Jambor  ---
Oops. I made a mistake, the commit above fixes PR 114247, sorry :-/
This one is the next in my queue.  Sorry again.

[Bug tree-optimization/113964] [11/12/13/14/15 Regression] repeat copy of struct

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Martin Jambor :

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

commit r14-9813-g8cd0d29270d4ed86c69b80c08de66dcb6c1e22fe
Author: Martin Jambor 
Date:   Fri Apr 5 18:18:39 2024 +0200

ipa: Force args obtined through pass-through maps to the expected type (PR
113964)

Interactions of IPA-CP and IPA-SRA on the same data is a rather big
source of issues, I'm afraid.  PR 113964 is a situation where IPA-CP
propagates an unsigned short in a union parameter into a function
which itself calls a different function which has a same union
parameter and both these union parameters are split with IPA-SRA.  The
leaf function however uses a signed short member of the union.

In the calling function, we get the unsigned constant as the
replacement for the union and it is then passed in the call without
any type compatibility checks.  Apparently on riscv64 it matters
whether the parameter is signed or unsigned short and so the leaf
function can see different values.

Fixed by using useless_type_conversion_p at the appropriate place and
if it fails, use force_value_to type as elsewhere in similar
situations.

gcc/ChangeLog:

2024-04-04  Martin Jambor  

PR ipa/113964
* ipa-param-manipulation.cc (ipa_param_adjustments::modify_call):
Force values obtined through pass-through maps to the expected
split type.

gcc/testsuite/ChangeLog:

2024-04-04  Patrick O'Neill  
Martin Jambor  

PR ipa/113964
* gcc.dg/ipa/pr114247.c: New test.

[Bug target/114607] aarch64: Incorrect expansion of svsudot

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

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

Richard Sandiford  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-04-05
 Ever confirmed|0   |1

[Bug target/114607] New: aarch64: Incorrect expansion of svsudot

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

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

Bug ID: 114607
   Summary: aarch64: Incorrect expansion of svsudot
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

svsudot is supposed to expand to USDOT with the second and third arguments
swapped.  However, there is a thinko in the code that does the reversal, making
it a no-op.  Unfortunately, the tests simply accept the buggy form. :-(

For example, gcc.target/aarch64/sve/acle/asm/sudot_s32.c contains:

/*
** sudot_s32_tied1:
**  usdot   z0\.s, z2\.b, z4\.b
**  ret
*/
TEST_TRIPLE_Z (sudot_s32_tied1, svint32_t, svint8_t, svuint8_t,
   z0 = svsudot_s32 (z0, z2, z4),
   z0 = svsudot (z0, z2, z4))

where the usdot z2 and z4 operands should be in the opposite order.

[Bug driver/114606] -Whardened doesn't trigger with -fcf-protection=none

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Last reconfirmed||2024-04-05
 Ever confirmed|0   |1

[Bug driver/114606] New: -Whardened doesn't trigger with -fcf-protection=none

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

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

Bug ID: 114606
   Summary: -Whardened doesn't trigger with -fcf-protection=none
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

-Whardened warns when -fhardened couldn't enable a hardening option because
that option was disabled on the command line, e.g.:

$ ./cc1plus -quiet g.C  -fhardened -O2 -fstack-protector
cc1plus: warning: ‘-fstack-protector-strong’ is not enabled by ‘-fhardened’
because it was specified on the command line [-Whardened]

but it doesn't work as expected with -fcf-protection=none:

$ ./cc1plus -quiet g.C  -fhardened -O2 -fcf-protection=none
# should warn

because we're checking == CF_NONE which doesn't distinguish between nothing and
-fcf-protection=none.  I'm hoping the fix is simply to use OPTION_SET_P.

[Bug middle-end/114596] [OpenMP] "declare variant" scoring seems incorrect for construct selectors

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

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

--- Comment #7 from sandra at gcc dot gnu.org ---
OK, I will do no more work on the old implementation, adjust the broken
testcases, and proceed with getting the my new implementation ready for stage 1
submission.  I don't know if I'll be able to easily disentangle the bug fixes
from the new functionality, though  everything is kind of mixed up together
with changes in representation and interfaces to get metadirectives and
"declare variant" using the same functions to score and sort the candidate
variants.  (My previously-posted set of metadirective patches also had a
scoring bug that I'm addressing with this set of changes.)

[Bug target/114603] aarch64: Invalid SVE cnot optimisation

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

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

Richard Sandiford  changed:

   What|Removed |Added

   Last reconfirmed||2024-04-05
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Sandiford  ---
Fix on trunk so far, but I'll backport if possible.

[Bug c++/114480] g++: internal compiler error: Segmentation fault signal terminated program cc1plus

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

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

--- Comment #21 from Alexander Monakov  ---
It is possible to reduce gcc_qsort workload by improving the presorted-ness of
the array, but of course avoiding quadratic behavior would be much better.

With the following change, we go from

   261,250,628,954  cycles:u
   533,040,964,437  instructions:u#2.04  insn per cycle
   114,415,857,214  branches:u
   395,327,966  branch-misses:u   #0.35% of all branches

to

   256,620,517,403  cycles:u
   526,337,243,809  instructions:u#2.05  insn per cycle
   113,447,583,099  branches:u
   383,121,251  branch-misses:u   #0.34% of all branches

diff --git a/gcc/tree-into-ssa.cc b/gcc/tree-into-ssa.cc
index d12a4a97f6..621793f7f4 100644
--- a/gcc/tree-into-ssa.cc
+++ b/gcc/tree-into-ssa.cc
@@ -805,21 +805,22 @@ prune_unused_phi_nodes (bitmap phis, bitmap kills, bitmap
uses)
  locate the nearest dominating def in logarithmic time by binary search.*/
   bitmap_ior (to_remove, kills, phis);
   n_defs = bitmap_count_bits (to_remove);
+  adef = 2 * n_defs + 1;
   defs = XNEWVEC (struct dom_dfsnum, 2 * n_defs + 1);
   defs[0].bb_index = 1;
   defs[0].dfs_num = 0;
-  adef = 1;
+  struct dom_dfsnum *head = defs + 1, *tail = defs + adef;
   EXECUTE_IF_SET_IN_BITMAP (to_remove, 0, i, bi)
 {
   def_bb = BASIC_BLOCK_FOR_FN (cfun, i);
-  defs[adef].bb_index = i;
-  defs[adef].dfs_num = bb_dom_dfs_in (CDI_DOMINATORS, def_bb);
-  defs[adef + 1].bb_index = i;
-  defs[adef + 1].dfs_num = bb_dom_dfs_out (CDI_DOMINATORS, def_bb);
-  adef += 2;
+  head->bb_index = i;
+  head->dfs_num = bb_dom_dfs_in (CDI_DOMINATORS, def_bb);
+  head++, tail--;
+  tail->bb_index = i;
+  tail->dfs_num = bb_dom_dfs_out (CDI_DOMINATORS, def_bb);
 }
+  gcc_assert (head == tail);
   BITMAP_FREE (to_remove);
-  gcc_assert (adef == 2 * n_defs + 1);
   qsort (defs, adef, sizeof (struct dom_dfsnum), cmp_dfsnum);
   gcc_assert (defs[0].bb_index == 1);

[Bug middle-end/114596] [OpenMP] "declare variant" scoring seems incorrect for construct selectors

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

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

--- Comment #6 from Tobias Burnus  ---
(In reply to sandra from comment #5)
> Tobias, it looks to me like you missed the connection ...

No, I didn't - I did link it (cf. top of comment 3) — but I just cannot read
:-/

Hence, for
(1)  *teams* *parallel* *for* parallel for
(2)  *teams* *parallel* for parallel *for*
(3)  *teams* parallel for *parallel* *for*

we now have
p = {1,2,3,4,5} → score = {1,2,4,8,16}

Thus:
(1) 1 + 2 + 4 = 9
(2) 1 + 2 + 16 = 19
(3) 1 + 8 + 16 = 25

such that (3) wins → and, hence, either of

 (f15) match (construct={parallel},user={condition(score(19):1)}) /* 8+19 */
 (f16) match (implementation={atomic_default_mem_order(score(27):seq_cst)})

as 27 > 25 - and OpenMP states that it is implementation defined which of the
score = 27 variant is used.

* * *

Thus, I concur that there is an ordering and, hence, scoring bug.

* * * 

> I don't know if anybody wants to tackle a bug fix for this code for GCC 14.

I think we don't - we are too close to the release. This has been implemented
since 2019, 'score()' is not implemented in Clang 18, and code like that is
unlikely to be often used. And the code is non-trivial. - All speaks against
rushing to do an implementation for GCC 14.

[Bug tree-optimization/112723] [11/12/13/14 Regression] Missed optimization for invariants 'c+c' when c += -2147483647-1 and c is a global variable

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

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

--- Comment #7 from Jakub Jelinek  ---
Ah, with -fwrapv.  Without -fwrapv the testcase invokes UB always, either the
first c + c overflows or the second one, or the c += -2147483647 - 1;
overflows.

[Bug tree-optimization/112723] [11/12/13/14 Regression] Missed optimization for invariants 'c+c' when c += -2147483647-1 and c is a global variable

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
Why is this marked as a regression?  I don't see 7.1 nor other versions behave
any differently than trunk.

[Bug middle-end/114596] [OpenMP] "declare variant" scoring seems incorrect for construct selectors

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

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

--- Comment #5 from sandra at gcc dot gnu.org ---
Tobias, it looks to me like you missed the connection between the first half of
item (1) in 7.3 (I'm still looking at the 5.2 spec):

"Each trait selector for which the corresponding trait appears in the construct
trait set in the OpenMP context is given the value 2**(p−1) where p is the
position of the corresponding trait, cp, in the context construct trait set..."

And this part of section 7.1:

"Specifically, the ordering of the set of constructs is c1 , ... , cN , where
c1 is the construct at the outermost nesting level and cN is the construct at
the innermost nesting level."

So, the outermost construct has the *lowest* position and *lowest* score.  In
this case, the "teams" construct is outermost, has p=1, and contributes 2**0 to
the score.  And to get the highest score for the duplicated construct traits,
it should prefer the innermost ones.

Re the adding one to the final score, that is also explicit in the spec, item 6
at the very end of section 7.3.

[Bug target/114605] [14 Regression] wrong code with -march=z13 -O0 since r14-5831

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

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 57889
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57889&action=edit
gcc14-pr114605.patch

Untested fix.

[Bug target/114603] aarch64: Invalid SVE cnot optimisation

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

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

--- Comment #1 from GCC Commits  ---
The trunk branch has been updated by Richard Sandiford :

https://gcc.gnu.org/g:67cbb1c638d6ab3a9cb77e674541e2b291fb67df

commit r14-9811-g67cbb1c638d6ab3a9cb77e674541e2b291fb67df
Author: Richard Sandiford 
Date:   Fri Apr 5 14:47:15 2024 +0100

aarch64: Fix bogus cnot optimisation [PR114603]

aarch64-sve.md had a pattern that combined:

cmpeq   pb.T, pa/z, zc.T, #0
mov zd.T, pb/z, #1

into:

cnotzd.T, pa/m, zc.T

But this is only valid if pa.T is a ptrue.  In other cases, the
original would set inactive elements of zd.T to 0, whereas the
combined form would copy elements from zc.T.

gcc/
PR target/114603
* config/aarch64/aarch64-sve.md (@aarch64_pred_cnot): Replace
with...
(@aarch64_ptrue_cnot): ...this, requiring operand 1 to be
a ptrue.
(*cnot): Require operand 1 to be a ptrue.
* config/aarch64/aarch64-sve-builtins-base.cc
(svcnot_impl::expand):
Use aarch64_ptrue_cnot for _x operations that are predicated
with a ptrue.  Represent other _x operations as fully-defined _m
operations.

gcc/testsuite/
PR target/114603
* gcc.target/aarch64/sve/acle/general/cnot_1.c: New test.

[Bug target/114605] [14 Regression] wrong code with -march=z13 -O0 since r14-5831

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2024-04-05
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
This is a clear bug in s390_const_int_pool_entry_p.  It just uses
get_pool_constant but ignores get_pool_mode, which on big-endian is
significant.  The function doesn't allow offsets like e.g. simplify-rtx.cc
(avoid_constant_pool_reference), but still needs to deal with mode mismatches.

[Bug gcov-profile/114599] [14 Regression] ICE: SIGSEGV in bitmap_set_bit(bitmap_head*, int) (bitmap.cc:975) with -O2 -fcondition-coverage

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #6 from H.J. Lu  ---
Not fixed.

[Bug gcov-profile/114599] [14 Regression] ICE: SIGSEGV in bitmap_set_bit(bitmap_head*, int) (bitmap.cc:975) with -O2 -fcondition-coverage

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

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #5 from H.J. Lu  ---
Created attachment 57888
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57888&action=edit
A testcase

The bug isn't fixed:

[hjl@gnu-tgl-3 gcc]$
/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/tools-build/gcc-debug/build-x86_64-linux/gcc/
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.misc-tests/gcov-24.c
-fdiagnostics-plain-output -O2 -fcondition-coverage -S -o gcov-24.s
during IPA pass: profile
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.misc-tests/gcov-24.c: In
function ‘do_all_fn_LHASH_DOALL_ARG_arg2’:
/export/gnu/import/git/sources/gcc/gcc/testsuite/gcc.misc-tests/gcov-24.c:20:1:
internal compiler error: Segmentation fault
0x16ccfa6 crash_signal
/export/gnu/import/git/sources/gcc/gcc/toplev.cc:319
0x180579d hash_table, unsigned int> >::hash_entry,
false, xcallocator>::find_with_hash(gcond* const&, unsigned int)
/export/gnu/import/git/sources/gcc/gcc/hash-table.h:983
0x1804c87 hash_map, unsigned int> >::get(gcond*
const&)
/export/gnu/import/git/sources/gcc/gcc/hash-map.h:191
0x17fdbf8 condition_uid
/export/gnu/import/git/sources/gcc/gcc/tree-profile.cc:370
0x17ff420 find_conditions(function*)
/export/gnu/import/git/sources/gcc/gcc/tree-profile.cc:877
0x158b963 branch_prob(bool)
/export/gnu/import/git/sources/gcc/gcc/profile.cc:1549
0x1802b86 tree_profiling
/export/gnu/import/git/sources/gcc/gcc/tree-profile.cc:1917
0x1803210 execute
/export/gnu/import/git/sources/gcc/gcc/tree-profile.cc:2046
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.
[hjl@gnu-tgl-3 gcc]$

[Bug c++/114600] [14 Regression] [modules] redefinition errors when using certain std headers in GMF

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

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

--- Comment #5 from Patrick Palka  ---
(In reply to Nathaniel Shead from comment #4)
> In general we don't yet implement merging of textual redefinitions; I guess
> this ultimately falls under that, but I'm not sure we have a dedicated bug
> report for that yet? Maybe PR99000.
Makes sense.

> I'm not yet sure exactly why my patch caused this to start failing though;
> it sounds like it's exporting some using-decls even though they aren't
> directly exported, which I suppose is still a bug in its own right.
Hmm, should the check added to add_binding_entity
  flags & (WMB_Using | WMB_Export)
instead be
  (flags & WMB_Using) && (flags & WMB_Export)
?

[Bug c++/111132] [11/12/13 Regression] Function redeclaration in local scope breaks constant expression evaluation

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
   |Function redeclaration in   |Function redeclaration in
   |local scope breaks constant |local scope breaks constant
   |expression evaluation   |expression evaluation

--- Comment #5 from Marek Polacek  ---
Fixed on trunk so far.

[Bug target/114605] [14 Regression] wrong code with -march=z13 -O0 since r14-5831

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Priority|P3  |P1

[Bug target/114605] New: [14 Regression] wrong code with -march=z13 -O0 since r14-5831

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

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

Bug ID: 114605
   Summary: [14 Regression] wrong code with -march=z13 -O0 since
r14-5831
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Since r14-5831-gaae723d360ca26cd9fd0b039fb0a616bd0eae363 we miscompile the
following testcase on s390x-linux with -O0 -march=z13:
typedef struct { const float *a; int b, c; float *d; } S;

__attribute__((noipa)) void
bar (void)
{
}

__attribute__((noinline, optimize (2))) static void
foo (S *e)
{
  const float *f;
  float *g;
  float h[4] = { 0.0, 0.0, 1.0, 1.0 };
  if (!e->b)
f = h;
  else
f = e->a;
  g = &e->d[0];
  __builtin_memcpy (g, f, sizeof (float) * 4);
  bar ();
  if (!e->b)
if (g[0] != 0.0 || g[1] != 0.0 || g[2] != 1.0 || g[3] != 1.0)
  __builtin_abort ();
}

int
main ()
{
  float d[4];
  S e = { .d = d };
  foo (&e);
  return 0;
}

The optimized dump difference from the previous commit is
@@ -23,7 +23,6 @@ Removing basic block 17
 __attribute__((optimize (2), noinline))
 void foo (struct S * e)
 {
-  float h[4];
   float * g;
   const float * f;
   int _1;
@@ -32,10 +31,10 @@ void foo (struct S * e)
   float _4;
   float _5;
   float _6;
-  uint128_t _13;
+  uint128_t pretmp_18;
+  uint128_t prephitmp_19;

[local count: 1073741824]:
-  h = *.LC0;
   _1 = e_10(D)->b;
   if (_1 == 0)
 goto ; [50.00%]
@@ -44,12 +43,12 @@ void foo (struct S * e)

[local count: 536870912]:
   f_11 = e_10(D)->a;
+  pretmp_18 = MEM  [(char * {ref-all})f_11];

[local count: 1073741824]:
-  # f_7 = PHI <&h(2), f_11(3)>
+  # prephitmp_19 = PHI <4575657222473777152(2), pretmp_18(3)>
   g_12 = e_10(D)->d;
-  _13 = MEM  [(char * {ref-all})f_7];
-  MEM  [(char * {ref-all})g_12] = _13;
+  MEM  [(char * {ref-all})g_12] = prephitmp_19;
   bar ();
   _2 = e_10(D)->b;
   if (_2 == 0)
@@ -89,7 +88,6 @@ void foo (struct S * e)
   __builtin_abort ();

[local count: 1073741824]:
-  h ={v} {CLOBBER(eol)};
   return;

 }
4575657222473777152 is 0x3f803f80 so on big endian that looks
reasonable.

[Bug middle-end/114604] Ranger allocates from uninitialized bitmap_default_obstack

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

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

--- Comment #2 from Richard Biener  ---
Created attachment 57887
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57887&action=edit
BITMAP_ALLOC instrumentation

This is the instrumentation patch.

[Bug libstdc++/11196] _GNU_SOURCE vs. M_PI

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||zwuis at outlook dot com

--- Comment #18 from Jonathan Wakely  ---
*** Bug 114602 has been marked as a duplicate of this bug. ***

[Bug libstdc++/114602] Compilcation failure when using a user-defined function which name is same as a posix function

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
This is a longstanding issue that glibc headers expose all APIs when included
from C++ code.

You can either cast the function pointer to the right type:

std::sort(ptr, ptr, static_cast(bcmp));

or use a lambda expression:

std::sort(ptr, ptr, [](foo l, foo r) { return bcmp(l, r); });

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

[Bug c++/111132] [11/12/13/14 Regression] Function redeclaration in local scope breaks constant expression evaluation

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

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

--- Comment #4 from GCC Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r14-9809-g8c9063825ce726fcbbc067d8a6d062cc2d4acf5e
Author: Marek Polacek 
Date:   Tue Apr 2 12:59:38 2024 -0400

c++: constexpr error with fn redecl in local scope [PR32]

We evaluate constexpr functions on the original, pre-genericization bodies.
That means that the function body we're evaluating will not have gone
through cp_genericize_r's "Map block scope extern declarations to visible
declarations with the same name and type in outer scopes if any".  Here:

  constexpr bool bar() { return true; } // #1
  constexpr bool foo() {
constexpr bool bar(void); // #2
return bar();
  }

it means that we:
1) register_constexpr_fundef (#1)
2) cp_genericize (#1)
   nothing interesting happens
3) register_constexpr_fundef (foo)
   does copy_fn, so we have two copies of the BIND_EXPR
4) cp_genericize (foo)
   this remaps #2 to #1, but only on one copy of the BIND_EXPR
5) retrieve_constexpr_fundef (foo)
   we find it, no problem
6) retrieve_constexpr_fundef (#2)
   and here #2 isn't found in constexpr_fundef_table, because
   we're working on the BIND_EXPR copy where #2 wasn't mapped to #1
   so we fail.  We've only registered #1.

It should work to use DECL_LOCAL_DECL_ALIAS (which used to be
extern_decl_map).  We evaluate constexpr functions on pre-cp_fold
bodies to avoid diagnostic problems, but the remapping I'm proposing
should not interfere with diagnostics.

This is not a problem for a global scope redeclaration; there we go
through duplicate_decls which keeps the DECL_UID:
  DECL_UID (olddecl) = olddecl_uid;
and DECL_UID is what constexpr_fundef_hasher::hash uses.

PR c++/32

gcc/cp/ChangeLog:

* constexpr.cc (get_function_named_in_call): Use
cp_get_fndecl_from_callee.
* cvt.cc (cp_get_fndecl_from_callee): If there's a
DECL_LOCAL_DECL_ALIAS, use it.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-redeclaration3.C: New test.
* g++.dg/cpp0x/constexpr-redeclaration4.C: New test.

[Bug c++/114600] [14 Regression] [modules] redefinition errors when using certain std headers in GMF

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

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

Nathaniel Shead  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=99000

--- Comment #4 from Nathaniel Shead  ---
In general we don't yet implement merging of textual redefinitions; I guess
this ultimately falls under that, but I'm not sure we have a dedicated bug
report for that yet? Maybe PR99000.

I'm not yet sure exactly why my patch caused this to start failing though; it
sounds like it's exporting some using-decls even though they aren't directly
exported, which I suppose is still a bug in its own right.

[Bug middle-end/114604] Ranger allocates from uninitialized bitmap_default_obstack

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com
   Keywords||ice-on-valid-code

--- Comment #1 from Richard Biener  ---
It looks like ranger initializes a few bitmap obstacks, if there's no
convenient
ranger-wide one then calling

bitmap_obstack_initialize (NULL);

from enable_ranger and

bitmap_obstack_release (NULL);

from disable_ranger would initialize the global one (those handle nesting
from other callers).

[Bug middle-end/114604] New: Ranger allocates from uninitialized bitmap_default_obstack

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

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

Bug ID: 114604
   Summary: Ranger allocates from uninitialized
bitmap_default_obstack
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Visible at least from gcc.dg/torture/pr52429.c when instrumenting
bitmap_alloc with

bitmap
bitmap_alloc (bitmap_obstack *bit_obstack MEM_STAT_DECL)
{
  bitmap map;

  if (!bit_obstack)
{
  gcc_assert (bitmap_default_obstack_depth > 0);
  bit_obstack = &bitmap_default_obstack;

gcc.dg/torture/pr52429.c:24:1: internal compiler error: in bitmap_alloc, at
bitmap.cc:785^M
0xf3d95b bitmap_alloc(bitmap_obstack*)^M
/home/rguenther/src/trunk/gcc/bitmap.cc:785^M
0x2e89005 update_list::update_list()^M
/home/rguenther/src/trunk/gcc/gimple-range-cache.cc:900^M
0x2e893a2 ranger_cache::ranger_cache(int, bool)^M
/home/rguenther/src/trunk/gcc/gimple-range-cache.cc:976^M
0x2e815a9 gimple_ranger::gimple_ranger(bool)^M
/home/rguenther/src/trunk/gcc/gimple-range.cc:44^M
0x2e83e88 enable_ranger(function*, bool)^M
/home/rguenther/src/trunk/gcc/gimple-range.cc:693^M
0x13bfd62 ipa_analyze_node(cgraph_node*)^M
/home/rguenther/src/trunk/gcc/ipa-prop.cc:3191^M

[Bug c++/114600] [14 Regression] [modules] redefinition errors when using certain std headers in GMF

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

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

Patrick Palka  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=109679
   Keywords||ice-on-valid-code

--- Comment #3 from Patrick Palka  ---
Shorter reduction demonstrating an ICE:

$ cat 114600.h # other files same as before
namespace std {
  template struct A { int n; };
  template A f();
  namespace __swappable_details { using std::f; }
}

internal compiler error: in finish_member_declaration, at cp/semantics.cc:3771

[Bug tree-optimization/114566] [11/12/13 Regression] Misaligned vmovaps when compiling with stack-protector-strong for znver4

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12/13/14 Regression]|[11/12/13 Regression]
   |Misaligned vmovaps when |Misaligned vmovaps when
   |compiling with  |compiling with
   |stack-protector-strong for  |stack-protector-strong for
   |znver4  |znver4
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

[Bug tree-optimization/114566] [11/12/13/14 Regression] Misaligned vmovaps when compiling with stack-protector-strong for znver4

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

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

--- Comment #17 from GCC Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r14-9808-ga844095e17c1a5aada1364c6f6eaade87ead463c
Author: Jakub Jelinek 
Date:   Fri Apr 5 14:56:14 2024 +0200

vect: Don't clear base_misaligned in update_epilogue_loop_vinfo [PR114566]

The following testcase is miscompiled, because in the vectorized
epilogue the vectorizer assumes it can use aligned loads/stores
(if the base decl gets alignment increased), but it actually doesn't
increase that.
This is because r10-4203-g97c1460367 added the hunk following
patch removes.  The explanation feels reasonable, but actually it
is not true as the testcase proves.
The thing is, we vectorize the main loop with 64-byte vectors
and the corresponding data refs have base_alignment 16 (the
a array has DECL_ALIGN 128) and offset_alignment 32.  Now, because
of the offset_alignment 32 rather than 64, we need to use unaligned
loads/stores in the main loop (and ditto in the first load/store
in vectorized epilogue).  But the second load/store in the vectorized
epilogue uses only 32-byte vectors and because it is a multiple
of offset_alignment, it checks if we could increase alignment of the
a VAR_DECL, the function returns true, sets base_misaligned = true
and says the access is then aligned.
But when update_epilogue_loop_vinfo clears base_misaligned with the
assumption that the var had to have the alignment increased already,
the update of DECL_ALIGN doesn't happen anymore.

Now, I'd think this base_alignment = false was needed before
r10-4030-gd2db7f7901 change was committed where it incorrectly
overwrote DECL_ALIGN even if it was already larger, rather than
just always increasing it.  But with that change in, it doesn't
make sense to me anymore.

Note, the testcase is latent on the trunk, but reproduces on the 13
branch.

2024-04-05  Jakub Jelinek  

PR tree-optimization/114566
* tree-vect-loop.cc (update_epilogue_loop_vinfo): Don't clear
base_misaligned.

* gcc.target/i386/avx512f-pr114566.c: New test.

[Bug c++/114600] [14 Regression] [modules] redefinition errors when using certain std headers in GMF

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||nshead at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Keywords||rejects-valid
   Target Milestone|--- |14.0
 Blocks||103524
Summary|[modules] redefinition  |[14 Regression] [modules]
   |errors when using certain   |redefinition errors when
   |std headers in GMF  |using certain std headers
   ||in GMF
 Ever confirmed|0   |1
   Last reconfirmed||2024-04-05
 Status|UNCONFIRMED |NEW

--- Comment #2 from Patrick Palka  ---
Confirmed, started with r14-6978.

Mechanical reduction:

$ cat 114600.h
namespace std {
template  struct integral_constant {
  typedef integral_constant type;
};
template  using __enable_if_t = int;
template  auto __and_fn() -> integral_constant;
template  struct __and_ : decltype(__and_fn<_Bn...>) {};
template 
using _Require = __enable_if_t<__and_<_Cond...>::value>;
template  _Require<_Tp> swap();
namespace __swappable_details {
using std::swap;
}
} // namespace std

$ cat 114600_a.C
module;

#include "114600.h"

export module std;

$ cat 114600_b.C
import std;

#include "114600.h"

int main()
{
}

$ g++ -fmodules-ts 114600_*.C
114600.h:3:29: error: template definition of non-template 'typedef struct
std::integral_constant<  > std::integral_constant<
 >::type'


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue

[Bug tree-optimization/102793] AArch64: sequential comparisons with equal conditional blocks don't use ccmp

[manolis.tsamis at vrull dot eu via Gcc-bugs]

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

--- Comment #7 from Manolis Tsamis  ---
Also submitted in the lists:
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/648856.html

I should note that I needed to modify the test uninit-pred-6_c.c and remove
this check:

  if (l)
if (n > 12)
  blah(v); /* { dg-bogus "uninitialized" "bogus warning" } */

because it was inconsistent. If the branch is merged to a simple if (l && (n >
12)) is fails (on master). With the proposed patch we get more ifcombining and
better codegen but this condition fails. I believe this would need an
enhancement in tree-ssa-uninit.

[Bug tree-optimization/102793] AArch64: sequential comparisons with equal conditional blocks don't use ccmp

[manolis.tsamis at vrull dot eu via Gcc-bugs]

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

Manolis Tsamis  changed:

   What|Removed |Added

 CC||manolis.tsamis at vrull dot eu

--- Comment #6 from Manolis Tsamis  ---
Created attachment 57886
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57886&action=edit
Patch with proposed fix for the issue.

Adding a copy of the ifcombine pass after pre solves this issues and improves
code generation is some other cases too. I specifically chose after the pre
pass because it deduplicates basic blocks and helps in maximizing the effect of
ifcombine.

[Bug target/114603] New: aarch64: Invalid SVE cnot optimisation

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

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

Bug ID: 114603
   Summary: aarch64: Invalid SVE cnot optimisation
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

An overly lax condition on the cnot combine pattern means that we optimise:

#include 

svint32_t foo(svbool_t pg, svint32_t y)
{
  return svsel(svcmpeq(pg, y, 0), svdup_s32(1), svdup_s32(0));
}

to a single cnot:

foo:
cnotz0.s, p0/m, z0.s
ret

The result must be 0 for inactive elements of pg, whereas the above would leave
the elements unchanged instead.

This seems to have been around since the SVE ACLE was first added.