[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value

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

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

--- Comment #18 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #17)
> (In reply to Steve Kargl from comment #16)
> > First, note, 'allocated(f())' throws an error.
> 
> Agree.
> 
> > Now, with the original code,
> > 
> >   is_allocated(f())
> > 
> > The function reference is evaluated, and then the function result
> > (aka it's value) is argument associated with an allocatable dummy
> > argument.  This is technically wrong as the actual argument (aka
> > value returned by the function reference) should not have the
> > allocatable attribute.
> 
> Agree.  See also the discussion on the J3 mailing list.
> 
> > I'll repeat.  The actual argument is the value resulting from
> > the function reference.  The "shall" in "shall be allocatable"
> > applies to something the programmer must ensure.
> 
> Agree.
> 
> > If we go back to the original code and modify to allocate
> > f by say doing 'f = 42' in f(), gfortran produces 
> > 
> > % gfcx -o z -Wall a.f90 && ./z
> >  T
> > 
> > This is the problem.  Yes, f is allocated and assigned 
> > 42.  The printed 'T' is bogus because 42 is value of
> > the function.  42 is no allocatable.
> 
> Agree again.
> 
> The point is that there is a bug in gfortran which currently effectively
> generates code which resembles
> 
>   integer, allocatable :: p
>   p = f()
>   print *, is_allocated(p)
>   deallocate (p)
> 
> (of course with a temporary for the function result).
> The technical reason for the crash is the copying of the function
> (non)result.
> 
> The patch in comment#9 rejects all related misuses.
> 
> Given the lengthy thread on the J3 mailing list, I am wondering whether there
> ever was an explicit IR on the issue, or was it considered so obvious that
> the clarification was deferred to the F2018 document.
> 
> 
> 
> > One place to possibly check for an error is when 
> > gfortran resolves argument association.  If a dummy
> > argument is allocatable, the actual argument needs 
> > to be allocatable and cannot not also be a function
> > result variable.

I think we agree on all points.  Here's the diff I envision.
NOte, I've restricted it to user defined functions.  Remove 
the esym check will enable it for any subprogram.


diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index db79b104dc2..f3bcdd76d6a 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -3622,6 +3622,18 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap,
gfc_formal_arglist *formal,
  goto match;
}

+  if (a->expr->expr_type == EXPR_FUNCTION
+ && a->expr->value.function.esym
+ && f->sym->attr.allocatable)
+   {
+ if (where)
+   gfc_error ("Actual argument for %qs at %L is a function result "
+   "and the dummy argument is ALLOCATABLE",
+   f->sym->name, >expr->where);
+ ok = false;
+ goto match;
+   }
+
   /* Check intent = OUT/INOUT for definable actual argument.  */
   if (!in_statement_function
  && (f->sym->attr.intent == INTENT_OUT

This gives

% gfcx -c a.f90
a.f90:5:25:

5 |print *, is_allocated(f())
  | 1
Error: Actual argument for 'p' at (1) is a function result and the dummy
argument is ALLOCATABLE

[Bug tree-optimization/109563] accessing 9223372036854775810 or more bytes at offsets [2, 9223372036854775807] and 1 may overlap up to 9223372036854775813 bytes at offset -3 [-Wrestrict]

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

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

--- Comment #2 from Frank Heckenbach  ---
Since I can't easily upgrade to trunk, I need to know if the warning is bogus
in 12.2 and I can safely disable it, or do I need to worry about the generated
code?

[Bug tree-optimization/105651] [12 Regression] bogus "may overlap" memcpy warning with std::string and operator+ at -O3

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/84774] [meta-bug] bogus/missing -Wrestrict

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

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

Bug 109563 Summary: accessing 9223372036854775810 or more bytes at offsets [2, 
9223372036854775807] and 1 may overlap up to 9223372036854775813 bytes at 
offset -3 [-Wrestrict]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109563

   What|Removed |Added

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

[Bug tree-optimization/109563] accessing 9223372036854775810 or more bytes at offsets [2, 9223372036854775807] and 1 may overlap up to 9223372036854775813 bytes at offset -3 [-Wrestrict]

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c++/109563] New: accessing 9223372036854775810 or more bytes at offsets [2, 9223372036854775807] and 1 may overlap up to 9223372036854775813 bytes at offset -3 [-Wrestrict]

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

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

Bug ID: 109563
   Summary: accessing 9223372036854775810 or more bytes at offsets
[2, 9223372036854775807] and 1 may overlap up to
9223372036854775813 bytes at offset -3 [-Wrestrict]
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: f.heckenb...@fh-soft.de
  Target Milestone: ---

I'd like to know if the warning is bogus or the library actually accesses
invalid memory.

% cat test.cpp
#include 

void f (const std::string )
{
  "x" + std::string (s);
}
% g++ --std=c++20 -O3 -Wall -c test.cpp
In file included from /usr/include/c++/12/string:40,
 from test.cpp:1:
In static member function ‘static constexpr std::char_traits::char_type*
std::char_traits::copy(char_type*, const char_type*, std::size_t)’,
inlined from ‘static constexpr void std::__cxx11::basic_string<_CharT,
_Traits, _Alloc>::_S_copy(_CharT*, const _CharT*, size_type) [with _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator]’ at
/usr/include/c++/12/bits/basic_string.h:423:21,
inlined from ‘constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Allocator>& std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_replace(size_type, size_type, const _CharT*, size_type) [with
_CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’ at /usr/include/c++/12/bits/basic_string.tcc:532:22,
inlined from ‘constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>& std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::replace(size_type, size_type, const _CharT*, size_type) [with _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator]’ at
/usr/include/c++/12/bits/basic_string.h:2171:19,
inlined from ‘constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::insert(size_type,
const _CharT*) [with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’ at /usr/include/c++/12/bits/basic_string.h:1928:22,
inlined from ‘constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Allocator> std::operator+(const _CharT*, __cxx11::basic_string<_CharT,
_Traits, _Allocator>&&) [with _CharT = char; _Traits = char_traits;
_Alloc = allocator]’ at /usr/include/c++/12/bits/basic_string.h:3541:36,
inlined from ‘void f(const std::string&)’ at test.cpp:5:7:
/usr/include/c++/12/bits/char_traits.h:431:56: warning: ‘void*
__builtin_memcpy(void*, const void*, long unsigned int)’ accessing
9223372036854775810 or more bytes at offsets [2, 9223372036854775807] and 1 may
overlap up to 9223372036854775813 bytes at offset -3 [-Wrestrict]
  431 | return static_cast(__builtin_memcpy(__s1, __s2,
__n));
  |

[Bug testsuite/106879] [13/14 regression] new test case gcc.dg/vect/bb-slp-layout-19.c fails

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jiu Fu Guo :

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

commit r14-105-g57e7229a29ca0e9929b61051e4f5857f0b41b6c7
Author: Jiufu Guo 
Date:   Tue Apr 18 15:56:53 2023 +0800

PR testsuite/106879 FAIL: gcc.dg/vect/bb-slp-layout-19.c on powerpc64

On P7, option -mno-allow-movmisalign is added during testing, which
prevents slp happen on the case.

Like PR65484 and PR87306, this patch use vect_hw_misalign to guard
the case on powerpc targets.

gcc/testsuite/ChangeLog:

PR testsuite/106879
* gcc.dg/vect/bb-slp-layout-19.c: Modify to guard the check with
vect_hw_misalign on POWERs.

[Bug target/109562] Failed to build native GCC 12.2.0 on RISC-V64 linux machine

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

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

--- Comment #1 from Andrew Pinski  ---
>/usr/include/stdio.h:189:24: error: expected ‘,’ or ‘;’ before ‘__attr_dealloc’
Hmm, --disable-multilib is not working 

[Bug target/109562] New: Failed to build native GCC 12.2.0 on RISC-V64 linux machine

[winterjasmine1 at hotmail dot com via Gcc-bugs]

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

Bug ID: 109562
   Summary: Failed to build native GCC 12.2.0 on RISC-V64 linux
machine
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: winterjasmine1 at hotmail dot com
  Target Milestone: ---

Created attachment 54885
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54885=edit
error log when building GCC 12.2.0 natively on RISC-V linux machine

Failed to build native GCC 12.2.0 on RISC-V64 linux machine.

Steps:
```
$sudo apt-get install autoconf automake autotools-dev curl python3 libmpc-dev
libmpfr-dev libgmp-dev gawk build-essential bison flex texinfo gperf libtool
patchutils bc zlib1g-dev libexpat-dev
$ cd gcc-12.2.0
$ contrib/download_prerequisites
$ mkdir build && cd build
$ ../configure --enable-languages=c,c++,fortran --prefix=$HOME/opt/gcc-12.2.0
--disable-multilib
$ make -j4
```
error info:
```
/usr/include/stdio.h:592:14: error: old-style parameter declarations in
prototyped function definition
  592 | extern char *fgets (char *__restrict __s, int __n, FILE *__restrict
__stream)
  |  ^
../../../libgcc/libgcc2.c:2457: error: expected ‘{’ at end of input
../../../libgcc/libgcc2.c:2457: warning: control reaches end of non-void
function [-Wreturn-type]
make[3]: *** [Makefile:501: _ashrdi3.o] Error 1
```

The full error log is attached.

[Bug c++/109561] New: -Wmaybe-uninitialized false positive false positive false positive false positive false positive

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

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

Bug ID: 109561
   Summary: -Wmaybe-uninitialized false positive false positive
false positive false positive false positive
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: f.heckenb...@fh-soft.de
  Target Milestone: ---

(code and error below)

I don't know how to put this nicely, this is a terrible message:

- Most of it consists of standard library internals.

- The actual message ("may be used uninitialized") is buried well within it and
also refers to internal fields.

- It is reported no less than 5 times!?

- Most of all, AFAICS, it's bogus. The default constructor of std::optional
should construct an object that does not contain a value and such objects can
be copied just fine.

- Like many such bogus warnings apparently, it's rather volatile. Unrelated
changes, e.g. to i or removing the defaulted constructor declaration, can make
it disappear. Producing this minimal example was a lot of guesswork what can be
removed in which order without disturbing the message.

- It's a regression from 10.2.1 and 11.3.

% cat test.cpp
#include 
#include 
#include 

struct O
{
  std::optional  i;
  std::optional  s;
  O () = default;
};

std::vector  a;

void f ()
{
  for (auto : a)
i = { };
}
% g++ --std=c++20 -O2 -Wall -c test.cpp
In file included from /usr/include/c++/12/string:53,
 from test.cpp:3:
In member function ‘constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::pointer std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::_M_data()
const [with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’,
inlined from ‘constexpr bool std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_is_local() const [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]’ at
/usr/include/c++/12/bits/basic_string.h:274:23,
inlined from ‘constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>& std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::operator=(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&) [with
_CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’ at /usr/include/c++/12/bits/basic_string.h:859:23,
inlined from ‘constexpr void
std::_Optional_payload_base<_Tp>::_M_move_assign(std::_Optional_payload_base<_Tp>&&)
[with _Tp = std::__cxx11::basic_string]’ at
/usr/include/c++/12/optional:194:19,
inlined from ‘constexpr std::_Optional_payload<_Tp, true, false, false>&
std::_Optional_payload<_Tp, true, false,
false>::operator=(std::_Optional_payload<_Tp, true, false, false>&&) [with _Tp
= std::__cxx11::basic_string]’ at /usr/include/c++/12/optional:420:22,
inlined from ‘constexpr std::_Optional_payload<_Tp, false, _Copy, _Move>&
std::_Optional_payload<_Tp, false, _Copy,
_Move>::operator=(std::_Optional_payload<_Tp, false, _Copy, _Move>&&) [with _Tp
= std::__cxx11::basic_string; bool _Copy = false; bool _Move = false]’ at
/usr/include/c++/12/optional:436:26,
inlined from ‘constexpr std::_Optional_base<_Tp, , 
>& std::_Optional_base<_Tp, , 
>::operator=(std::_Optional_base<_Tp, ,  >&&) [with _Tp =
std::__cxx11::basic_string; bool  = false; bool  =
false]’ at /usr/include/c++/12/optional:550:23,
inlined from ‘constexpr std::optional >&
std::optional
>::operator=(std::optional >&&)’ at
/usr/include/c++/12/optional:705:11,
inlined from ‘constexpr O& O::operator=(O&&)’ at test.cpp:5:8,
inlined from ‘void f()’ at test.cpp:17:11:
/usr/include/c++/12/bits/basic_string.h:234:28: warning: ‘*(const
std::__cxx11::basic_string, std::allocator
>*)((char*)& + offsetof(O,
O::s.std::optional,
std::allocator >
>::.std::_Optional_base, std::allocator >, false,
false>::)).std::__cxx11::basic_string::_M_dataplus.std::__cxx11::basic_string::_Alloc_hider::_M_p’
may be used uninitialized [-Wmaybe-uninitialized]
  234 |   { return _M_dataplus._M_p; }
  |^~~~
test.cpp: In function ‘void f()’:
test.cpp:17:11: note: ‘’ declared here
   17 | i = { };
  |   ^
In member function ‘constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::size_type std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::size()
const [with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’,
inlined from ‘constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>& std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::operator=(std::__cxx11::basic_string<_CharT, _Traits, _Alloc>&&) [with
_CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’ at /usr/include/c++/12/bits/basic_string.h:866:17,
inlined from ‘constexpr void
std::_Optional_payload_base<_Tp>::_M_move_assign(std::_Optional_payload_base<_Tp>&&)
[with _Tp = std::__cxx11::basic_string]’ at
/usr/include/c++/12/optional:194:19,
  

[Bug c++/108993] Value initialization does not occur for derived class , for gcc versions > 5

[panigstein at hotmail dot com via Gcc-bugs]

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

panigstein at hotmail dot com changed:

   What|Removed |Added

 CC||panigstein at hotmail dot com

--- Comment #2 from panigstein at hotmail dot com ---
(In reply to Andrew Pinski from comment #1)
> Hmm,
>  I noticed that since GCC 7 with -std=c++17, the b.x is not initialized at
> all. So the question I have is there a difference between C++ standards here?
> 
> Note the issue is we call Base's constructor after doing the zero
> initialization and the Base's constructor has a clobber in it which I think
> is correct.
> 
> This is all front-end generation and not exactly related to the
> optimizations directly.

There is no difference between C++ standards in this respect. For a class that
has a defaulted default constructor (Derived), value-initialization consists of
zero-initialization followed by default-initialization. The clobbering of the
Base sub-object is incorrect here and makes the implementation of
value-initialization non-conforming.

[Bug testsuite/109560] new test case g++.dg/ext/int128-8.C from r14-88-ged32ec26697cc7 fails

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|other   |testsuite

--- Comment #1 from Andrew Pinski  ---
The testcase I think just needs:
/* { dg-require-effective-target int128 } */

[Bug other/109560] New: new test case g++.dg/ext/int128-8.C from r14-88-ged32ec26697cc7 fails

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

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

Bug ID: 109560
   Summary: new test case g++.dg/ext/int128-8.C from
r14-88-ged32ec26697cc7 fails
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:ed32ec26697cc77492d094b31a0d2eebc0535644, r14-88-ged32ec26697cc7

This fails for 32 bits on powerpc64 BE.

For 64 bit I get:

make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m64}'
dg.exp=g++.dg/ext/int128-8.C"
# of expected passes3
# of unsupported tests  1

For 32 bit I get:

make  -k check-gcc RUNTESTFLAGS="--target_board=unix'{-m32}'
dg.exp=g++.dg/ext/int128-8.C"
FAIL: g++.dg/ext/int128-8.C  -std=gnu++14 (test for excess errors)
FAIL: g++.dg/ext/int128-8.C  -std=gnu++17 (test for excess errors)
FAIL: g++.dg/ext/int128-8.C  -std=gnu++20 (test for excess errors)
# of unexpected failures3
# of unsupported tests  1


Excess errors:
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:5:22: error:
expected ';' before '__int128_t'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:6:20: error:
expected ';' before '__int128_t'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:16:39: error:
wrong number of template arguments (1, should be 2)
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:17:46: error:
wrong number of template arguments (1, should be 2)
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:18:25: error:
'__int128_t' was not declared in this scope; did you mean '__int128__'?
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:18:37: error:
's128' was not declared in this scope
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:18:41: error:
template argument 1 is invalid
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:18:41: error:
template argument 2 is invalid
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:21:24: error:
's128' was not declared in this scope
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:21:41: error:
expected primary-expression before '__int128'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:21:41: error:
expected ')' before '__int128'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:21:55: error:
expected ',' before ';' token
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:21:55: error:
expected string-literal before ';' token
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:21:55: error:
expected ')' before ';' token
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:22:24: error:
'u128' was not declared in this scope
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:22:41: error:
expected primary-expression before 'unsigned'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:22:41: error:
expected ')' before 'unsigned'
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:22:64: error:
expected ',' before ';' token
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:22:64: error:
expected string-literal before ';' token
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:22:64: error:
expected ')' before ';' token
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:23:16: error:
's128' was not declared in this scope
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/ext/int128-8.C:24:16: error:
'u128' was not declared in this scope



commit ed32ec26697cc77492d094b31a0d2eebc0535644 (HEAD)
Author: Jason Merrill 
Date:   Tue Apr 18 17:12:17 2023 -0400

c++: fix 'unsigned __int128_t' semantics [PR108099]

[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value

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

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

--- Comment #17 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #16)
> First, note, 'allocated(f())' throws an error.

Agree.

> Now, with the original code,
> 
>   is_allocated(f())
> 
> The function reference is evaluated, and then the function result
> (aka it's value) is argument associated with an allocatable dummy
> argument.  This is technically wrong as the actual argument (aka
> value returned by the function reference) should not have the
> allocatable attribute.

Agree.  See also the discussion on the J3 mailing list.

> I'll repeat.  The actual argument is the value resulting from
> the function reference.  The "shall" in "shall be allocatable"
> applies to something the programmer must ensure.

Agree.

> If we go back to the original code and modify to allocate
> f by say doing 'f = 42' in f(), gfortran produces 
> 
> % gfcx -o z -Wall a.f90 && ./z
>  T
> 
> This is the problem.  Yes, f is allocated and assigned 
> 42.  The printed 'T' is bogus because 42 is value of
> the function.  42 is no allocatable.

Agree again.

The point is that there is a bug in gfortran which currently effectively
generates code which resembles

  integer, allocatable :: p
  p = f()
  print *, is_allocated(p)
  deallocate (p)

(of course with a temporary for the function result).
The technical reason for the crash is the copying of the function (non)result.

The patch in comment#9 rejects all related misuses.

Given the lengthy thread on the J3 mailing list, I am wondering whether there
ever was an explicit IR on the issue, or was it considered so obvious that
the clarification was deferred to the F2018 document.



> One place to possibly check for an error is when 
> gfortran resolves argument association.  If a dummy
> argument is allocatable, the actual argument needs 
> to be allocatable and cannot not also be a function
> result variable.

[Bug middle-end/109559] [12/13/14 Regression] Unexpected -Wmaybe-uninitialized warning when inlining with system header

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

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

--- Comment #2 from Marek Polacek  ---
Originally this happened when including boost headers, function_template.hpp in
particular, where newer versions suppress a lot of warnings:

commit b75386f628b46f1060a20b6e015931bac37b7da7 (origin/feature/drone)
Author: Peter Dimov 
Date:   Sun Feb 12 04:50:04 2023 +0200

Avoid -Wuninitialized under GCC 11.3

commit 9229ed30103df59a4f989ca0235b0d1026bf6e1c
Author: Peter Dimov 
Date:   Sun Feb 12 04:47:38 2023 +0200

Avoid another -Wmaybe-uninitialized under GCC 11/12

commit 16fca8368b5da14c4bcad977c2738dc6e482e1b7 (tag: boost-1.81.0.beta1, tag:
boost-1.81.0, tag: boost-1.80.0.beta1, tag: boost-1.80.0,
origin/feature/issue-42)
Author: Peter Dimov 
Date:   Mon May 30 20:25:13 2022 +0300

Keep -Wmaybe-uninitialized disabled

commit 4cf7c718b873223cbab6f8188bea2034f27ba99d
Merge: 389f886 5b4e279
Author: Peter Dimov 
Date:   Mon May 30 19:56:08 2022 +0300

Merge branch 'gcc12-Wuninitialized' of
https://github.com/jngrad/boost-function into feature/issue-42

commit abc1bf9b4ae3f45251d17b451c69c3e79dfd0cf6 (origin/feature/update-ci)
Author: Peter Dimov 
Date:   Mon May 30 18:44:07 2022 +0300

Extend GCC 11 workaround to GCC 12 as well

commit 5b4e2797a28f9477d2df5fa915409dac73ff00c6
Author: Jean-Noël Grad 
Date:   Mon May 30 16:16:41 2022 +0200

Avoid -Wuninitialized warnings in GCC 12

commit 277757befc321bda3b9d8038ee59ae6e4616cdca
Author: Peter Dimov 
Date:   Thu Dec 16 06:18:06 2021 +0200

Disable -Wmaybe-uninitialized in function_template.hpp for GCC 11

commit 7c90434317894f1a0c63c7a395ddf569eff1d308
Author: Romain Geissler 
Date:   Fri Mar 27 18:56:14 2020 +

Avoid -Wmaybe-uninitialized warnings in gcc (issue #27).

[Bug middle-end/109559] [12/13/14 Regression] Unexpected -Wmaybe-uninitialized warning when inlining with system header

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|Unexpected  |[12/13/14 Regression]
   |-Wmaybe-uninitialized   |Unexpected
   |warning when inlining with  |-Wmaybe-uninitialized
   |system header   |warning when inlining with
   ||system header
   Keywords||diagnostic
   Target Milestone|--- |12.3

--- Comment #1 from Marek Polacek  ---
Started with r12-1992.  

We have an inlining context containing locations for each call site along
the inlining stack: struct inlining_info.  It has a stack of locations,
and a flag that says whether all of them come from a system header.  If so,
we don't warn:

1548   if (!report_warning_p && diagnostic->m_iinfo.m_allsyslocs)
1549 /* Bail if the warning is not to be reported because all locations
1550in the inlining stack (if there is one) are in system headers.  */
1551 return false;

but in this test diagnostic->m_iinfo.m_allsyslocs is false because the inlining
causes that the outermost context is the un.cc file, which is not a system
header.

It looks like this is a failure to propagate the sysp flag when inlining a
function.

[Bug middle-end/109559] New: Unexpected -Wmaybe-uninitialized warning when inlining with system header

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

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

Bug ID: 109559
   Summary: Unexpected -Wmaybe-uninitialized warning when inlining
with system header
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

The following testcase (the directives simulate a system header) triggers a
-Wmaybe-uninitialized warning:

$ xg++ -c un.cc -Wall -O2
In member function ‘int function1::swap(function1)’,
inlined from ‘int function::operator=(Functor) [with Functor =
FilonIntegral::integrate() const::]’ at :8:56,
inlined from ‘double FilonIntegral::integrate() const’ at :9:6:
:5:49: warning: ‘f1’ may be used uninitialized [-Wmaybe-uninitialized]
: In member function ‘double FilonIntegral::integrate() const’:
:1:3: note: by argument 1 of type ‘const function_base*’ to ‘int
function_base::has_trivial_copy_and_destroy() const’ declared here
:8:12: note: ‘f1’ declared here

$ xg++ -c un.cc -Wall -O2 -fno-inline
# nothing

# 0 "" 3
struct function_base {
  has_trivial_copy_and_destroy() const;
  int functor;
};
struct function1 : function_base {
  swap(function1) { has_trivial_copy_and_destroy(); }
};
struct function : function1 {
  template  operator=(Functor) { swap(*this); }
};
# 4 ""
struct FilonIntegral {
  double integrate() const;
};
double FilonIntegral::integrate() const {
  function f1;
  f1 = [] {};
  return 0;
}

[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #16 from Steve Kargl  ---
On Wed, Apr 19, 2023 at 07:15:50PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
> 
> --- Comment #15 from anlauf at gcc dot gnu.org ---
> (In reply to Steve Kargl from comment #13)
> > Note 1 in Fortran 2023, Sec. 8.5.3, p. 100, is non-normative
> > text.  I suppose one can claim that gfortran should throw an
> > error when a function result is marked with the allocatable
> > attribute.
> 
> You mean when the function result is not allocated in that case?


First, note, 'allocated(f())' throws an error.

Error: 'array' argument of 'allocated' intrinsic at (1) must be a variable

You get this error regardless of the allocation status of the 
function result.

Now, with the original code,

  is_allocated(f())

The function reference is evaluated, and then the function result
(aka it's value) is argument associated with an allocatable dummy
argument.  This is technically wrong as the actual argument (aka
value returned by the function reference) should not have the
allocatable attribute.

   Fortran 2018

   15.5.2.6 Allocatable dummy variables

   The requirements in this subclause apply to actual arguments
   that correspond to allocatable dummy data objects.

   The actual argument shall be allocatable.  It is permissible
   for the actual argument to have an allocation status of
   unallocated.

I'll repeat.  The actual argument is the value resulting from
the function reference.  The "shall" in "shall be allocatable"
applies to something the programmer must ensure.


> > Unfortunately, it is likely a catch-22 situation
> > in that gfortran needs to know the function result is allocatable
> > so it can do the allocaton within the function, but it is not
> > an allocatable outside of the function.  Not sure gfortran
> > can mark an internal symbol to do both.
> 
> I checked how to implement a run-time check for a non-allocated
> function result, but did this in the wrong place - in the caller.
> This did work when I did allocate and the deallocate before return,
> otherwise the result variable is simply undefined, and the check does
> not work.
> 
> So a run-time check needs to be put where the function return is generated.
> 

If we go back to the original code and modify to allocate
f by say doing 'f = 42' in f(), gfortran produces 

% gfcx -o z -Wall a.f90 && ./z
 T

This is the problem.  Yes, f is allocated and assigned 
42.  The printed 'T' is bogus because 42 is value of
the function.  42 is no allocatable.

One place to possibly check for an error is when 
gfortran resolves argument association.  If a dummy
argument is allocatable, the actual argument needs 
to be allocatable and cannot not also be a function
result variable.

[Bug c++/100157] Support `__type_pack_element` like Clang

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:58b7dbf865b146a4e65dbda9be6df78f212c03b6

commit r14-92-g58b7dbf865b146a4e65dbda9be6df78f212c03b6
Author: Patrick Palka 
Date:   Wed Apr 19 15:36:34 2023 -0400

c++: Define built-in for std::tuple_element [PR100157]

This adds a new built-in to replace the recursive class template
instantiations done by traits such as std::tuple_element and
std::variant_alternative.  The purpose is to select the Nth type from a
list of types, e.g. __type_pack_element<1, char, int, float> is int.
We implement it as a special kind of TRAIT_TYPE.

For a pathological example tuple_element_t<1000, tuple<2000 types...>>
the compilation time is reduced by more than 90% and the memory used by
the compiler is reduced by 97%.  In realistic examples the gains will be
much smaller, but still relevant.

Unlike the other built-in traits, __type_pack_element uses template-id
syntax instead of call syntax and is SFINAE-enabled, matching Clang's
implementation.  And like the other built-in traits, it's not mangleable
so we can't use it directly in function signatures.

N.B. Clang seems to implement __type_pack_element as a first-class
template that can e.g. be used as a template-template argument.  For
simplicity we implement it in a more ad-hoc way.

Co-authored-by: Jonathan Wakely 

PR c++/100157

gcc/cp/ChangeLog:

* cp-trait.def (TYPE_PACK_ELEMENT): Define.
* cp-tree.h (finish_trait_type): Add complain parameter.
* cxx-pretty-print.cc (pp_cxx_trait): Handle
CPTK_TYPE_PACK_ELEMENT.
* parser.cc (cp_parser_constant_expression): Document default
arguments.
(cp_parser_trait): Handle CPTK_TYPE_PACK_ELEMENT.  Pass
tf_warning_or_error to finish_trait_type.
* pt.cc (tsubst) : Handle non-type first
argument.  Pass complain to finish_trait_type.
* semantics.cc (finish_type_pack_element): Define.
(finish_trait_type): Add complain parameter.  Handle
CPTK_TYPE_PACK_ELEMENT.
* tree.cc (strip_typedefs): Handle non-type first argument.
Pass tf_warning_or_error to finish_trait_type.
* typeck.cc (structural_comptypes) : Use
cp_tree_equal instead of same_type_p for the first argument.

libstdc++-v3/ChangeLog:

* include/bits/utility.h (_Nth_type): Conditionally define in
terms of __type_pack_element if available.
* testsuite/20_util/tuple/element_access/get_neg.cc: Prune
additional errors from the new built-in.

gcc/testsuite/ChangeLog:

* g++.dg/ext/type_pack_element1.C: New test.
* g++.dg/ext/type_pack_element2.C: New test.
* g++.dg/ext/type_pack_element3.C: New test.

[Bug c++/58538] Injected class-name treated as type-name instead of template-name when used as a template-argument for a template template-parameter

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #6 from Patrick Palka  ---
Fixed for GCC 13 then I suppose

[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value

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

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

--- Comment #15 from anlauf at gcc dot gnu.org ---
(In reply to Steve Kargl from comment #13)
> Note 1 in Fortran 2023, Sec. 8.5.3, p. 100, is non-normative
> text.  I suppose one can claim that gfortran should throw an
> error when a function result is marked with the allocatable
> attribute.

You mean when the function result is not allocated in that case?

> Unfortunately, it is likely a catch-22 situation
> in that gfortran needs to know the function result is allocatable
> so it can do the allocaton within the function, but it is not
> an allocatable outside of the function.  Not sure gfortran
> can mark an internal symbol to do both.

I checked how to implement a run-time check for a non-allocated
function result, but did this in the wrong place - in the caller.
This did work when I did allocate and the deallocate before return,
otherwise the result variable is simply undefined, and the check does
not work.

So a run-time check needs to be put where the function return is generated.

[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #14 from anlauf at gcc dot gnu.org ---
(In reply to Leandro Lupori from comment #12)
> Its inclusion in flang (with a portability warning) is being analyzed:
> https://reviews.llvm.org/D147614

Thanks for this link, which has pointers to the J3 list including:

https://mailman.j3-fortran.org/pipermail/j3/2012-April/005029.html

and the thread starting at

https://mailman.j3-fortran.org/pipermail/j3/2017-March/010158.html

with a clarification by Malcolm Cohen:

https://mailman.j3-fortran.org/pipermail/j3/2017-March/010181.html

> However, the main motivation was to improve compatibility with other
> compilers, such as gfortran and ifort.

Compatibility should be best for standard-conforming code... ;-)
I'm still waiting for a response from Intel.

> I'm trying to check with the issue reporter how extensive is his usage of
> this extension and how much effort it would require for him to avoid using
> it.

[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #13 from Steve Kargl  ---
On Wed, Apr 19, 2023 at 05:25:20PM +, leandro.lupori at linaro dot org
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
> 
> I'm trying to check with the issue reporter how extensive is his usage of this
> extension and how much effort it would require for him to avoid using it.
> 

It's not an extension.  It is a bug in the original
Fortran code.  The Fortran standard requires a function
result to be available at the completion of execution
of a function reference.  The code in the original
bug report clearly violates this.

Note 1 in Fortran 2023, Sec. 8.5.3, p. 100, is non-normative
text.  I suppose one can claim that gfortran should throw an
error when a function result is marked with the allocatable
attribute.  Unfortunately, it is likely a catch-22 situation
in that gfortran needs to know the function result is allocatable
so it can do the allocaton within the function, but it is not
an allocatable outside of the function.  Not sure gfortran
can mark an internal symbol to do both.

[Bug middle-end/109557] __builtin_dynamic_object_size() does not work for simple testing case

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

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

--- Comment #7 from qinzhao at gcc dot gnu.org ---
Okay, thanks for the comment. I see why this should not work.

[Bug c++/109551] Show location where implicit instantiation first required

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-04-19

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

[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value

[leandro.lupori at linaro dot org via Gcc-bugs]

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

--- Comment #12 from Leandro Lupori  ---
(In reply to anlauf from comment #11)
> Do you have anybody else supporting the view that the code in question
> should work as an extension?
> 

I know there is some usage of this extension, in code similar to this (using a
function result as an allocatable argument), as it works with gfortran and
ifort (https://github.com/llvm/llvm-project/issues/60226).

Its inclusion in flang (with a portability warning) is being analyzed:
https://reviews.llvm.org/D147614

However, the main motivation was to improve compatibility with other compilers,
such as gfortran and ifort.

I'm trying to check with the issue reporter how extensive is his usage of this
extension and how much effort it would require for him to avoid using it.

[Bug c++/109556] [13/14 Regression] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1927

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #9 from Patrick Palka  ---
Fixed for GCC 13.1, thanks for the bug report.

FWIW a potential workaround for this bug, which seems to work for me at least,
is to remove the Magnitude constraint from to_prefix_base and
to_base_scaled_unit.

[Bug c++/109556] [13/14 Regression] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1927

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:90361bc6f4edb444e86380b6d1e08475fa74

commit r13-7227-g90361bc6f4edb444e86380b6d1e08475fa74
Author: Patrick Palka 
Date:   Wed Apr 19 13:07:46 2023 -0400

c++: bad ggc_free in try_class_unification [PR109556]

Aside from correcting how try_class_unification copies multi-dimensional
'targs', r13-377-g3e948d645bc908 also made it ggc_free this copy as an
optimization.  But this is wrong since the call to unify within might've
captured the args in persistent memory such as the satisfaction cache
(as part of constrained auto deduction).

PR c++/109556

gcc/cp/ChangeLog:

* pt.cc (try_class_unification): Don't ggc_free the copy of
'targs'.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-placeholder13.C: New test.

(cherry picked from commit 5e284ebbc3082c5a8974d24e3a0977aa48f3cc60)

[Bug c++/109556] [13/14 Regression] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1927

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:5e284ebbc3082c5a8974d24e3a0977aa48f3cc60

commit r14-91-g5e284ebbc3082c5a8974d24e3a0977aa48f3cc60
Author: Patrick Palka 
Date:   Wed Apr 19 13:07:46 2023 -0400

c++: bad ggc_free in try_class_unification [PR109556]

Aside from correcting how try_class_unification copies multi-dimensional
'targs', r13-377-g3e948d645bc908 also made it ggc_free this copy as an
optimization.  But this is wrong since the call to unify within might've
captured the args in persistent memory such as the satisfaction cache
(as part of constrained auto deduction).

PR c++/109556

gcc/cp/ChangeLog:

* pt.cc (try_class_unification): Don't ggc_free the copy of
'targs'.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-placeholder13.C: New test.

[Bug middle-end/109557] __builtin_dynamic_object_size() does not work for simple testing case

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

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

Siddhesh Poyarekar  changed:

   What|Removed |Added

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

--- Comment #6 from Siddhesh Poyarekar  ---
(In reply to Martin Uecker from comment #5)
> With "in general" I meant in a different program.  From just knowing the
> type of the pointer you can not derive the object size.  This is how I
> understood the original question.

Ah ok, agreed.  Closing this as invalid then; I noticed I was missing the
inline keyword when I tried forcing inlining, so that was also a PEBKAC.

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

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

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work|13.0|
Summary|[12 Regression] ICE with|[12/13/14 Regression] ICE
   |type alias with `signed |with type alias with
   |__int128_t` |`signed __int128_t`

--- Comment #23 from Jason Merrill  ---
The static_assert regressions from comment #9 and 10 demonstrate that this
issue isn't actually fixed yet.

[Bug middle-end/109557] __builtin_dynamic_object_size() does not work for simple testing case

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #5 from Martin Uecker  ---
(In reply to Siddhesh Poyarekar from comment #4)
> (In reply to Martin Uecker from comment #3)
> > I general the pointer could point to the first object of an array that has
> > more elements, or to an object of a different type.
> 
> How so?  p in comment 0 is just a NULL-initialized pointer.  It gets
> assigned to a malloc'd storage in store() (which the code in main() cannot
> see) but until then, it's a NULL pointer.

With "in general" I meant in a different program.  From just knowing the type
of the pointer you can not derive the object size.  This is how I understood
the original question.

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

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

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

--- Comment #22 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:7b30f13b904f137c77e5180357af7917a3b47af0

commit r12-9447-g7b30f13b904f137c77e5180357af7917a3b47af0
Author: Jason Merrill 
Date:   Tue Apr 18 17:12:17 2023 -0400

c++: fix 'unsigned __int128_t' semantics [PR108099]

My earlier patch for 108099 made us accept this non-standard pattern but
messed up the semantics, so that e.g. unsigned __int128_t was not a 128-bit
type.

PR c++/108099

gcc/cp/ChangeLog:

* decl.cc (grokdeclarator): Keep typedef_decl for __int128_t.

gcc/testsuite/ChangeLog:

* g++.dg/ext/int128-8.C: New test.

[Bug middle-end/109557] __builtin_dynamic_object_size() does not work for simple testing case

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

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

--- Comment #4 from Siddhesh Poyarekar  ---
(In reply to Martin Uecker from comment #3)
> I general the pointer could point to the first object of an array that has
> more elements, or to an object of a different type.

How so?  p in comment 0 is just a NULL-initialized pointer.  It gets assigned
to a malloc'd storage in store() (which the code in main() cannot see) but
until then, it's a NULL pointer.

[Bug fortran/100297] FAIL: gfortran.dg/allocatable_function_1.f90 gfortran.dg/reshape_8.f90

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |14.0

--- Comment #6 from anlauf at gcc dot gnu.org ---
Fixed.

[Bug testsuite/83904] gfortran.dg allocatable_function_1 failures

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |14.0

--- Comment #3 from anlauf at gcc dot gnu.org ---
Fixed.

[Bug middle-end/109557] __builtin_dynamic_object_size() does not work for simple testing case

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #3 from Martin Uecker  ---
I general the pointer could point to the first object of an array that has more
elements, or to an object of a different type.  The semantics of C are not
strong enough here, but it would be good to have some kind of annotation for
the pointer that would allow this.

[Bug target/107479] bpf: add __builtin_btf_type_id

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

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

Jose E. Marchesi  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-04-19
   Assignee|unassigned at gcc dot gnu.org  |cupertino.miranda at 
oracle dot co
   ||m
 CC||jemarch at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug fortran/100297] FAIL: gfortran.dg/allocatable_function_1.f90 gfortran.dg/reshape_8.f90

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r14-90-g6fc8e25cb6b5d720bedd85194b0ad740d75082f4
Author: Harald Anlauf 
Date:   Tue Apr 18 21:24:20 2023 +0200

testsuite: fix scan-tree-dump patterns [PR83904,PR100297]

Adjust scan-tree-dump patterns so that they do not accidentally match a
valid path.

gcc/testsuite/ChangeLog:

PR testsuite/83904
PR fortran/100297
* gfortran.dg/allocatable_function_1.f90: Use "__builtin_free "
instead of the naive "free".
* gfortran.dg/reshape_8.f90: Extend pattern from a simple "data".

[Bug testsuite/83904] gfortran.dg allocatable_function_1 failures

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

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

commit r14-90-g6fc8e25cb6b5d720bedd85194b0ad740d75082f4
Author: Harald Anlauf 
Date:   Tue Apr 18 21:24:20 2023 +0200

testsuite: fix scan-tree-dump patterns [PR83904,PR100297]

Adjust scan-tree-dump patterns so that they do not accidentally match a
valid path.

gcc/testsuite/ChangeLog:

PR testsuite/83904
PR fortran/100297
* gfortran.dg/allocatable_function_1.f90: Use "__builtin_free "
instead of the naive "free".
* gfortran.dg/reshape_8.f90: Extend pattern from a simple "data".

[Bug target/107480] bpf: add __builtin_preserve_type_info

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

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

Jose E. Marchesi  changed:

   What|Removed |Added

   Last reconfirmed||2023-04-19
   Assignee|unassigned at gcc dot gnu.org  |cupertino.miranda at 
oracle dot co
   ||m
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
 CC||jemarch at gcc dot gnu.org

[Bug middle-end/109557] __builtin_dynamic_object_size() does not work for simple testing case

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

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

--- Comment #2 from Siddhesh Poyarekar  ---
(In reply to qinzhao from comment #0)
> I am wondering for 
> p.3_1 = p;
> _2 = __builtin_object_size (p.3_1, 0);
> 
> why the size of p.3_1 cannot use the TYPE_SIZE of the pointee of p when its
> size can be determined (i.e, not a structure with a flexible array member,
> etc)?

To answer this specific question, it's because the compiler can't see in main()
if p is pointing to any actual storage.

[Bug target/107481] bpf: add __builtin_preserve_enum_value

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

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

Jose E. Marchesi  changed:

   What|Removed |Added

 CC||jemarch at gcc dot gnu.org
   Last reconfirmed||2023-04-19
   Assignee|unassigned at gcc dot gnu.org  |cupertino.miranda at 
oracle dot co
   ||m
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

[Bug c++/109556] [13/14 Regression] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1927

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

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

--- Comment #6 from Jakub Jelinek  ---
Indeed, the reduction got stuck at around 1.4M size and didn't reduce further
until I've killed it.

[Bug middle-end/109557] __builtin_dynamic_object_size() does not work for simple testing case

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

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

--- Comment #1 from Siddhesh Poyarekar  ---
The __bdos call itself cannot succeed in main() because it cannot see the
allocation in store().  One way it could succeed is if store() was inlined, but
for some reason it doesn't, even if you make the function static inline.

If I decorate store() with __attribute__((inline)) I get the warning:

foo.c:10:1: warning: ‘always_inline’ function might not be inlinable
[-Wattributes]

but it seems to proceed to inline the call because the assert in main() is no
longer hit.

So from the __bdos context I'm inclined to say NOTABUG.

[Bug target/107844] error: argument is not a field access for __builtin_preserve_field_info

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

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

Jose E. Marchesi  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |cupertino.miranda at 
oracle dot co
   ||m

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

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

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

--- Comment #40 from qinzhao at gcc dot gnu.org ---
I had an initial patch to support the element_count attribute and use this
attribute in builtin_dynamic_object_size(), for the following testing case:

  1 #include 
  2 #include 
  3 #ifdef ENABLE_ELEMENT_COUNT_ATTRIBUTE  
  4 int k;
  5 struct P {
  6   int k;
  7   int x[] __attribute__ ((element_count ("k")));
  8 } *p;
  9 #else
 10 struct P {
 11   int k;
 12   int x[];
 13 } *p;
 14 #endif
 15 
 16 void store(int a, int b)
 17 {
 18   p = (struct P *)malloc (sizeof (struct P) + a * sizeof (int));
 19   p->k = a;
 20   p->x[b] = 0;
 21   assert (__builtin_dynamic_object_size (p->x, 1) == (p->k * sizeof
(int)));
 22   assert (__builtin_dynamic_object_size (p, 0) == (p->k * sizeof (int) +
sizeof (struct P)));
 23   return;
 24 }
 25 
 26 int main()
 27 {
 28  store(7, 7);
 29  p->x[8] = 1;
 30 #ifdef ENABLE_ELEMENT_COUNT_ATTRIBUTE 
 31  assert (__builtin_dynamic_object_size (p->x, 1) == (p->k * sizeof (int)));
 32  assert (__builtin_dynamic_object_size (p, 0) == (p->k * sizeof (int) +
sizeof (struct P)));
 33 #endif
 34 }

when compiled with my gcc as:

opc@qinzhao-ol8u3-x86 108896]$ sh t
/home/opc/Install/latest-d/bin/gcc -O -DENABLE_ELEMENT_COUNT_ATTRIBUTE t.c
a.out: t.c:32: main: Assertion `__builtin_dynamic_object_size (p, 0) == (p->k *
sizeof (int) + sizeof (struct P))' failed.
t: line 21: 3266310 Aborted (core dumped) ./a.out

with this private gcc, the __builtin_dynamic_object_size (p->x,1) at line 31
can be correctly computed based on the attribute.

However, due to PR109557, the __builtin_dynamic_object_size (p, 0) at line 32
cannot be computed. 
Due to bug PR109557, the assertion at line 32 failed.

[Bug target/109558] bpf: support BTF and DWARF tag annotations for BPF

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

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

Jose E. Marchesi  changed:

   What|Removed |Added

   Last reconfirmed||2023-04-19
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |david.faust at oracle 
dot com
 Ever confirmed|0   |1

[Bug target/109558] New: bpf: support BTF and DWARF tag annotations for BPF

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

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

Bug ID: 109558
   Summary: bpf: support BTF and DWARF tag annotations for BPF
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jemarch at gcc dot gnu.org
  Target Milestone: ---

There is a need to support:

- Two new C-language-level attributes that allow to associate (to "tag")
  particular declarations and types with arbitrary strings. This is intended to
be used to, for example, characterize certain pointer types in the kernel
verifier.

- The conveyance of that information in the DWARF output in the form of a new
  DIE: DW_TAG_(GNU|LLVM)_annotation.

- The conveyance of that information in the BTF output in the form of two new
  kinds of BTF objects: BTF_KIND_DECL_TAG and BTF_KIND_TYPE_TAG.

All of these facilities are being added to the eBPF ecosystem, and support for
them exists in some form in LLVM.  We have already discussed and agred on the
details of what to support.

[Bug middle-end/109557] New: __builtin_dynamic_object_size() does not work for simple testing case

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

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

Bug ID: 109557
   Summary: __builtin_dynamic_object_size() does not work for
simple testing case
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

during my work for PR108896, I found that for the following small testing case:

[opc@qinzhao-ol8u3-x86 108896]$ cat test.c
#include 
#include 
struct P {
  int k;
  int x[10]; 
} *p;

void store(int a, int b) 
{
  p = (struct P *)malloc (sizeof (struct P));
  p->k = a;
  p->x[b] = 0;
  assert (__builtin_dynamic_object_size (p, 0) == sizeof (struct P));
  return;
}

int main()
{
  store(7, 7);
  assert (__builtin_dynamic_object_size (p, 0) == sizeof (struct P));
  free (p);
}

with gcc13, compiled with -O, the above first assertion succeed, but the second
one failed.

when checking the tree-object-size.cc, I found:
1377 static void
1378 expr_object_size (struct object_size_info *osi, tree ptr, tree value)
1379 {
1380   int object_size_type = osi->object_size_type;
1381   unsigned int varno = SSA_NAME_VERSION (ptr);
1382   tree bytes, wholesize;
1383 
1384   gcc_assert (!object_sizes_unknown_p (object_size_type, varno));
1385   gcc_assert (osi->pass == 0);
1386 
1387   if (TREE_CODE (value) == WITH_SIZE_EXPR)
1388 value = TREE_OPERAND (value, 0);
1389 
1390   /* Pointer variables should have been handled by merge_object_sizes.  */
1391   gcc_assert (TREE_CODE (value) != SSA_NAME
1392   || !POINTER_TYPE_P (TREE_TYPE (value)));
1393 
1394   if (TREE_CODE (value) == ADDR_EXPR)
1395 addr_object_size (osi, value, object_size_type, , );
1396   else
1397 bytes = wholesize = size_unknown (object_size_type);
1398 
1399   object_sizes_set (osi, varno, bytes, wholesize);
1400 }

in the above, for the 2nd __builtin_dynamic_object_size, the above line 1397 is
called, therefore size_unknown was returned for it.

I am wondering for 
p.3_1 = p;
_2 = __builtin_object_size (p.3_1, 0);

why the size of p.3_1 cannot use the TYPE_SIZE of the pointee of p when its
size can be determined (i.e, not a structure with a flexible array member,
etc)?

[Bug c/109553] Atomic operations vs const locations

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2023-04-19

--- Comment #5 from Andrew Pinski  ---
>Both of these functions compile fine with GCC.

No GCC has a diagnostic for casa_uint32_t too:
: In function 'casa_uint32_t':
:13:3: error: passing argument 1 of '__atomic_compare_exchange_4'
discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
   13 |   __atomic_compare_exchange_n (a, b, 3, 0, __ATOMIC_ACQUIRE,
__ATOMIC_ACQUIRE);
  |   ^~~
:13:3: note: expected 'volatile void *' but argument is of type 'const
uint32_t *' {aka 'const unsigned int *'}

This is with -pedantic-errors.

The C front-end diagnostic by default even.

The C++ front-end does not even need -pedantic-errors either:
: In function 'void casa_uint32_t(const uint32_t*, uint32_t*,
uint32_t*)':
:13:32: error: invalid conversion from 'const void*' to 'volatile
void*' [-fpermissive]
   13 |   __atomic_compare_exchange_n (a, b, 3, 0, __ATOMIC_ACQUIRE,
__ATOMIC_ACQUIRE);
  |^
  ||
  |const void*


GCC treats these as normal function calls from the front-end so the warning is
an extension even.

That is:
void f(volatile void*);

void g(const void *a)
{
f(a);
}
Will gives a similar warning.

[Bug c/109553] Atomic operations vs const locations

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

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

--- Comment #4 from Xi Ruoyao  ---
(In reply to Andrew Pinski from comment #3)
> Note I disagree with load_uint32_t having a warning. the pointer might be
> have a const qualifier on it does not mean the location is const overall.

And the doc didn't say "type cannot be const-qualified" (though const-qualified
type does not make any sense for store).

[Bug c++/109556] [13/14 Regression] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1927

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

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

Patrick Palka  changed:

   What|Removed |Added

   Keywords|needs-bisection,|
   |needs-reduction |

--- Comment #5 from Patrick Palka  ---
template
concept C = (N != 0);

template
struct A { };

template auto M>
void f(A);

int main() {
  f(A<1, 42>{});
  f(A<2, 42>{});
}

Bisection seems unreliable probably due to the use-after-free nature of the
bug, but removing those calls to ggc_free fixes the issue so
r13-377-g3e948d645bc908 is almost certainly the culprit.

[Bug c++/109556] [13/14 Regression] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1927

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-04-19
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |13.0
   Keywords||GC, ice-on-valid-code
 Ever confirmed|0   |1
Summary|internal compiler error: in |[13/14 Regression] internal
   |iterative_hash_template_arg |compiler error: in
   |, at cp/pt.cc:1927  |iterative_hash_template_arg
   ||, at cp/pt.cc:1927

[Bug c/109553] Atomic operations vs const locations

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

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

--- Comment #3 from Andrew Pinski  ---
Note I disagree with load_uint32_t having a warning. the pointer might be have
a const qualifier on it does not mean the location is const overall.

[Bug middle-end/109555] memcmp with string literals cause branchy code maybe could use branchless?

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
Summary|suboptimal code for |memcmp with string literals
   |comparing strings with  |cause branchy code maybe
   |string literals |could use branchless?

[Bug middle-end/66588] combine should try transforming if_then_else of zero_extends into zero_extend of if_then_else

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

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

--- Comment #8 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:04a9209dc865dafe3c9615f5c868aa3fd89b96cf

commit r14-89-g04a9209dc865dafe3c9615f5c868aa3fd89b96cf
Author: Andrew Pinski 
Date:   Thu Apr 13 00:40:40 2023 +

i386: Add new pattern for zero-extend cmov

After a phiopt change, I got a failure of cmov9.c.
The RTL IR has zero_extend on the outside of
the if_then_else rather than on the side. Both
ways are considered canonical as mentioned in
PR 66588.

This fixes the failure I got and also adds a testcase
which fails before even my phiopt patch but will pass
with this patch.

OK? Bootstrapped and tested on x86_64-linux-gnu with
no regressions.

gcc/ChangeLog:

* config/i386/i386.md (*movsicc_noc_zext_1): New pattern.

gcc/testsuite/ChangeLog:

* gcc.target/i386/cmov10.c: New test.
* gcc.target/i386/cmov11.c: New test.

[Bug target/109549] [14 Regression] cmov6.c test fail after commit r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a

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

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

--- Comment #6 from Jeffrey A. Law  ---
And just an FYI, the tester is flagging conditional move failures for mips64-*
rx-elf and s390-linux-gnu.  Most likely these are additional cases where the
hook is indicating the transformation isn't profitable, but the target tests
are expecting the transformation to happen.

I'll debug those other targets and take appropriate action.  At this point I
don't see anything that would strongly suggest reversion of the patch, just
that we need a bit of testsuite adjustment.

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

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

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

--- Comment #21 from CVS Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r14-88-ged32ec26697cc77492d094b31a0d2eebc0535644
Author: Jason Merrill 
Date:   Tue Apr 18 17:12:17 2023 -0400

c++: fix 'unsigned __int128_t' semantics [PR108099]

My earlier patch for 108099 made us accept this non-standard pattern but
messed up the semantics, so that e.g. unsigned __int128_t was not a 128-bit
type.

PR c++/108099

gcc/cp/ChangeLog:

* decl.cc (grokdeclarator): Keep typedef_decl for __int128_t.

gcc/testsuite/ChangeLog:

* g++.dg/ext/int128-8.C: New test.

[Bug c++/109554] Compiler generates incorrect code when the function declared with returned parameterm but no 'return' in its body

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

 Resolution|WONTFIX |INVALID

[Bug rtl-optimization/78952] Combine does not convert 8-bit sign-extract to a zero-extract for QImode operations

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:0df6d181230f0480547ed08b4e4354db68242724

commit r14-85-g0df6d181230f0480547ed08b4e4354db68242724
Author: Uros Bizjak 
Date:   Wed Apr 19 17:00:52 2023 +0200

i386: Emit compares between high registers and memory

Following code:

typedef __SIZE_TYPE__ size_t;

struct S1s
{
  char pad1;
  char val;
  short pad2;
};

extern char ts[256];

_Bool foo (struct S1s a, size_t i)
{
  return (ts[i] > a.val);
}

compiles with -O2 to:

movl%edi, %eax
movsbl  %ah, %edi
cmpb%dil, ts(%rsi)
setg%al
ret

the compare could use high register %ah instead of %dil:

movl%edi, %eax
cmpbts(%rsi), %ah
setl%al
ret

Use any_extract code iterator to handle signed and unsigned extracts
from high register and introduce peephole2 patterns to propagate
norex memory opeerand into the compare insn.

gcc/ChangeLog:

PR target/78904
PR target/78952
* config/i386/i386.md (*cmpqi_ext_1_mem_rex64): New insn
pattern.
(*cmpqi_ext_1): Use nonimmediate_operand predicate
for operand 0. Use any_extract code iterator.
(*cmpqi_ext_1 peephole2): New peephole2 pattern.
(*cmpqi_ext_2): Use any_extract code iterator.
(*cmpqi_ext_3_mem_rex64): New insn pattern.
(*cmpqi_ext_1): Use general_operand predicate
for operand 1. Use any_extract code iterator.
(*cmpqi_ext_3 peephole2): New peephole2 pattern.
(*cmpqi_ext_4): Use any_extract code iterator.

gcc/testsuite/ChangeLog:

PR target/78904
PR target/78952
* gcc.target/i386/pr78952-3.c: New test.

[Bug target/78904] zero-extracts are not effective

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

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:0df6d181230f0480547ed08b4e4354db68242724

commit r14-85-g0df6d181230f0480547ed08b4e4354db68242724
Author: Uros Bizjak 
Date:   Wed Apr 19 17:00:52 2023 +0200

i386: Emit compares between high registers and memory

Following code:

typedef __SIZE_TYPE__ size_t;

struct S1s
{
  char pad1;
  char val;
  short pad2;
};

extern char ts[256];

_Bool foo (struct S1s a, size_t i)
{
  return (ts[i] > a.val);
}

compiles with -O2 to:

movl%edi, %eax
movsbl  %ah, %edi
cmpb%dil, ts(%rsi)
setg%al
ret

the compare could use high register %ah instead of %dil:

movl%edi, %eax
cmpbts(%rsi), %ah
setl%al
ret

Use any_extract code iterator to handle signed and unsigned extracts
from high register and introduce peephole2 patterns to propagate
norex memory opeerand into the compare insn.

gcc/ChangeLog:

PR target/78904
PR target/78952
* config/i386/i386.md (*cmpqi_ext_1_mem_rex64): New insn
pattern.
(*cmpqi_ext_1): Use nonimmediate_operand predicate
for operand 0. Use any_extract code iterator.
(*cmpqi_ext_1 peephole2): New peephole2 pattern.
(*cmpqi_ext_2): Use any_extract code iterator.
(*cmpqi_ext_3_mem_rex64): New insn pattern.
(*cmpqi_ext_1): Use general_operand predicate
for operand 1. Use any_extract code iterator.
(*cmpqi_ext_3 peephole2): New peephole2 pattern.
(*cmpqi_ext_4): Use any_extract code iterator.

gcc/testsuite/ChangeLog:

PR target/78904
PR target/78952
* gcc.target/i386/pr78952-3.c: New test.

[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

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

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

--- Comment #24 from Jakub Jelinek  ---
You're right.  libstdc++.so.6 would then initialize just the old symver copy
and not the new one, which could be used by newer shared libraries.
So that leaves the asm (".globl _Zwhatever"); in the header file.

[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

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

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

--- Comment #23 from Florian Weimer  ---
(In reply to Jakub Jelinek from comment #20)
> So, when the @@GLIBCXX_3.4.31 alias is weak, at least the F36 linker puts
> into the binary not just one but both symbols and so the aliasing isn't
> broken.

I'm not sure this is sufficient because old programs will only have the
@GLIBCXX_3.4 reference and still break the aliases if copy relocations are
involved. The internal libstdc++ things we could perhaps resolve, but even with
that, it will only work if everything in the executable either uses the old
version, or the new version. Mixed-mode operation still won't work because of
the separation of the aliases.

[Bug target/106342] [12/13/14 Regression] internal compiler error: in extract_insn, at recog.cc:2791 since r12-4240-g2b8453c401b699

[iii at linux dot ibm.com via Gcc-bugs]

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

--- Comment #10 from Ilya Leoshkevich  ---
This bug was fixed and backported to gcc-12:

commit 06254d97b8fa3a5d1c8b6b4e091d851700801385
Author: Ilya Leoshkevich 
Date:   Fri Jul 29 16:14:10 2022 +0200

PR106342 - IBM zSystems: Provide vsel for all vector modes

dg.exp=pr104612.c fails with an ICE on s390x, because copysignv2sf3
produces an insn that vsel is supposed to recognize, but can't,
because it's not defined for V2SF.  Fix by defining it for all vector
modes supported by copysign3.

gcc/ChangeLog:

* config/s390/vector.md (V_HW_FT): New iterator.
* config/s390/vx-builtins.md (vsel): Use V_HW_FT instead
of V_HW.

(cherry picked from commit 2f17f489de47d46626ed85804c3b810547ef550e)

I think it should be closed.

[Bug c++/109554] Compiler generates incorrect code when the function declared with returned parameterm but no 'return' in its body

[xvladsoft at yahoo dot com via Gcc-bugs]

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

Khokholkov Vladimir  changed:

   What|Removed |Added

 Resolution|INVALID |WONTFIX

--- Comment #3 from Khokholkov Vladimir  ---
(In reply to Xi Ruoyao from comment #2)
> And it's clearly documented in https://gcc.gnu.org/gcc-8/changes.html:
> 
> Flowing off the end of a non-void function is considered unreachable and may
> be subject to optimization on that basis. As a result of this change,
> -Wreturn-type warnings are enabled by default for C++.
> 
> If you insist on ignoring the -Wreturn-type warning, you are doing things
> wrong.

I see...
Ok, thanks!
I think the issue should be closed then.
(P.S. I do not ignore that message, just accidentally found this case and
decided to investigate).

B.R.
Vladimir.

[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

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

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

--- Comment #22 from Jakub Jelinek  ---
extern int cinalias __attribute__((__symver__ ("_ZSt4cin@GLIBCXX_3.4")));
void foo ()
{
  cinalias++;
}
doesn't work to refer to older symver, but
extern int cinalias;
asm (".symver cinalias, _ZSt4cin@GLIBCXX_3.4");
void foo ()
{
  cinalias++;
}
does.  Of course, needs testing with old binutils and the like.

[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

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

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

--- Comment #21 from Sam James  ---
The commits got reverted in r14-76-ga6e4b81b12e57b and r14-77-gfac24d43e68838
after marxin reported a segfault with mold in #gcc and fweimer reported an
issue with cmake at https://bugzilla.redhat.com/show_bug.cgi?id=2187768#c4.

[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #20 from Jakub Jelinek  ---
So,
( for i in 7.c 7.ver 7a.c 7a.ver 8.c 7.h; do echo $i; cat /tmp/$i; done; gcc
-shared -fpic -Wl,--version-script=/tmp/7.ver /tmp/7.c -o /tmp/7.so; gcc -I
/tmp/ -o /tmp/8 /tmp/8.c /tmp/7.so; /tmp/8; echo $?; gcc -shared -fpic
-Wl,--version-script=/tmp/7a.ver /tmp/7a.c -o /tmp/7.so; /tmp/8; echo $? )
7.c
void
_Zwhatever (void)
{
}

void
foo (void)
{
}
7.ver
GLIBCXX_3.4.31 {
  global: foo;
  local: *;
};
GLIBCXX_3.4.32 {
  global: _Zwhatever;
} GLIBCXX_3.4.31;
7a.c
void
foo (void)
{
}
7a.ver
GLIBCXX_3.4.31 {
  global: foo;
  local: *;
};
8.c
#include "7.h"

int
main ()
{
}
7.h
asm (".globl _Zwhatever");
0
/tmp/8: /tmp/7.so: version `GLIBCXX_3.4.32' not found (required by /tmp/8)
1
is one proof-of-concept on what we could do.

Another one is
/tmp/4.C
namespace std {
# define _GLIBCXX_IO_GLOBAL(type, X, N) namespace __io { type X
__attribute__((__symver__ ("_ZSt" #N #X "@GLIBCXX_3.4"))); } \
  extern type X##alias __attribute__((__weak__, __alias__ ("_ZNSt4__io" #N #X
"E"), __symver__ ("_ZSt" #N #X "@@GLIBCXX_3.4.31")));
  _GLIBCXX_IO_GLOBAL(int, cin, 3)
  _GLIBCXX_IO_GLOBAL(int, cout, 4)
  _GLIBCXX_IO_GLOBAL(int, cerr, 4)
  _GLIBCXX_IO_GLOBAL(int, clog, 4)
}
/tmp/4.c
extern int _ZSt4cerr;
int
main ()
{
  _ZSt4cerr++;
}
/tmp/4.ver
GLIBCXX_3.4 {
  global:
_ZSt3cin;
_ZSt4cerr;
_ZSt4cout;
_ZSt4clog;
  local: *;
};
GLIBCXX_3.4.31 {
  global:
_ZSt3cin;
_ZSt4cerr;
_ZSt4cout;
_ZSt4clog;
} GLIBCXX_3.4;
gcc -shared -o /tmp/4.so /tmp/4.C -fpic -Wl,--version-script=/tmp/4.ver
gcc -o /tmp/4 /tmp/4.c /tmp/4.so
eadelf -Wa /tmp/4 2>&1 | grep cerr
0040401c  00040005 R_X86_64_COPY  0040401c
_ZSt4cerr@GLIBCXX_3.4 + 0
 3: 0040401c 4 OBJECT  WEAK   DEFAULT   23
_ZSt4cerr@GLIBCXX_3.4.31 (3)
 4: 0040401c 4 OBJECT  GLOBAL DEFAULT   23
_ZSt4cerr@GLIBCXX_3.4 (4)
58: 0040401c 4 OBJECT  WEAK   DEFAULT   23
_ZSt4cerr@GLIBCXX_3.4.31
59: 0040401c 4 OBJECT  GLOBAL DEFAULT   23
_ZSt4cerr@GLIBCXX_3.4
So, when the @@GLIBCXX_3.4.31 alias is weak, at least the F36 linker puts into
the binary not just one but both symbols and so the aliasing isn't broken.
We'd need to also arrange for ios_init.o to refer to _ZSt4cerr@GLIBCXX_3.4
rather than _ZSt4cerr, because binaries built against older libstdc++ will have
just _ZSt4cerr@GLIBCXX_3.4 symbol on the copy relocation.

Or combination of both, do the former on Solaris and the latter on Linux.  To
be tested with older linkers/assemblers, non-glibc dynamic linkers and the
like.

[Bug c++/109556] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1927

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org

--- Comment #4 from Patrick Palka  ---
It looks like the satisfaction cache is holding on to a TREE_VEC that's been
ggc_free'd.  It got freed from

pt.cc:try_class_unification#L23897:

  if (TMPL_ARGS_HAVE_MULTIPLE_LEVELS (targs))
for (tree level : tree_vec_range (targs))
  ggc_free (level);
  ggc_free (targs);

Removing these calls to ggc_free fixes the ICE, thus I'm pretty sure this
started with r13-377-g3e948d645bc908.  In hindsight freeing this copy of
'targs' isn't generally safe because the call to unify in try_class_unification
could perform satisfaction which in turn would capture parts of targs into the
satisfaction cache.

[Bug c/109553] Atomic operations vs const locations

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

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

Wilco  changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #2 from Wilco  ---
(In reply to Xi Ruoyao from comment #1)

> > but even for atomic load we may want to hint to the user to avoid doing an
> > atomic load from const types.
> 
> this does not make sense.  The "const" in "const T *" only means you cannot
> modify the object via the pointer, not mean the value of the object won't
> change.  Consider:
> 
> void thread1(int *ptr)
> {
>   /* ... */
>   __atomic_add_fetch (ptr, 1, __ATOMIC_SEQ_CST);
>   /* ... */
> }
> 
> void thread2(const int *ptr)
> {
>   /* ... */
>   int t = __atomic_load_n (ptr, __ATOMIC_SEQ_CST);
>   /* ... */
> }
> 
> It's perfectly legal the two "ptr" can point to the same object.  Then if
> you use the usual load intead of __atomic_load_n, a race will happen.

It would be legal if __atomic_load_n is documented to use a const argument, but
it doesn't allow const:
https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/_005f_005fatomic-Builtins.html#g_t_005f_005fatomic-Builtins:~:text=Built%2Din%20Function%3A%20type%20__atomic_load_n%20(type%20*ptr%2C%20int%20memorder)

Since atomic accesses are about synchronizing writes with reads, a diagnostic
would be useful, particularly for the case Kyrill mentioned.

[Bug c++/109556] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1927

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

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

--- Comment #3 from Jakub Jelinek  ---
Reproduced, reducing now.

[Bug target/109549] [14 Regression] cmov6.c test fail after commit r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-04-19

--- Comment #5 from Jeffrey A. Law  ---
Yea, that's exactly what's kicking in here.  The converted sequence looks like
this:

(insn 29 0 28 (set (reg:SI 86)
(const_int 10 [0xa])) 83 {*movsi_internal}
 (nil))

(insn 28 29 30 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:SI 83 [ c ])
(const_int 0 [0]))) 7 {*cmpsi_ccno_1}
 (nil))

(insn 30 28 32 (set (reg/v:SI 85 [ e ])
(if_then_else:SI (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg/v:SI 85 [ e ])
(reg:SI 86))) 1318 {*movsicc_noc}
 (nil))

(insn 32 30 31 (set (reg:SI 87)
(const_int 20 [0x14])) 83 {*movsi_internal}
 (nil))

(insn 31 32 33 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:SI 83 [ c ])
(const_int 0 [0]))) 7 {*cmpsi_ccno_1}
 (nil))

(insn 33 31 0 (set (reg/v:SI 84 [ d ])
(if_then_else:SI (ne (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg/v:SI 84 [ d ])
(reg:SI 87))) 1318 {*movsicc_noc}
 (nil))


Note the two movsicc_* patterns.

So the question now is what to do about it.  It looks like things are behaving
as expected, so my first inclination would be to adjust the test.  Actually
splitting it into two would likely be even better.  One would verify that by
default we do not generate a pair of cmovs for this code, the other would turn
the tuning bit off and verify that we do generate the pair of cmovs.

Happy to do whatever the x86 maintainers want here.

[Bug target/109549] [14 Regression] cmov6.c test fail after commit r14-53-g675b1a7f113adb1d737adaf78b4fd90be7a0ed1a

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

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

--- Comment #4 from Jeffrey A. Law  ---
x86's tuning does have some support for avoiding multiple cmovs in a single
if-converted sequence.  I'll double check if that's kicking in here.

[Bug c++/109556] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1927

[fabian.sauter+bz_gcc at apsensing dot com via Gcc-bugs]

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

--- Comment #2 from Fabian Sauter  
---
Created attachment 54884
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54884=edit
Preprocessed Source

Ah, it failed to upload with: "The file you are trying to attach is 2505
kilobytes (KB) in size. Attachments cannot be more than 1000 KB."

I compressed it!

[Bug c++/109556] internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1927

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Preprocessed source stored into /tmp/ccG8HXcN.out file, please attach this to
your bugreport.

^^^

[Bug c++/109556] New: internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1927

[fabian.sauter+bz_gcc at apsensing dot com via Gcc-bugs]

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

Bug ID: 109556
   Summary: internal compiler error: in
iterative_hash_template_arg, at cp/pt.cc:1927
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fabian.sauter+bz_gcc at apsensing dot com
  Target Milestone: ---

I'm using gcc 13.0.1-0 on Fedora 38.
I hope this is the correct place to report this bug since in the log it states
I should report it at RedHats bug tracker but I was not able to find a gcc
section there.

Compiling mpunits (https://github.com/mpusz/units) fails with gcc13. With gcc12
it still works.

I'm still failing to reduce the problem to a single failing source header file.

Let me know if you need anything else.


## How to Reproduce:
git clone https://github.com/mpusz/units.git
cd units && mkdir build && cd build
cmake ..
cmake --build .

## Related Issues
https://github.com/mpusz/units/issues/450

## Output:
```
[ 30%] Building CXX object
CMakeFiles/test_headers.dir/headers/src/systems/si/include/units/isq/si/absorbed_dose.cpp.o
In file included from
/home/fabian/Repos/units/src/systems/si/include/units/isq/si/force.h:33,
 from
/home/fabian/Repos/units/src/systems/si/include/units/isq/si/energy.h:32,
 from
/home/fabian/Repos/units/./src/systems/si/include/units/isq/si/absorbed_dose.h:32,
 from
/home/fabian/Repos/units/build/headers/src/systems/si/include/units/isq/si/absorbed_dose.cpp:1:
/home/fabian/Repos/units/src/systems/si/include/units/isq/si/mass.h: In
substitution of ‘template  requires (Dimension)
&& (UnitOf) && (Representation) class units::quantity [with D =
units::isq::si::dim_mass; U = units::isq::si::gigagram; Rep = long int]’:
/home/fabian/Repos/units/src/systems/si/include/units/isq/si/mass.h:88:7:  
required by substitution of ‘template  requires (UnitOf) && (Representation) using units::isq::si::mass
= units::quantity [with U =
units::isq::si::gigagram; Rep = long int]’
/home/fabian/Repos/units/src/systems/si/include/units/isq/si/mass.h:218:37:  
required from here
/home/fabian/Repos/units/src/systems/si/include/units/isq/si/mass.h:88:7:
internal compiler error: in iterative_hash_template_arg, at cp/pt.cc:1927
   88 | using mass = quantity;
  |   ^~~~
Please submit a full bug report, with preprocessed source.
See  for instructions.
Preprocessed source stored into /tmp/ccG8HXcN.out file, please attach this to
your bugreport.
gmake[2]: *** [CMakeFiles/test_headers.dir/build.make:1182:
CMakeFiles/test_headers.dir/headers/src/systems/si/include/units/isq/si/absorbed_dose.cpp.o]
Error 1
gmake[1]: *** [CMakeFiles/Makefile2:575: CMakeFiles/test_headers.dir/all] Error
2
gmake: *** [Makefile:136: all] Error 2
```

[Bug middle-end/109555] suboptimal code for comparing strings with string literals

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to niXman from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Note branchless might be worse.
> 
> really?
> could you explain please?

Yes cache misses. That is the second load might miss the cache.
Plus the non reduced case will most likely have a branch on the result so in
the end, it would just do unnecessary things if it is different.


> 
> 
> 
> > Anyways there is a duplicate of this bug
> > already. I think I filed it.
> 
> thank you!

[Bug middle-end/109555] suboptimal code for comparing strings with string literals

[i.nixman at autistici dot org via Gcc-bugs]

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

--- Comment #2 from niXman  ---
(In reply to Andrew Pinski from comment #1)
> Note branchless might be worse.

really?
could you explain please?



> Anyways there is a duplicate of this bug
> already. I think I filed it.

thank you!

[Bug middle-end/109555] suboptimal code for comparing strings with string literals

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

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

--- Comment #1 from Andrew Pinski  ---
Note branchless might be worse. Anyways there is a duplicate of this bug
already. I think I filed it.

[Bug middle-end/109555] New: suboptimal code for comparing strings with string literals

[i.nixman at autistici dot org via Gcc-bugs]

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

Bug ID: 109555
   Summary: suboptimal code for comparing strings with string
literals
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i.nixman at autistici dot org
  Target Milestone: ---

hello!


the example:

#include 
int main(int argc, char **argv) {
return std::memcmp(argv[0], "MCRYF", 5) == 0;
}


this code compiled with GCC (-std=c++11 -O2) will be translated as the
following assembler code (https://godbolt.org/z/zzjaGdWdT):

main:
mov rax, QWORD PTR [rsi]
cmp DWORD PTR [rax], 1498563405
je  .L5
.L2:
mov eax, 1
.L3:
xor eax, 1
ret
.L5:
cmp BYTE PTR [rax+4], 70
jne .L2
xor eax, eax
jmp .L3



but if the code is compiled using CLang, we get a more optimal branch-less
assembler code (https://godbolt.org/z/E9o1oMzra):

main:   # @main
mov rax, qword ptr [rsi]
mov ecx, 1498563405
xor ecx, dword ptr [rax]
movzx   edx, byte ptr [rax + 4]
xor edx, 70
xor eax, eax
or  edx, ecx
seteal
ret



maybe it's not a difficult fix, and maybe someone will see the point to improve
this...


thanks!

[Bug c++/109548] Detect c_str() dangling problems

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #2)
> Btw, is there an API to std::move the (possibly) allocated string out of
> the std::string and make it available as C string pointer?

No, ownership always belongs to a std::string object.

[Bug c/109553] Atomic operations vs const locations

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #1 from Xi Ruoyao  ---
(In reply to ktkachov from comment #0)
> When reasoning about optimal sequences for atomic operations for various
> targets the issue of read-only memory locations keeps coming up,
> particularly when talking about doing non-native larger-sized accesses
> locklessly
> 
> I wonder if the frontends in GCC should be more assertive with warnings on
> such constructs. Consider, for example:
> #include 
> 
> uint32_t
> load_uint32_t (const uint32_t *a)
> {
>   return __atomic_load_n (a, __ATOMIC_ACQUIRE);
> }
> 
> void
> casa_uint32_t (const uint32_t *a, uint32_t *b, uint32_t *c)
> {
>   __atomic_compare_exchange_n (a, b, 3, 0, __ATOMIC_ACQUIRE,
> __ATOMIC_ACQUIRE);
> }
> 
> Both of these functions compile fine with GCC.
> With Clang casa_uint32_t  gives a hard error:
> error: address argument to atomic operation must be a pointer to non-const
> type ('const uint32_t *' (aka 'const unsigned int *') invalid)
>   __atomic_compare_exchange_n (a, b, 3, 0, __ATOMIC_ACQUIRE,
> __ATOMIC_ACQUIRE);
> 
> I would argue that for both cases the compiler should emit something. I
> think an error is a appropriate for the __atomic_compare_exchange_n case,

Agree, but...

> but even for atomic load we may want to hint to the user to avoid doing an
> atomic load from const types.

this does not make sense.  The "const" in "const T *" only means you cannot
modify the object via the pointer, not mean the value of the object won't
change.  Consider:

void thread1(int *ptr)
{
  /* ... */
  __atomic_add_fetch (ptr, 1, __ATOMIC_SEQ_CST);
  /* ... */
}

void thread2(const int *ptr)
{
  /* ... */
  int t = __atomic_load_n (ptr, __ATOMIC_SEQ_CST);
  /* ... */
}

It's perfectly legal the two "ptr" can point to the same object.  Then if you
use the usual load intead of __atomic_load_n, a race will happen.

[Bug c++/109554] Compiler generates incorrect code when the function declared with returned parameterm but no 'return' in its body

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

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

--- Comment #2 from Xi Ruoyao  ---
And it's clearly documented in https://gcc.gnu.org/gcc-8/changes.html:

Flowing off the end of a non-void function is considered unreachable and may be
subject to optimization on that basis. As a result of this change,
-Wreturn-type warnings are enabled by default for C++.

If you insist on ignoring the -Wreturn-type warning, you are doing things
wrong.

[Bug tree-optimization/44794] pre- and post-loops should not be unrolled.

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

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug c/109554] Compiler generates incorrect code when the function declared with returned parameterm but no 'return' in its body

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
Failure to return a value in a non-void function invokes undefined behaviour. 
For C++ this is independent of whether the caller uses the return value.

[Bug tree-optimization/44794] pre- and post-loops should not be unrolled.

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

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

--- Comment #7 from Richard Biener  ---
Heuristic to not unroll loops with prefetches is missing.  The aprefetch pass
could set ->unroll to 1 in the loop structure.

[Bug tree-optimization/44794] pre- and post-loops should not be unrolled.

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r14-71-ga243ce2a52a6c62bc0d6be0b756a85dd9c1bceb7
Author: Richard Biener 
Date:   Thu Mar 9 09:02:07 2023 +0100

tree-optimization/44794 - avoid excessive RTL unrolling on epilogues

The following adjusts tree_[transform_and_]unroll_loop to set an
upper bound on the number of iterations on the epilogue loop it
creates.  For the testcase at hand which involves array prefetching
this avoids applying RTL unrolling to them when -funroll-loops is
specified.

Other users of this API includes predictive commoning and
unroll-and-jam.

PR tree-optimization/44794
* tree-ssa-loop-manip.cc (tree_transform_and_unroll_loop):
If an epilogue loop is required set its iteration upper bound.

[Bug c/109554] New: Compiler generates incorrect code when the function declared with returned parameterm but no 'return' in its body

[xvladsoft at yahoo dot com via Gcc-bugs]

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

Bug ID: 109554
   Summary: Compiler generates incorrect code when the function
declared with returned parameterm but no 'return' in
its body
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xvladsoft at yahoo dot com
  Target Milestone: ---

Created attachment 54883
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54883=edit
The source file which shows issue.

Good day!

First of all, thanks alot for you efforts to create so nice compiler! It is
really nice: generates small and fast code!

But looks like I found an issue: the compiler does not generate a 'return
point' where the function is declared with not-void return parameter, but no
'return' operators in its body.

Details:
  *** 1) Operation system:
uname -a
Linux XVlad-Work 4.19.0-22-amd64 #1 SMP Debian 4.19.260-1 (2022-09-29) x86_64
GNU/Linux
  *** 2) Compiler version (according to https://gcc.godbolt.org/ issue
reproduces from 8.3.0 till the latest (12.+)):
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6) 

  *** 3) Command line to compile:
gcc -O3 ./SandBox_2.cpp
  *** 4) Command line to execute:
./a.out 0

Observations:
Please, look at the code in the attached file: 
 - when it is compiled as:
/GccBug$ gcc -O0 ./SandBox_2.cpp
 - program executes correctly:
/GccBug$ ./a.out 0
Hello world from SandBox-2!
8.3.0
Point-A 0, 0
 - *BUT* when it is compiled as:
/GccBug$ gcc -O3 ./SandBox_2.cpp
 - program crashes:
/GccBug$ ./a.out 0
Hello world from SandBox-2!
8.3.0
Point-A 0, 0
Point-B 1, 0
Segmentation fault<<

[Bug c/109553] New: Atomic operations vs const locations

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

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

Bug ID: 109553
   Summary: Atomic operations vs const locations
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---

When reasoning about optimal sequences for atomic operations for various
targets the issue of read-only memory locations keeps coming up, particularly
when talking about doing non-native larger-sized accesses locklessly

I wonder if the frontends in GCC should be more assertive with warnings on such
constructs. Consider, for example:
#include 

uint32_t
load_uint32_t (const uint32_t *a)
{
  return __atomic_load_n (a, __ATOMIC_ACQUIRE);
}

void
casa_uint32_t (const uint32_t *a, uint32_t *b, uint32_t *c)
{
  __atomic_compare_exchange_n (a, b, 3, 0, __ATOMIC_ACQUIRE, __ATOMIC_ACQUIRE);
}

Both of these functions compile fine with GCC.
With Clang casa_uint32_t  gives a hard error:
error: address argument to atomic operation must be a pointer to non-const type
('const uint32_t *' (aka 'const unsigned int *') invalid)
  __atomic_compare_exchange_n (a, b, 3, 0, __ATOMIC_ACQUIRE, __ATOMIC_ACQUIRE);

I would argue that for both cases the compiler should emit something. I think
an error is a appropriate for the __atomic_compare_exchange_n case, but even
for atomic load we may want to hint to the user to avoid doing an atomic load
from const types.

[Bug middle-end/109552] New: ICE with "cancel" directive in "taskloop" construct

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

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

Bug ID: 109552
   Summary: ICE with "cancel" directive in "taskloop" construct
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: frederik at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54882
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54882=edit
C version of the test

The following Fortran code produces an ICE in the middle-end when I compile it
as a libgomp test (i.e. with -fopenmp; same error at different optimization
levels):

program test
  integer :: a
  integer :: i

  !$omp parallel
  !$omp taskloop
   do i = 1,10
 !$omp cancel taskgroup if (a .eq. 1)
 call abort ()
  end do
  !$omp end taskloop
  !$omp end parallel
end program

Error:

FAIL: libgomp.fortran/cancel-taskloop.f90   -O  (test for excess errors)
Excess errors:
during GIMPLE pass: ompexp
../../../../libgomp/testsuite/libgomp.fortran/cancel-taskloop.f90:6:16:
internal compiler error: in verify_sese, at tree-cfg.cc:7654
0x7c0878 verify_sese(basic_block_def*, basic_block_def*, vec*)
../../gcc/tree-cfg.cc:7654
0x14d4958 move_sese_region_to_fn(function*, basic_block_def*, basic_block_def*,
tree_node*)
../../gcc/tree-cfg.cc:7770
0x2606968 expand_omp_taskreg
../../gcc/omp-expand.cc:1444
0x260ca3f expand_omp_synch
../../gcc/omp-expand.cc:8659
0x260ca3f expand_omp
../../gcc/omp-expand.cc:10616
0x260c77c expand_omp
../../gcc/omp-expand.cc:10565
0x260c77c expand_omp
../../gcc/omp-expand.cc:10565
0x260e9fa execute_expand_omp
../../gcc/omp-expand.cc:10819

A canonical conversion of the test to C/C++ leads to the same error from
gcc/g++.

I am not sure if the code is valid according to the OpenMP spec, but the ICE is
certainly wrong.

The GCC build has been configured with "--enable-languages=fortran,c,c++
--enable-checking=all --disable-multilib --disable-bootstrap" and the version
is
"gcc version 14.0.0 20230419 (experimental) (GCC)".

[Bug target/109465] LoongArch: The expansion of memcpy is slow and bloated for some sizes

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

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

Xi Ruoyao  changed:

   What|Removed |Added

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

--- Comment #3 from Xi Ruoyao  ---
Fixed for GCC 14.  Not suitable for backporting.

[Bug target/109465] LoongArch: The expansion of memcpy is slow and bloated for some sizes

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Xi Ruoyao :

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

commit r14-70-g6d7e0bcfa49e4ddc84dabe520bba8a023bc52692
Author: Xi Ruoyao 
Date:   Wed Apr 12 11:45:48 2023 +

LoongArch: Improve cpymemsi expansion [PR109465]

We'd been generating really bad block move sequences which is recently
complained by kernel developers who tried __builtin_memcpy.  To improve
it:

1. Take the advantage of -mno-strict-align.  When it is set, set mode
   size to UNITS_PER_WORD regardless of the alignment.
2. Half the mode size when (block size) % (mode size) != 0, instead of
   falling back to ld.bu/st.b at once.
3. Limit the length of block move sequence considering the number of
   instructions, not the size of block.  When -mstrict-align is set and
   the block is not aligned, the old size limit for straight-line
   implementation (64 bytes) was definitely too large (we don't have 64
   registers anyway).

Change since v1: add a comment about the calculation of num_reg.

gcc/ChangeLog:

PR target/109465
* config/loongarch/loongarch-protos.h
(loongarch_expand_block_move): Add a parameter as alignment RTX.
* config/loongarch/loongarch.h:
(LARCH_MAX_MOVE_BYTES_PER_LOOP_ITER): Remove.
(LARCH_MAX_MOVE_BYTES_STRAIGHT): Remove.
(LARCH_MAX_MOVE_OPS_PER_LOOP_ITER): Define.
(LARCH_MAX_MOVE_OPS_STRAIGHT): Define.
(MOVE_RATIO): Use LARCH_MAX_MOVE_OPS_PER_LOOP_ITER instead of
LARCH_MAX_MOVE_BYTES_PER_LOOP_ITER.
* config/loongarch/loongarch.cc (loongarch_expand_block_move):
Take the alignment from the parameter, but set it to
UNITS_PER_WORD if !TARGET_STRICT_ALIGN.  Limit the length of
straight-line implementation with LARCH_MAX_MOVE_OPS_STRAIGHT
instead of LARCH_MAX_MOVE_BYTES_STRAIGHT.
(loongarch_block_move_straight): When there are left-over bytes,
half the mode size instead of falling back to byte mode at once.
(loongarch_block_move_loop): Limit the length of loop body with
LARCH_MAX_MOVE_OPS_PER_LOOP_ITER instead of
LARCH_MAX_MOVE_BYTES_PER_LOOP_ITER.
* config/loongarch/loongarch.md (cpymemsi): Pass the alignment
to loongarch_expand_block_move.

gcc/testsuite/ChangeLog:

PR target/109465
* gcc.target/loongarch/pr109465-1.c: New test.
* gcc.target/loongarch/pr109465-2.c: New test.
* gcc.target/loongarch/pr109465-3.c: New test.

[Bug c++/109548] Detect c_str() dangling problems

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
David possibly has inputs on how this should be done so the analyzer can do
this kind of diagnostic.  Generally I'd say we want sth like

 T * __attribute__ ((return_lifetime(1))) foo (U *p, ...);

where we specify the lifetime of the returned referenced object to be
the same as a referenced object in the argument list?  So yes, the
[[gnu::lifetime(this)]] attribution would maybe do that but can
the attribute refer to another explicitely named argument as well?

Btw, is there an API to std::move the (possibly) allocated string out of
the std::string and make it available as C string pointer?

[Bug fortran/100815] [10/11 Regression] Segfault assigning to scalar allocatable polymorphic LHS since r11-6253-gce8dcc9105cbd404

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

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

Martin Liška  changed:

   What|Removed |Added

Summary|[10/11/12/13/14 Regression] |[10/11 Regression] Segfault
   |Segfault assigning to   |assigning to scalar
   |scalar allocatable  |allocatable polymorphic LHS
   |polymorphic LHS since   |since
   |r11-6253-gce8dcc9105cbd404  |r11-6253-gce8dcc9105cbd404

--- Comment #5 from Martin Liška  ---
It's fixed on master with r12-3897-g00f6de9c691195.

[Bug debug/109237] csmith: another timeout with -g -O3 this time since r12-156-g8d4c374c4419a875

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

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

--- Comment #15 from Richard Biener  ---
Spread pretty evenly now.  Everything >= 5%

 tree CFG cleanup   :   5.25 (  8%)   0.00 (  0%)   5.27 (  7%)
   89k (  0%)
 expand :   3.22 (  5%)   0.18 (  2%)   3.41 (  4%)
 2177M ( 31%)
 scheduling 2   :   6.93 ( 10%)   1.37 ( 18%)   8.29 ( 11%)
  746M ( 11%)
 TOTAL  :  69.08  7.60 76.70   
 6951M

and the profile is

Samples: 287K of event 'cycles:u', Event count (approx.): 376155371739  
Overhead   Samples  Command  Shared Object Symbol   
   3.02%  8226  cc1  cc1   [.] init_alias_analysis
   3.02%  8300  cc1  cc1   [.] df_note_compute
   2.65%  7299  cc1  cc1   [.]
contains_no_active_insn_p
   2.53%  7016  cc1  cc1   [.]
delete_trivially_dead_insns
   2.15%  6150  cc1  cc1   [.] get_ref_base_and_extent
   1.92%  5443  cc1  cc1   [.] ggc_set_mark
   1.58%  4291  cc1  cc1   [.] fast_dce
   1.58%  4348  cc1  cc1   [.]
gimple_purge_dead_eh_edges
   1.53%  4141  cc1  cc1   [.] delete_unmarked_insns
   1.52%  4146  cc1  cc1   [.] prescan_insns_for_dce
   1.40%  3841  cc1  cc1   [.] cleanup_control_flow_bb
   1.28%  3467  cc1  cc1   [.] rebuild_jump_labels_1
   1.16%  3176  cc1  cc1   [.] df_live_bb_local_compute
   1.13%  3114  cc1  cc1   [.] gimple_merge_blocks
   1.09%  2977  cc1  cc1   [.] df_lr_bb_local_compute
   1.05%  2962  cc1  cc1   [.] (anonymous
namespace)::pass_rtl_cprop::execute
   1.03%  2988  cc1  cc1   [.] for_each_inc_dec
   1.01%  3168  cc1  cc1   [.] walk_tree_1
   0.87%  2790  cc1  cc1   [.] ggc_internal_alloc

[Bug fortran/103366] [10/11/12/13/14 Regression] ICE in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.c:5647

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

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

Paul Thomas  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|10.5|12.3

--- Comment #12 from Paul Thomas  ---
(In reply to anlauf from comment #11)
> (In reply to CVS Commits from comment #8)
> > The master branch has been updated by Paul Thomas :
> > 
> > https://gcc.gnu.org/g:828474fafd2ed33430172fe227f9da7d6fb98723
> > 
> > commit r12-6419-g828474fafd2ed33430172fe227f9da7d6fb98723
> 
> This patch is installed for 12-branch and 13-trunk.  The surrounding code
> was added during 12 development, so a backport would not be possible.
> 
> Can we mark this fixed for 12/13?
> 
> Does it still occur in 10/11?
> 
> Should we set the target milestone to 12.2 and close this PR?

It still occurs in 10-/11-branches. However, as you say, a backport will be
"slightly impossible".

Closing as fixed.

Paul

[Bug tree-optimization/109011] missed optimization in presence of __builtin_ctz

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

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

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

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

commit r14-65-gade0a1ee5c6707b950ba284adcfed0514866c12d
Author: Jakub Jelinek 
Date:   Wed Apr 19 11:14:23 2023 +0200

tree-vect-patterns: Improve __builtin_{clz,ctz,ffs}ll vectorization
[PR109011]

For __builtin_popcountll tree-vect-patterns.cc has
vect_recog_popcount_pattern, which improves the vectorized code.
Without that the vectorization is always multi-type vectorization
in the loop (at least int and long long types) where we emit two
.POPCOUNT calls with long long arguments and int return value and then
widen to long long, so effectively after vectorization do the
V?DImode -> V?DImode popcount twice, then pack the result into V?SImode
and immediately unpack.

The following patch extends that handling to __builtin_{clz,ctz,ffs}ll
builtins as well (as long as there is an optab for them; more to come
laster).

x86 can do __builtin_popcountll with -mavx512vpopcntdq, __builtin_clzll
with -mavx512cd, ppc can do __builtin_popcountll and __builtin_clzll
with -mpower8-vector and __builtin_ctzll with -mpower9-vector, s390
can do __builtin_{popcount,clz,ctz}ll with -march=z13 -mzarch (i.e. VX).

2023-04-19  Jakub Jelinek  

PR tree-optimization/109011
* tree-vect-patterns.cc (vect_recog_popcount_pattern): Rename to
...
(vect_recog_popcount_clz_ctz_ffs_pattern): ... this.  Handle also
CLZ, CTZ and FFS.  Remove vargs variable, use
gimple_build_call_internal rather than
gimple_build_call_internal_vec.
(vect_vect_recog_func_ptrs): Adjust popcount entry.

* gcc.dg/vect/pr109011-1.c: New test.

[Bug target/109040] [13 Regression] wrong code with v16hi compare & mask on riscv64 at -O2 since r13-4907-g2e886eef7f2b5a

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

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

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

https://gcc.gnu.org/g:76f44fbfea1f11e53d4b7e83f0debd029c94a1b3

commit r14-64-g76f44fbfea1f11e53d4b7e83f0debd029c94a1b3
Author: Jakub Jelinek 
Date:   Wed Apr 19 11:13:11 2023 +0200

dse: Use SUBREG_REG for copy_to_mode_reg in DSE replace_read for
WORD_REGISTER_OPERATIONS targets [PR109040]

While we've agreed this is not the right fix for the PR109040 bug,
the patch clearly improves generated code (at least on the testcase from
the
PR), so I'd like to propose this as optimization heuristics improvement
for GCC 14.

2023-04-19  Jakub Jelinek  

PR target/109040
* dse.cc (replace_read): If read_reg is a SUBREG of a word mode
REG, for WORD_REGISTER_OPERATIONS copy SUBREG_REG of it into
a new REG rather than the SUBREG.

[Bug fortran/100815] [10/11/12/13/14 Regression] Segfault assigning to scalar allocatable polymorphic LHS since r11-6253-gce8dcc9105cbd404

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

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

--- Comment #4 from Paul Thomas  ---
Hi Martin,

This is fixed in 12-branch onwards.

I have not been able to find the fix - could you find it, please? I tried
comparing the diff in comment #2 with the current head but the differences in
the affected code didn't do the job.

Cheers

Paul