[Bug target/106060] Inefficient constant broadcast on x86_64

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #1 from Hongtao.liu  ---
I remember it's on purpose by r12-1958-gedafb35bdadf30, related PR100865.

[Bug tree-optimization/106025] [13 Regression] Incorrect optimization at -O2 leads to infinite test execution time since r13-469-g9a53101caadae1b5

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

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

--- Comment #4 from Richard Biener  ---
It looks like the pattern just exposes an existing issue. 
-fdbg-cnt=match:0-104 breaks while -fdbg-cnt=match:0-103 is OK but the MAX
generation for this looks correct.

Disabling VRP fixes it but avoids the MAX generation as we end up with

 if (_22 < _33)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  _36 = (short int) _22;
  # RANGE [-32768, 32767]
  _38 = (int) _36;

   [local count: 1073741824]:
  # RANGE [-32768, 32767]
  # prephitmp_39 = PHI <_1(6), _38(7)>

_22 is indeed small.  We recognize ushortA < ushortB ? (int)ushortB :
(int)ushortA as (int)MAX (ushortA, ushortB)

Not sure what goes wrong here.

[Bug rust/105913] gccrs doesn't compile on 32-bit targets

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

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

Rainer Orth  changed:

   What|Removed |Added

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

--- Comment #6 from Rainer Orth  ---
Unfortunately, after I created my original patch, another instance of the same
issue crept in: reported upstream with an incremental patch.

[Bug c++/106057] Missed stmt_can_throw_external check in stmt_kills_ref_p

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

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

--- Comment #2 from Jan Hubicka  ---
The second testcase (with longjmp) invalid since longjmp can clobber automatic
variable and making the variable static breaks the testcase since we believe
htat longjmp reads global memory state (it doesn't).

The first testcase is also kind-of bordeline since it is question whether
const/pure can throw.

Performance wise we probably do not need to care about longjmp but with
cxa_throw we may want to get side effects modeled right...

[Bug c++/105885] [12/13 Regression] the address of 'template argument' will never be NULL warning

[info--- via Gcc-bugs]

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

--- Comment #3 from Markus Ebner  ---
> I guess reporters reasoning is that ARG is defaulted to nullptr and that's 
> the reason the diagnostic is unwanted?

I don't think it has any todo with whether nullptr is the default value for ARG
or not. Even if it's not the default value, it is a valid one the API's user
might explicitly pass to ARG.

My point rather is that, at least the way I understood it, `if constexpr` is
meant to implement conditional behavior based on a template argument. And it is
obvious that one of the if-branches is going to be comparing ARG to whatever
was passed in for it. So the compiler warning about this didn't make much sense
for me here.
Of course I could use template specialization to get rid of the warning, but
what if the function body is very long and only a tiny fraction of it needs
special handling for ARG? Then I would be copying the function body multiple
times for all specializations.

[Bug ipa/105600] [10/11/12 Regression] ICE with LTO when building Mumble

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

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

--- Comment #18 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Martin Liska
:

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

commit r12-8509-gc600ff8dc5a870d952c9c63fe4fa4535b9f0a488
Author: Martin Liska 
Date:   Wed May 18 15:07:53 2022 +0200

ipa-icf: skip variables with body_removed

Similarly to cgraph_nodes, it may happen that body_removed is set
during merging of symbols.

PR ipa/105600

gcc/ChangeLog:

* ipa-icf.cc (sem_item_optimizer::filter_removed_items):
Skip variables with body_removed.

(cherry picked from commit 31ce821a790caec8a2849dd67a9847e78a33d14c)

[Bug ipa/105600] [10/11/12 Regression] ICE with LTO when building Mumble

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

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

--- Comment #19 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Martin Liska
:

https://gcc.gnu.org/g:3f1637f8b17ded9e08841abc1182dcde0e35e660

commit r11-10089-g3f1637f8b17ded9e08841abc1182dcde0e35e660
Author: Martin Liska 
Date:   Wed May 18 15:07:53 2022 +0200

ipa-icf: skip variables with body_removed

Similarly to cgraph_nodes, it may happen that body_removed is set
during merging of symbols.

PR ipa/105600

gcc/ChangeLog:

* ipa-icf.c (sem_item_optimizer::filter_removed_items):
Skip variables with body_removed.

(cherry picked from commit 31ce821a790caec8a2849dd67a9847e78a33d14c)

[Bug ipa/105600] [10/11/12 Regression] ICE with LTO when building Mumble

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #20 from Martin Liška  ---
Fixed on gcc-11 and gcc-12 branches, skipping gcc-10 branch.

[Bug c++/106062] [13 Regression] ICE in build_builtin_unreachable since r13-1204-gd68d366425369649

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Patch preapproved.

[Bug tree-optimization/106064] New: Wrong code comparing two global zero-sized arrays

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

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

Bug ID: 106064
   Summary: Wrong code comparing two global zero-sized arrays
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: acoplan at gcc dot gnu.org
  Target Milestone: ---

For the following C code:

int a[0] = {};
int b[0] = {};
int f(void)
{
return a != b;
}
int g(void)
{
return (__UINTPTR_TYPE__)a != (__UINTPTR_TYPE__)b;
}

on AArch64 at -O2, we generate:

f:
mov w0, 1
ret
g:
mov w0, 0
ret

so f and g get optimized in contradictory ways. At least one of them must be
wrong.

[Bug c++/106062] [13 Regression] ICE in build_builtin_unreachable since r13-1204-gd68d366425369649

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

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

Martin Liška  changed:

   What|Removed |Added

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

[Bug c++/106062] [13 Regression] ICE in build_builtin_unreachable since r13-1204-gd68d366425369649

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r13-1217-g8a15cd3396aa08dc2633982481fe392af0aa9e78
Author: Martin Liska 
Date:   Thu Jun 23 14:43:50 2022 +0200

c++: properly initialize UBSAN built-ins

PR c++/106062

gcc/ChangeLog:

* ubsan.cc (sanitize_unreachable_fn): Change order of calls
in order to initialize UBSAN built-ins.

gcc/testsuite/ChangeLog:

* gfortran.dg/ubsan/pr106062.f90: New test.

[Bug c++/106062] [13 Regression] ICE in build_builtin_unreachable since r13-1204-gd68d366425369649

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed.

[Bug fortran/106065] New: Crash when reading extended derived type array in namelist

[philippe.wautelet at aero dot obs-mip.fr via Gcc-bugs]

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

Bug ID: 106065
   Summary: Crash when reading extended derived type array in
namelist
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: philippe.wautelet at aero dot obs-mip.fr
  Target Milestone: ---

Created attachment 53195
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53195&action=edit
Reproducer

I get a crash when using an array of extended derived types.
If I define an other type containing the same information but not extended, the
problem disappears.

See the attached source:
> gfortran type_extends_nml.f90 ;./a.out

&NAM_BAL_NE
 DATE_TIME_NE(1)%NYEAR=   2022,
 DATE_TIME_NE(1)%NMONTH=  0,
 DATE_TIME_NE(1)%NDAY=  0,
 DATE_TIME_NE(1)%XTIME=  0.,
 DATE_TIME_NE(2)%NYEAR=  0,
 DATE_TIME_NE(2)%NMONTH=  0,
 DATE_TIME_NE(2)%NDAY=  0,
 DATE_TIME_NE(2)%XTIME=  1.2337,
 /
At line 36 of file type_extends_nml.f90
Fortran runtime error: Cannot match namelist object name 2022

I tested with several versions of gfortran from version 5.5.0 to 12.1.0. All
failed.

[Bug testsuite/106059] [13 regression] cc.dg/vect/pr79347.c fails after r13-1171-g9f55aee9dca759

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

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

--- Comment #1 from Segher Boessenkool  ---
Well, this patch should not have changed behaviour at all!

[Bug tree-optimization/106063] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O2 -fno-tree-forwprop --param=evrp-mode=legacy-first

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #1 from Andrew Macleod  ---
That option enables legacy EVRP, and will be going away soon.  however, looking
at the IL, the difference out of EVRP is that legacy doesnt touch the code. The
IL is:

  vector(1) __int128 _1;
  vector(1)  _2;
  V _4;

   :
  _1 = v_3(D) & { 15 };
  _2 = v_3(D) == _1;
  _4 = VEC_COND_EXPR <_2, { -1 }, { 0 }>;
  return _4;


Ranger ends up triggering a simplification :

Folding statement: _2 = v_3(D) == _1;
gimple_simplified to _6 = v_3(D) & { -16 };
_2 = _6 == { 0 };
Folded into: _2 = _6 == { 0 };

producing:

_1 = v_3(D) & { 15 };
_6 = v_3(D) & { -16 };
_2 = _6 == { 0 };
_4 = VEC_COND_EXPR <_2, { -1 }, { 0 }>;
return _4;

Which ends up not causing the ICE seen in this PR.

However, if we completely disable EVRP, we also get the trap.

   -O2 -fno-tree-forwprop --disable-tree-evrp

So it would seem the problem probably lies with vector expansion?

[Bug c++/105885] [12/13 Regression] the address of 'template argument' will never be NULL warning

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

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

commit r13-1218-g6e4d5300c1f62c3f0cd1bf859b0ee6bb4e31e434
Author: Jason Merrill 
Date:   Wed Jun 22 23:50:23 2022 -0400

c++: -Waddress and value-dependent expr [PR105885]

We already suppress various warnings for code that would be tautological if
written directly, but not when it's the result of template substitution. 
It
seems we need to do this for -Waddress as well.

PR c++/105885

gcc/cp/ChangeLog:

* pt.cc (tsubst_copy_and_build): Also suppress -Waddress for
comparison of dependent operands.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/constexpr-if37.C: New test.

[Bug c++/94554] spurious -Waddress warning within "if constexpr" function-null compares

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:124a9e08b7a83795bd4d09001955f0eef68ecd00

commit r13-1219-g124a9e08b7a83795bd4d09001955f0eef68ecd00
Author: Jason Merrill 
Date:   Thu Jun 23 00:24:22 2022 -0400

c++: -Waddress and if constexpr [PR94554]

Like we avoid various warnings for seemingly tautological expressions when
substituting a template, we should avoid warning for the implicit
conversion
to bool in an if statement.  I considered also doing this for the
conditions
in loop expressions, but that seems unnecessary, as a loop condition is
unlikely to be a constant.

The change to finish_if_stmt_cond isn't necessary since dependent_operand_p
looks through IMPLICIT_CONV_EXPR, but makes it more constent with
e.g. build_x_binary_op that determines the type of an expression and then
builds it using the original operands.

PR c++/94554

gcc/cp/ChangeLog:

* pt.cc (dependent_operand_p): Split out from...
(tsubst_copy_and_build): ...here.
(tsubst_expr) [IF_STMT]: Use it.
* semantics.cc (finish_if_stmt_cond): Keep the pre-conversion
condition in the template tree.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/constexpr-if38.C: New test.

[Bug analyzer/105890] RFE: -fanalyzer should complain about mkstemp with not enough "X"s in format string

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

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

--- Comment #2 from David Malcolm  ---
  https://pubs.opengroup.org/onlinepubs/009604499/functions/mkstemp.html says:
"The string in template should look like a filename with six trailing 'X's"


https://pubs.opengroup.org/onlinepubs/9699919799/functions/mkstemp.html says:
"The application shall ensure that the string provided in template is a
pathname ending with at least six trailing 'X' characters."

[Bug fortran/105807] ICE / error when defining a class containing polymorphic components

[gscfq--- via Gcc-bugs]

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

--- Comment #3 from G. Steinmetz  ---

One tick simpler, without vect3d :

$ cat z3.f90
program p
type t
end type
type t2
class(t), allocatable :: v
end type
type, extends(t2) :: elem2d
end type
type(t) :: b
class(t2), allocatable :: e
e = elem2d(b)
end program


No ICE when b is replaced by constructor t() :

$ cat z5.f90
program p
type t
end type
type t2
class(t), allocatable :: v
end type
type, extends(t2) :: elem2d
end type
class(t2), allocatable :: e
e = elem2d(t())
end program

[Bug fortran/106047] ICE in structure_alloc_comps, at fortran/trans-array.cc:9574

[gscfq--- via Gcc-bugs]

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

--- Comment #2 from G. Steinmetz  ---

Hmm, exploring some more test cases;
z2 gives same ICE, z3 prints 128, z4 gives an error, z5 is ok/works :

$ cat z2.f90
program p
   type t
  character(:), allocatable :: c
   end type
   type(t) :: x ! without = t()
   integer, parameter :: n = storage_size(x)
end

$ cat z3.f90
program p
   type t
  character(:), allocatable :: c
   end type
   type(t), parameter :: x = t()   ! that is t(null())
   integer :: n = storage_size(x)
   print *, n
end

$ cat z4.f90
program p
   type t
  character(:), allocatable :: c
   end type
   type(t), parameter :: x = t('abc')   ! instead of t(null())
   integer :: n = storage_size(x)
   print *, n
end

$ cat z5.f90
program p
   type t
  character(:), allocatable :: c
   end type
   type(t) :: x 
   integer :: n
   n = storage_size(x)
   print *, n
end

---

Some examples without "type" :

$ cat zz1.f90
program p
   character(:), allocatable :: c
   integer :: n = storage_size(c)
   print *, n
end

$ cat zz2.f90
program p
   character(:), allocatable :: c
   integer, parameter :: n = storage_size(c)
   print *, n
end

$ cat zz3.f90
program p
   character(:), allocatable :: c
   print *, storage_size(c)
end


$ gfortran-13-20220619 -c zz1.f90
zz1.f90:3:31:

3 |integer :: n = storage_size(c)
  |   1
Error: Parameter 'c' at (1) has not been declared or is a variable, which does
not reduce to a constant expression
$
$ gfortran-13-20220619 -c zz2.f90
zz2.f90:3:42:

3 |integer, parameter :: n = storage_size(c)
  |  1
Error: Parameter 'c' at (1) has not been declared or is a variable, which does
not reduce to a constant expression
$
$ gfortran-13-20220619 zz3.f90 ; a.out
   0
$

Via Compiler Explorer :
Latest ifort/ifx indeed compiles z1/2/3/5, rejects z4 with an error (ok).
Latest ifort/ifx rejects zz1/zz2 with an error, accepts zz3 and prints 0.

[Bug c++/105925] [11/12/13 Regression] Could not convert '{{0, 0.0}}' from '' to 'X' since r12-954-g84fd1b5dff70cd74

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/94554] spurious -Waddress warning within "if constexpr" function-null compares

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed for GCC 13.

[Bug c/103360] [meta-bug] bogus/missing -Waddress

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

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

Bug 94554 Summary: spurious -Waddress warning within "if constexpr" 
function-null compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94554

   What|Removed |Added

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

[Bug c++/105885] [12/13 Regression] the address of 'template argument' will never be NULL warning

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

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

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

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

commit r12-8510-gb96b64bec37c3dddf1f0f93c27ceb4fd5685c70a
Author: Jason Merrill 
Date:   Wed Jun 22 23:50:23 2022 -0400

c++: -Waddress and value-dependent expr [PR105885]

We already suppress various warnings for code that would be tautological if
written directly, but not when it's the result of template substitution. 
It
seems we need to do this for -Waddress as well.

PR c++/105885

gcc/cp/ChangeLog:

* pt.cc (tsubst_copy_and_build): Also suppress -Waddress for
comparison of dependent operands.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/constexpr-if37.C: New test.

[Bug target/106060] Inefficient constant broadcast on x86_64

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

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

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

This generates:

 :
   0:   b8 7b 00 00 00  mov$0x7b,%eax
   5:   c5 f9 6e c0 vmovd  %eax,%xmm0
   9:   c4 e2 7d 78 c0  vpbroadcastb %xmm0,%ymm0
   e:   c3  ret
   f:   90  nop

0010 :
  10:   b8 01 00 00 00  mov$0x1,%eax
  15:   c5 f9 6e c0 vmovd  %eax,%xmm0
  19:   c4 e2 7d 78 c0  vpbroadcastb %xmm0,%ymm0
  1e:   c3  ret
  1f:   90  nop

0020 :
  20:   b8 fe ff ff ff  mov$0xfffe,%eax
  25:   c5 f9 6e c0 vmovd  %eax,%xmm0
  29:   c4 e2 7d 78 c0  vpbroadcastb %xmm0,%ymm0
  2e:   c3  ret

[Bug c++/105885] [12/13 Regression] the address of 'template argument' will never be NULL warning

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed for 12.2/13.

[Bug c++/105593] avx512 math function raises uninitialized variable warning

[rogerio.souza at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Rogério de Souza Moraes  ---
I got another example with similar warning:

#

#include 
//#pragma GCC diagnostic push
//#pragma GCC diagnostic ignored "-Wmaybe-uninitialized"
#include 
//#pragma GCC diagnostic pop
#include 

namespace sysOs
{
  std::regex rgxVer("ABC");
}

int main()
{
  return 0;
}

###

The code above is available at https://godbolt.org/z/chsjPKE33. 

Compiled with:

gcc -c -fPIC -Werror -std=c++2a  -Wno-unused -O -Wall

it returns the warning:

/opt/compiler-explorer/gcc-12.1.0/include/c++/12.1.0/bits/std_function.h:405:42:
error: '*(std::function*)((char*)&__tmp +
offsetof(std::__detail::_StateT,
std::__detail::_State::.std::__detail::_State_base::)).std::function::_M_invoker'
may be used uninitialized [-Werror=maybe-uninitialized]
  405 |   : _Function_base(), _M_invoker(__x._M_invoker)
  |  ^~


Would it be related with the same issue reported here? This example does not
raise the warning on GCC 11.3.

Regards,
--
Rogerio

[Bug tree-optimization/106064] Wrong code comparing two global zero-sized arrays

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||ktkachov at gcc dot gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
This seems to have changed in the GCC 9 series. GCC 8.5 generates:
f():
mov w0, 1
ret
g():
mov w0, 1
ret
b:
a:

Tagging as a claimed wrong-code bug.

[Bug testsuite/106059] [13 regression] cc.dg/vect/pr79347.c fails after r13-1171-g9f55aee9dca759

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

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug c++/99963] [11 Regression] [concepts] template vs concept auto reports ambiguous overload

[tabloid.adroit at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Yuanfang Chen  ---
(In reply to Yuanfang Chen from comment #4)
> (In reply to Patrick Palka from comment #1)
> > Started with r11-1571.  Reduced testcase that replaces the abbreviated
> > function templates with their corresponding non-abbreviated forms:
> > 
> > template  concept C1 = true;
> > template  concept C2 = C1 && true;
> > 
> > template  int f(T, U);
> > template  int f(U, T);
> > 
> > int x = f(0, 0); // error: ambiguous call
> > 
> > 
> > If I understand the wording of P2113 correctly:
> > 
> >   If deduction against the other template succeeds for both transformed
> > templates, constraints can be considered as follows:
> >   - ... if the corresponding template-parameters of the
> > template-parameter-lists are not equivalent ([temp.over.link]) or if the
> > function parameters that positionally correspond between the two templates
> > are not of the same type, neither template is more specialized than the 
> > other
> > 
> > then I think we're correct to reject the call as ambiguous because although
> > the second overload is more constrained than the first, their function
> > parameter lists aren't equivalent.
> 
> IMHO, `template  int f(U, T);` should win over `template  C1 U> int f(T, U);`.
> 
> Based on interpreting the intent mentioned in
> https://github.com/cplusplus/nbballot/issues/119 and the second example in
> https://eel.is/c++draft/temp.fct#temp.func.order-example-6, the
> `corresponding` (of the `corresponding template-parameters of ...`)
> relationship is based on the mapping used during partial-ordering deduction.
> So the deduction between `f(T, ..)` against `f(U, ..)` builds the 
> mapping, the deduction between `f(.., U)` against `f(.., T)` builds the  T> mapping. The correspondence is [T, U] against [U, T]. So `C1 T` is less
> constrained than `C2 U`, thus the second `f` wins.

Sorry. I spoke too soon. Template parameters reordering is not allowed for the
test case. The call is indeed ambiguous.

[Bug analyzer/106066] New: crash dump when "-fdump-analyzer" enabled

[chipitsine at gmail dot com via Gcc-bugs]

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

Bug ID: 106066
   Summary: crash dump when "-fdump-analyzer" enabled
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: chipitsine at gmail dot com
  Target Milestone: ---

reproduce steps (using latest gcc13 from git):


git clone https://github.com/haproxy/haproxy
cd haproxy

export CC=/path/to/latest/gcc13
export ADDITIONAL_CFLAGS="-fanalyzer -fdump-analyzer"


QUICTLS=yes scripts/build-ssl.sh
make -j3 CC=$CC V=1 ERR=1 TARGET=linux-glibc USE_OPENSSL=1 USE_QUIC=1
USE_ZLIB=1 USE_PCRE=1 USE_PCRE_JIT=1 USE_LUA=1 USE_SYSTEMD=1
ADDLIB="-Wl,-rpath,${HOME}/opt/lib" SSL_LIB=${HOME}/opt/lib
SSL_INC=${HOME}/opt/include DEBUG_CFLAGS="-g ${ADDITIONAL_CFLAGS}"




stacktrace:

during IPA pass: analyzer
src/ev_epoll.c: In function ‘_do_poll’:
src/ev_epoll.c:239:55: internal compiler error: Segmentation fault
  239 | ((e & EPOLLERR)   ? FD_EV_ERR_RW  : 0);
  | ~~^~~~
0xf3ec3f crash_signal
/home/ilia/gcc/gcc-master/gcc/toplev.cc:322
0x101a64c tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
/home/ilia/gcc/gcc-master/gcc/tree.h:3638
0x101a64c dump_mem_ref
/home/ilia/gcc/gcc-master/gcc/tree-pretty-print.cc:1700
0x100ff3f dump_generic_node(pretty_printer*, tree_node*, int, dump_flag, bool)
/home/ilia/gcc/gcc-master/gcc/tree-pretty-print.cc:2061
0x1011554 dump_generic_node(pretty_printer*, tree_node*, int, dump_flag, bool)
/home/ilia/gcc/gcc-master/gcc/tree-pretty-print.cc:2425
0x1014d46 dump_generic_node(pretty_printer*, tree_node*, int, dump_flag, bool)
/home/ilia/gcc/gcc-master/gcc/tree-pretty-print.cc:2910
0x12faef9 ana::dump_tree(pretty_printer*, tree_node*)
/home/ilia/gcc/gcc-master/gcc/analyzer/region-model.cc:87
0x12faef9 ana::dump_quoted_tree(pretty_printer*, tree_node*)
/home/ilia/gcc/gcc-master/gcc/analyzer/region-model.cc:97
0x12ed6f9 ana::sm_state_map::print(ana::region_model const*, bool, bool,
pretty_printer*) const
/home/ilia/gcc/gcc-master/gcc/analyzer/program-state.cc:242
0x12ef45e ana::program_state::dump_to_pp(ana::extrinsic_state const&, bool,
bool, pretty_printer*) const
/home/ilia/gcc/gcc-master/gcc/analyzer/program-state.cc:901
0x12f0283 ana::program_state::detect_leaks(ana::program_state const&,
ana::program_state const&, ana::svalue const*, ana::extrinsic_state const&,
ana::region_model_context*)
/home/ilia/gcc/gcc-master/gcc/analyzer/program-state.cc:1366
0x12f0986 ana::program_state::prune_for_point(ana::exploded_graph&,
ana::program_point const&, ana::exploded_node*, ana::uncertainty_t*) const
/home/ilia/gcc/gcc-master/gcc/analyzer/program-state.cc:1214
0x12de456 ana::exploded_graph::process_node(ana::exploded_node*)
/home/ilia/gcc/gcc-master/gcc/analyzer/engine.cc:3822
0x12df0fa ana::exploded_graph::process_worklist()
/home/ilia/gcc/gcc-master/gcc/analyzer/engine.cc:3240
0x12e1467 ana::impl_run_checkers(ana::logger*)
/home/ilia/gcc/gcc-master/gcc/analyzer/engine.cc:5832
0x12e2295 ana::run_checkers()
/home/ilia/gcc/gcc-master/gcc/analyzer/engine.cc:5906
0x12d1c48 execute
/home/ilia/gcc/gcc-master/gcc/analyzer/analyzer-pass.cc:87
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/106067] New: Error on implicit conversion to std::function: 'static constexpr bool std::_Function_handler<...>...' used before its definition

[e.tadeu at gmail dot com via Gcc-bugs]

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

Bug ID: 106067
   Summary: Error on implicit conversion to std::function: 'static
constexpr bool std::_Function_handler<...>...' used
before its definition
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: e.tadeu at gmail dot com
  Target Milestone: ---

The following code started failing on GCC 11.3 (also fails on GCC 12):

#include 

double fn();

template )>
void caller()
{
auto f = T(fn);
// auto f = T(std::function(fn));  // workaround (this works)
}


The snippet is also here: https://godbolt.org/z/zh7nr7vKc

The full error is:

In file included from
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/move.h:57,
 from
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/stl_function.h:60,
 from
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/functional:49,
 from :1:
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/type_traits: In
instantiation of 'struct std::is_trivially_copyable':
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h:69:12:
  required from 'struct std::__is_location_invariant'
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h:125:38:
  required from 'const bool std::_Function_base::_Base_manager::__stored_locally'
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h:130:8:
  required from 'class std::_Function_base::_Base_manager'
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h:260:11:
  required from 'class std::_Function_handler'
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h:436:65:
  required from 'std::function<_Res(_ArgTypes ...)>::function(_Functor&&) [with
_Functor = double (*)(); _Constraints = void; _Res = double; _ArgTypes = {}]'
:8:15:   required from here
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/type_traits:713:52: error:
non-constant condition for static assertion
  713 |  
static_assert(std::__is_complete_or_unbounded(__type_identity<_Tp>{}),
  |
~~~^~~~
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/type_traits:713:52: error:
'constexpr std::true_type
std::__is_complete_or_unbounded(std::__type_identity<_Tp>) [with _Tp = double
(*)(); long unsigned int  = 8; std::true_type =
std::integral_constant]' used before its definition
In file included from
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/functional:59,
 from :1:
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h: In
instantiation of 'std::function<_Res(_ArgTypes ...)>::function(_Functor&&)
[with _Functor = double (*)(); _Constraints = void; _Res = double; _ArgTypes =
{}]':
:8:15:   required from here
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h:436:72:
error: 'static constexpr bool std::_Function_handler<_Res(_ArgTypes ...),
_Functor>::_S_nothrow_init() [with _Fn = double (*)(); _Res = double; _Functor
= double (*)(); _ArgTypes = {}]' used before its definition
  436 | noexcept(_Handler<_Functor>::template
_S_nothrow_init<_Functor>())
  | 
~~^~
ASM generation compiler returned: 1
In file included from
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/move.h:57,
 from
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/stl_function.h:60,
 from
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/functional:49,
 from :1:
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/type_traits: In
instantiation of 'struct std::is_trivially_copyable':
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h:69:12:
  required from 'struct std::__is_location_invariant'
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h:125:38:
  required from 'const bool std::_Function_base::_Base_manager::__stored_locally'
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h:130:8:
  required from 'class std::_Function_base::_Base_manager'
   
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/bits/std_function.h:260:11:
  required from 'class std::_Function_handler'
   
/opt/compiler-explorer/gcc-11.3

[Bug analyzer/106066] crash dump when "-fdump-analyzer" enabled

[chipitsine at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Илья Шипицин  ---
another crash using "-fanalyzer-verbose-state-changes"

stacktrace


during IPA pass: analyzer
src/ssl_crtlist.c:523:17: internal compiler error: Segmentation fault
  523 | entry = crtlist_entry_new();
  | ^
0xf3ec3f crash_signal
/home/ilia/gcc/gcc-master/gcc/toplev.cc:322
0x950028 c_tree_printer
/home/ilia/gcc/gcc-master/gcc/c/c-objc-common.cc:305
0x1eea9ef pp_format(pretty_printer*, text_info*)
/home/ilia/gcc/gcc-master/gcc/pretty-print.cc:1475
0x1e65b58 make_label_text(bool, char const*, ...)
/home/ilia/gcc/gcc-master/gcc/analyzer/analyzer.cc:439
0x1e6afc0 ana::state_change_event::get_desc(bool) const
/home/ilia/gcc/gcc-master/gcc/analyzer/checker-path.cc:409
0x1e68232 ana::checker_event::prepare_for_emission(ana::checker_path*,
ana::pending_diagnostic*, diagnostic_event_id_t)
/home/ilia/gcc/gcc-master/gcc/analyzer/checker-path.cc:237
0x1e8622f ana::checker_path::prepare_for_emission(ana::pending_diagnostic*)
/home/ilia/gcc/gcc-master/gcc/analyzer/checker-path.h:652
0x1e8622f ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic const&)
/home/ilia/gcc/gcc-master/gcc/analyzer/diagnostic-manager.cc:1396
0x1e8a0d3 ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
/home/ilia/gcc/gcc-master/gcc/analyzer/diagnostic-manager.cc:1296
0x1e8677c ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
/home/ilia/gcc/gcc-master/gcc/analyzer/diagnostic-manager.cc:1348
0x12e148a ana::impl_run_checkers(ana::logger*)
/home/ilia/gcc/gcc-master/gcc/analyzer/engine.cc:5846
0x12e230e ana::run_checkers()
/home/ilia/gcc/gcc-master/gcc/analyzer/engine.cc:5906
0x12d1c48 execute
/home/ilia/gcc/gcc-master/gcc/analyzer/analyzer-pass.cc:87
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/106068] New: Infinite loop generated with -mcpu=cortex-m7 and -O2

[dflogeras2 at gmail dot com via Gcc-bugs]

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

Bug ID: 106068
   Summary: Infinite loop generated with -mcpu=cortex-m7 and -O2
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dflogeras2 at gmail dot com
  Target Milestone: ---

Created attachment 53197
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53197&action=edit
Preprocessed src to reproduce bug

We hit this suspected bug compiling an older firmware after recently upgrading
to a more recent version of GCC.  It can be triggered by 11.3.0, while the old
5.4.x version did not produce the infinite loop.

The code snippet is from a quite old version of LWIP (stripped down to the
minimal).  It appears to not be exiting the loop on the second condition (n<2).

The exact command I used to generate the .i is as follows:

  arm-none-eabi-gcc -mcpu=cortex-m7 src/core/dhcp.c -c -save-temps -g -O2


GCC that it definitely fails on is as follows:

arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-none-eabi/11.3.0/lto-wrapper
Target: arm-none-eabi
Configured with:
/var/tmp/notmpfs/portage/cross-arm-none-eabi/gcc-11.3.0/work/gcc-11.3.0/configure
--host=x86_64-pc-linux-gnu --target=arm-none-eabi --build=x86_64-pc-linux-gnu
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/arm-none-eabi/gcc-bin/11.3.0
--includedir=/usr/lib/gcc/arm-none-eabi/11.3.0/include
--datadir=/usr/share/gcc-data/arm-none-eabi/11.3.0
--mandir=/usr/share/gcc-data/arm-none-eabi/11.3.0/man
--infodir=/usr/share/gcc-data/arm-none-eabi/11.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/arm-none-eabi/11.3.0/include/g++-v11
--with-python-dir=/share/gcc-data/arm-none-eabi/11.3.0/python
--enable-languages=c,c++ --enable-obsolete --enable-secureplt --disable-werror
--with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=release
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 11.3.0 p4'
--disable-esp --enable-libstdcxx-time --disable-libstdcxx-pch
--enable-poison-system-directories --disable-libstdcxx-time
--with-sysroot=/usr/arm-none-eabi --disable-bootstrap --with-newlib
--enable-multilib --disable-fixed-point --disable-libgomp --disable-libssp
--disable-libada --disable-cet --disable-systemtap
--disable-valgrind-annotations --disable-vtable-verify --disable-libvtv
--without-zstd --enable-lto --without-isl --disable-libsanitizer
--disable-default-pie --enable-default-ssp --with-multilib-list=rmprofile
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 11.3.0 (Gentoo 11.3.0 p4)

[Bug target/106068] Infinite loop generated with -mcpu=cortex-m7 and -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
You access an out of bounds for the array dhcp_rx_options_given in the while
statement:

  while((dhcp_rx_options_given[8 + n] != 0) && (n < 2)) {


Swap around the two expressions so you check to make sure n is less than 2
before doing the array access. that is:

  while((n < 2) && (dhcp_rx_options_given[8 + n] != 0)) {

[Bug target/106068] Infinite loop generated with -mcpu=cortex-m7 and -O2

[dflogeras2 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Dave Flogeras  ---
(In reply to Andrew Pinski from comment #1)
> You access an out of bounds for the array dhcp_rx_options_given in the while
> statement:
> 
>   while((dhcp_rx_options_given[8 + n] != 0) && (n < 2)) {
> 
> 
> Swap around the two expressions so you check to make sure n is less than 2
> before doing the array access. that is:
> 
>   while((n < 2) && (dhcp_rx_options_given[8 + n] != 0)) {


For that code, agreed, and that was indeed both our and upstreams workaround. 
We were just wondering if it was a legitimate compiler bug given that it
generated an infinite loop in asm.  Or does it just fall under "undefined"

[Bug target/106068] Infinite loop generated with -mcpu=cortex-m7 and -O2

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Dave Flogeras from comment #2)
> For that code, agreed, and that was indeed both our and upstreams
> workaround.  We were just wondering if it was a legitimate compiler bug
> given that it generated an infinite loop in asm.  Or does it just fall under
> "undefined"

It is undefined if you access an out of bounds in an array. In this case the
compiler assumes there would be no such access and optimizes the range of n
because of the access and then removes the bounds check as the access already
happened.
So yes it is falls under undefined.

[Bug c++/105982] [13 Regression] internal compiler error: in lookup_template_class, at cp/pt.cc:10361

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

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

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

https://gcc.gnu.org/g:01aff2ba18a654324957af446a3065db489c0f14

commit r13-1224-g01aff2ba18a654324957af446a3065db489c0f14
Author: Patrick Palka 
Date:   Thu Jun 23 16:18:55 2022 -0400

c++: context completion in lookup_template_class [PR105982]

The below testcase demonstrates that completion of the substituted
context during lookup_template_class can end up registering the desired
specialization for us in more cases than r13-1045-gcb7fd1ea85feea
anticipated.  In particular this can happen for a non-dependent
specialization of a nested class as well.

For this testcase, during overload resolution with A's guides, we
substitute the deduced argument T=int into the TYPENAME_TYPE B::C,
during which we call lookup_template_class for A::B with T=int,
which completes A for the first time, which recursively registers
the desired specialization of B already.  The parent call to
lookup_template_class then tries to register the same specialization,
triggering an ICE.

This patch fixes this by making lookup_template_class determine more
directly whether we need to recheck the specializations table after
completion of the context -- when and only when the call to complete_type
had an effect.

PR c++/105982

gcc/cp/ChangeLog:

* pt.cc (lookup_template_class): After calling complete_type for
the substituted context, check the table again iff the type was
previously incomplete and complete_type made it complete.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/class-deduction111.C: New test.

[Bug c++/105982] [13 Regression] internal compiler error: in lookup_template_class, at cp/pt.cc:10361

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Fixed.

[Bug target/86722] ifcvt produces x&0 that is never cleaned up

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Target Milestone|--- |12.0
 Resolution|--- |FIXED
 CC||roger at nextmovesoftware dot 
com

--- Comment #6 from Roger Sayle  ---
This is now fixed on mainline (and GCC 12).

[Bug c++/105931] [12/13 regression] ICE in cxx_eval_constant_expression

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

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

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

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

commit r13-1225-gb00b95198e6720eb23a2618870d67800f6180fdd
Author: Patrick Palka 
Date:   Thu Jun 23 16:36:43 2022 -0400

c++: constexpr folding in unevaluated context [PR105931]

Changing the type of N from int to unsigned in decltype82.C (from
r13-986-g0ecb6b906f215e) reveals another spot where we perform constexpr
evaluation in an unevaluated context for sake of warnings, this time
from the call to shorten_compare in cp_build_binary_op, which calls
fold_for_warn.

We could (and probably should) suppress the shorten_compare warnings
when in an unevaluated context, but there's probably other callers of
fold_for_warn that are similarly affected.  So this patch takes the
approach of directly suppressing fold_for_warn when in an unevaluated
context.

PR c++/105931

gcc/cp/ChangeLog:

* expr.cc (fold_for_warn): Don't fold when in an unevaluated
context.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/decltype82a.C: New test.

[Bug c++/105925] [11/12/13 Regression] Could not convert '{{0, 0.0}}' from '' to 'X' since r12-954-g84fd1b5dff70cd74

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

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

commit r13-1226-gd610ae121e8ecd738de4dc01e6ac11ecf7c2327e
Author: Jason Merrill 
Date:   Thu Jun 23 16:04:02 2022 -0400

c++: anon union designated init [PR105925]

This testcase was failing because CONSTRUCTOR_IS_DESIGNATED_INIT wasn't
getting set on the introduced CONSTRUCTOR for the anonymous union, and
build_aggr_conv uses that flag to decide whether to pay attention to the
indexes of the CONSTRUCTOR.  So set the flag when we see a designator
rather
than relying on copying it from another CONSTRUCTOR.

This avoids some redundant errors on desig4.C because we stop setting
CONSTRUCTOR_IS_DESIGNATED_INIT on _Complex CONSTRUCTORs where it's
nonsense.

PR c++/105925

gcc/cp/ChangeLog:

* decl.cc (reshape_init_array_1): Set
CONSTRUCTOR_IS_DESIGNATED_INIT here.
(reshape_init_class): And here.
(reshape_init): Not here.

gcc/testsuite/ChangeLog:

* g++.dg/ext/desig4.C: Remove extra errors.
* g++.dg/cpp2a/desig26.C: New test.

[Bug c++/105925] [11/12/13 Regression] Could not convert '{{0, 0.0}}' from '' to 'X' since r12-954-g84fd1b5dff70cd74

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

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

commit r13-1227-g6c72f1bfc3469422460d86314a081353632d4bcb
Author: Jason Merrill 
Date:   Thu Jun 23 14:41:19 2022 -0400

c++: designated init cleanup [PR105925]

build_aggr_conv expects to run after reshape_init, which will usually have
filled out all the CONSTRUCTOR indexes; there's no reason to limit using
those to the case where the user gave an explicit designator.

PR c++/105925

gcc/cp/ChangeLog:

* call.cc (build_aggr_conv): Don't depend on
CONSTRUCTOR_IS_DESIGNATED_INIT.

[Bug fortran/105813] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8490

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
Simpler fix:

diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 0c2cb50c6a7..91d87a1b2c1 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -6353,6 +6353,8 @@ gfc_check_unpack (gfc_expr *vector, gfc_expr *mask,
gfc_expr *field)
   if (!same_type_check (vector, 0, field, 2))
 return false;

+  gfc_simplify_expr (mask, 0);
+
   if (mask->expr_type == EXPR_ARRAY
   && gfc_array_size (vector, &vector_size))
 {

[Bug c++/105925] [11/12/13 Regression] Could not convert '{{0, 0.0}}' from '' to 'X' since r12-954-g84fd1b5dff70cd74

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

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

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

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

commit r12-8511-gdb29b66193407d2fd6a04a07ecbd961c8d3f7d62
Author: Jason Merrill 
Date:   Thu Jun 23 16:04:02 2022 -0400

c++: anon union designated init [PR105925]

This testcase was failing because CONSTRUCTOR_IS_DESIGNATED_INIT wasn't
getting set on the introduced CONSTRUCTOR for the anonymous union, and
build_aggr_conv uses that flag to decide whether to pay attention to the
indexes of the CONSTRUCTOR.  So set the flag when we see a designator
rather
than relying on copying it from another CONSTRUCTOR.

PR c++/105925

gcc/cp/ChangeLog:

* decl.cc (reshape_init_array_1): Set
CONSTRUCTOR_IS_DESIGNATED_INIT here.
(reshape_init_class): And here.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/desig26.C: New test.

[Bug fortran/105813] ICE in gfc_simplify_unpack, at fortran/simplify.cc:8490

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

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

--- Comment #3 from Steve Kargl  ---
On Thu, Jun 23, 2022 at 09:18:40PM +, anlauf at gcc dot gnu.org wrote:
> 
> --- Comment #2 from anlauf at gcc dot gnu.org ---
> Simpler fix:
> 
> diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
> index 0c2cb50c6a7..91d87a1b2c1 100644
> --- a/gcc/fortran/check.cc
> +++ b/gcc/fortran/check.cc
> @@ -6353,6 +6353,8 @@ gfc_check_unpack (gfc_expr *vector, gfc_expr *mask,
> gfc_expr *field)
>if (!same_type_check (vector, 0, field, 2))
>  return false;
> 
> +  gfc_simplify_expr (mask, 0);
> +
>if (mask->expr_type == EXPR_ARRAY
>&& gfc_array_size (vector, &vector_size))
>  {
> 

If it survives regression testing, then I think it
can be committed.

[Bug libstdc++/106067] Error on implicit conversion to std::function: 'static constexpr bool std::_Function_handler<...>...' used before its definition

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

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

--- Comment #1 from Jonathan Wakely  ---
Probably due to r12-3174 (backported as r11-9289)

[Bug target/106069] New: wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

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

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

Bug ID: 106069
   Summary: wrong code with -O -fno-tree-forwprop -maltivec on
ppc64le
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

The following test crashes at runtime since r12-4496-g0910c516a3d72a.

$ ./cc1plus.r12-4495 -quiet -O -fno-tree-forwprop -maltivec q.C; g++ q.s;
./a.out
$ ./cc1plus.r12-4496 -quiet -O -fno-tree-forwprop -maltivec q.C; g++ q.s;
./a.out 
Aborted

Target: powerpc64le-unknown-linux-gnu
Configured with: /home/polacek/src/gcc/configure --enable-languages=c,c++
--enable-checking=yes -with-system-zlib --disable-bootstrap --disable-libvtv
--disable-libitm --disable-libsanitizer
gcc version 13.0.0 20220622 (experimental) (GCC)


extern "C" void *memcpy(void *, const void *, unsigned long);
typedef __attribute__((altivec(vector__))) unsigned native_simd_type;

union {
  native_simd_type V;
  int R[4];
} store_le_vec;

struct S {
  S() = default;
  S(unsigned B0) {
native_simd_type val{B0};
m_simd = val;
  }
  void store_le(unsigned char out[]) {
store_le_vec.V = m_simd;
unsigned int x0 = store_le_vec.R[0];
memcpy(out, &x0, 1);
  }
  S rotl(unsigned int r) {
native_simd_type rot{r};
return __builtin_vec_rl(m_simd, rot);
  }
  void operator+=(S other) {
m_simd = __builtin_vec_add(m_simd, other.m_simd);
  }
  void operator^=(S other) {
m_simd = __builtin_vec_xor(m_simd, other.m_simd);
  }
  static void transpose(S &B0, S B1, S B2, S B3) {
native_simd_type T0 = __builtin_vec_mergeh(B0.m_simd, B2.m_simd);
native_simd_type T1 = __builtin_vec_mergeh(B1.m_simd, B3.m_simd);
native_simd_type T2 = __builtin_vec_mergel(B0.m_simd, B2.m_simd);
native_simd_type T3 = __builtin_vec_mergel(B1.m_simd, B3.m_simd);
B0 = __builtin_vec_mergeh(T0, T1);
B3 = __builtin_vec_mergel(T2, T3);
  }
  S(native_simd_type x) : m_simd(x) {}
  native_simd_type m_simd;
};

void
foo (unsigned char output[], unsigned state[])
{
  S R00 = state[0];
  S R01 = state[0];
  S R02 = state[2];
  S R03 = state[0];
  S R05 = state[5];
  S R06 = state[6];
  S R07 = state[7];
  S R08 = state[8];
  S R09 = state[9];
  S R10 = state[10];
  S R11 = state[11];
  S R12 = state[12];
  S R13 = state[13];
  S R14 = state[4];
  S R15 = state[15];
  for (int r = 0; r != 10; ++r) {
R09 += R13;
R11 += R15;
R05 ^= R09;
R06 ^= R10;
R07 ^= R11;
R07 = R07.rotl(7);
R00 += R05;
R01 += R06;
R02 += R07;
R15 ^= R00;
R12 ^= R01;
R13 ^= R02;
R00 += R05;
R01 += R06;
R02 += R07;
R15 ^= R00;
R12 = R12.rotl(8);
R13 = R13.rotl(8);
R10 += R15;
R11 += R12;
R08 += R13;
R09 += R14;
R05 ^= R10;
R06 ^= R11;
R07 ^= R08;
R05 = R05.rotl(7);
R06 = R06.rotl(7);
R07 = R07.rotl(7);
  }
  R00 += state[0];
  S::transpose(R00, R01, R02, R03);
  R00.store_le(output);
}

unsigned char res[1];
unsigned main_state[]{1634760805, 60878,  2036477234, 6,
  0,  825562964,  1471091955, 1346092787,
  506976774,  4197066702, 518848283,  118491664,
  0,  0,  0,  0};
int
main ()
{
  foo (res, main_state);
  if (res[0] != 152)
__builtin_abort();
}

[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

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

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |12.2
   Keywords||wrong-code
 Target||powerpc64le-unknown-linux-g
   ||nu
   Host||powerpc64le-unknown-linux-g
   ||nu
Summary|wrong code with -O  |[12/13 Regression] wrong
   |-fno-tree-forwprop  |code with -O
   |-maltivec on ppc64le|-fno-tree-forwprop
   ||-maltivec on ppc64le
 CC||luoxhu at gcc dot gnu.org
  Build||powerpc64le-unknown-linux-g
   ||nu

[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

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

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

--- Comment #1 from Marek Polacek  ---
The difference between r12-4495 and r12-4496:

$ diff -up b/q.C.252r.expand a/q.C.252r.expand
--- b/q.C.252r.expand   2022-06-23 23:16:44.753507476 +
+++ a/q.C.252r.expand   2022-06-23 23:16:16.232784087 +
@@ -831,10 +831,14 @@ try_optimize_cfg iteration 2
 (subreg:V16QI (reg/v:V4SI 168 [ R02$m_simd ]) 0)) "q.C":31:47 -1
  (nil))
 (insn 188 187 189 5 (set (reg:V4SI 339)
-(unspec:V4SI [
-(subreg:V4SI (reg:V16QI 338) 0)
-(subreg:V4SI (reg:V16QI 337) 0)
-] UNSPEC_VMRGL_DIRECT)) "q.C":31:47 -1
+(vec_select:V4SI (vec_concat:V8SI (subreg:V4SI (reg:V16QI 338) 0)
+(subreg:V4SI (reg:V16QI 337) 0))
+(parallel [
+(const_int 2 [0x2])
+(const_int 6 [0x6])
+(const_int 3 [0x3])
+(const_int 7 [0x7])
+]))) "q.C":31:47 -1
  (nil))
 (insn 189 188 190 5 (set (reg:V16QI 336)
 (subreg:V16QI (reg:V4SI 339) 0)) "q.C":31:47 -1
@@ -846,10 +850,14 @@ try_optimize_cfg iteration 2
 (subreg:V16QI (reg/v:V4SI 143 [ val ]) 0)) "q.C":32:47 -1
  (nil))
 (insn 192 191 193 5 (set (reg:V4SI 344)
-(unspec:V4SI [
-(subreg:V4SI (reg:V16QI 343) 0)
-(subreg:V4SI (reg:V16QI 342) 0)
-] UNSPEC_VMRGL_DIRECT)) "q.C":32:47 -1
+(vec_select:V4SI (vec_concat:V8SI (subreg:V4SI (reg:V16QI 343) 0)
+(subreg:V4SI (reg:V16QI 342) 0))
+(parallel [
+(const_int 2 [0x2])
+(const_int 6 [0x6])
+(const_int 3 [0x3])
+(const_int 7 [0x7])
+]))) "q.C":32:47 -1
  (nil))
 (insn 193 192 194 5 (set (reg:V16QI 341)
 (subreg:V16QI (reg:V4SI 344) 0)) "q.C":32:47 -1
@@ -861,10 +869,14 @@ try_optimize_cfg iteration 2
 (subreg:V4SI (reg:V16QI 341) 0)) "q.C":35:8 -1
  (nil))
 (insn 196 195 197 5 (set (reg:V4SI 349)
-(unspec:V4SI [
-(subreg:V4SI (reg:V16QI 341) 0)
-(subreg:V4SI (reg:V16QI 336) 0)
-] UNSPEC_VMRGL_DIRECT)) "q.C":35:8 -1
+(vec_select:V4SI (vec_concat:V8SI (subreg:V4SI (reg:V16QI 341) 0)
+(subreg:V4SI (reg:V16QI 336) 0))
+(parallel [
+(const_int 2 [0x2])
+(const_int 6 [0x6])
+(const_int 3 [0x3])
+(const_int 7 [0x7])
+]))) "q.C":35:8 -1
  (nil))
 (insn 197 196 198 5 (set (reg:V16QI 348)
 (subreg:V16QI (reg:V4SI 349) 0)) "q.C":35:8 -1
@@ -934,7 +946,7 @@ try_optimize_cfg iteration 2
 (reg/f:DI 120)) "q.C":103:7 -1
  (nil))
 (call_insn 9 8 10 2 (parallel [
-(call (mem:SI (symbol_ref:DI ("_Z3fooPhPj") [flags 0x3] 
) [0 foo S4 A8])
+(call (mem:SI (symbol_ref:DI ("_Z3fooPhPj") [flags 0x3] 
) [0 foo S4 A8])
 (const_int 0 [0]))
 (use (const_int 0 [0]))
 (clobber (reg:DI 96 lr))
@@ -968,7 +980,7 @@ try_optimize_cfg iteration 2
  -> 17)
 (note 14 13 15 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
 (call_insn 15 14 16 4 (parallel [
-(call (mem:SI (symbol_ref:DI ("abort") [flags 0x41] 
) [0 __builtin_abort S4 A8])
+(call (mem:SI (symbol_ref:DI ("abort") [flags 0x41] 
) [0 __builtin_abort S4 A8])
 (const_int 0 [0]))
 (use (const_int 0 [0]))
 (clobber (reg:DI 96 lr))

[Bug c++/105925] [11/12/13 Regression] Could not convert '{{0, 0.0}}' from '' to 'X' since r12-954-g84fd1b5dff70cd74

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

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

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

https://gcc.gnu.org/g:553aecc570ce4ef5c751dc39b83bfbde6380f953

commit r11-10091-g553aecc570ce4ef5c751dc39b83bfbde6380f953
Author: Jason Merrill 
Date:   Thu Jun 23 16:04:02 2022 -0400

c++: anon union designated init [PR105925]

This testcase was failing because CONSTRUCTOR_IS_DESIGNATED_INIT wasn't
getting set on the introduced CONSTRUCTOR for the anonymous union, and
build_aggr_conv uses that flag to decide whether to pay attention to the
indexes of the CONSTRUCTOR.  So set the flag when we see a designator
rather
than relying on copying it from another CONSTRUCTOR.

PR c++/105925

gcc/cp/ChangeLog:

* decl.c (reshape_init_array_1): Set
CONSTRUCTOR_IS_DESIGNATED_INIT here.
(reshape_init_class): And here.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/desig26.C: New test.

[Bug c++/105925] [11/12/13 Regression] Could not convert '{{0, 0.0}}' from '' to 'X' since r12-954-g84fd1b5dff70cd74

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

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
  Known to work||11.3.1, 12.1.1, 13.0

--- Comment #8 from Jason Merrill  ---
Fixed for 11.4/12.2/13.

[Bug fortran/106065] Crash when reading extended derived type array in namelist

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-06-24
 CC||jvdelisle at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jerry DeLisle  ---
Well, its not really a 'crash', but certainly not correct.

Comment out the READ statements and look at the result:

$ ./a.out 
&NAM_BAL_NE
 DATE_TIME_NE(1)%NYEAR=0  ,
 DATE_TIME_NE(1)%NMONTH=0  ,
 DATE_TIME_NE(1)%NDAY=0  ,
 DATE_TIME_NE(1)%XTIME=  0.,
 DATE_TIME_NE(2)%NYEAR=0  ,
 DATE_TIME_NE(2)%NMONTH=0  ,
 DATE_TIME_NE(2)%NDAY=0  ,
 DATE_TIME_NE(2)%XTIME=  0.,
 /
&NAM_BAL_E
 DATE_TIME_E%TDATE%NYEAR=0  ,
 DATE_TIME_E%TDATE%NMONTH=0  ,
 DATE_TIME_E%TDATE%NDAY=0  ,
 DATE_TIME_E%YTIME=  0.,
 /

The extended type is not even being seen as an array

[Bug c++/106024] [11/12/13 Regression] ICE on missing template keyword in template method call in pack expansion

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Testcase with only one lambda:

template  void sink(Ts &&...);
template  void f()
{
  sink ([]  (auto...) { return 1; }
.operator()(args...)...);
}

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

[Bug target/106069] [12/13 Regression] wrong code with -O -fno-tree-forwprop -maltivec on ppc64le

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

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

--- Comment #2 from luoxhu at gcc dot gnu.org ---
Could you also paste the ASM difference please? (I don't have environment at
handle so far..)

[Bug tree-optimization/106070] New: Wrong code with -O1

[vsevolod.livinskiy at gmail dot com via Gcc-bugs]

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

Bug ID: 106070
   Summary: Wrong code with -O1
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskiy at gmail dot com
  Target Milestone: ---

GCC produces incorrect code with -O1.
I was not able to merge the test into a single file.

Reproducer:
// func.cpp
extern unsigned var_2;
extern int var_4;
extern signed char var_10;
extern unsigned long long arr_252;
void test() {
  for (unsigned a = 0; a < (unsigned char)var_10; a += 2)
arr_252 = var_2 != var_4 ? var_4 : (long)var_2;
}

//driver.cpp
#include 

unsigned int var_2 = 1;
int var_4 = -1;
signed char var_10 = (signed char)(-127 - 1);
unsigned long long int arr_252;

void test();

int main() {
test();
printf("%llx\n", arr_252);
if (arr_252 != 0x)
__builtin_abort();
}

Error:
>$ g++ -O0 func.cpp driver.cpp && ./a.out 

>$  g++ -O1 func.cpp driver.cpp && ./a.out 

Aborted (core dumped)

gcc version 13.0.0 20220623 (31ce821a790caec8a2849dd67a9847e78a33d14c)

[Bug tree-optimization/106070] Wrong code with -O1

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

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

--- Comment #1 from Andrew Pinski  ---
Single file testcase:
#include 
unsigned int var_2 = 1;
int var_4 = -1;
signed char var_10 = (signed char)(-127 - 1);
unsigned long long int arr_252;
[[gnu::noipa]]
void test() {
  for (unsigned a = 0; a < (unsigned char)var_10; a += 2)
arr_252 = var_2 != var_4 ? var_4 : (long)var_2;
}

void test();

int main() {
test();
printf("%llx\n", arr_252);
if (arr_252 != 0x)
__builtin_abort();
}

(The [[gnu::noipa]] makes things easier for single file testcases so no
inlining or other IPA passes on the function).

[Bug tree-optimization/106070] Wrong code with -O1

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-06-24
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||needs-bisection

--- Comment #2 from Andrew Pinski  ---
Reduced testcase:
#include 
unsigned int var_2 = 1;
int var_4 = -1;
int var_10 = 4;
unsigned long arr_252;
[[gnu::noipa]]
void test() {
  for (int a = 0; a < var_10; a += 2)
arr_252 = var_2 != (int)var_4 ? (unsigned long)var_4 : (unsigned
long)var_2;
}

void test();

int main() {
test();
fprintf(stderr, "%lx\n", arr_252);
if (arr_252 != 0x)
__builtin_abort();
}

 CUT ---
There is a missing sign extend from 32bit to 64bit.

Confirmed.

[Bug fortran/106047] ICE in structure_alloc_comps, at fortran/trans-array.cc:9574

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code

--- Comment #3 from G. Steinmetz  ---

Regarding these variants, all of them actually work :


$ cat zc1.f90
program p
   type t
  integer, allocatable :: c
   end type
   type(t) :: x
   integer :: n = storage_size(x)
   print *, n
end


$ cat zc2.f90
program p
   type t
  logical, allocatable :: c
   end type
   type(t) :: x
   integer :: n = storage_size(x)
   print *, n
end


$ cat zc3.f90
program p
   type t
  real, allocatable :: c
   end type
   type(t) :: x
   integer :: n = storage_size(x)
   print *, n
end


$ cat zc4.f90
program p
   type t
  character, allocatable :: c
   end type
   type(t) :: x
   integer :: n = storage_size(x)
   print *, n
end


$ cat zc5.f90
program p
   type t
  class(*), allocatable :: c
   end type
   type(t) :: x
   integer :: n = storage_size(x)
   print *, n
end


$ gfortran-13-20220619 zc1.f90 ; a.out
  64
$ gfortran-13-20220619 zc2.f90 ; a.out
  64
$ gfortran-13-20220619 zc3.f90 ; a.out
  64
$ gfortran-13-20220619 zc4.f90 ; a.out
  64
$ gfortran-13-20220619 zc5.f90 ; a.out
 192

---

Testing additional options, there is never an ICE with zc5.f90,
but with the other ones e.g. at line 9129 instead of line 9574 :


$ gfortran-13-20220619 -c zc1.f90 -fcoarray=single
zc1.f90:5:15:

5 |type(t) :: x
  |   1
internal compiler error: Segmentation fault
0xcd90df crash_signal
../../gcc/toplev.cc:322
0x7c4366 structure_alloc_comps
../../gcc/fortran/trans-array.cc:9129
0x7c7348 gfc_nullify_alloc_comp(gfc_symbol*, tree_node*, int, int)
../../gcc/fortran/trans-array.cc:10149
0x7c7348 gfc_trans_deferred_array(gfc_symbol*, gfc_wrapped_block*)
../../gcc/fortran/trans-array.cc:11206
0x7dabac gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*)
../../gcc/fortran/trans-decl.cc:4994
0x7dd1a5 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.cc:7756
0x75f53e translate_all_program_units
../../gcc/fortran/parse.cc:6669
0x75f53e gfc_parse_file()
../../gcc/fortran/parse.cc:6956
0x7acb6f gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229

[Bug target/105930] [12/13 Regression] Excessive stack spill generation on 32-bit x86

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

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

--- Comment #20 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:3b8794302b52a819ca3ea78238e9b5025d1c56dd

commit r13-1239-g3b8794302b52a819ca3ea78238e9b5025d1c56dd
Author: Roger Sayle 
Date:   Fri Jun 24 07:15:08 2022 +0100

PR target/105930: Split *xordi3_doubleword after reload on x86.

This patch addresses PR target/105930 which is an ia32 stack frame size
regression in high-register pressure XOR-rich cryptography functions
reported by Linus Torvalds.  The underlying problem is once the limited
number of registers on the x86 are exhausted, the register allocator
has to decide which to spill, where some eviction choices lead to much
poorer code, but these consequences are difficult to predict in advance.

The patch below, which splits xordi3_doubleword and iordi3_doubleword
after reload (instead of before), significantly reduces the amount of
spill code and stack frame size, in what might appear to be an arbitrary
choice.

My explanation of this behaviour is that the mixing of pre-reload split
SImode instructions and post-reload split DImode instructions is
confusing some of the heuristics used by reload.  One might think
that splitting early gives the register allocator more freedom to
use available registers, but in practice the constraint that double
word values occupy consecutive registers (when ultimately used as a
DImode value) is the greater constraint.  Instead, I believe in this
case, the pseudo registers used in memory addressing, appear to be
double counted for split SImode instructions compared to unsplit
DImode instructions.  For the reduced test case in comment #13, this
leads to %eax being used to hold the long-lived argument pointer "v",
blocking the use of the ax:dx pair for processing double word values.
The important lines are at the very top of the assembly output:

GCC 11  [use %ecx to address memory, require a 24-byte stack frame]
sub esp, 24
mov ecx, DWORD PTR [esp+40]

GCC 12 [use %eax to address memory, require a 44-byte stack frame]
sub esp, 44
mov eax, DWORD PTR [esp+64]

2022-06-24  Roger Sayle  
Uroš Bizjak  

gcc/ChangeLog
PR target/105930
* config/i386/i386.md (*di3_doubleword): Split after
reload.  Use rtx_equal_p to avoid creating memory-to-memory moves,
and emit NOTE_INSN_DELETED if operand[2] is zero (i.e. with -O0).

[Bug fortran/106071] New: single where run error

[han.wu--- via Gcc-bugs]

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

Bug ID: 106071
   Summary: single where run error
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: han...@compiler-dev.com
  Target Milestone: ---

two layer where work ok, why single where work error? 

example one:

program test
  real :: x(3) = 1, y(3) = 2
  logical :: m(3) = .true., m2(3) = .false.
  where (m)
x = f1()
!where (m2)
!  y = f2()
!end where
  end where
  if (any(x/=3)) then
print *, 'FAIL', x
  !if (any(x/=3 .or. y/=3)) then
  !  print *,'FAIL',x,y
  else
print *,'ok'
  end if
contains
  function f1()
m = .false.
!m2 = .true.
f1 = 3
  end function
  !function f2()
  !  m2 = .false.
  !  f2 = 3
  !end function
end

gfortran-12:
ASM generation compiler returned: 0
Execution build compiler returned: 0
Program returned: 0
 FAIL   3.   1.   1.   

example two:
program test
  real :: x(3) = 1, y(3) = 2
  logical :: m(3) = .true., m2(3) = .false.
  where (m)
x = f1()
where (m2)
  y = f2()
end where
  end where
  if (any(x/=3 .or. y/=3)) then
print *,'FAIL',x,y
  else
print *,'ok'
  end if
contains
  function f1()
m = .false.
m2 = .true.
f1 = 3
  end function
  function f2()
m2 = .false.
f2 = 3
  end function
end

ASM generation compiler returned: 0
Execution build compiler returned: 0
Program returned: 0
 ok

Looking forward to hearing from you！