[Bug libstdc++/115064] New: Possible problem with money_put

[lcarreon at bigpond dot net.au via Gcc-bugs]

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

Bug ID: 115064
   Summary: Possible problem with money_put
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lcarreon at bigpond dot net.au
  Target Milestone: ---

I have been experimenting with std::money_put and discovered the following:

#include 
#include 
#include 
#include 
#include 

int main()
{
  std::locale loc{std::locale{"de_DE.utf8"}};
  std::cout.imbue(loc);

  auto money = 123456789.0L;

  {
const auto& money_put =
std::use_facet>(std::cout.getloc());
std::cout << "\"" << std::showbase << std::setw(20) << std::right;
money_put.put(std::cout, false, std::cout, '*', money);
std::cout << "\"" << std::endl;
  }

  {
std::ostringstream str;
str.imbue(loc);
const auto& money_put = std::use_facet>(str.getloc());
str << std::showbase << std::setw(20) << std::right;
money_put.put(str, false, str, '*', money);
str << std::endl;
for (const auto& ch : str.str())
{
  std::cout << std::format("{:02x} ", ch);
}
std::cout << std::endl;
  }

  return 0;
}

I compiled the above program using g++ 14.0.1 using c++20 mode. When I execute
the program on a terminal whose LANG is set to en_AU.utf8, I get the following
result:

"1.234.567,89*€"
2a 2a 2a 2a 31 2e 32 33 34 2e 35 36 37 2c 38 39 2a e2 82 ac 0a

The first line above is the problematic one because it shows only 18 characters
inside the double quotes instead of 20.  The second line above explains why. 
The euro symbol is made up of three octets which is upsetting std::setw(20).

I revised the above program using wchar_t and std::wcout as follows:

#include 
#include 
#include 
#include 
#include 

int main()
{
  std::locale loc{std::locale{"de_DE.utf8"}};
  std::wcout.imbue(loc);

  auto money = 123456789.0L;

  {
const auto& money_put =
std::use_facet>(std::wcout.getloc());
std::wcout << L"\"" << std::showbase << std::setw(20) << std::right;
money_put.put(std::wcout, false, std::wcout, L'*', money);
std::wcout << L"\"" << std::endl;
  }

  {
std::wostringstream str;
str.imbue(loc);
const auto& money_put =
std::use_facet>(str.getloc());
str << std::showbase << std::setw(20) << std::right;
money_put.put(str, false, str, L'*', money);
str << std::endl;
for (const auto& ch : str.str())
{
  std::wcout << std::format(L"{:02x} ", static_cast(ch));
}
std::wcout << std::endl;
  }

  return 0;
}

Executing the above program on the same terminal, I get the following:

"**1.234.567,89*EUR"
2a 2a 2a 2a 2a 2a 31 2e 32 33 34 2e 35 36 37 2c 38 39 2a 20ac 0a

The first line above now has 22 characters instead of 20.  The second line
above shows what characters were sent to the terminal.  It seems the euro
symbol "20ac" is displayed by the terminal as "EUR" instead of the single glyph
"€".

I understand that the terminal is set for UTF-8, thus the correct display of
the euro symbol in char mode.  But why display "EUR" in wchar_t mode?

[Bug target/115065] New: AVR clz is not always fast as can be

[WolfgaNg.Hospital at arcor dot de via Gcc-bugs]

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

Bug ID: 115065
   Summary: AVR clz is not always fast as can be
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: WolfgaNg.Hospital at arcor dot de
  Target Milestone: ---

Created attachment 58186
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58186&action=edit
AVR assembly code for __clzhi2

For 8-bit AVRs, count leading zeroes is based on __clzhi2. (This is in contrast
to popcount using the single-register (qi) variant. Possibly due to the
convenience of having the MSB of the result cleared in just one place. No idea
if it was wiser to declare the result single-register, plenty even for
"double-width integer" arguments.)
Instruction order isn't optimal up to now, allowing to take one cycle off for
argument values 1-255. (This includes the worst case: 1.)

[Bug tree-optimization/114932] Improvement in CHREC can give large performance gains

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #8 from Tamar Christina  ---
(In reply to Richard Biener from comment #7)
> Likely
> 
>   Base: (integer(kind=4) *) &block + ((sizetype) ((unsigned long) l0_19(D) *
> 324) + 36)
> 
> vs.
> 
>   Base: (integer(kind=4) *) &block + ((sizetype) ((integer(kind=8)) l0_19(D)
> * 81) + 9) * 4
> 
> where we fail to optimize the outer multiply.  It's
> 
>  ((unsigned)((signed)x * 81) + 9) * 4
> 
> and likely done by extract_muldiv for the case of (unsigned)x.  The trick
> would be to promote the inner multiply to unsigned to make the otherwise
> profitable transform valid.  But best not by enhancing extract_muldiv ...

Ah, merci!

Mine then.

[Bug debug/115066] New: [debug, gsplit-dwarf, gdwarf-4, g3] DW_MACRO_define_strp used for debug_str_offsets index

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

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

Bug ID: 115066
   Summary: [debug, gsplit-dwarf, gdwarf-4, g3]
DW_MACRO_define_strp used for debug_str_offsets index
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider a hello world, compiled with split dwarf and dwarf version 4, and -g3
for macro info:
...
$ gcc -gdwarf-4 -gsplit-dwarf /data/vries/hello.c -g3 -save-temps -dA
...

In section .debug_macro.dwo, we have:
...
.Ldebug_macro0:
.value  0x4 # DWARF macro version number
.byte   0x2 # Flags: 32-bit, lineptr present
.long   .Lskeleton_debug_line0
.byte   0x3 # Start new file
.uleb128 0  # Included from line number 0
.uleb128 0x1# file /data/vries/hello.c
.byte   0x5 # Define macro strp
.uleb128 0  # At line number 0
.uleb128 0x1d0  # The macro: "__STDC__ 1"
...

So, given that we use a DW_MACRO_define_strp, we'd expect 0x1d0 to be an offset
into a .debug_str section.

However, in .debug_str.dwo we find:
...
  0x01d0 455f584f 50454e32 4b385853 49005345 E_XOPEN2K8XSI.SE
...

In fact, 0x1d0 is an index into the string offset table in
.debug_str_offsets.dwo:
...
.long   0x34f0  # indexed string 0x1d0: __STDC__ 1
...

So, it looks like DW_MACRO_define_strx should have been used instead.

[Bug debug/115066] [debug, gsplit-dwarf, gdwarf-4, g3] DW_MACRO_define_strp used for debug_str_offsets index

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

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

--- Comment #1 from Tom de Vries  ---
Looking at the source code, I wonder if this would fix it:
...
diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index eedb13bb069..045858bf638 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -29045,7 +29045,7 @@ output_macinfo_op (macinfo_entry *ref)
  && !DWARF2_INDIRECT_STRING_SUPPORT_MISSING_ON_TARGET
  && (debug_str_section->common.flags & SECTION_MERGE) != 0)
{
- if (dwarf_split_debug_info && dwarf_version >= 5)
+ if (dwarf_split_debug_info && (!dwarf_strict || dwarf_version >= 5))
ref->code = ref->code == DW_MACINFO_define
? DW_MACRO_define_strx : DW_MACRO_undef_strx;
  else
...

[Bug c++/115031] g++.dg/modules/pr99023_b.X FAILs

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

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

Rainer Orth  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #1 from Rainer Orth  ---
Nathan, any suggestion where to start looking here?

[Bug c++/98529] [11/12/13/14/15 Regression] g++.dg/modules/stdio-1_a.H FAILs

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

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

Rainer Orth  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-May/651
   ||427.html

--- Comment #10 from Rainer Orth  ---
Patch posted.

[Bug target/112959] install.tex needs updates on FreeBSD

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #11 from Gerald Pfeifer  ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #6)
>> What's there looks good to me.
>
> Cool, thank you. I cherry picked the changes I made to the GCC 14 
> branch, so they should be in the GCC 14.2 release.

Great, thanks.

>> However, one issue mentioned in PR target/112959 is missing, namely the
>> problem of getting a working Ada bootstrap compiler. I have no idea if
>> gnat12 has been fixed since and is now able to build Ada on trunk/the
>> gcc-14 branch.  Otherwise, the old GNAT 6.4.1 worked for me, but this
>> isn't easy to find.
>
> Looking at the lang/gnat12 and now lang/gcc13 ports and recent changes
> including ones like
[...]
> (which was a few days after this report was filed) I am hopefully it would
> work. However, I cannot guarantee.
>
> I am temped to mark this report as RESOLVED based on my changes.

I tend to agree: if someone runs into GNAT problems in the future, they
can report them anew.

[Bug libstdc++/66146] call_once not C++11-compliant

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

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

--- Comment #58 from Iain Sandoe  ---
As far as I can tell, (at least on targets with TLS support) since the
variables __once_callable and __once_call have a single instance per thread,
the current implementation does not support nested once_call()s in the same
thread either.

[Bug libstdc++/115059] Constraints/Mandates on the comparison operators of std::optional and std::variant are overly strict

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

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

--- Comment #1 from Jonathan Wakely  ---
I don't want to change anything in libstdc++ here. Either std::is_convertible
should be sufficient to check "convertible to" constraints, or "convertible to"
should exclude these kind of games.

[Bug libstdc++/115063] compilation error: std::basic_stracktrace::max_size()

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Target Milestone|--- |13.3
   Keywords||rejects-valid
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Last reconfirmed||2024-05-13
 Status|UNCONFIRMED |ASSIGNED

[Bug debug/115066] [debug, gsplit-dwarf, gdwarf-4, g3] DW_MACRO_define_strp used for debug_str_offsets index

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

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

--- Comment #2 from Tom de Vries  ---
(In reply to Tom de Vries from comment #1)
> Looking at the source code, I wonder if this would fix it:
> ...
> diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
> index eedb13bb069..045858bf638 100644
> --- a/gcc/dwarf2out.cc
> +++ b/gcc/dwarf2out.cc
> @@ -29045,7 +29045,7 @@ output_macinfo_op (macinfo_entry *ref)
> && !DWARF2_INDIRECT_STRING_SUPPORT_MISSING_ON_TARGET
> && (debug_str_section->common.flags & SECTION_MERGE) != 0)
>   {
> -   if (dwarf_split_debug_info && dwarf_version >= 5)
> +   if (dwarf_split_debug_info && (!dwarf_strict || dwarf_version >= 5))
>   ref->code = ref->code == DW_MACINFO_define
>   ? DW_MACRO_define_strx : DW_MACRO_undef_strx;
> else
> ...

With that change I get:
...
.Ldebug_macro0:
.value  0x4 # DWARF macro version number
.byte   0x2 # Flags: 32-bit, lineptr present
.long   .Lskeleton_debug_line0
.byte   0x3 # Start new file
.uleb128 0  # Included from line number 0
.uleb128 0x1# file /data/vries/hello.c
.byte   0xb # Define macro strx
.uleb128 0  # At line number 0
.uleb128 0x17b  # The macro: "__STDC__ 1"
...

[Bug c++/115067] New: Bogus -O2 -Wnull-dereference for istreambuf_iterator

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 115067
   Summary: Bogus -O2 -Wnull-dereference for istreambuf_iterator
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

#include 
#include 
#include 

std::string fn() {
  std::istringstream is {"bob"};
  auto beg = std::istreambuf_iterator(is);
  auto end = std::istreambuf_iterator();
  return {beg, end};
}

int main() {
  std::cout << fn() << "\n";
}

https://godbolt.org/z/rGqW5he87

The above code always triggers the following warning when -O2
-Wnull-dereference is used since GCC-12:

/opt/compiler-explorer/gcc-trunk-20240513/include/c++/15.0.0/streambuf:495:30:
error: potential null pointer dereference [-Werror=null-dereference]
  495 |   egptr() const { return _M_in_end; }
  |  ^
In member function 'std::basic_streambuf<_CharT, _Traits>::char_type*
std::basic_streambuf<_CharT, _Traits>::gptr() const [with _CharT = char;
_Traits = std::char_traits]',
inlined from 'std::basic_streambuf<_CharT, _Traits>::int_type
std::basic_streambuf<_CharT, _Traits>::sbumpc() [with _CharT = char; _Traits =
std::char_traits]' at
/opt/compiler-explorer/gcc-trunk-20240513/include/c++/15.0.0/streambuf:326:33,
inlined from 'std::istreambuf_iterator<_CharT, _Traits>&
std::istreambuf_iterator<_CharT, _Traits>::operator++() [with _CharT = char;
_Traits = std::char_traits]' at
/opt/compiler-explorer/gcc-trunk-20240513/include/c++/15.0.0/bits/streambuf_iterator.h:173:17,
inlined from 'void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_construct(_InIterator, _InIterator, std::input_iterator_tag) [with
_InIterator = std::istreambuf_iterator >; _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20240513/include/c++/15.0.0/bits/basic_string.tcc:182:6,
inlined from 'std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::basic_string(_InputIterator, _InputIterator, const _Alloc&) [with
_InputIterator = std::istreambuf_iterator >;
 = void; _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20240513/include/c++/15.0.0/bits/basic_string.h:770:16,
inlined from 'std::string fn()' at :9:19:
/opt/compiler-explorer/gcc-trunk-20240513/include/c++/15.0.0/streambuf:492:30:
error: potential null pointer dereference [-Werror=null-dereference]
  492 |   gptr()  const { return _M_in_cur;  }

[Bug middle-end/113982] Poor codegen for 64-bit add with carry widening functions

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

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

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

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

commit r15-427-gb621482296f6dec0abb22ed39cc4ce6811535d47
Author: Jakub Jelinek 
Date:   Mon May 13 11:15:27 2024 +0200

tree-ssa-math-opts: Pattern recognize yet another .ADD_OVERFLOW pattern
[PR113982]

We pattern recognize already many different patterns, and closest to the
requested one also
   yc = (type) y;
   zc = (type) z;
   x = yc + zc;
   w = (typeof_y) x;
   if (x > max)
where y/z has the same unsigned type and type is a wider unsigned type
and max is maximum value of the narrower unsigned type.
But apparently people are creative in writing this in diffent ways,
this requests
   yc = (type) y;
   zc = (type) z;
   x = yc + zc;
   w = (typeof_y) x;
   if (x >> narrower_type_bits)

The following patch implements that.

2024-05-13  Jakub Jelinek  

PR middle-end/113982
* tree-ssa-math-opts.cc (arith_overflow_check_p): Also return 1
for RSHIFT_EXPR by precision of maxval if shift result is only
used in a cast or comparison against zero.
(match_arith_overflow): Handle the RSHIFT_EXPR use case.

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

[Bug tree-optimization/115033] Incorrect optimization of by-reference closure fields by fre1 pass

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||alias
 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---

  resultIsStatic = 1;
  D.39198.__inputIsStatic = &inputIsStatic;
  D.39198.__resultIsStatic = &resultIsStatic;
  D.39198.__newShape = &newShape;
  D.39198.__totalSize = &totalSize;
  resultShape = llvm::map_to_vector&,
inferReshapeExpandedType(llvm::ArrayRef, llvm::ArrayRef):: > (&newShape, &D.39198); [return slot optimization]
  D.39198 ={v} {CLOBBER(eol)};
  inputIsStatic.3_7 = inputIsStatic;
  _8 = ~inputIsStatic.3_7;
  if (inputIsStatic.3_7 != 0)
goto ; [INV]
  else
goto ; [INV]

   :
  resultIsStatic.4_9 = resultIsStatic;

I don't see how llvm::map_to_vector modifies 'resultIsStatic' so it seems
like a correct optimization to assume it is 1?  Or maybe I am misunderstanding
the call.  We end up in

struct SmallVector llvm::map_to_vector&,
inferReshapeExpandedType(llvm::ArrayRef, llvm::ArrayRef):: > (struct ArrayRef & C, struct ._anon_81 & F)

where I can see a struct .anon_81 (that's from the lambda I guess).

The source seems to be

  bool resultIsStatic = true;
  auto resultShape = llvm::map_to_vector(newShape, [&](int64_t size) -> int64_t
{

if (size >= 0)
  return size;

if (!inputIsStatic) {
  resultIsStatic = false;
  return kDynamic;
...

so it might be interesting to try reducing it further.  I'll note that
using -fno-ipa-modref avoids FRE doing the CSE but -fno-strict-aliasing
doesn't.  So maybe it's a genuine modref bug.  IIRC there are some
that might be fixed in GCC 14 but not yet earlier.

[Bug tree-optimization/115033] [12/13/14/15 Regression] Incorrect optimization of by-reference closure fields by fre1 pass

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.4
Summary|Incorrect optimization of   |[12/13/14/15 Regression]
   |by-reference closure fields |Incorrect optimization of
   |by fre1 pass|by-reference closure fields
   ||by fre1 pass

--- Comment #5 from Richard Biener  ---
Btw, GCC 14 was just released and the bug seems to reproduce there, too (if it
is a bug).

[Bug middle-end/113982] Poor codegen for 64-bit add with carry widening functions

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Should be fixed now.

[Bug tree-optimization/115034] Missed optimization: reduntant store of identical value in the slot

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
   Last reconfirmed||2024-05-13
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
This would work if we'd duplicate the path from a = 0 to *outl = 1; return 0;
but we don't early enough (on GIMPLE) and we don't do that on RTL until
BB reorder where ther's no later pass doing this optimization either.

On GIMPLE we see

   [local count: 1073741824]:
  *outl_4(D) = 0;
  if (c1_6(D) != 0)
goto ; [50.00%]
  else
goto ; [50.00%]
...
   [local count: 965079152]:
  # a_1 = PHI <1(3), 0(2)>
  *outl_4(D) = a_1;
  return 0;

but I think tracer doesn't consider paths to exit aka tail duplication,
likely because on GIMPLE we force a single return block.  There's also
no partial redundant store elimination.

[Bug middle-end/115036] division is not shortened based on value range

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

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

--- Comment #1 from Richard Biener  ---
former fold_stmt_using_ranges has code to narrow ops.

[Bug target/115038] [14/15 regression] internal error in seh_cfa_offset with -O2 -fno-omit-frame-pointer

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Target|X86_64-mingw32  |x86_64-mingw32
  Known to work||13.2.0

[Bug target/115042] [14/15 Reression] valgrind test fails to compile on armv7

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.2
Summary|valgrind test fails to  |[14/15 Reression] valgrind
   |compile on armv7|test fails to compile on
   ||armv7

[Bug c++/115049] [14/15 Regression] Silent severe miscompilation around inline functions

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-mingw64
Summary|Silent severe   |[14/15 Regression] Silent
   |miscompilation around   |severe miscompilation
   |inline functions|around inline functions
   Target Milestone|--- |14.2
   Keywords||wrong-code

[Bug libstdc++/115059] Constraints/Mandates on the comparison operators of std::optional and std::variant are overly strict

[de34 at live dot cn via Gcc-bugs]

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

--- Comment #2 from Jiang An  ---
(In reply to Jonathan Wakely from comment #1)
> I don't want to change anything in libstdc++ here. Either
> std::is_convertible should be sufficient to check "convertible to"
> constraints, or "convertible to" should exclude these kind of games.

Yeah. This is perphaps in the scope of LWG484 and LWG3105, but guaranteed copy
elision doesn't seem discussed yet.

[Bug tree-optimization/115055] reassociation should use match-and-simplify

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
  b_5 = a_3(D) & c_4(D);
  _1 = a_3(D) == 0;
  _2 = (int) _1;
  _6 = b_5 & _2;
  return _6;

I believe reassoc doesn't see that a and (int)(a == 0) are "related" when
ranking ops of the AND, so it fails to appropriately order them and thus
trigger the simplification.  We definitely want to avoid doing n^2
matching combos of all AND operands.

So confirmed, but not necessarily confirming the proposed solution.

[Bug rtl-optimization/115056] [14/15 regression] Miscompilation (also triggering -Wstringop-overflow and -Warray-bounds warning) when -O2 or higher

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.2

[Bug target/115010] m68k: invalid subl instruction generated

[admin--- via Gcc-bugs]

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

--- Comment #12 from Thorsten Otto  ---
Created attachment 58187
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58187&action=edit
2nd test case

[Bug target/115010] m68k: invalid subl instruction generated

[admin--- via Gcc-bugs]

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

--- Comment #13 from Thorsten Otto  ---
Now its getting really strange. I've attached a 2nd test case above. With that,
the bug can be reproduced also with gcc 11.4.0 (but not with gcc-10, gcc-12 or
gcc-13).

It is slightly larger than the first case, but also has references to
__builtin_mul_overflow(). The 1st test case does not trigger the bug in gcc-11
though. 

Note that the commit that was identified as the culprit was only applied to the
gcc-14 branch, but not to gcc-11.

[Bug tree-optimization/115060] Probable an issue around usage of vect_look_through_possible_promotion in tree-vect-patterns.cc

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||rguenth at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
   Last reconfirmed||2024-05-13
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  Probably vect_get_internal_def itself should concern itself with
this.

[Bug debug/115066] [debug, gsplit-dwarf, gdwarf-4, g3] DW_MACRO_define_strp used for debug_str_offsets index

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-debug

--- Comment #3 from Richard Biener  ---
And with -gstrict-dwarf -gdwarf-4?

[Bug debug/115066] [debug, gsplit-dwarf, gdwarf-4, g3] DW_MACRO_define_strp used for debug_str_offsets index

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

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

--- Comment #4 from Tom de Vries  ---
(In reply to Richard Biener from comment #3)
> And with -gstrict-dwarf -gdwarf-4?

With:
...
$ gcc.sh -gdwarf-4 -gsplit-dwarf /data/vries/hello.c -g3 -gstrict-dwarf
...
we get:
...
.section.debug_macinfo.dwo,"e",@progbits
.Ldebug_macinfo0:
.byte   0x3 # Start new file
.uleb128 0  # Included from line number 0
.uleb128 0x1# file /data/vries/hello.c
.byte   0x1 # Define macro
.uleb128 0  # At line number 0
.ascii "__STDC__ 1\0"   # The macro
...

[Bug target/112959] install.tex needs updates on FreeBSD

[gerald at pfeifer dot com via Gcc-bugs]

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

Gerald Pfeifer  changed:

   What|Removed |Added

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

--- Comment #14 from Gerald Pfeifer  ---
Thank you Thierry and Rainer - based on your feedback let me close
this as resolved.

[Bug debug/115066] [debug, gsplit-dwarf, gdwarf-4, g3] DW_MACRO_define_strp used for debug_str_offsets index

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
(In reply to Tom de Vries from comment #1)
> Looking at the source code, I wonder if this would fix it:
> ...
> diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
> index eedb13bb069..045858bf638 100644
> --- a/gcc/dwarf2out.cc
> +++ b/gcc/dwarf2out.cc
> @@ -29045,7 +29045,7 @@ output_macinfo_op (macinfo_entry *ref)
> && !DWARF2_INDIRECT_STRING_SUPPORT_MISSING_ON_TARGET
> && (debug_str_section->common.flags & SECTION_MERGE) != 0)
>   {
> -   if (dwarf_split_debug_info && dwarf_version >= 5)
> +   if (dwarf_split_debug_info && (!dwarf_strict || dwarf_version >= 5))
>   ref->code = ref->code == DW_MACINFO_define
>   ? DW_MACRO_define_strx : DW_MACRO_undef_strx;
> else
> ...

Just make it if (dwarf_split_debug_info) then?
I mean, this whole code is guarded with
  if ((!dwarf_strict || dwarf_version >= 5)
  && ...)

[Bug target/114412] [14/15 Regression] 7% slowdown of 436.cactusADM on aarch64

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

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #3 from Tamar Christina  ---
Hi Filip,

Do you generate these runs with counters based PGO or compiler instrumentation?

Just so I know before I start trying to reproduce them.

[Bug target/113578] Incorrect sign printed for -nan on RISC-V

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

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

--- Comment #8 from Jonathan Wakely  ---
Hmm, you could be right. It looks like the printf in Apple libc doesn't print
"-nan" even when not converting from float to double.

According to
https://developer.r-project.org/Blog/content/post/2020-11-02-apple-silicon.html
the Apple silicon NaN payloads are not propagated by default, but I don't know
if that means the signbit is not propagated. I assumed it meant they were
running in default NaN mode.

[Bug debug/115066] [debug, gsplit-dwarf, gdwarf-4, g3] DW_MACRO_define_strp used for debug_str_offsets index

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

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

--- Comment #6 from Tom de Vries  ---
(In reply to Jakub Jelinek from comment #5)
> Just make it if (dwarf_split_debug_info) then?

That works as well indeed:
...
diff --git a/gcc/dwarf2out.cc b/gcc/dwarf2out.cc
index eedb13bb069..70b7f5f42cd 100644
--- a/gcc/dwarf2out.cc
+++ b/gcc/dwarf2out.cc
@@ -29045,7 +29045,7 @@ output_macinfo_op (macinfo_entry *ref)
  && !DWARF2_INDIRECT_STRING_SUPPORT_MISSING_ON_TARGET
  && (debug_str_section->common.flags & SECTION_MERGE) != 0)
{
- if (dwarf_split_debug_info && dwarf_version >= 5)
+ if (dwarf_split_debug_info)
ref->code = ref->code == DW_MACINFO_define
? DW_MACRO_define_strx : DW_MACRO_undef_strx;
  else
@@ -29097,12 +29097,20 @@ output_macinfo_op (macinfo_entry *ref)
   HOST_WIDE_INT_PRINT_UNSIGNED,
   ref->lineno);
   if (node->form == DW_FORM_strp)
-dw2_asm_output_offset (dwarf_offset_size, node->label,
-   debug_str_section, "The macro: \"%s\"",
-   ref->info);
+   {
+ gcc_assert (ref->code == DW_MACRO_define_strp
+ || ref->code == DW_MACRO_undef_strp);
+ dw2_asm_output_offset (dwarf_offset_size, node->label,
+debug_str_section, "The macro: \"%s\"",
+ref->info);
+   }
   else
-dw2_asm_output_data_uleb128 (node->index, "The macro: \"%s\"",
- ref->info);
+   {
+ gcc_assert (ref->code == DW_MACRO_define_strx
+ || ref->code == DW_MACRO_undef_strx);
+ dw2_asm_output_data_uleb128 (node->index, "The macro: \"%s\"",
+  ref->info);
+   }
   break;
 case DW_MACRO_import:
   dw2_asm_output_data (1, ref->code, "Import");
...

I've also added asserts detecting this PR.

[Bug middle-end/115067] Bogus -O2 -Wnull-dereference for istreambuf_iterator

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Dup

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

[Bug libstdc++/105580] [12/13/14/15 Regression] warning "potential null pointer dereference" raised when using istreambuf_iterator and any "-O" flag

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||hewillk at gmail dot com

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

[Bug middle-end/86172] [meta-bug] issues with -Wnull-dereference

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

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

Bug 115067 Summary: Bogus -O2 -Wnull-dereference for istreambuf_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115067

   What|Removed |Added

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

[Bug tree-optimization/114826] [13 Regression] Bogus -Warray-bounds warning for 32-byte array with certain march flags

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug analyzer/114159] [13 Regression] ICE: in call_info, at analyzer/call-info.cc:143 with -fanalyzer -fanalyzer-call-summaries --param=analyzer-max-svalue-depth=0

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/113332] [12/13 regression] checking ICE when building fcitx-5.1.6

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/113158] [11/12/13 Regression] Erroneous "looser exception specification" error for class template and depedent noexcept value

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/112658] [12/13 Regression] ICE: finish_expr_stmt with casting an temp array to pointer and constructor call

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/111668] [12/13 Regression] vrp2 (match and simplify) introduces invalid wide signed Boolean values

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug analyzer/111266] [13 Regression] Missing -Wanalyzer-out-of-bounds for concrete offset overwrite.

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/111249] [12/13 Regression] Aggressive loop optimization reports "iteration 2147483645 invokes undefined behavior"

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c/111059] [11/12/13 Regression] ICE: in gimplify_expr, at gimplify.cc:17253

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug sanitizer/110676] [11/12/13 Regression] strlen of array[1] should not be optimized to 0 if using ASAN

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/110269] [13 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-4607-g2dc5d6b1e7e

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug analyzer/109802] [13 Regression] ICE using dubious flexible arrays in unions

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug libstdc++/109772] [13 Regression] Memory layout optimization of std::chrono::hh_mm_ss is wrong

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug analyzer/109077] [11/12/13 Regression] Analyzer headers not installed

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/115010] m68k: invalid subl instruction generated

[admin--- via Gcc-bugs]

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

--- Comment #14 from Thorsten Otto  ---
A bisect between 10.0.0 and 11.4.0 for the 2nd testcase gave me this commit:

commit 512c6ba04102295fccc62a173ee0086ca733c920
From: Richard Biener 
Date: Thu, 12 Nov 2020 11:29:12 +0100
Subject: [PATCH] Avoid PRE insert iteration when possible

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

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug debug/107169] [13 Regression] -fcompare-debug failure at -O and above since r13-2921-gf1adf45b17f7f1ed

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/102250] [11/12/13 Regression] python is not documented as a Prerequisite for building for riscv

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug debug/92387] [11/12/13 Regression] gcc generates wrong debug information at -O1 since r10-1907-ga20f263ba1a76a

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug middle-end/54052] [11/12/13 Regression] g++ takes excessive time in opt and generate phase; can lead to Segmentation Fault when not enough memory available

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c/115068] New: RISC-V: Illegal instruction of vfwadd

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

Bug ID: 115068
   Summary: RISC-V: Illegal instruction of vfwadd
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juzhe.zhong at rivai dot ai
  Target Milestone: ---

#include 
#include 

vfloat64m8_t test_vfwadd_wf_f64m8_m(vbool8_t vm, vfloat64m8_t vs2, float rs1,
size_t vl) {
  return __riscv_vfwadd_wf_f64m8_m(vm, vs2, rs1, vl);
}

char global_memory[1024];
void *fake_memory = (void *)global_memory;

int main ()
{
  asm volatile("fence":::"memory");
  vfloat64m8_t vfwadd_wf_f64m8_m_vd =
test_vfwadd_wf_f64m8_m(__riscv_vreinterpret_v_i8m1_b8(__riscv_vundefined_i8m1()),
__riscv_vundefined_f64m8(), 1.0, __riscv_vsetvlmax_e64m8());
  asm volatile(""::"vr"(vfwadd_wf_f64m8_m_vd):"memory");

  return 0;
}

https://compiler-explorer.com/z/rq7K33zE5

main:
fence
lui a5,%hi(.LC0)
flw fa5,%lo(.LC0)(a5)
vsetvli a5,zero,e32,m4,ta,ma
vfwadd.wf   v0,v8,fa5,v0.t ---> vd should not be v0.
li  a0,0
ret

[Bug libstdc++/114958] use __builtin_shufflevector for std::experimental::simd split and concat (at least the common cases) to enable better optimizations

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Matthias Kretz :

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

commit r15-429-gfb1649f8b4ad5043dd0e65e4e3a643a0ced018a9
Author: Matthias Kretz 
Date:   Mon May 6 12:13:55 2024 +0200

libstdc++: Use __builtin_shufflevector for simd split and concat

Signed-off-by: Matthias Kretz 

libstdc++-v3/ChangeLog:

PR libstdc++/114958
* include/experimental/bits/simd.h (__as_vector): Return scalar
simd as one-element vector. Return vector from single-vector
fixed_size simd.
(__vec_shuffle): New.
(__extract_part): Adjust return type signature.
(split): Use __extract_part for any split into non-fixed_size
simds.
(concat): If the return type stores a single vector, use
__vec_shuffle (which calls __builtin_shufflevector) to produce
the return value.
* include/experimental/bits/simd_builtin.h
(__shift_elements_right): Removed.
(__extract_part): Return single elements directly. Use
__vec_shuffle (which calls __builtin_shufflevector) to for all
non-trivial cases.
* include/experimental/bits/simd_fixed_size.h (__extract_part):
Return single elements directly.
* testsuite/experimental/simd/pr114958.cc: New test.

[Bug c++/98529] [11/12/13/14/15 Regression] g++.dg/modules/stdio-1_a.H FAILs

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

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

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Rainer Orth :

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

commit r15-430-gc4af8ebdb0318b5e9ed3dfdea5501a3260f3acea
Author: Rainer Orth 
Date:   Mon May 13 14:02:46 2024 +0200

testsuite: c++: Allow for std::printf in g++.dg/modules/stdio-1_a.H
[PR98529]

g++.dg/modules/stdio-1_a.H currently FAILs on Solaris:

FAIL: g++.dg/modules/stdio-1_a.H -std=c++17  scan-lang-dump module
"Depset:0 decl entity:[0-9]* function_decl:'::printf'"
FAIL: g++.dg/modules/stdio-1_a.H -std=c++2a  scan-lang-dump module
"Depset:0 decl entity:[0-9]* function_decl:'::printf'"
FAIL: g++.dg/modules/stdio-1_a.H -std=c++2b  scan-lang-dump module
"Depset:0 decl entity:[0-9]* function_decl:'::printf'"

The problem is that the module file doesn't contain

 Depset:0 decl entity:95 function_decl:'::printf'

as expected by the test, but

 Depset:0 decl entity:26 function_decl:'::std::printf'

This happens because Solaris  declares printf in namespace std
as allowed by C++11, Annex D, D.5.

This patch allows for both forms.

Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11, and
x86_64-pc-linux-gnu.

2024-05-13  Rainer Orth  

gcc/testsuite:
PR c++/98529
* g++.dg/modules/stdio-1_a.H (scan-lang-dump): Allow for
::std::printf.

[Bug c++/98529] [11/12/13/14/15 Regression] g++.dg/modules/stdio-1_a.H FAILs

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|11.5|15.0
 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org

--- Comment #12 from Rainer Orth  ---
Fixed for GCC 15.

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 98529 Summary: [11/12/13/14/15 Regression] g++.dg/modules/stdio-1_a.H FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98529

   What|Removed |Added

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

[Bug middle-end/54052] [11/12/13 Regression] g++ takes excessive time in opt and generate phase; can lead to Segmentation Fault when not enough memory available

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

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

--- Comment #16 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Richard Biener
:

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

commit r13-8763-gd629308c699bb8fe90c2afeb7fa1acb12cb5526b
Author: Richard Biener 
Date:   Mon Feb 19 11:10:50 2024 +0100

rtl-optimization/54052 - RTL SSA PHI insertion compile-time hog

The following tries to address the PHI insertion compile-time hog in
RTL fwprop observed with the PR54052 testcase where the loop computing
the "unfiltered" set of variables possibly needing PHI nodes for each
block exhibits quadratic compile-time and memory-use.

It does so by pruning the local DEFs with LR_OUT of the block, removing
regs that can never be LR_IN (defined by this block) in the dominance
frontier.

PR rtl-optimization/54052
* rtl-ssa/blocks.cc (function_info::place_phis): Filter
local defs by LR_OUT.

(cherry picked from commit c7151283dc747769d4ac4f216d8f519bda2569b5)

[Bug libstdc++/106852] Implement C++23 P2465R3 Standard Library Modules std and std.compat

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #4 from Boris Kolpackov  ---
FWIW, this project contains a subset of module interface files that
(reportedly) can be used to build a (probably incomplete) `std` module with
`libstdc++` using Clang (the README says it requires `libc++` but I've
confirmed with the author it is tested with both `libstdc++` and `libc++`):

https://github.com/alibaba/async_simple/tree/CXX20Modules/third_party_module/stdmodules

I am putting it out there in case someone is looking for a potential starting
point: maybe we could get going using Clang while GCC's modules support is
being worked into shape (and I am glad to see there was some progress on this
front for 14).

[Bug tree-optimization/60276] [4.7 Regression] -O3 autovectorizer breaks on a particular loop

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

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

--- Comment #16 from GCC Commits  ---
The master branch has been updated by Richard Biener :

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

commit r15-431-g8a9b159a86081053289be0c44339623ff59717a2
Author: Richard Biener 
Date:   Thu Nov 9 11:30:22 2023 +0100

PR60276 fix for single-lane SLP

When enabling single-lane SLP and not splitting groups the fix for
PR60276 is no longer effective since it for unknown reason exempted
pure SLP.  The following removes this exemption, making
gcc.dg/vect/pr60276.c PASS even with --param vect-single-lane-slp=1

PR tree-optimization/60276
* tree-vect-stmts.cc (vectorizable_load): Do not exempt
pure_slp grouped loads from the STMT_VINFO_MIN_NEG_DIST
restriction.

[Bug target/115058] on target arm -mcpu=cortex-a78ae does not allow use pauth and dot product

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

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

Richard Earnshaw  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2024-05-13

--- Comment #1 from Richard Earnshaw  ---
It looks like those messages are coming from the assembler, not the compiler,
but without a testcase it's difficult to be exactly sure what your problem is.

Please attach a small program that demonstrates your problem and state the 
/exact/ command line you used.

[Bug libstdc++/88545] std::find compile to memchr in trivial random access cases (patch)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #2 from Jonathan Wakely  ---
(In reply to Georg Sauthoff from comment #0)
> Created attachment 45259 [details]
> specialize std::find to memchr for character searches in continous memory
> 
> If std::find() is called with continuous random access iterators and a
> trivial char sized value, then calling memchr() is much more efficient than
> calling into the generic __find_if().
> 
> The attached patch implements this optimization.
> 
> That means it specializes a std::find helper on the iterator category and
> the value and calls __builtin_memchr() if possible.

Why specialize on the iterator category, when the __is_simple boolean already
checks if the iterator is a pointer?

The condition of a trivial byte-sized type seem insufficient, because you could
have:

struct B {
  char c;
  bool operator==(const B& b) const { return true; }
};



I would prefer to do simply:

--- a/libstdc++-v3/include/bits/stl_algo.h
+++ b/libstdc++-v3/include/bits/stl_algo.h
@@ -3846,6 +3846,32 @@ _GLIBCXX_BEGIN_NAMESPACE_ALGO
   __glibcxx_function_requires(_EqualOpConcept<
typename iterator_traits<_InputIterator>::value_type, _Tp>)
   __glibcxx_requires_valid_range(__first, __last);
+
+#if __cpp_if_constexpr
+  using _ValT = typename iterator_traits<_InputIterator>::value_type;
+  if constexpr (is_same_v<_ValT, _Tp>)
+   if constexpr (__is_byte<_ValT>::__value)
+#if __cpp_lib_concepts
+ if constexpr (contiguous_iterator<_InputIterator>)
+   {
+ if (const size_t __n = __last - __first)
+   {
+ auto __p0 = std::to_address(__first);
+ if (auto __p1 = __builtin_memchr(__p0, __val, __n))
+   return __first + (__p1 - __p0);
+   }
+ return __last;
+   }
+#else
+ if constexpr (is_pointer_v<_InputIterator>)
+   {
+ if (const size_t __n = __last - __first)
+   if (auto __p = __builtin_memchr(__first, __val, __n))
+ return __p;
+ return __last;
+   }
+#endif
+#endif
   return std::__find_if(__first, __last,
__gnu_cxx::__ops::__iter_equals_val(__val));
 }


I think we're going to remove the manual loop unrolling in __find_if for GCC
15, which should allow the compiler to optimize it better, potentially
auto-vectorizing. That might make memchr less advantageous, but I think it's
worth doing anyway.

[Bug target/115069] New: 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[colin.king at intel dot com via Gcc-bugs]

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

Bug ID: 115069
   Summary: 8 bit integer vector performance regression, x86,
between gcc-14 and gcc-13 using avx2 target clones on
skylake platform
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: colin.king at intel dot com
  Target Milestone: ---

Created attachment 58188
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58188&action=edit
reproducer source code

I'm seeing a ~12-14% performance regression in gcc-14 compared to gcc-13, using
gcc on Ubuntu 24.04:

Versions:
gcc version 13.2.0 (Ubuntu 13.2.0-23ubuntu4) 
gcc version 14.0.1 20240412 (experimental) [master r14-9935-g67e1433a94f]
(Ubuntu 14-20240412-0ubuntu1) 

cking@skylake:~$ gcc-13 reproducer-vecmath.c -O2
cking@skylake:~$ ./a.out 
13540.16 vec8 ops per sec, duration = 14.77 secs

cking@skylake:~$ gcc-14 reproducer-vecmath.c -O2
cking@skylake:~$ ./a.out 
11720.25 vec8 ops per sec, duration = 17.06 secs

The original issue appeared when regression testing stress-ng vecmath stressor
[1]. I've managed to extract the attached reproducer from the original code
(see attached).

Salient point to focus on:

1. The issue is also dependant on the TARGET_CLONES macro being defined as
__attribute__((target_clones("mmx,avx,avx2,default")))  - the avx2 target
clones seems to be an issue in reproducing this problem, remove it for gcc-14
and the performance regression is reduced.

Attached are the reproducer C source and disassembled object code. 

References: [1]
https://github.com/ColinIanKing/stress-ng/blob/master/stress-vecmath.c

[Bug target/115069] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[colin.king at intel dot com via Gcc-bugs]

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

--- Comment #1 from Colin Ian King  ---
Created attachment 58189
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58189&action=edit
gcc-13 disassembly

[Bug target/115069] 8 bit integer vector performance regression, x86, between gcc-14 and gcc-13 using avx2 target clones on skylake platform

[colin.king at intel dot com via Gcc-bugs]

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

--- Comment #2 from Colin Ian King  ---
Created attachment 58190
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58190&action=edit
gcc-14 disassembly

[Bug libstdc++/115040] Missed optimization opportunity in std::find of std::vector elements

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #4)
> Then this is partly a dup of bug 88545

Yes, that would manually transform the find_epi8 case into a memchr call, but
Clang doesn't need a manual transform in the library, it does it in the
compiler.

Tamar's plan to remove the manual loop unrolling in our std::find_if might help
here, but I'm not sure.

[Bug c++/114901] GCC internal_error on CTAD alias

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:6d31a370e26eeb950c326332633b3e8e84b6630b

commit r15-434-g6d31a370e26eeb950c326332633b3e8e84b6630b
Author: Patrick Palka 
Date:   Mon May 13 09:53:40 2024 -0400

c++: nested aggregate/alias CTAD fixes [PR114974, PR114901, PR114903]

During maybe_aggr_guide with a nested class template and paren init,
like with list init we need to consider the generic template type rather
than the partially instantiated type since partial instantiations don't
have (partially instantiated) TYPE_FIELDS.  In turn we need to partially
substitute PARMs in the paren init case as well.  As a drive-by improvement
it seems better to use outer_template_args instead of DECL_TI_ARGS during
this partial substitution so that we lower instead of substitute the
innermost template parameters, which is generally more robust.

And during alias_ctad_tweaks with a nested class template, even though
the guides may be already partially instantiated we still need to
substitute the outermost arguments into its constraints.

PR c++/114974
PR c++/114901
PR c++/114903

gcc/cp/ChangeLog:

* pt.cc (maybe_aggr_guide): Fix obtaining TYPE_FIELDS in
the paren init case.  Hoist out partial substitution logic
to apply to the paren init case as well.
(alias_ctad_tweaks): Substitute outer template arguments into
a guide's constraints.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-aggr14.C: New test.
* g++.dg/cpp2a/class-deduction-alias20.C: New test.
* g++.dg/cpp2a/class-deduction-alias21.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/114974] CTAD; templated inner class of template class seems to be handled incorrectly

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:6d31a370e26eeb950c326332633b3e8e84b6630b

commit r15-434-g6d31a370e26eeb950c326332633b3e8e84b6630b
Author: Patrick Palka 
Date:   Mon May 13 09:53:40 2024 -0400

c++: nested aggregate/alias CTAD fixes [PR114974, PR114901, PR114903]

During maybe_aggr_guide with a nested class template and paren init,
like with list init we need to consider the generic template type rather
than the partially instantiated type since partial instantiations don't
have (partially instantiated) TYPE_FIELDS.  In turn we need to partially
substitute PARMs in the paren init case as well.  As a drive-by improvement
it seems better to use outer_template_args instead of DECL_TI_ARGS during
this partial substitution so that we lower instead of substitute the
innermost template parameters, which is generally more robust.

And during alias_ctad_tweaks with a nested class template, even though
the guides may be already partially instantiated we still need to
substitute the outermost arguments into its constraints.

PR c++/114974
PR c++/114901
PR c++/114903

gcc/cp/ChangeLog:

* pt.cc (maybe_aggr_guide): Fix obtaining TYPE_FIELDS in
the paren init case.  Hoist out partial substitution logic
to apply to the paren init case as well.
(alias_ctad_tweaks): Substitute outer template arguments into
a guide's constraints.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-aggr14.C: New test.
* g++.dg/cpp2a/class-deduction-alias20.C: New test.
* g++.dg/cpp2a/class-deduction-alias21.C: New test.

Reviewed-by: Jason Merrill 

[Bug c++/114903] constraint of CTAD alias deduction guide is evaluated on a wrong type

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:6d31a370e26eeb950c326332633b3e8e84b6630b

commit r15-434-g6d31a370e26eeb950c326332633b3e8e84b6630b
Author: Patrick Palka 
Date:   Mon May 13 09:53:40 2024 -0400

c++: nested aggregate/alias CTAD fixes [PR114974, PR114901, PR114903]

During maybe_aggr_guide with a nested class template and paren init,
like with list init we need to consider the generic template type rather
than the partially instantiated type since partial instantiations don't
have (partially instantiated) TYPE_FIELDS.  In turn we need to partially
substitute PARMs in the paren init case as well.  As a drive-by improvement
it seems better to use outer_template_args instead of DECL_TI_ARGS during
this partial substitution so that we lower instead of substitute the
innermost template parameters, which is generally more robust.

And during alias_ctad_tweaks with a nested class template, even though
the guides may be already partially instantiated we still need to
substitute the outermost arguments into its constraints.

PR c++/114974
PR c++/114901
PR c++/114903

gcc/cp/ChangeLog:

* pt.cc (maybe_aggr_guide): Fix obtaining TYPE_FIELDS in
the paren init case.  Hoist out partial substitution logic
to apply to the paren init case as well.
(alias_ctad_tweaks): Substitute outer template arguments into
a guide's constraints.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-aggr14.C: New test.
* g++.dg/cpp2a/class-deduction-alias20.C: New test.
* g++.dg/cpp2a/class-deduction-alias21.C: New test.

Reviewed-by: Jason Merrill 

[Bug ipa/114985] [15 regression] internal compiler error: in discriminator_fail during stage2

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

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

--- Comment #19 from Martin Jambor  ---
The following minimized testcase ICEs with r15-312-g36e877996936ab
cross-compiler to ppc64le with -O2 nicely:


void omp_clause_elt_check(int *, const char *, const char *);
enum { C_OMP_CLAUSE_SPLIT_COUNT };
enum c_omp_region_type { C_ORT_OMP };
void c_finish_omp_clauses(int *, c_omp_region_type);
int *c_parser_omp_all_clauses_prev;
int *c_parser_omp_all_clauses(bool finish_p) {
  if (finish_p)
c_finish_omp_clauses(c_parser_omp_all_clauses_prev, C_ORT_OMP);
  return c_parser_omp_all_clauses_prev;
}
int c_parser_omp_teams___trans_tmp_104;
static void c_parser_omp_teams(int **cclauses) {
  c_parser_omp_all_clauses(cclauses);
  omp_clause_elt_check(&c_parser_omp_teams___trans_tmp_104, "", __FUNCTION__);
}
void c_parser_omp_target() {
  int *cclauses[C_OMP_CLAUSE_SPLIT_COUNT];
  c_parser_omp_teams(cclauses);
}

[Bug tree-optimization/113583] Main loop in 519.lbm not vectorized.

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

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

--- Comment #18 from Robin Dapp  ---
A bit of a follow-up:  I'm working on a patch for reassociation that can handle
the mentioned cases and some more but it will still require a bit of time to
get everything regression free and correct.  What it does is allow reassoc to
look through constant multiplications and negates to provide more freedom in
the optimization process.

Regarding the mentioned element-wise costing how should we proceed here?  I'm
going to remove the hunk in question, run SPEC2017 on x86 and post a patch in
order to get some data and basis for discussion.

[Bug libstdc++/88545] std::find compile to memchr in trivial random access cases (patch)

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> +  using _ValT = typename iterator_traits<_InputIterator>::value_type;
> +  if constexpr (is_same_v<_ValT, _Tp>)
> +   if constexpr (__is_byte<_ValT>::__value)

We can do better than this.

We can use memchr to find a char in a range of signed char, or even to find an
int in a range of signed char, as long as we're careful about values.

For example, given s = "abc"sv, std::find(s.begin(). s.end(), 'a'+0) should
find a match, but std::find(s.begin(), s.end(), 'a'+256) should not (even
though memchr would match in that case, because it does (unsigned
char)('a'+256)).

We should also ensure that std::ranges::find gets the same optimizations.

[Bug tree-optimization/109071] -Warray-bounds false positive warnings due to code duplication from jump threading

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

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

--- Comment #10 from qinzhao at gcc dot gnu.org ---
with the following added heuristic in array-bound checker:

+  /* If the stmt is duplicated and splitted, the warning level is not 2,
+ and the current block is not dominating the exit block, not report
+ the warning.  */
+  if (is_splitted && warn_array_bounds < 2
+  && !is_dominate_exit)
+return false;
+

such false positive warnings are moved from -Warray-bound=1 to -Warray-bound=2.
[opc@qinzhao-ol8u3-x86 109071]$ /home/opc/Install/latest-d/bin/gcc -O2
-Warray-bounds=2 -c -o t.o t.c
t.c: In function ‘sparx5_set’:
t.c:12:29: warning: array subscript 4 is above array bounds of ‘int[4]’
[-Warray-bounds=]
   12 | int *val = &sg->vals[index];
  | ^~~
t.c:8:18: note: while referencing ‘vals’
8 | struct nums {int vals[4];};
  |  ^~~~
[opc@qinzhao-ol8u3-x86 109071]$ /home/opc/Install/latest-d/bin/gcc -O2
-Warray-bounds=1 -c -o t.o t.c
[opc@qinzhao-ol8u3-x86 109071]$

[Bug fortran/115070] New: ICE using IEEE_ARITHMETIC in a derived type method with intent(out) statement

[bardeau at iram dot fr via Gcc-bugs]

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

Bug ID: 115070
   Summary: ICE using IEEE_ARITHMETIC in a derived type method
with intent(out) statement
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bardeau at iram dot fr
  Target Milestone: ---

Hi,

gfortran 14.0.1 raises an ICE in the following context:

~> uname -a
Linux bardeau-lap 6.8.8-300.fc40.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Apr 27
17:53:31 UTC 2024 x86_64 GNU/Linux

~> cat /etc/redhat-release 
Fedora release 40 (Forty)

~> gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/14/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,m2,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-libstdcxx-backtrace
--with-libstdcxx-zoneinfo=/usr/share/zoneinfo --with-linker-hash-style=gnu
--enable-plugin --enable-initfini-array
--with-isl=/builddir/build/BUILD/gcc-14.0.1-20240411/obj-x86_64-redhat-linux/isl-install
--enable-offload-targets=nvptx-none,amdgcn-amdhsa --enable-offload-defaulted
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
--with-build-config=bootstrap-lto --enable-link-serialization=1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240411 (Red Hat 14.0.1-0) (GCC)

~> cat bug-gfortran.f90
module my_mod
  type my_type
integer :: a
  end type my_type
contains
  subroutine my_sub(obs)
use ieee_arithmetic
class(my_type), intent(out) :: obs
  end subroutine my_sub
end module my_mod

~> gfortran -c bug-gfortran.f90 
bug-gfortran.f90:10:17:

   10 | end module my_mod
  | ^
internal compiler error: in gimplify_var_or_parm_decl, at gimplify.cc:3307
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

It seems that the combination of "use ieee_arithmetic" and the "intent(out)"
statement is important (for example using intent(inout) fixes the ICE). I let
you rephrase the summary to a better description.

[Bug target/115071] New: performance regression, x86, between gcc-14 and gcc-13 using -O3 and _Pragma("GCC unroll 4") on skylake

[colin.king at intel dot com via Gcc-bugs]

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

Bug ID: 115071
   Summary: performance regression, x86, between gcc-14 and gcc-13
using -O3 and _Pragma("GCC unroll 4") on skylake
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: colin.king at intel dot com
  Target Milestone: ---

Created attachment 58191
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58191&action=edit
reproducer source code

I'm seeing a ~15% performance regression in gcc-14 compared to gcc-13, using
gcc on Ubuntu 24.04:

Versions:
gcc version 13.2.0 (Ubuntu 13.2.0-23ubuntu4) 
gcc version 14.0.1 20240412 (experimental) [master r14-9935-g67e1433a94f]
(Ubuntu 14-20240412-0ubuntu1) 

cking@skylake:~$ gcc-13 reproducer-bitonicsort.c -O2
cking@skylake:~$ ./a.out 
duration: 5.71 seconds, count = 1119566602

cking@skylake:~$ gcc-14 reproducer-bitonicsort.c -O2
cking@skylake:~$ ./a.out 
duration: 6.56 seconds, count = 1119566602

The original issue appeared when regression testing stress-ng bitonic sorting
stressor [1]. I've managed to extract the attached reproducer from the original
code (see attached).

Salient point to focus on:

1. The issue is also dependant on the use of _Pragma("GCC unroll 4")
2. The issue is also dependant on the use of __attribute__((optimize("-O3")))
by use of the OPTIMIZE3 macro in the example.

Attached are the reproducer C source and disassembled object code. 

References:
[1] https://github.com/ColinIanKing/stress-ng/blob/master/stress-bitonicsort.c

[Bug target/115071] performance regression, x86, between gcc-14 and gcc-13 using -O3 and _Pragma("GCC unroll 4") on skylake

[colin.king at intel dot com via Gcc-bugs]

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

--- Comment #1 from Colin Ian King  ---
Created attachment 58192
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58192&action=edit
gcc-13 disassembly

[Bug target/115071] performance regression, x86, between gcc-14 and gcc-13 using -O3 and _Pragma("GCC unroll 4") on skylake

[colin.king at intel dot com via Gcc-bugs]

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

--- Comment #2 from Colin Ian King  ---
Created attachment 58193
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58193&action=edit
gcc-14 disassembly

[Bug fortran/115072] New: Memory link with unlimited polymorphic function result

[rnhmjoj at eurofusion dot eu via Gcc-bugs]

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

Bug ID: 115072
   Summary: Memory link with unlimited polymorphic function result
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rnhmjoj at eurofusion dot eu
  Target Milestone: ---

The following program works as expected, but the result of the id(x) function
does not appear to be ever deallocated creating a memory leak:

program test

  print *, transfer(id(7), 1)

contains

  pure function id(x) result(y)
class(*), intent(in)  :: x
class(*), allocatable :: y
y = x
  end function

end program test

Specifically, running the program in valgrind memcheck with --leak-check=full
reveals this:

4 bytes in 1 blocks are definitely lost in loss record 1 of 1
   at 0x484276B: malloc (in vgpreload_memcheck-amd64-linux.so)
   by 0x401338: id.1 (test.f90:10)
   by 0x401243: MAIN__ (test.f90:3)
   by 0x401432: main (test.f90:3)

Replacing the `class(*)` with some other type does not produce a leak.

[Bug analyzer/107750] [13/14/15 Regression] Many gcc.dg/analyzer/fd-*.c tests FAIL

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
I think I've found what's going on:  really has

#if !defined(_XPG4_2) || defined(__EXTENSIONS__)
#ifndef NC_TPI_CLTS
#define NC_TPI_CLTS 1   /* must agree with netconfig.h */
#define NC_TPI_COTS 2   /* must agree with netconfig.h */
[...]
#if !defined(_XPG4_2) || defined(__EXTENSIONS__)
#define SOCK_STREAM NC_TPI_COTS /* stream socket */
#define SOCK_DGRAM  NC_TPI_CLTS /* datagram socket */
[...]
#else
#define SOCK_STREAM 2   /* stream socket */
#define SOCK_DGRAM  1   /* datagram socket */

The problem seems to be the indirection: when SOCK_DGRAM etc. are
defined as numeric constants, things work, while the indirection via
NC_TPI_* does not.

[Bug target/114988] RISC-V: ICE in intrinsic __riscv_vfwsub_wf_f32mf2

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Pan Li :

https://gcc.gnu.org/g:41b3cf262e61aee9d26380f1c820e0eaae740f50

commit r15-435-g41b3cf262e61aee9d26380f1c820e0eaae740f50
Author: Pan Li 
Date:   Sat May 11 15:25:28 2024 +0800

RISC-V: Bugfix ICE for RVV intrinisc vfw on _Float16 scalar

For the vfw vx format RVV intrinsic, the scalar type _Float16 also
requires the zvfh extension.  Unfortunately,  we only check the
vector tree type and miss the scalar _Float16 type checking.  For
example:

vfloat32mf2_t test_vfwsub_wf_f32mf2(vfloat32mf2_t vs2, _Float16 rs1, size_t
vl)
{
  return __riscv_vfwsub_wf_f32mf2(vs2, rs1, vl);
}

It should report some error message like zvfh extension is required
instead of ICE for unreg insn.

This patch would like to make up such kind of validation for _Float16
in the RVV intrinsic API.  It will report some error like below when
there is no zvfh enabled.

error: built-in function '__riscv_vfwsub_wf_f32mf2(vs2,  rs1,  vl)'
  requires the zvfhmin or zvfh ISA extension

Passed the rv64gcv fully regression tests, included c/c++/fortran.

PR target/114988

gcc/ChangeLog:

* config/riscv/riscv-vector-builtins.cc
(validate_instance_type_required_extensions): New func impl to
validate the intrinisc func type ops.
(expand_builtin): Validate instance type before expand.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/pr114988-1.c: New test.
* gcc.target/riscv/rvv/base/pr114988-2.c: New test.

Signed-off-by: Pan Li 

[Bug tree-optimization/115073] New: RISC-V: Gimple fold not honor C[LT]Z_DEFINED_VALUE_AT_ZERO

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

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

Bug ID: 115073
   Summary: RISC-V: Gimple fold not honor
C[LT]Z_DEFINED_VALUE_AT_ZERO
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kito at gcc dot gnu.org
  Target Milestone: ---
Target: riscv64-unknown-linux-gnu

# What's up?

A loop induction variable initialized from __builtin_ctz (x), and the loop
bound is 32, and increment is one, and GCC turn it into infinite loops when x
is 0.

However RISC-V has defined CTZ_DEFINED_VALUE_AT_ZERO as 32 for SImode, so it's
not UB IMO, but seems like gimple-range-op.cc and match.pd are not handle that.

# Command to reproduce
```
$ riscv64-unknown-elf-gcc -O3 -march=rv64gc_zba_zbb_zbc
```

# Testcase
```c
void f();
void foo(unsigned int id, unsigned int x)
{
for (unsigned int idx = __builtin_ctz(x); idx < 32; idx++) {
f();
}
}
```

# Asm output with comment:

```
foo:
addisp,sp,-32
sd  s0,16(sp)
sd  s1,8(sp)
sd  ra,24(sp)
ctzws0,a1 # s0 is 32 if a1 is 0
li  s1,32
.L2:
addiw   s0,s0,1   # thne s0 become 33 here
callf
bne s0,s1,.L2 # compare with 32, which never terminate
ld  ra,24(sp)
ld  s0,16(sp)
ld  s1,8(sp)
addisp,sp,32
jr  ra
```


# What I tried?

I try to call CTZ_DEFINED_VALUE_AT_ZERO gimple-range-op.cc but it seems not
help for this test case, and then I found it was screw up at match.pd when ccp
pass.

It applied a CTZ simplifications at match.pd:

```
 (for op (eq ne)
  (simplify
   /* __builtin_ctz (x) == C -> (x & ((1 << (C + 1)) - 1)) == (1 << C).  */
   (op (ctz:s @0) INTEGER_CST@1)
(with { tree type0 = TREE_TYPE (@0); 
int prec = TYPE_PRECISION (type0);
  } 
 (if (prec <= MAX_FIXED_MODE_SIZE)
  (if (tree_int_cst_sgn (@1) < 0 || wi::to_widest (@1) >= prec) 
   { constant_boolean_node (op == EQ_EXPR ? false : true, type); }
   (op (bit_and @0 { wide_int_to_tree (type0,
   wi::mask (tree_to_uhwi (@1) + 1,
 false, prec)); })
   { wide_int_to_tree (type0,
   wi::shifted_mask (tree_to_uhwi (@1), 1,
 false, prec)); })))
```

Then I found it has checked with CTZ_DEFINED_VALUE_AT_ZERO
(g:75f8900159133ce069ef1d2edf3b67c7bc82e305) untill
g:7383cb56e1170789929201b0dadc156888928fdd, but I realized it because is not
really work well here CLZ_DEFINED_VALUE_AT_ZERO.

So I did some aggressive experiment here: convert __builtin_ctz to IFN_CTZ with
second operand (from C[LT]Z_DEFINED_VALUE_AT_ZERO, ideally), it can work *IF*
backend provide patterns for ctz, but NOT work when backend is not provided, it
could be a problem to RISC-V since ctz is not included in baseline ISA for
RISC-V.

It might be arguable if target didn't have ctz/clz pattern but
C[LT]Z_DEFINED_VALUE_AT_ZERO is provided to backend, so I think middle-end
optimization should still honor with that?

Or another thought is convert that into target macro to resolve the issue
describe in g:75f8900159133ce069ef1d2edf3b67c7bc82e305?


# Aggressive experiment:
```
diff --git a/gcc/c-family/c-gimplify.cc b/gcc/c-family/c-gimplify.cc
index 494da49791d..d84469a6dca 100644
--- a/gcc/c-family/c-gimplify.cc
+++ b/gcc/c-family/c-gimplify.cc
@@ -858,7 +858,16 @@ c_gimplify_expr (tree *expr_p, gimple_seq *pre_p
ATTRIBUTE_UNUSED,
  c, CALL_EXPR_ARG (*expr_p, 1));
return GS_OK;
  }
-   break;
+  if (fndecl && fndecl_built_in_p(fndecl, BUILT_IN_CTZ) &&
+  call_expr_nargs(*expr_p) == 1) {
+tree a = save_expr(CALL_EXPR_ARG(*expr_p, 0));
+*expr_p = build_call_expr_internal_loc(
+EXPR_LOCATION(*expr_p), IFN_CTZ, TREE_TYPE(a), 2, a,
+build_int_cst(TREE_TYPE(a), 32));
+return GS_OK;
+  }
+
+break;
   }

 default:;
```

[Bug tree-optimization/115073] RISC-V: Gimple fold not honor C[LT]Z_DEFINED_VALUE_AT_ZERO

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
That is misunderstanding of what C[LT]Z_DEFINED_VALUE_AT_ZERO is.
The builtin has always UB on zero.
If you want to define it for zero, use x ? __builtin_clz (x) : 32 (and the
like) or
__builtin_clzg (x, 32) in the source.
C[LT]Z_DEFINED_VALUE_AT_ZERO returning 2 then makes sure the compiler can fold
those conditionals or builtins into .CLZ internal calls with 2 arguments which
makes it well defined for all inputs.

[Bug tree-optimization/115073] RISC-V: Gimple fold not honor C[LT]Z_DEFINED_VALUE_AT_ZERO

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Invalid as explained.  The builtin has undefined behavior no matter what the
backend says is the value at 0.

[Bug rtl-optimization/115013] [15 Regression] LRA: PR114810 fix result in ICE in the RISC-V Vector

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Vladimir Makarov :

https://gcc.gnu.org/g:44e7855e4e817a7f5a1e332cd95e780e57052dba

commit r15-436-g44e7855e4e817a7f5a1e332cd95e780e57052dba
Author: Vladimir N. Makarov 
Date:   Mon May 13 10:12:11 2024 -0400

[PR115013][LRA]: Modify register starvation recognition

  My recent patch to recognize reg starvation resulted in few GCC test
failures.  The following patch fixes this by using more accurate
starvation calculation and ignoring small reg classes.

gcc/ChangeLog:

PR rtl-optimization/115013
* lra-constraints.cc (process_alt_operands): Update all_used_nregs
only for winreg.  Ignore reg starvation for small reg classes.

[Bug tree-optimization/115073] RISC-V: Gimple fold not honor C[LT]Z_DEFINED_VALUE_AT_ZERO

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

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

--- Comment #3 from Jakub Jelinek  ---
Or another option is to use C23 , that is well defined for all
values.
But you need recent glibc (2.39 snapshots or 2.40) & gcc (14) for that.

[Bug tree-optimization/115073] RISC-V: Gimple fold not honor C[LT]Z_DEFINED_VALUE_AT_ZERO

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

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

--- Comment #4 from Andrew Pinski  ---
Note -fsanitize=undefined does detect this undefinedness at runtime already
too.

[Bug c++/114974] CTAD; templated inner class of template class seems to be handled incorrectly

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:57cd8665fea4c339369a43be017583621aa82fed

commit r14-10201-g57cd8665fea4c339369a43be017583621aa82fed
Author: Patrick Palka 
Date:   Mon May 13 09:53:40 2024 -0400

c++: nested aggregate/alias CTAD fixes [PR114974, PR114901, PR114903]

During maybe_aggr_guide with a nested class template and paren init,
like with list init we need to consider the generic template type rather
than the partially instantiated type since partial instantiations don't
have (partially instantiated) TYPE_FIELDS.  In turn we need to partially
substitute PARMs in the paren init case as well.  As a drive-by improvement
it seems better to use outer_template_args instead of DECL_TI_ARGS during
this partial substitution so that we lower instead of substitute the
innermost template parameters, which is generally more robust.

And during alias_ctad_tweaks with a nested class template, even though
the guides may be already partially instantiated we still need to
substitute the outermost arguments into its constraints.

PR c++/114974
PR c++/114901
PR c++/114903

gcc/cp/ChangeLog:

* pt.cc (maybe_aggr_guide): Fix obtaining TYPE_FIELDS in
the paren init case.  Hoist out partial substitution logic
to apply to the paren init case as well.
(alias_ctad_tweaks): Substitute outer template arguments into
a guide's constraints.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-aggr14.C: New test.
* g++.dg/cpp2a/class-deduction-alias20.C: New test.
* g++.dg/cpp2a/class-deduction-alias21.C: New test.

Reviewed-by: Jason Merrill 
(cherry picked from commit 6d31a370e26eeb950c326332633b3e8e84b6630b)

[Bug c++/114901] GCC internal_error on CTAD alias

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

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

--- Comment #6 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:57cd8665fea4c339369a43be017583621aa82fed

commit r14-10201-g57cd8665fea4c339369a43be017583621aa82fed
Author: Patrick Palka 
Date:   Mon May 13 09:53:40 2024 -0400

c++: nested aggregate/alias CTAD fixes [PR114974, PR114901, PR114903]

During maybe_aggr_guide with a nested class template and paren init,
like with list init we need to consider the generic template type rather
than the partially instantiated type since partial instantiations don't
have (partially instantiated) TYPE_FIELDS.  In turn we need to partially
substitute PARMs in the paren init case as well.  As a drive-by improvement
it seems better to use outer_template_args instead of DECL_TI_ARGS during
this partial substitution so that we lower instead of substitute the
innermost template parameters, which is generally more robust.

And during alias_ctad_tweaks with a nested class template, even though
the guides may be already partially instantiated we still need to
substitute the outermost arguments into its constraints.

PR c++/114974
PR c++/114901
PR c++/114903

gcc/cp/ChangeLog:

* pt.cc (maybe_aggr_guide): Fix obtaining TYPE_FIELDS in
the paren init case.  Hoist out partial substitution logic
to apply to the paren init case as well.
(alias_ctad_tweaks): Substitute outer template arguments into
a guide's constraints.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-aggr14.C: New test.
* g++.dg/cpp2a/class-deduction-alias20.C: New test.
* g++.dg/cpp2a/class-deduction-alias21.C: New test.

Reviewed-by: Jason Merrill 
(cherry picked from commit 6d31a370e26eeb950c326332633b3e8e84b6630b)

[Bug c++/114903] constraint of CTAD alias deduction guide is evaluated on a wrong type

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

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

--- Comment #2 from GCC Commits  ---
The releases/gcc-14 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:57cd8665fea4c339369a43be017583621aa82fed

commit r14-10201-g57cd8665fea4c339369a43be017583621aa82fed
Author: Patrick Palka 
Date:   Mon May 13 09:53:40 2024 -0400

c++: nested aggregate/alias CTAD fixes [PR114974, PR114901, PR114903]

During maybe_aggr_guide with a nested class template and paren init,
like with list init we need to consider the generic template type rather
than the partially instantiated type since partial instantiations don't
have (partially instantiated) TYPE_FIELDS.  In turn we need to partially
substitute PARMs in the paren init case as well.  As a drive-by improvement
it seems better to use outer_template_args instead of DECL_TI_ARGS during
this partial substitution so that we lower instead of substitute the
innermost template parameters, which is generally more robust.

And during alias_ctad_tweaks with a nested class template, even though
the guides may be already partially instantiated we still need to
substitute the outermost arguments into its constraints.

PR c++/114974
PR c++/114901
PR c++/114903

gcc/cp/ChangeLog:

* pt.cc (maybe_aggr_guide): Fix obtaining TYPE_FIELDS in
the paren init case.  Hoist out partial substitution logic
to apply to the paren init case as well.
(alias_ctad_tweaks): Substitute outer template arguments into
a guide's constraints.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/class-deduction-aggr14.C: New test.
* g++.dg/cpp2a/class-deduction-alias20.C: New test.
* g++.dg/cpp2a/class-deduction-alias21.C: New test.

Reviewed-by: Jason Merrill 
(cherry picked from commit 6d31a370e26eeb950c326332633b3e8e84b6630b)

[Bug c++/114974] CTAD; templated inner class of template class seems to be handled incorrectly

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |14.2
 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 CC||ppalka at gcc dot gnu.org

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 14.2, thanks for the reports.

[Bug c++/114901] GCC internal_error on CTAD alias

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |14.2
 CC||ppalka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #7 from Patrick Palka  ---
Fixed for GCC 14.2

[Bug c++/114903] constraint of CTAD alias deduction guide is evaluated on a wrong type

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |14.2
 CC||ppalka at gcc dot gnu.org

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 14.2

[Bug c++/112658] [12/13 Regression] ICE: finish_expr_stmt with casting an temp array to pointer and constructor call

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|12.4|14.0
 Status|ASSIGNED|RESOLVED

--- Comment #9 from Patrick Palka  ---
Not backporting any of these fixes since this never properly worked -- it was
either wrong-code, rejects-valid or (most recently) ice-on-valid -- and so not
really a regression.

[Bug c++/113332] [12/13 regression] checking ICE when building fcitx-5.1.6

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|12.4|14.0

--- Comment #6 from Patrick Palka  ---
It doesn't seem worth backporitng this relatively risky patch just to fix a
checking-only assertion failure that we otherwise gracefully handle.