[Bug fortran/82774] [10/11/12/13/14 Regression] Structure constructor and deferred type parameter character component

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #12 from Paul Thomas  ---
Hi Steve,

Fixed on trunk. I will back port to 13-branch in 2-3 weeks time.

Thanks for the report - it's a pity that it took so long to fix :-(

Paul

[Bug fortran/104429] [10/11/12/13/14 Regression] ICE in gfc_conv_variable, at fortran/trans-expr.cc:3056 since r9-2664-g1312bb902382cb48

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #6 from Paul Thomas  ---
Fixed on trunk. I will back port to 13-branch in 2-3 weeks time.

Thanks for the report

Paul

[Bug fortran/103389] [10/11/12/13/14 Regression] ICE in estimate_move_cost, at tree-inline.c:4191 since r9-5784-ga3df90b9672562d0

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #7 from Paul Thomas  ---
Fixed on trunk. I will back port to 13-branch in 2-3 weeks time.

Thanks for the report

Paul

[Bug fortran/87946] [10/11/12/13/14 Regression] ICE in gfc_walk_array_ref, at fortran/trans-array.c:10506

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #10 from Paul Thomas  ---
Fixed on trunk. I will back port to 13-branch in 2-3 weeks time.

Thanks for the report

Paul

[Bug target/87496] ICE in aggregate_value_p at gcc/function.c:2046

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

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #18 from Paul Thomas  ---
Sorry for the noise - a bit of a slip occurred in the ChangeLog.

Cheers

Paul

[Bug fortran/100193] [10/11/12/13/14 Regression] ICE in alloc_scalar_allocatable_for_assignment, at fortran/trans-expr.c:10837

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #6 from Paul Thomas  ---
Fixed on trunk. I will back port to 13-branch in 2-3 weeks time.

Thanks for the report

Paul

[Bug fortran/105152] [10/11/12/13/14 Regression] ICE in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.cc:5647 since r9-5372-gbbf18dc5d248a79a

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

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #6 from Paul Thomas  ---
Fixed on trunk. I will back port to 13-branch in 2-3 weeks time.

Thanks for the report

Paul

[Bug fortran/103389] [10/11/12/13/14 Regression] ICE in estimate_move_cost, at tree-inline.c:4191 since r9-5784-ga3df90b9672562d0

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r14-870-g6c95fe9bc0553743098eeaa739f14b885050fa42
Author: Paul Thomas 
Date:   Tue May 16 06:35:40 2023 +0100

Fortran: Fix an assortment of bugs

2023-05-16  Paul Thomas  

gcc/fortran
PR fortran/105152
* interface.cc (gfc_compare_actual_formal): Emit an error if an
unlimited polymorphic actual is not matched either to an
unlimited or assumed type formal argument.

PR fortran/100193
* resolve.cc (resolve_ordinary_assign): Emit an error if the
var expression of an ordinary assignment is a proc pointer
component.

PR fortran/87496
* trans-array.cc (gfc_walk_array_ref): Provide assumed shape
arrays coming from interface mapping with a viable arrayspec.

PR fortran/103389
* trans-expr.cc (gfc_conv_intrinsic_to_class): Tidy up flagging
of unlimited polymorphic 'class_ts'.
(gfc_conv_gfc_desc_to_cfi_desc): Assumed type is unlimited
polymorphic and should accept any actual type.

PR fortran/104429
(gfc_conv_procedure_call): Replace dreadful kludge with a call
to gfc_finalize_tree_expr. Avoid dereferencing a void pointer
by giving it the pointer type of the actual argument.

PR fortran/82774
(alloc_scalar_allocatable_subcomponent): Shorten the function
name and replace the symbol argument with the se string length.
If a deferred length character length is either not present or
is not a variable, give the typespec a variable and assign the
string length to that. Use gfc_deferred_strlen to find the
hidden string length component.
(gfc_trans_subcomponent_assign): Convert the expression before
the call to alloc_scalar_allocatable_subcomponent so that a
good string length is provided.
(gfc_trans_structure_assign): Remove the unneeded derived type
symbol from calls to gfc_trans_subcomponent_assign.

gcc/testsuite/
PR fortran/105152
* gfortran.dg/pr105152.f90 : New test

PR fortran/100193
* gfortran.dg/pr100193.f90 : New test

PR fortran/87946
* gfortran.dg/pr87946.f90 : New test

PR fortran/103389
* gfortran.dg/pr103389.f90 : New test

PR fortran/104429
* gfortran.dg/pr104429.f90 : New test

PR fortran/82774
* gfortran.dg/pr82774.f90 : New test

[Bug fortran/87946] [10/11/12/13/14 Regression] ICE in gfc_walk_array_ref, at fortran/trans-array.c:10506

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r14-870-g6c95fe9bc0553743098eeaa739f14b885050fa42
Author: Paul Thomas 
Date:   Tue May 16 06:35:40 2023 +0100

Fortran: Fix an assortment of bugs

2023-05-16  Paul Thomas  

gcc/fortran
PR fortran/105152
* interface.cc (gfc_compare_actual_formal): Emit an error if an
unlimited polymorphic actual is not matched either to an
unlimited or assumed type formal argument.

PR fortran/100193
* resolve.cc (resolve_ordinary_assign): Emit an error if the
var expression of an ordinary assignment is a proc pointer
component.

PR fortran/87496
* trans-array.cc (gfc_walk_array_ref): Provide assumed shape
arrays coming from interface mapping with a viable arrayspec.

PR fortran/103389
* trans-expr.cc (gfc_conv_intrinsic_to_class): Tidy up flagging
of unlimited polymorphic 'class_ts'.
(gfc_conv_gfc_desc_to_cfi_desc): Assumed type is unlimited
polymorphic and should accept any actual type.

PR fortran/104429
(gfc_conv_procedure_call): Replace dreadful kludge with a call
to gfc_finalize_tree_expr. Avoid dereferencing a void pointer
by giving it the pointer type of the actual argument.

PR fortran/82774
(alloc_scalar_allocatable_subcomponent): Shorten the function
name and replace the symbol argument with the se string length.
If a deferred length character length is either not present or
is not a variable, give the typespec a variable and assign the
string length to that. Use gfc_deferred_strlen to find the
hidden string length component.
(gfc_trans_subcomponent_assign): Convert the expression before
the call to alloc_scalar_allocatable_subcomponent so that a
good string length is provided.
(gfc_trans_structure_assign): Remove the unneeded derived type
symbol from calls to gfc_trans_subcomponent_assign.

gcc/testsuite/
PR fortran/105152
* gfortran.dg/pr105152.f90 : New test

PR fortran/100193
* gfortran.dg/pr100193.f90 : New test

PR fortran/87946
* gfortran.dg/pr87946.f90 : New test

PR fortran/103389
* gfortran.dg/pr103389.f90 : New test

PR fortran/104429
* gfortran.dg/pr104429.f90 : New test

PR fortran/82774
* gfortran.dg/pr82774.f90 : New test

[Bug target/87496] ICE in aggregate_value_p at gcc/function.c:2046

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

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

--- Comment #17 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r14-870-g6c95fe9bc0553743098eeaa739f14b885050fa42
Author: Paul Thomas 
Date:   Tue May 16 06:35:40 2023 +0100

Fortran: Fix an assortment of bugs

2023-05-16  Paul Thomas  

gcc/fortran
PR fortran/105152
* interface.cc (gfc_compare_actual_formal): Emit an error if an
unlimited polymorphic actual is not matched either to an
unlimited or assumed type formal argument.

PR fortran/100193
* resolve.cc (resolve_ordinary_assign): Emit an error if the
var expression of an ordinary assignment is a proc pointer
component.

PR fortran/87496
* trans-array.cc (gfc_walk_array_ref): Provide assumed shape
arrays coming from interface mapping with a viable arrayspec.

PR fortran/103389
* trans-expr.cc (gfc_conv_intrinsic_to_class): Tidy up flagging
of unlimited polymorphic 'class_ts'.
(gfc_conv_gfc_desc_to_cfi_desc): Assumed type is unlimited
polymorphic and should accept any actual type.

PR fortran/104429
(gfc_conv_procedure_call): Replace dreadful kludge with a call
to gfc_finalize_tree_expr. Avoid dereferencing a void pointer
by giving it the pointer type of the actual argument.

PR fortran/82774
(alloc_scalar_allocatable_subcomponent): Shorten the function
name and replace the symbol argument with the se string length.
If a deferred length character length is either not present or
is not a variable, give the typespec a variable and assign the
string length to that. Use gfc_deferred_strlen to find the
hidden string length component.
(gfc_trans_subcomponent_assign): Convert the expression before
the call to alloc_scalar_allocatable_subcomponent so that a
good string length is provided.
(gfc_trans_structure_assign): Remove the unneeded derived type
symbol from calls to gfc_trans_subcomponent_assign.

gcc/testsuite/
PR fortran/105152
* gfortran.dg/pr105152.f90 : New test

PR fortran/100193
* gfortran.dg/pr100193.f90 : New test

PR fortran/87946
* gfortran.dg/pr87946.f90 : New test

PR fortran/103389
* gfortran.dg/pr103389.f90 : New test

PR fortran/104429
* gfortran.dg/pr104429.f90 : New test

PR fortran/82774
* gfortran.dg/pr82774.f90 : New test

[Bug fortran/82774] [10/11/12/13/14 Regression] Structure constructor and deferred type parameter character component

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r14-870-g6c95fe9bc0553743098eeaa739f14b885050fa42
Author: Paul Thomas 
Date:   Tue May 16 06:35:40 2023 +0100

Fortran: Fix an assortment of bugs

2023-05-16  Paul Thomas  

gcc/fortran
PR fortran/105152
* interface.cc (gfc_compare_actual_formal): Emit an error if an
unlimited polymorphic actual is not matched either to an
unlimited or assumed type formal argument.

PR fortran/100193
* resolve.cc (resolve_ordinary_assign): Emit an error if the
var expression of an ordinary assignment is a proc pointer
component.

PR fortran/87496
* trans-array.cc (gfc_walk_array_ref): Provide assumed shape
arrays coming from interface mapping with a viable arrayspec.

PR fortran/103389
* trans-expr.cc (gfc_conv_intrinsic_to_class): Tidy up flagging
of unlimited polymorphic 'class_ts'.
(gfc_conv_gfc_desc_to_cfi_desc): Assumed type is unlimited
polymorphic and should accept any actual type.

PR fortran/104429
(gfc_conv_procedure_call): Replace dreadful kludge with a call
to gfc_finalize_tree_expr. Avoid dereferencing a void pointer
by giving it the pointer type of the actual argument.

PR fortran/82774
(alloc_scalar_allocatable_subcomponent): Shorten the function
name and replace the symbol argument with the se string length.
If a deferred length character length is either not present or
is not a variable, give the typespec a variable and assign the
string length to that. Use gfc_deferred_strlen to find the
hidden string length component.
(gfc_trans_subcomponent_assign): Convert the expression before
the call to alloc_scalar_allocatable_subcomponent so that a
good string length is provided.
(gfc_trans_structure_assign): Remove the unneeded derived type
symbol from calls to gfc_trans_subcomponent_assign.

gcc/testsuite/
PR fortran/105152
* gfortran.dg/pr105152.f90 : New test

PR fortran/100193
* gfortran.dg/pr100193.f90 : New test

PR fortran/87946
* gfortran.dg/pr87946.f90 : New test

PR fortran/103389
* gfortran.dg/pr103389.f90 : New test

PR fortran/104429
* gfortran.dg/pr104429.f90 : New test

PR fortran/82774
* gfortran.dg/pr82774.f90 : New test

[Bug fortran/104429] [10/11/12/13/14 Regression] ICE in gfc_conv_variable, at fortran/trans-expr.cc:3056 since r9-2664-g1312bb902382cb48

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r14-870-g6c95fe9bc0553743098eeaa739f14b885050fa42
Author: Paul Thomas 
Date:   Tue May 16 06:35:40 2023 +0100

Fortran: Fix an assortment of bugs

2023-05-16  Paul Thomas  

gcc/fortran
PR fortran/105152
* interface.cc (gfc_compare_actual_formal): Emit an error if an
unlimited polymorphic actual is not matched either to an
unlimited or assumed type formal argument.

PR fortran/100193
* resolve.cc (resolve_ordinary_assign): Emit an error if the
var expression of an ordinary assignment is a proc pointer
component.

PR fortran/87496
* trans-array.cc (gfc_walk_array_ref): Provide assumed shape
arrays coming from interface mapping with a viable arrayspec.

PR fortran/103389
* trans-expr.cc (gfc_conv_intrinsic_to_class): Tidy up flagging
of unlimited polymorphic 'class_ts'.
(gfc_conv_gfc_desc_to_cfi_desc): Assumed type is unlimited
polymorphic and should accept any actual type.

PR fortran/104429
(gfc_conv_procedure_call): Replace dreadful kludge with a call
to gfc_finalize_tree_expr. Avoid dereferencing a void pointer
by giving it the pointer type of the actual argument.

PR fortran/82774
(alloc_scalar_allocatable_subcomponent): Shorten the function
name and replace the symbol argument with the se string length.
If a deferred length character length is either not present or
is not a variable, give the typespec a variable and assign the
string length to that. Use gfc_deferred_strlen to find the
hidden string length component.
(gfc_trans_subcomponent_assign): Convert the expression before
the call to alloc_scalar_allocatable_subcomponent so that a
good string length is provided.
(gfc_trans_structure_assign): Remove the unneeded derived type
symbol from calls to gfc_trans_subcomponent_assign.

gcc/testsuite/
PR fortran/105152
* gfortran.dg/pr105152.f90 : New test

PR fortran/100193
* gfortran.dg/pr100193.f90 : New test

PR fortran/87946
* gfortran.dg/pr87946.f90 : New test

PR fortran/103389
* gfortran.dg/pr103389.f90 : New test

PR fortran/104429
* gfortran.dg/pr104429.f90 : New test

PR fortran/82774
* gfortran.dg/pr82774.f90 : New test

[Bug fortran/105152] [10/11/12/13/14 Regression] ICE in gfc_conv_gfc_desc_to_cfi_desc, at fortran/trans-expr.cc:5647 since r9-5372-gbbf18dc5d248a79a

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r14-870-g6c95fe9bc0553743098eeaa739f14b885050fa42
Author: Paul Thomas 
Date:   Tue May 16 06:35:40 2023 +0100

Fortran: Fix an assortment of bugs

2023-05-16  Paul Thomas  

gcc/fortran
PR fortran/105152
* interface.cc (gfc_compare_actual_formal): Emit an error if an
unlimited polymorphic actual is not matched either to an
unlimited or assumed type formal argument.

PR fortran/100193
* resolve.cc (resolve_ordinary_assign): Emit an error if the
var expression of an ordinary assignment is a proc pointer
component.

PR fortran/87496
* trans-array.cc (gfc_walk_array_ref): Provide assumed shape
arrays coming from interface mapping with a viable arrayspec.

PR fortran/103389
* trans-expr.cc (gfc_conv_intrinsic_to_class): Tidy up flagging
of unlimited polymorphic 'class_ts'.
(gfc_conv_gfc_desc_to_cfi_desc): Assumed type is unlimited
polymorphic and should accept any actual type.

PR fortran/104429
(gfc_conv_procedure_call): Replace dreadful kludge with a call
to gfc_finalize_tree_expr. Avoid dereferencing a void pointer
by giving it the pointer type of the actual argument.

PR fortran/82774
(alloc_scalar_allocatable_subcomponent): Shorten the function
name and replace the symbol argument with the se string length.
If a deferred length character length is either not present or
is not a variable, give the typespec a variable and assign the
string length to that. Use gfc_deferred_strlen to find the
hidden string length component.
(gfc_trans_subcomponent_assign): Convert the expression before
the call to alloc_scalar_allocatable_subcomponent so that a
good string length is provided.
(gfc_trans_structure_assign): Remove the unneeded derived type
symbol from calls to gfc_trans_subcomponent_assign.

gcc/testsuite/
PR fortran/105152
* gfortran.dg/pr105152.f90 : New test

PR fortran/100193
* gfortran.dg/pr100193.f90 : New test

PR fortran/87946
* gfortran.dg/pr87946.f90 : New test

PR fortran/103389
* gfortran.dg/pr103389.f90 : New test

PR fortran/104429
* gfortran.dg/pr104429.f90 : New test

PR fortran/82774
* gfortran.dg/pr82774.f90 : New test

[Bug fortran/100193] [10/11/12/13/14 Regression] ICE in alloc_scalar_allocatable_for_assignment, at fortran/trans-expr.c:10837

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r14-870-g6c95fe9bc0553743098eeaa739f14b885050fa42
Author: Paul Thomas 
Date:   Tue May 16 06:35:40 2023 +0100

Fortran: Fix an assortment of bugs

2023-05-16  Paul Thomas  

gcc/fortran
PR fortran/105152
* interface.cc (gfc_compare_actual_formal): Emit an error if an
unlimited polymorphic actual is not matched either to an
unlimited or assumed type formal argument.

PR fortran/100193
* resolve.cc (resolve_ordinary_assign): Emit an error if the
var expression of an ordinary assignment is a proc pointer
component.

PR fortran/87496
* trans-array.cc (gfc_walk_array_ref): Provide assumed shape
arrays coming from interface mapping with a viable arrayspec.

PR fortran/103389
* trans-expr.cc (gfc_conv_intrinsic_to_class): Tidy up flagging
of unlimited polymorphic 'class_ts'.
(gfc_conv_gfc_desc_to_cfi_desc): Assumed type is unlimited
polymorphic and should accept any actual type.

PR fortran/104429
(gfc_conv_procedure_call): Replace dreadful kludge with a call
to gfc_finalize_tree_expr. Avoid dereferencing a void pointer
by giving it the pointer type of the actual argument.

PR fortran/82774
(alloc_scalar_allocatable_subcomponent): Shorten the function
name and replace the symbol argument with the se string length.
If a deferred length character length is either not present or
is not a variable, give the typespec a variable and assign the
string length to that. Use gfc_deferred_strlen to find the
hidden string length component.
(gfc_trans_subcomponent_assign): Convert the expression before
the call to alloc_scalar_allocatable_subcomponent so that a
good string length is provided.
(gfc_trans_structure_assign): Remove the unneeded derived type
symbol from calls to gfc_trans_subcomponent_assign.

gcc/testsuite/
PR fortran/105152
* gfortran.dg/pr105152.f90 : New test

PR fortran/100193
* gfortran.dg/pr100193.f90 : New test

PR fortran/87946
* gfortran.dg/pr87946.f90 : New test

PR fortran/103389
* gfortran.dg/pr103389.f90 : New test

PR fortran/104429
* gfortran.dg/pr104429.f90 : New test

PR fortran/82774
* gfortran.dg/pr82774.f90 : New test

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

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

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

--- Comment #13 from Sam James  ---
the OOB read seems to go away with --enable-checking=yes,rtl,extra (previously
had --enable-checking=release)...? (at least for 13)

[Bug tree-optimization/101805] Max -> bool0 | bool1 Min -> a & b

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Fixed by r14-868-gb06cfb62229f17eca59fa4aabf853d7e17e2327b (I typed the wrong
bug # in the commit message).

[Bug tree-optimization/109424] ~((x > y) ? x : y) produces two not instructions

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

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

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

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

commit r14-868-gb06cfb62229f17eca59fa4aabf853d7e17e2327b
Author: Andrew Pinski 
Date:   Mon May 15 21:44:27 2023 +

MATCH: [PR109424] Simplify min/max of boolean arguments

This is version 2 of
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577394.html
which does not depend on adding gimple_truth_valued_p at this point.
Instead will use zero_one_valued_p which is already used for mult
simplifications
to make sure that we only have [0,1] rather having the mistake of maybe
having [-1,0]
as the range for signed bools.

This shows up in a few places in GCC itself but only at -O1, we miss the
min/max conversion
because of PR 107888 (which I will be testing seperately).

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

Thanks,
Andrew Pinski

PR tree-optimization/109424

gcc/ChangeLog:

* match.pd: Add patterns for min/max of zero_one_valued
values to `&`/`|`.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/bool-12.c: New test.
* gcc.dg/tree-ssa/bool-13.c: New test.
* gcc.dg/tree-ssa/minmax-20.c: New test.
* gcc.dg/tree-ssa/minmax-21.c: New test.

[Bug tree-optimization/107888] [12/13/14 Regression] Missed min/max transformation in phiopt due to VRP

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

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

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

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

commit r14-868-gb06cfb62229f17eca59fa4aabf853d7e17e2327b
Author: Andrew Pinski 
Date:   Mon May 15 21:44:27 2023 +

MATCH: [PR109424] Simplify min/max of boolean arguments

This is version 2 of
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577394.html
which does not depend on adding gimple_truth_valued_p at this point.
Instead will use zero_one_valued_p which is already used for mult
simplifications
to make sure that we only have [0,1] rather having the mistake of maybe
having [-1,0]
as the range for signed bools.

This shows up in a few places in GCC itself but only at -O1, we miss the
min/max conversion
because of PR 107888 (which I will be testing seperately).

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

Thanks,
Andrew Pinski

PR tree-optimization/109424

gcc/ChangeLog:

* match.pd: Add patterns for min/max of zero_one_valued
values to `&`/`|`.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/bool-12.c: New test.
* gcc.dg/tree-ssa/bool-13.c: New test.
* gcc.dg/tree-ssa/minmax-20.c: New test.
* gcc.dg/tree-ssa/minmax-21.c: New test.

[Bug c++/109870] Miscomputation of return type of unevaluated lambda in type alias in template context

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

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

--- Comment #1 from Andrew Pinski  ---
Most likely a dup of a bug that PR 107430 depends on.

[Bug c++/109870] New: Miscomputation of return type of unevaluated lambda in type alias in template context

[ed at catmur dot uk via Gcc-bugs]

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

Bug ID: 109870
   Summary: Miscomputation of return type of unevaluated lambda in
type alias in template context
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ed at catmur dot uk
  Target Milestone: ---

template struct X {};
template
struct M {
using R = decltype([] { return 1; }());
template struct S { X p; };
};
M::S s;

9.1 through 14.0.0 trunk reject with:

: In instantiation of 'struct M::S':
:7:17:   required from here
:4:36: error: return-statement with a value, in function returning
'void' [-fpermissive]
4 | using R = decltype([] { return 1; }());
  |^

It appears the `U` type parameter in `M::S` is overwriting the lambda
deduced return type.

Possibly related to #92707, #103569

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

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

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

--- Comment #6 from Kewen Lin  ---
(In reply to Hongtao.liu from comment #5)
> (In reply to Kewen Lin from comment #3)
> > (In reply to Hongtao.liu from comment #2)
> > > Does https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617431.html help?
> > 
> > Sorry, I just measured those degraded bmks with this fix, the results showed
> > it didn't help.
> 
> Sorry for the inconvience, could you try again with attached patch.
> The patch will still use GENERAL_REGS when hard_regno_mode_ok for mode and
> GENERAL_REGS(which is the case in PR109610), hope it can also fix this
> regression.

Thanks for the prompt fix, I'll do the perf evaluation once the perf boxes get
released (they are used by others now) and get back to you.

[Bug tree-optimization/90087] Suboptimal codegen for x < 0 ? x - INT_MIN : x

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

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

--- Comment #3 from Andrew Pinski  ---
THis way with type_min and type_max filled out correctly.

(simplify
 (cond (lt @0 integer_zero_p) (minus @0 INTEGER_CST@1) @0)
 (if (TYPE_SIGNED (type) && wi::to_widest(@0) == type_min(@0))
  (bit_ior @0 { build_int_cst (type_max(type), type); } )))

Note I think TYPE_PRECISION needs to be a power of 2 but I could be wrong ...

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Hongtao.liu  ---
(In reply to Kewen Lin from comment #3)
> (In reply to Hongtao.liu from comment #2)
> > Does https://gcc.gnu.org/pipermail/gcc-patches/2023-May/617431.html help?
> 
> Sorry, I just measured those degraded bmks with this fix, the results showed
> it didn't help.

Sorry for the inconvience, could you try again with attached patch.
The patch will still use GENERAL_REGS when hard_regno_mode_ok for mode and
GENERAL_REGS(which is the case in PR109610), hope it can also fix this
regression.

[Bug rtl-optimization/109858] [14 Regression] r14-172 caused some SPEC2017 bmk to degrade on Power

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
Created attachment 55091
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55091&action=edit
Only use NO_REGS in cost calculation when !hard_regno_mode_ok for GENERAL_REGS
and mode.

[Bug tree-optimization/109869] New: comparing SCHAR_MIN and SCHAR_MAX but with widden type could be optimized better

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

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

Bug ID: 109869
   Summary: comparing SCHAR_MIN and SCHAR_MAX but with widden type
could be optimized better
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take (for most targets):
```
bool f1 (signed char i)
{
  unsigned long long _1 = i;
  bool _5 = _1 == 127;
  bool _6 = _1 == 18446744073709551488ull;
  return _5 | _6;
}
bool f2 (signed char i)
{
  return i == -128 || i == 127;
  __SIZE_TYPE__ _1 = i;
}
```

These two functions should produce the same code.

I noticed this while looking at PR 77899 .

[Bug c/109863] RFE: more consistent flex array initialization: lift static storage requirement in gnu2x

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

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

--- Comment #2 from Xi Ruoyao  ---
(In reply to Xi Ruoyao from comment #1)
> Note that the entire "initializing a flexible array member" thing is a GNU
> extension and not supported by the standard.  So GCC is free to support the
> constexpr case but reject other non-static cases.

Or, "it's an extension after all, so it's not related to if the standard say
constexpr implies static or not".

[Bug c/109863] RFE: more consistent flex array initialization: lift static storage requirement in gnu2x

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

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

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #1 from Xi Ruoyao  ---
Note that the entire "initializing a flexible array member" thing is a GNU
extension and not supported by the standard.  So GCC is free to support the
constexpr case but reject other non-static cases.

[Bug tree-optimization/77899] incorrect VR_RANGE for a signed char function argument

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #13 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #12)
> Even this should be folded but is not currently:
> void f (signed char i)
> {
>   char d [260];
> 
>   const char *p = &d[130];
> 
>   p += i;
> 
>   if (p == d + 2 || d + 257 == p)
> __builtin_abort ();
> }

That was handled by r13-4555-g892e8c520be37d (aka PR 107699).

The non eq/ne ones are not handled though; I think there might be another bug
about that ...

[Bug tree-optimization/101805] Max -> bool0 | bool1 Min -> a & b

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-May/618
   ||645.html

--- Comment #5 from Andrew Pinski  ---
Updated patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618645.html

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

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

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

--- Comment #12 from Andrew Pinski  ---
Jakub, assign this to me if you think we should go down that route unless you
want to take the patch further.

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

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

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

--- Comment #11 from Andrew Pinski  ---
Created attachment 55090
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55090&action=edit
Patch which I came up with

This patch adds back zero_sized_field_decl but keeps the call to is_empty_type
too.

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

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

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

--- Comment #10 from Sam James  ---
fwiw, on glibc, I don't get the oob read w/ valgrind but still the ICE as
you've already found.

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

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

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

--- Comment #9 from Jakub Jelinek  ---
The ICE started with r13-436-gaf34279921f4bb95b07c0be but the undesirable store
is
there already since r12-2975-g32c3a75390623a0470df52.

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> That might have been caused by r12-1150-g34aae6b561871d . I will look into
> it soon because we should not be emitting an assignment here ...

Yes it was introduced by that revision, specifically the change of
zero_sized_field_decl to is_empty_type. We checked the DECL_SIZE being zero but
now we check the size of type being empty but is_empty_type is not considered
true for bitfield types of size 0 ...

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
I'll have a look tomorrow^H^H^H^H^Hlater today.

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

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

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

--- Comment #6 from Andrew Pinski  ---
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806#c15 .

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

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

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

--- Comment #5 from Andrew Pinski  ---
A little more reduced:
```
struct ClockImpl  {
  virtual void addRef();
  long tv_nsec;
  int : 0;
};
void f() { ClockImpl b{}; }
```

So maybe this is a gimplifier issue producing the assignment to the zero-sized
bitfield:

  b.D.2780 = 0;

What is interesting is GCC 11 didn't produce the assignment but GCC 12 does.
That might have been caused by r12-1150-g34aae6b561871d . I will look into it
soon because we should not be emitting an assignment here ...

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

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

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

--- Comment #16 from Sam James  ---
Filed my musl one as PR109868, sorry for clogging up this one!

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

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

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

--- Comment #4 from Andrew Pinski  ---
Hmm:
  D.2948._startTime.D.2792 = 0;

That seems wrong.

Reduced further:
```
struct SimpleRefCounted {
  virtual void addRef();
};
struct ClockImpl : SimpleRefCounted {
  long tv_nsec;
  int : 0;
};
void f() { ClockImpl b{}; }
```
And yes it is the zero sized bitfield causing issues ...

[Bug tree-optimization/109868] [13/14 regression] ICE: segmentation fault or ICE in min_value with zero sized bitfield

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |tree-optimization
  Known to fail||13.1.0, 14.0
  Known to work||12.3.0
 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |13.2
   Last reconfirmed||2023-05-15
Summary|[13/14 regression] ICE: |[13/14 regression] ICE:
   |segmentation fault when |segmentation fault or ICE
   |building small C++ program  |in min_value with zero
   ||sized bitfield
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code

--- Comment #3 from Andrew Pinski  ---
Confirmed. I can reproduce it also on normal x86_64-linux-gnu and
aarch64-linux-gnu even.

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

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

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

--- Comment #15 from Jakub Jelinek  ---
That ICE is because layout_class_type calls c_build_bitfield_integer_type with
width of 0 and that type is then seen by ranger for some reason:
#7  0x00c4eee1 in layout_class_type (t=, virtuals_p=0x7fffd4c8)
at ../../gcc/cp/class.cc:6858
6853  tree ftype = TREE_TYPE (field);
6854  width = tree_to_uhwi (DECL_SIZE (field));
6855  if (width != TYPE_PRECISION (ftype))
6856{
6857  TREE_TYPE (field)
6858= c_build_bitfield_integer_type (width,
6859 TYPE_UNSIGNED
(ftype));
6860  TREE_TYPE (field)
6861= cp_build_qualified_type (TREE_TYPE (field),
6862   cp_type_quals (ftype));
I think unnamed bitfields are just padding and shouldn't have this called.

[Bug c++/109868] [13/14 regression] ICE: segmentation fault when building small C++ program

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

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

--- Comment #2 from Sam James  ---
Created attachment 55089
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55089&action=edit
clock.ii (reduced)

[Bug c++/109868] [13/14 regression] ICE: segmentation fault when building small C++ program

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

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

--- Comment #1 from Sam James  ---
Created attachment 55088
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55088&action=edit
clock.ii.orig

[Bug c++/109868] New: [13/14 regression] ICE: segmentation fault when building small C++ program

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

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

Bug ID: 109868
   Summary: [13/14 regression] ICE: segmentation fault when
building small C++ program
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: amonakov at gcc dot gnu.org
  Target Milestone: ---

I originally reported this at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806#c12.

For me, this crashes on x86_64-gentoo-linux-musl:
```
struct SimpleRefCounted {
  virtual void addRef();
};
struct timespec {
  long tv_nsec;
  int : 0;
};
struct ClockImpl : SimpleRefCounted {
  timespec _startTime;
};
struct Clock {
  Clock();
};
Clock::Clock() { ClockImpl(); }
```

with:
```
# g++ /tmp/foo.cxx -O2 -wrapper valgrind
==1239523== Memcheck, a memory error detector
==1239523== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1239523== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==1239523== Command: /usr/libexec/gcc/x86_64-gentoo-linux-musl/13/cc1plus
-quiet -D_GNU_SOURCE /tmp/foo.cxx -quiet -dumpdir a- -dumpbase foo.cxx
-dumpbase-ext .cxx -mtune=generic -march=x86-64 -O2 -fcf-protection -o
/tmp/ccigHfiN.s
==1239523==
==1239523== Invalid read of size 1
==1239523==at 0x97844C: to_wide (tree.h:6257)
==1239523==by 0x97844C: irange::set_varying(tree_node*) (value-range.h:959)
==1239523==by 0x10C1A45: range_query::get_tree_range(vrange&, tree_node*,
gimple*) (value-query.cc:252)
==1239523==by 0x1B52256: gimple_ranger::range_of_stmt(vrange&, gimple*,
tree_node*) (gimple-range.cc:298)
==1239523==by 0x1B52778: gimple_ranger::register_inferred_ranges(gimple*)
(gimple-range.cc:474)
==1239523==by 0x109FB19: rvrp_folder::fold_stmt(gimple_stmt_iterator*)
(tree-vrp.cc:1079)
==1239523==by 0xFA9ED3:
substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
(tree-ssa-propagate.cc:848)
==1239523==by 0x1B24C2E: dom_walker::walk(basic_block_def*)
(domwalk.cc:311)
==1239523==by 0xFA9312:
substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
(tree-ssa-propagate.cc:971)
==1239523==by 0x109DB80: execute_ranger_vrp(function*, bool, bool)
(tree-vrp.cc:1107)
==1239523==by 0xD3A0EA: execute_one_pass(opt_pass*) (passes.cc:2651)
==1239523==by 0xD3A9AF: execute_pass_list_1(opt_pass*) (passes.cc:2760)
==1239523==by 0xD3A9C1: execute_pass_list_1(opt_pass*) (passes.cc:2761)
==1239523==  Address 0x4 is not stack'd, malloc'd or (recently) free'd
==1239523==
during GIMPLE pass: evrp
/tmp/foo.cxx: In constructor 'Clock::Clock()':
/tmp/foo.cxx:14:31: internal compiler error: Segmentation fault
   14 | Clock::Clock() { ClockImpl(); }
  |   ^

0xe10df3 crash_signal
   
/usr/src/debug/sys-devel/gcc-13.1.1_p20230513/gcc-13-20230513/gcc/toplev.cc:314
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.
```

It crashes without valgrind too, just less informative.

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

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

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

--- Comment #14 from Sam James  ---
(In reply to Alexander Monakov from comment #13)
> The 128KB stack size is for *secondary* threads on musl (i.e. those created
> via pthread_create). The main thread has the same stack as on glibc (GCC
> extends it to 128MB unless there's a hard limit).

To be fair, I didn't know if gcc did everything in a single thread. Thanks.

> 
> This doesn't look like a stack exhaustion and should be a separate bug.

I asked on IRC and was pointed here rather than file a dupe, but I'll file one
now in that case.

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #13 from Alexander Monakov  ---
The 128KB stack size is for *secondary* threads on musl (i.e. those created via
pthread_create). The main thread has the same stack as on glibc (GCC extends it
to 128MB unless there's a hard limit).

This doesn't look like a stack exhaustion and should be a separate bug.

[Bug fortran/109865] different results when routine moved inside the contains statement

[Gary.White at ColoState dot edu via Gcc-bugs]

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

--- Comment #8 from GARY.WHITE at ColoState dot edu  ---
I just tried to send you a zip file with all the code and instructions (see
below), but it is over 6Mb in size, and was rejected.  Where can I put it that
you can access it?

I have put the file test_case.zip on my Onedrive account at

https://1drv.ms/u/s!Ak8uiHyJ2kc2iqIPdvZKUGDak3CZ9A?e=yFcRJZ

Gary


Gary C. White, CWB(r)
Professor Emeritus
Department of Fish, Wildlife, and Conservation Biology
10 Wagar
Colorado State University
Fort Collins, CO 80523
(515)450-2768 Mobile
gary.wh...@colostate.edu
https://sites.warnercnr.colostate.edu/gwhite/
he/him/his

See where we are!

"Leadership is a privilege to better the lives of others. It is not an
opportunity to satisfy personal greed." Mwai Kibaki

-Original Message-
From: White,Gary
Sent: Monday, May 15, 2023 3:53 PM
To: kargl at gcc dot gnu.org 
Subject: RE: [Bug fortran/109865] different results when routine moved inside
the contains statement

Sorry I can't simplify this down to a nice compact piece of code, but ...

In the attached test_case.zip file are all the *.f90 files, makefile, and some
library files that work on ubuntu with gfortran-12.  I can provide Windows
libraries if that is easier.

  Create the executable file, mark64,  by a  simple  make or  make type=mark64

Right now, the makefile does not have an -O0 on the va09ad.f90 compile line. 
As we found out, over-riding -O3 on va09ad.f90 compilation produces correct
code.

Execute the test case with

 ./mark64 i=dipper.inp o=dipper.out

I've included 2 output files, dipper_correct.out and dipper_incorrect.out so
you can see what correct and incorrect outputs look like.

Hopefully this all works out.

Thanks.

Gary

Gary C. White, CWB(r)
Professor Emeritus
Department of Fish, Wildlife, and Conservation Biology
10 Wagar
Colorado State University
Fort Collins, CO 80523
(515)450-2768 Mobile
gary.wh...@colostate.edu
https://sites.warnercnr.colostate.edu/gwhite/
he/him/his

See where we are!

"Leadership is a privilege to better the lives of others. It is not an
opportunity to satisfy personal greed." Mwai Kibaki

-Original Message-
From: kargl at gcc dot gnu.org 
Sent: Monday, May 15, 2023 2:42 PM
To: White,Gary 
Subject: [Bug fortran/109865] different results when routine moved inside the
contains statement

** Caution: EXTERNAL Sender **

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

--- Comment #6 from kargl at gcc dot gnu.org --- (In reply to
gary.wh...@colostate.edu from comment #5)
> (In reply to Steve Kargl from comment #4)

> > I assume you've also tried with -fcheck=all.
> > Your report states you're using og12.  If it supports the sanitizer,
> > can you add -fsanitize=undefined to the options?
>
> -fcheck=all does not generate any warnings.
> -fsanitize=undefined returns pages when loading of:
>
> undefined reference to `__ubsan_handle_pointer_overflow'
>
> which makes no sense to me

Hmmm.  Thanks for checking.  Either your version of gcc is not built with
--enable-libsanitizer or gfortran cannot find the library.  At this point, it
seems we're going to need a complete testcase.

--
You are receiving this mail because:
You reported the bug.

[Bug fortran/109865] different results when routine moved inside the contains statement

[Gary.White at ColoState dot edu via Gcc-bugs]

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

--- Comment #7 from GARY.WHITE at ColoState dot edu  ---
Sorry I can't simplify this down to a nice compact piece of code, but ...

In the attached test_case.zip file are all the *.f90 files, makefile, and some
library files that work on ubuntu with gfortran-12.  I can provide Windows
libraries if that is easier.

  Create the executable file, mark64,  by a  simple
 make
or
 make type=mark64

Right now, the makefile does not have an -O0 on the va09ad.f90 compile line. 
As we found out, over-riding -O3 on va09ad.f90 compilation produces correct
code.

Execute the test case with

 ./mark64 i=dipper.inp o=dipper.out

I've included 2 output files, dipper_correct.out and dipper_incorrect.out so
you can see what correct and incorrect outputs look like.

Hopefully this all works out.

Thanks.

Gary

Gary C. White, CWB(r)
Professor Emeritus
Department of Fish, Wildlife, and Conservation Biology
10 Wagar
Colorado State University
Fort Collins, CO 80523
(515)450-2768 Mobile
gary.wh...@colostate.edu
https://sites.warnercnr.colostate.edu/gwhite/
he/him/his

See where we are!

"Leadership is a privilege to better the lives of others. It is not an
opportunity to satisfy personal greed." Mwai Kibaki

-Original Message-
From: kargl at gcc dot gnu.org 
Sent: Monday, May 15, 2023 2:42 PM
To: White,Gary 
Subject: [Bug fortran/109865] different results when routine moved inside the
contains statement

** Caution: EXTERNAL Sender **

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

--- Comment #6 from kargl at gcc dot gnu.org --- (In reply to
gary.wh...@colostate.edu from comment #5)
> (In reply to Steve Kargl from comment #4)

> > I assume you've also tried with -fcheck=all.
> > Your report states you're using og12.  If it supports the sanitizer,
> > can you add -fsanitize=undefined to the options?
>
> -fcheck=all does not generate any warnings.
> -fsanitize=undefined returns pages when loading of:
>
> undefined reference to `__ubsan_handle_pointer_overflow'
>
> which makes no sense to me

Hmmm.  Thanks for checking.  Either your version of gcc is not built with
--enable-libsanitizer or gfortran cannot find the library.  At this point, it
seems we're going to need a complete testcase.

--
You are receiving this mail because:
You reported the bug.

[Bug tree-optimization/101805] Max -> bool0 | bool1 Min -> a & b

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|patch   |
URL|https://gcc.gnu.org/piperma |
   |il/gcc-patches/2021-August/ |
   |577394.html |

--- Comment #4 from Andrew Pinski  ---
About to submit an updated version of this patch.

[Bug c++/109867] New: -Wswicht-default reports missing default in coroutine

[lukaslang.bugtracker at outlook dot com via Gcc-bugs]

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

Bug ID: 109867
   Summary: -Wswicht-default reports missing default in coroutine
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lukaslang.bugtracker at outlook dot com
  Target Milestone: ---

Consider the following implementation of a simple coroutine
(https://godbolt.org/z/rcevTd5f6):

#include 

struct task
{
struct promise_type
{
std::suspend_always initial_suspend();
std::suspend_always final_suspend() noexcept;
void unhandled_exception();
task get_return_object();
void return_value(int);
};
};

int main()
{
auto t = []() -> task
{
co_return 2;
}();
} 

Compiling this with -std=c++20 -Wswitch-default -Werror results in an error at
the end of the coroutine body:

:20:5: error: switch missing default case [-Werror=switch-default]
   20 | }();

Since I can get neither clang nor msvc to complain, I assume this is a bug, or
am I missing something? If this is indeed a bug, can I work around this without
having to disable the warning?

[Bug tree-optimization/109720] -Wmaybe-uninitialized triggering when I can see no path that would allow it

[psmith at gnu dot org via Gcc-bugs]

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

--- Comment #7 from Paul Smith  ---
Just to note this code also throws this warning in GCC 12.3 but it doesn't
complain in GCC 11.3 which is what I was using before.

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

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

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

Sam James  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org
   See Also||https://bugs.gentoo.org/sho
   ||w_bug.cgi?id=906380

--- Comment #12 from Sam James  ---
I think I'm hitting this on musl too. Reported in Gentoo at
https://bugs.gentoo.org/906380.

For me, this crashes on x86_64-gentoo-linux-musl:
```
struct SimpleRefCounted {
  virtual void addRef();
};
struct timespec {
  long tv_nsec;
  int : 0;
};
struct ClockImpl : SimpleRefCounted {
  timespec _startTime;
};
struct Clock {
  Clock();
};
Clock::Clock() { ClockImpl(); }
```

with:
```
# g++ /tmp/foo.cxx -O2 -wrapper valgrind
==1239523== Memcheck, a memory error detector
==1239523== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1239523== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==1239523== Command: /usr/libexec/gcc/x86_64-gentoo-linux-musl/13/cc1plus
-quiet -D_GNU_SOURCE /tmp/foo.cxx -quiet -dumpdir a- -dumpbase foo.cxx
-dumpbase-ext .cxx -mtune=generic -march=x86-64 -O2 -fcf-protection -o
/tmp/ccigHfiN.s
==1239523==
==1239523== Invalid read of size 1
==1239523==at 0x97844C: to_wide (tree.h:6257)
==1239523==by 0x97844C: irange::set_varying(tree_node*) (value-range.h:959)
==1239523==by 0x10C1A45: range_query::get_tree_range(vrange&, tree_node*,
gimple*) (value-query.cc:252)
==1239523==by 0x1B52256: gimple_ranger::range_of_stmt(vrange&, gimple*,
tree_node*) (gimple-range.cc:298)
==1239523==by 0x1B52778: gimple_ranger::register_inferred_ranges(gimple*)
(gimple-range.cc:474)
==1239523==by 0x109FB19: rvrp_folder::fold_stmt(gimple_stmt_iterator*)
(tree-vrp.cc:1079)
==1239523==by 0xFA9ED3:
substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
(tree-ssa-propagate.cc:848)
==1239523==by 0x1B24C2E: dom_walker::walk(basic_block_def*)
(domwalk.cc:311)
==1239523==by 0xFA9312:
substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
(tree-ssa-propagate.cc:971)
==1239523==by 0x109DB80: execute_ranger_vrp(function*, bool, bool)
(tree-vrp.cc:1107)
==1239523==by 0xD3A0EA: execute_one_pass(opt_pass*) (passes.cc:2651)
==1239523==by 0xD3A9AF: execute_pass_list_1(opt_pass*) (passes.cc:2760)
==1239523==by 0xD3A9C1: execute_pass_list_1(opt_pass*) (passes.cc:2761)
==1239523==  Address 0x4 is not stack'd, malloc'd or (recently) free'd
==1239523==
during GIMPLE pass: evrp
/tmp/foo.cxx: In constructor 'Clock::Clock()':
/tmp/foo.cxx:14:31: internal compiler error: Segmentation fault
   14 | Clock::Clock() { ClockImpl(); }
  |   ^

0xe10df3 crash_signal
   
/usr/src/debug/sys-devel/gcc-13.1.1_p20230513/gcc-13-20230513/gcc/toplev.cc:314
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.
```

(Obviously crashes w/o valgrind too, just the output is way less helpful.)

Note that musl has a small default stack size, as I mentioned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695#c18.

[Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to Scot Breitenfeld from comment #3)
> I see the same issue with NAG, regardless of the optimization level. Our CI
> testing had missed it because this was a parallel test, and we don't test
> parallel with NAG.
> 
> I guess the issue is whether marking TYPE(C_PTR) as CLOBBER is correct. I
> looked through the 2018 standard and could not locate anything that
> addresses this use case. Are you interpreting the possibility that a
> TYPE(C_PTR) should not be declared INTENT(OUT)?

Fortran 2023, 8.5.10

The INTENT (OUT) attribute for a nonpointer dummy argument specifies
that the dummy argument becomes undefined on invocation of the procedure,
except for any subcomponents that are default-initialized (7.5.4.6).

[Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Scot Breitenfeld from comment #3)
> I guess the issue is whether marking TYPE(C_PTR) as CLOBBER is correct. I
> looked through the 2018 standard and could not locate anything that
> addresses this use case. Are you interpreting the possibility that a
> TYPE(C_PTR) should not be declared INTENT(OUT)?

Maybe I am missing your intention, but I interpret your code that you
want to pass a (C) pointer to variable attr_rdata0 to return your result.
But that needs to be intent(in).  Your subroutine is not really supposed
to return a pointer but a result in the location the pointer dereferences.

Feel free to correct me.

> I can instead change the subroutine to declare buf as
> 
> INTEGER(C_INT), INTENT(OUT), TARGET :: buf
> 
> and f_ptr = C_LOC(buf) and there is no issue.

I cannot confirm this with my gcc installations, and there is no reason
that this should make a difference.

> So it seems to depend on the
> TYPE of the argument being passed.

There are cases where no clobber is currently generated.  For example,
if the dummy variable is a Fortran pointer, which has a completely
different semantics from TYPE(C_PTR).

Still I don't understand why you don't use INTENT(IN) for the pointer.
In that case you could do things in the main like:

  CALL H5Aread_async_f(C_LOC(attr_rdata0))

which appears to represent what I am guessing, and which gets rejected for
INTENT /= IN with a possibly more helpful error message.

[Bug testsuite/66005] libgomp make check time is excessive

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

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

--- Comment #14 from Thomas Schwinge  ---
(In reply to Eric Gallager from comment #12)
> Note that there's a gnulib module for flock:
> https://www.gnu.org/software/gnulib/manual/html_node/flock.html

I'd see that one -- but it also says: "the replacement function does not really
work", so I don't think that's useful?

(In reply to Jakub Jelinek from comment #13)
> And fcntl in tclx.

Seen that, too -- but is TclX something that people actually have
available/installed?  (Rainer?)

> Anyway, I think choosing between flock(1) and some
> python file locking would be better than using perl which is only needed in
> maintainer mode and not otherwise.

Rainer, would a 'python3' variant work for you?

[Bug fortran/109865] different results when routine moved inside the contains statement

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

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

--- Comment #6 from kargl at gcc dot gnu.org ---
(In reply to gary.wh...@colostate.edu from comment #5)
> (In reply to Steve Kargl from comment #4)

> > I assume you've also tried with -fcheck=all.
> > Your report states you're using og12.  If 
> > it supports the sanitizer, can you add 
> > -fsanitize=undefined to the options?
> 
> -fcheck=all does not generate any warnings.
> -fsanitize=undefined returns pages when loading of:
> 
> undefined reference to `__ubsan_handle_pointer_overflow'
> 
> which makes no sense to me

Hmmm.  Thanks for checking.  Either your version of
gcc is not built with --enable-libsanitizer or 
gfortran cannot find the library.  At this point,
it seems we're going to need a complete testcase.

[Bug fortran/109865] different results when routine moved inside the contains statement

[Gary.White at ColoState dot edu via Gcc-bugs]

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

--- Comment #5 from GARY.WHITE at ColoState dot edu  ---
(In reply to Steve Kargl from comment #4)
> On Mon, May 15, 2023 at 07:11:17PM +, Gary.White at ColoState dot edu
> wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865
> > (In reply to kargl from comment #2)
> > > (In reply to gary.wh...@colostate.edu from comment #0)
> > > 
> > > > Options being used to compile the code:
> > > > COPTIONS = -cpp -std=f2018 -c -D ieee -D dbleprecision -m64
> > > > -fsignaling-nans -ffpe-summary='invalid','zero','overflow','underflow' 
> > > > -O3
> > > > -funroll-loops -ffast-math 
> > > 
> > > What happens if you remove -ffast-math and use -O0 or -O1?
> > 
> > -O0 generates correct code with or without -ffastmath, -O1 does not generate
> > correct code.
> 
> I assume you've also tried with -fcheck=all.
> Your report states you're using og12.  If 
> it supports the sanitizer, can you add 
> -fsanitize=undefined to the options?

-fcheck=all does not generate any warnings.
-fsanitize=undefined returns pages when loading of:

undefined reference to `__ubsan_handle_pointer_overflow'

which makes no sense to me

[Bug testsuite/66005] libgomp make check time is excessive

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

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

--- Comment #13 from Jakub Jelinek  ---
And fcntl in tclx.  Anyway, I think choosing between flock(1) and some python
file locking would be better than using perl which is only needed in maintainer
mode and not otherwise.

[Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.

[brtnfld at hdfgroup dot org via Gcc-bugs]

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

--- Comment #3 from Scot Breitenfeld  ---
I see the same issue with NAG, regardless of the optimization level. Our CI
testing had missed it because this was a parallel test, and we don't test
parallel with NAG.

I guess the issue is whether marking TYPE(C_PTR) as CLOBBER is correct. I
looked through the 2018 standard and could not locate anything that addresses
this use case. Are you interpreting the possibility that a TYPE(C_PTR) should
not be declared INTENT(OUT)?

I can instead change the subroutine to declare buf as

INTEGER(C_INT), INTENT(OUT), TARGET :: buf

and f_ptr = C_LOC(buf) and there is no issue. So it seems to depend on the TYPE
of the argument being passed.

[Bug testsuite/66005] libgomp make check time is excessive

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

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

--- Comment #12 from Eric Gallager  ---
Note that there's a gnulib module for flock:
https://www.gnu.org/software/gnulib/manual/html_node/flock.html

[Bug fortran/109865] different results when routine moved inside the contains statement

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

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

--- Comment #4 from Steve Kargl  ---
On Mon, May 15, 2023 at 07:11:17PM +, Gary.White at ColoState dot edu
wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109865
> (In reply to kargl from comment #2)
> > (In reply to gary.wh...@colostate.edu from comment #0)
> > 
> > > Options being used to compile the code:
> > >   COPTIONS = -cpp -std=f2018 -c -D ieee -D dbleprecision -m64
> > > -fsignaling-nans -ffpe-summary='invalid','zero','overflow','underflow' -O3
> > > -funroll-loops -ffast-math 
> > 
> > What happens if you remove -ffast-math and use -O0 or -O1?
> 
> -O0 generates correct code with or without -ffastmath, -O1 does not generate
> correct code.

I assume you've also tried with -fcheck=all.
Your report states you're using og12.  If 
it supports the sanitizer, can you add 
-fsanitize=undefined to the options?

[Bug fortran/109865] different results when routine moved inside the contains statement

[Gary.White at ColoState dot edu via Gcc-bugs]

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

--- Comment #3 from GARY.WHITE at ColoState dot edu  ---
(In reply to kargl from comment #2)
> (In reply to gary.wh...@colostate.edu from comment #0)
> > Created attachment 55087 [details]
> > set of subroutines where moving mc11ad inside the contains statement
> > produces incorrect results
> > 
> > In the following code, when the subroutine mc11ad is moved inside the
> > contains statement, incorrect results are produced.
> 
> Produce wrong results is meaningless as you haven't told what the
> correct results and wrong results are.  A difference in the 7
> decimal place for REAL may be entirely possible due to floating
> point round-off
> 
> > Options being used to compile the code:
> > COPTIONS = -cpp -std=f2018 -c -D ieee -D dbleprecision -m64
> > -fsignaling-nans -ffpe-summary='invalid','zero','overflow','underflow' -O3
> > -funroll-loops -ffast-math 
> 
> What happens if you remove -ffast-math and use -O0 or -O1?

-O0 generates correct code with or without -ffastmath, -O1 does not generate
correct code.

[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org

--- Comment #14 from Thomas Schwinge  ---
(In reply to Jonathan Wakely from comment #13)
> (In reply to Thomas Koenig from comment #7)
> > Author: tkoenig
> > Date: Thu Nov 16 20:24:00 2017
> > New Revision: 254845
> > 
> > URL: https://gcc.gnu.org/viewcvs?rev=254845&root=gcc&view=rev
> > Log:
> > 2017-11-16  Thomas Koenig  
> > 
> > PR bootstrap/82856
> > * doc/install.texi: Document incompatibility of Perl >=5.6.26
> > with the required version of automake 1.11.6.
> > 
> > 
> > Modified:
> > trunk/gcc/ChangeLog
> > trunk/gcc/doc/install.texi
> 
> Thomas, this patch refers to a non-existent 5.6.26 version (did you mean
> 5.26.0?)
> 
> But is this even still relevant now that we've updated the automake version?
> Can we revert it to just say 5.6.1 or later?

Indeed; 
"Back to requiring "Perl version 5.6.1 (or later)" [PR82856]".

[Bug fortran/109865] different results when routine moved inside the contains statement

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to gary.wh...@colostate.edu from comment #0)
> Created attachment 55087 [details]
> set of subroutines where moving mc11ad inside the contains statement
> produces incorrect results
> 
> In the following code, when the subroutine mc11ad is moved inside the
> contains statement, incorrect results are produced.

Produce wrong results is meaningless as you haven't told what the
correct results and wrong results are.  A difference in the 7
decimal place for REAL may be entirely possible due to floating
point round-off

> Options being used to compile the code:
>   COPTIONS = -cpp -std=f2018 -c -D ieee -D dbleprecision -m64
> -fsignaling-nans -ffpe-summary='invalid','zero','overflow','underflow' -O3
> -funroll-loops -ffast-math 

What happens if you remove -ffast-math and use -O0 or -O1?

[Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.

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

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #1)
> I think that you might want to cross-check your testcase with the NAG
> compiler, or some other compiler which provides a means to initialize
> INTENT(OUT) arguments to detect such code.

I've just checked: NAG behaves similarly to gfortran; the code crashes
with INTENT(OUT) and works with INTENT(INOUT) as well as INTENT(IN).

[Bug rtl-optimization/109866] New: Sometimes using sub/test instead just test

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

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

Bug ID: 109866
   Summary: Sometimes using sub/test instead just test
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
int g(void); int h(void); int t(void);
int f(int a, int b)
{
  int c = a - b;
  if(c == 0)
return g();
  if (c > 0)
return h();
  return t();
}
```
This is reduced from bzip2 in spec 2006, though I am not so sure any more.
On x86_64 GCC produces:
```
subl%esi, %edi
testl   %edi, %edi
je  .L5
jle .L3
jmp h()
.L3:
jmp t()
.L5:
jmp g()
```
But GCC should produce (likes clang/LLVM does):
```
cmpl%esi, %edi
je  .L5
jle .L3
jmp h()
.L3:
jmp t()
.L5:
jmp g()
```

Note a similar thing happens with aarch64 target too.

[Bug testsuite/66005] libgomp make check time is excessive

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

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

--- Comment #11 from Thomas Schwinge  ---
(In reply to myself from comment #10)
> Could we easily build a portable 'flock'-like using 'fcntl' locking
> primitives?

(, for
example.)

> (I've not yet looked.)


But simpler, is it OK to require Perl (Ick!) for parallelized
'check-target-libgomp'?  There's ,
and I've got that implemented as a fallback 'flock'.  (It's certainly not,
after two decades or so, my desire to write something in Perl, but I suppose
it's available "almost everywhere" and the fallback 'flock' is simple to
implement.)

[Bug fortran/109865] different results when routine moved inside the contains statement

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2023-05-15
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Please provide a compilable, self-contained testcase.  I get:

varmat.F90:3:11:

3 |   use status_module
  |   1
Fatal Error: Cannot open module file 'status_module.mod' for reading at (1): No
such file or directory
compilation terminated.

[Bug fortran/109861] Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2023-05-15
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
 CC||anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
I believe the sample code is misleading, and the behavior is expected:

  SUBROUTINE h5aread_async_f(buf)
TYPE(C_PTR), INTENT(OUT) :: buf

You can see what happens if you specify the flag -fdump-tree-original as
part of F90FLAGS.

Now compare the dump-tree for INTENT(INOUT) vs. INTENT(OUT):

--- fcode.F90.005t.original.inout   2023-05-15 20:03:07.292148948 +0200
+++ fcode.F90.005t.original.out 2023-05-15 20:03:36.292208016 +0200
@@ -19,6 +19,7 @@
 D.4223 = (void *) &attr_rdata0;
 f_ptr = D.4223;
   }
+  f_ptr = {CLOBBER};
   h5aread_async_f (&f_ptr);
   {
 struct __st_parameter_dt dt_parm.0;

When the dummy argument buf is declared with INTENT(OUT), we mark the
actual argument in the caller with CLOBBER, which means that the optimizer
may throw away previous calculations and assignments as they do not matter.

If you add a line

print '(Z16.16)', buf

into that subroutine, you'll see that the clobber annotation serves its
purpose once optimization is enabled.

I think that you might want to cross-check your testcase with the NAG
compiler, or some other compiler which provides a means to initialize
INTENT(OUT) arguments to detect such code.

[Bug fortran/109865] New: different results when routine moved inside the contains statement

[Gary.White at ColoState dot edu via Gcc-bugs]

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

Bug ID: 109865
   Summary: different results when routine moved inside the
contains statement
   Product: gcc
   Version: og12 (devel/omp/gcc-12)
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Gary.White at ColoState dot edu
  Target Milestone: ---

Created attachment 55087
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55087&action=edit
set of subroutines where moving mc11ad inside the contains statement produces
incorrect results

In the following code, when the subroutine mc11ad is moved inside the contains
statement, incorrect results are produced.  Works fine outside the contains
statement as provided here.  This subroutine is only called from the main
subroutine va09ad, nowhere else.  Other clues are that if I put this routine
inside a module, incorrect results are produced.  This set of routines is used
in a much larger code, so I'm not able to isolate the problem down to a simple
example.  

I have verified that this is a gfortran bug because the code produces correct
results with the Intel compiler with mc11ad inside or outside the contains
statement.

gfortran compiler I'm using:
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
12.1.0-2ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-12
--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-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-12-sZcx2y/gcc-12-12.1.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-sZcx2y/gcc-12-12.1.0/debian/tmp-gcn/usr
--enable-offload-defaulted --without-cuda-driver --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (Ubuntu 12.1.0-2ubuntu1~22.04)

Options being used to compile the code:
COPTIONS = -cpp -std=f2018 -c -D ieee -D dbleprecision -m64
-fsignaling-nans -ffpe-summary='invalid','zero','overflow','underflow' -O3
-funroll-loops -ffast-math 


  subroutine
va09ad(functn,n,x,f,g,h,w,dfn,eps2,mode,maxfn,iprint,iexit,itn,parm,beta,design)
 use status_module, only : int32, wp, sysout, syscrn, nlogit,
ncovs_nlbetas, ncovs, &
zero, one, two, modnam, num_to_str, outtext
 implicit none
 integer(kind=int32), intent(in) :: n, mode, maxfn, iprint
 integer(kind=int32), intent(out) :: iexit, itn
 real(kind=wp), intent(in) :: dfn, eps2(n)
 real(kind=wp), intent(out) ::  x(n),g(n),h(n*(n+1)/2),w(n*3), f
 real(kind=wp), intent(out) :: parm(nlogit), beta(ncovs_nlbetas),
design(nlogit,ncovs)
 external functn
 integer(kind=int32) ig, igg, is, ir, mk, ij, i, ifn, icon
 real(kind=wp)   alphalocal, z, gs, gys, df, gs0, tot, fy, zz, dgs,
sigma, epsln
 character(len=:), allocatable :: frmt

 interface 
subroutine functn(nparm, xbeta, xloglk, g, parm, beta, design)
   use status_module  
   use data_module
   implicit none
   integer(kind=int32), intent(in) :: nparm
   real(kind=wp), intent(in out) :: xbeta(nparm), g(nparm),
parm(nlogit), beta(ncovs_nlbetas), design(nlogit,ncovs)   
   real(kind=wp), intent(out) :: xloglk
end subroutine functn
 end interface

 ! This interface causes problems with prcisub.f90, 
 ! just as does including mc11ad inside the contains statement.
 !interface
 !   subroutine mc11ad(a,n,z,sigma,w,ir,mk,eps2)
 !  use status_module, only : wp, int32, zero, one
 !  implicit none
 !  integer(kind=int32), intent(in)  :: n, mk
 !  integer(kind=int32), intent(out) :: ir
 !  real(kind=wp), intent(in out) :: a(n*(n+1)/2),z(n),w(n*3)
 !  real(kind=wp), intent(in) :: eps2
 !  real(kind=w

[Bug target/105719] RFE: fixincludes should handle Frameworks

[bkorb at gnu dot org via Gcc-bugs]

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

--- Comment #5 from Bruce Korb  ---
It's been a long time since I mucked with fixincludes. My first guess, without
going back and reading code, would be to provide fixincludes with a list of
trees to traverse and not have it burned into fixincludes at all. That might
even be helpful for cross compiles also. :)

[Bug c++/109864] excplicit constructor considered during overload resolution leads to ambiguity

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

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

Arsen Arsenović  changed:

   What|Removed |Added

 CC||arsen at gcc dot gnu.org

--- Comment #2 from Arsen Arsenović  ---
seems to be https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109247

a near exact match, even

[Bug c++/109864] excplicit constructor considered during overload resolution leads to ambiguity

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

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

--- Comment #1 from Andrew Pinski  ---
Note there are some C++ defect reports in this area 
And this is most likely a dup of another bug.

[Bug c++/109864] New: excplicit constructor considered during overload resolution leads to ambiguity

[dmatthews at utexas dot edu via Gcc-bugs]

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

Bug ID: 109864
   Summary: excplicit constructor considered during overload
resolution leads to ambiguity
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmatthews at utexas dot edu
  Target Milestone: ---

gcc version:


Using built-in specs.
COLLECT_GCC=/opt/homebrew/opt/gcc/bin/gcc-13
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/13.1.0/bin/../libexec/gcc/aarch64-apple-darwin21/13/lto-wrapper
Target: aarch64-apple-darwin21
Configured with: ../configure --prefix=/opt/homebrew/opt/gcc
--libdir=/opt/homebrew/opt/gcc/lib/gcc/current --disable-nls
--enable-checking=release --with-gcc-major-version-only
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-13
--with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr
--with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl
--with-zstd=/opt/homebrew/opt/zstd --with-pkgversion='Homebrew GCC 13.1.0'
--with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--with-system-zlib --build=aarch64-apple-darwin21
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (Homebrew GCC 13.1.0)

(also tested on all x86_64 versions back to 4.9.x on godbolt.org)

Steps to reproduce:
---

1. Enter the following program in test.cxx:

#include 

struct foo
{
foo(std::initializer_list) {}
};

struct bar
{
explicit bar(std::initializer_list) {}
bar() {}
void baz(foo) {}
void baz(bar&&) {}
};

int main()
{
bar x;
x.baz({1,2});
}

2. Compile with "gcc test.cxx".

Expected result:


The program should compile successfully, with a call to bar::baz(foo).

Actual result:
--

gcc reports an ambiguity between bar::baz(foo) and bar::baz(bar&&) even though
the latter involves the explicit constructor
bar::bar(std::initializer_list) during an implicit conversion:

test.cxx: In function 'int main()':
test.cxx:19:10: error: call of overloaded 'baz()' is ambiguous
   19 | x.baz({1,2});
  | ~^~~
test.cxx:12:10: note: candidate: 'void bar::baz(foo)'
   12 | void baz(foo) {}
  |  ^~~
test.cxx:13:10: note: candidate: 'void bar::baz(bar&&)'
   13 | void baz(bar&&) {}
  |  ^~~

[Bug fortran/109846] Pointer-valued function reference rejected as actual argument

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

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

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

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

commit r14-863-gfa0569e90efe8a5cb895a3f50dd502f849940828
Author: Harald Anlauf 
Date:   Sun May 14 21:53:51 2023 +0200

Fortran: CLASS pointer function result in variable definition context
[PR109846]

gcc/fortran/ChangeLog:

PR fortran/109846
* expr.cc (gfc_check_vardef_context): Check appropriate pointer
attribute for CLASS vs. non-CLASS function result in variable
definition context.

gcc/testsuite/ChangeLog:

PR fortran/109846
* gfortran.dg/ptr-func-5.f90: New test.

[Bug tree-optimization/109695] [14 Regression] crash in gimple_ranger::range_of_expr since r14-377-gc92b8be9b52b7e

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

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

--- Comment #36 from CVS Commits  ---
The master branch has been updated by Aldy Hernandez :

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

commit r14-862-g76e11280e79c5dd5089c17d5726cae9a5a21bc2e
Author: Aldy Hernandez 
Date:   Mon May 15 12:25:58 2023 +0200

Add auto-resizing capability to irange's [PR109695]


We can now have int_range for automatically
resizable ranges.  int_range_max is now int_range<3, true>
for a 69X reduction in size from current trunk, and 6.9X reduction from
GCC12.  This incurs a 5% performance penalty for VRP that is more than
covered by our > 13% improvements recently.


int_range_max is the temporary range object we use in the ranger for
integers.  With the conversion to wide_int, this structure bloated up
significantly because wide_ints are huge (80 bytes a piece) and are
about 10 times as big as a plain tree.  Since the temporary object
requires 255 sub-ranges, that's 255 * 80 * 2, plus the control word.
This means the structure grew from 4112 bytes to 40912 bytes.

This patch adds the ability to resize ranges as needed, defaulting to
no resizing, while int_range_max now defaults to 3 sub-ranges (instead
of 255) and grows to 255 when the range being calculated does not fit.

For example:

int_range<1> foo;   // 1 sub-range with no resizing.
int_range<5> foo;   // 5 sub-ranges with no resizing.
int_range<5, true> foo; // 5 sub-ranges with resizing.

I ran some tests and found that 3 sub-ranges cover 99% of cases, so
I've set the int_range_max default to that:

typedef int_range<3, /*RESIZABLE=*/true> int_range_max;

We don't bother growing incrementally, since the default covers most
cases and we have a 255 hard-limit.  This hard limit could be reduced
to 128, since my tests never saw a range needing more than 124, but we
could do that as a follow-up if needed.

With 3-subranges, int_range_max is now 592 bytes versus 40912 for
trunk, and versus 4112 bytes for GCC12!  The penalty is 5.04% for VRP
and 3.02% for threading, with no noticeable change in overall
compilation (0.27%).  This is more than covered by our 13.26%
improvements for the legacy removal + wide_int conversion.

I think this approach is a good alternative, while providing us with
flexibility going forward.  For example, we could try defaulting to a
8 sub-ranges for a noticeable improvement in VRP.  We could also use
large sub-ranges for switch analysis to avoid resizing.

Another approach I tried was always resizing.  With this, we could
drop the whole int_range nonsense, and have irange just hold a
resizable range.  This simplified things, but incurred a 7% penalty on
ipa_cp.  This was hard to pinpoint, and I'm not entirely convinced
this wasn't some artifact of valgrind.  However, until we're sure,
let's avoid massive changes, especially since IPA changes are coming
up.

For the curious, a particular hot spot for IPA in this area was:

ipcp_vr_lattice::meet_with_1 (const value_range *other_vr)
{
...
...
  value_range save (m_vr);
  m_vr.union_ (*other_vr);
  return m_vr != save;
}

The problem isn't the resizing (since we do that at most once) but the
fact that for some functions with lots of callers we end up a huge
range that gets copied and compared for every meet operation.  Maybe
the IPA algorithm could be adjusted somehow??.

Anywhooo... for now there is nothing to worry about, since value_range
still has 2 subranges and is not resizable.  But we should probably
think what if anything we want to do here, as I envision IPA using
infinite ranges here (well, int_range_max) and handling frange's, etc.

gcc/ChangeLog:

PR tree-optimization/109695
* value-range.cc (irange::operator=): Resize range.
(irange::union_): Same.
(irange::intersect): Same.
(irange::invert): Same.
(int_range_max): Default to 3 sub-ranges and resize as needed.
* value-range.h (irange::maybe_resize): New.
(~int_range): New.
(int_range::int_range): Adjust for resizing.
(int_range::operator=): Same.

[Bug other/105819] comma `,` in directory name causes build to fail

[bug-reports.delphin at laposte dot net via Gcc-bugs]

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

--- Comment #17 from bug-reports.delphin at laposte dot net ---
First of all, thank you very much. You were stronly right.

In fact, it was not a PATH error, but a folder name error. I check it again and
it was true : unfortunately, I changed a dot sign to a coma sign in the name of
the folders.

I zoomed my Terminal window, and I found this : my eye vision has fairly
weakened. I didn't well differentiate between the two signs, my vision now is
too low. Even though I changed some months ago my glasses : myopia decreased,
but presbyopia increased. The new lenses have corrected - in its way of
accomodation... - the crystalline(eye) lenses, but I found that the field of
view is now very reduces : just a rectangle with a 1-mm width only,
approximately. Good book reading but failing to work before a computer screen
during several hours each day. I met the optician two weeks ago, and, when I
told her I work on a computer from the morning to the afternoon, explaining my
issues with such a vision and their glasses, she told me that my glasses are
not fairly adapted to screen reading. Now, I need to buy new dedicated glasses
for screen working, with wider and a larger and wider field of view (but not
good for book reading). Next months, or in one year.

With GCC, it was now well compiled for versions : 12.1.0, 12.2.0, 13.1.0. I had
just a matter for the 1st compilation of 13.1.0 : it looped during several (>=
6) hours at the step : echo timestamp s-gyte. I canceled the process and
started it again, after having cleaned everything in the build folder. It
compiled to the end in around 10 hours now.

Son, an advice for every developer :

Even though you are young or have a good vision, ALWAYS wear glasses protecting
your eyes when you are in front of a screen. ALWAYS. Otherwise, one day, your
vision will stronly weaken.

As an example ->

https://www.essilorindia.com/products/computer-glasses

Kind regards,

L. D.

[Bug c/109828] [13/14 Regression] static compound literal with flexible array in initializer leads to invalid size and ICE

[yann at droneaud dot fr via Gcc-bugs]

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

--- Comment #8 from Yann Droneaud  ---
(In reply to Yann Droneaud from comment #7)
> I've also experimented compound literal initialization at block level
> instead of file level. Except in case it's not supported, it shows the same
> issue at block level as file level.
> 
> https://godbolt.org/z/vn5Pn7hTx
> 
> Unrelated, I've noted it's not possible to initialize the flexible array if
> the initializer is not having a static storage. I would have expected this
> restriction to be lifted by now.

I've opened bug #109863

[Bug c/109863] New: RFE: more consistent flex array initialization: lift static storage requirement in gnu2x

[yann at droneaud dot fr via Gcc-bugs]

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

Bug ID: 109863
   Summary: RFE: more consistent flex array initialization: lift
static storage requirement in gnu2x
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yann at droneaud dot fr
  Target Milestone: ---

I've noted some discrepancies in the flex array initialization support:

/* https://godbolt.org/z/9er5G9G15 */

struct s { char i; char c[]; };

extern void t(const struct s*);

void f(void)
{
// ERROR: non-static initialization of a flexible array member
const struct s c0 = { .c = "0", };
t(&c0);

// ERROR: non-static initialization of a flexible array member
const struct s *const c1 = &(const struct s) { .c = "1", };
t(c1);

// OK
const struct s *const c2 = &(constexpr struct s) { .c = "2", };
t(c2);

// ERROR: initializer element is not constant
static const struct s *const c3 = &(constexpr struct s) { .c = "3", };
t(c3);

// OK
static const struct s *const c4 = &(static constexpr struct s) { .c =
"4", };
t(c4);
}

AFAICT constexpr is not supposed to also mean static storage at the block
level, so flex array in c2 is initialized in a non-static way ...

Then I would be happy if GCC could be enhanced to not reject c0 and c1
initialization.

But I fear the opposite will happen, and GCC will reject c2 initialization too
:)

[Bug tree-optimization/109862] IV-OPTs could use int but still uses smaller sized for IV

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/109862] New: IV-OPTs could use int but still uses smaller sized for IV

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

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

Bug ID: 109862
   Summary: IV-OPTs could use int but still uses smaller sized for
IV
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64, riscv32, riscv64

Take:
```
int f(char a)
{
unsigned char t;
unsigned short t1 = a;
for(t = 0; t < 8; t ++)
{
t1 >>=1;
t1 += a;
}
return t1;
}
int f1(char a)
{
unsigned int t;
unsigned short t1 = a;
for(t = 0; t < 8; t ++)
{
t1 >>=1;
t1 += a;
}
return t1;
}

```
f1 produces better code as there is no extra zero-extend (anding) inside the
loop for the IV of t.

Note this shows up in coremarks in the crc functions (if not unrolling).

[Bug tree-optimization/109852] Making of gcc13 errors out compiling libcpp/charset.cc with Wstringop-overflow Error with "-march=native -O3 "

[ferdasi at opentrash dot com via Gcc-bugs]

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

--- Comment #5 from Erich  ---
The output of -v ->
Lesen der Spezifikationen von
/home//software/gcc13/host-x86_64-pc-linux-gnu/prev-gcc/specs
COLLECT_GCC=/home//software/gcc13/host-x86_64-pc-linux-gnu/prev-gcc/xg++
Ziel: x86_64-pc-linux-gnu
Konfiguriert mit: configure --disable-multilib
--prefix=/home//software/gccinstall
Thread-Modell: posix
Unterstützte LTO-Kompressionsalgorithmen: zlib zstd
gcc-Version 14.0.0 20230514 (experimental) (GCC)

[Bug tree-optimization/109852] Making of gcc13 errors out compiling libcpp/charset.cc with Wstringop-overflow Error with "-march=native -O3 "

[ferdasi at opentrash dot com via Gcc-bugs]

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

--- Comment #4 from Erich  ---
Created attachment 55086
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55086&action=edit
Compressed preprocessed charset.i file

[Bug c++/109241] [12/13/14 Regression] ICE Segmentation fault for statement expression with a local type inside inside a generic lambda inside a generic lambda since r13-6722-gb323f52ccf966800

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

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

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

https://gcc.gnu.org/g:396a4e76afec30d2461638f569cae18955eb4ad2

commit r12-9539-g396a4e76afec30d2461638f569cae18955eb4ad2
Author: Jason Merrill 
Date:   Wed Mar 22 16:11:47 2023 -0400

c++: local class in nested generic lambda [PR109241]

In this testcase, the tree walk to look for bare parameter packs was
confused by finding a type with no TREE_BINFO.  But it should be fine that
it's unset; we already checked for unexpanded packs at parse time.

I also tried doing the partial instantiation of the local class, which is
probably the long-term direction we want to go, but for stage 4 let's go
with this safer change.

PR c++/109241

gcc/cp/ChangeLog:

* pt.cc (find_parameter_packs_r): Handle null TREE_BINFO.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/lambda-generic-local-class2.C: New test.

[Bug c++/109860] ICE: in make_typename_type with redudant template in requires with typename

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-05-15
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug c++/109860] ICE: in make_typename_type with redudant template in requires with typename

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||8.1.0
Summary|ICE: in make_typename_type, |ICE: in make_typename_type
   |at cp/decl.cc:4268  |with redudant template in
   ||requires with typename
   Keywords|ice-on-invalid-code |ice-on-valid-code

--- Comment #1 from Andrew Pinski  ---
This code is valid as far as I Know.
Reduced testcase:
```
namespace t {
  template
  struct tuple {};
}
template
concept C = requires {
 typename t::template tuple;
};
```

clang accepts the code. the template there is not needed but should be ok.

[Bug c++/109859] [12/13/14 Regression] ICE on concept mis-typed as template type parameter

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-05-15

[Bug c++/109859] [12/13/14 Regression] ICE on concept mis-typed as template type parameter

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
   Target Milestone|--- |12.4
Summary|ICE on concept mis-typed as |[12/13/14 Regression] ICE
   |template type parameter |on concept mis-typed as
   ||template type parameter

--- Comment #2 from Andrew Pinski  ---
In GCC 11 and before, GCC would accept the reduced testcase but didn't ICE.

[Bug libgcc/109712] Segmentation fault in linear_search_fdes

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Carlos Galvez  ---
Upon closer inspection, it turns out we were building with GCC 7, but then
using libgcc_s.so.1 and libstdc++.so.6 from GCC trunk at runtime (via
LD_LIBRARY_PATH). Building with GCC trunk instead solves the segfault I
described above.

In particular it seems the problem is libgcc_s.so.1 - if I use the system-wide 
one (older) instead of the one from GCC trunk, the problem goes away.

Is this expected though? My understanding was that libgcc_s and libstdc++ are
backwards compatible, i.e. I can always keep the latest one installed on my
system and I should be able to run applications linked against older libraries
(which is what is happening here). There's also symbol versioning so old
symbols are kept.

[Bug testsuite/66005] libgomp make check time is excessive

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

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #10 from Thomas Schwinge  ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > --- Comment #7 from Thomas Schwinge  ---
> > Resolved for GCC 14.  Not planning on backporting to release branches (but
> > could, if desired).
> 
> Unfortunately not: flock is completely unportable.  It's not in
> POSIX.1/XPG7, and none of Solaris, macOS, or AIX have it.

OK, indeed my approach depends on 'flock'.  Otherwise, we still serialize
'check-target-libgomp', as before.

(In reply to Jakub Jelinek from comment #9)
> r5-3553 uses if {![catch {open $path {RDWR CREAT EXCL} 0600} fd]} { to
> determine which make check invocation should be given a particular batch of
> tests (in an initially empty directory), could you use that instead?

We'd like something that blocks until the lock is available, and something that
works on file descriptors and unlocks implicitly upon 'close'/process exit (to
avoid stale locks).

Using something like Jakub posted with spinning probably does waste too many
parallel slots here?  I'll try to experiment with that, though: at the long
tail at the end of overall parallel testing (that is, when all parallel slots
are otherwise unused), it's still better than no parallelism at all?

Could we easily build a portable 'flock'-like using 'fcntl' locking primitives?
 (I've not yet looked.)

[Bug libstdc++/109857] Debian stable's tzdata 2021a has bad data that cannot be parsed by libstdc++

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||http://bugs.debian.org/1036
   ||104

--- Comment #3 from Jonathan Wakely  ---
FWIW I've confirmed that libstdc++ is able to parse all tzdata.zi files from
2019a to 2023c, using the upstream files.

The Debian bug has been reported to bugs.debian.org.

I'll keep this bug open because I still think this would be a good idea:

(In reply to Jonathan Wakely from comment #0)
> We should also consider ignoring the system tzdata files if the bundled copy
> (currently 2023c) is newer. Or at least try using the bundled one if the
> parsing the system file fails, as in this case.

[Bug fortran/109861] New: Optimization is marking uninitialized C_PTR being passed to a C function, causes segfault.

[brtnfld at hdfgroup dot org via Gcc-bugs]

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

Bug ID: 109861
   Summary: Optimization is marking  uninitialized  C_PTR being
passed to a C function, causes segfault.
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: brtnfld at hdfgroup dot org
  Target Milestone: ---

Created attachment 55085
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55085&action=edit
Fortran/C/Makfile. Changing the optimization level in the makefile reproduces
the behaviour.

For a TYPE(C_PTR), INTENT(OUT), buf, which is being passed through a Fortran
subroutine to get the value set in a C function, an optimization of >= -O1
gives the warning "used uninitialized [-Wuninitialized]" and then the program
Segmentation faults - invalid memory reference. It works for gfortran 12 but
fails for gfortran 13 and 14. It works if the INTENT is INOUT.

[Bug libstdc++/109857] tzdata 2021a has bad data that cannot be parsed by libstdc++

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> On debian stable the tzdata.zi file is from version 2021a of the IANA time
> zone database and contains this line:
> 
> R K 2023 Max - O lastTh 24 0 -

This is a Debian-specific bug, because they backported the Egypt DST changes:
https://github.com/eggert/tz/commit/dcd8cbed23201416cbd3bbf43f669737693282d7
but not the typo fix:
https://github.com/eggert/tz/commit/af242d11b62584808a66851b8707148bf1ee8d0a

I'm not sure we should bother handling this in libstdc++.

[Bug c/109828] [13/14 Regression] static compound literal with flexible array in initializer leads to invalid size and ICE

[yann at droneaud dot fr via Gcc-bugs]

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

--- Comment #7 from Yann Droneaud  ---
I've also experimented compound literal initialization at block level instead
of file level. Except in case it's not supported, it shows the same issue at
block level as file level.

https://godbolt.org/z/vn5Pn7hTx

Unrelated, I've noted it's not possible to initialize the flexible array if the
initializer is not having a static storage. I would have expected this
restriction to be lifted by now.

[Bug testsuite/66005] libgomp make check time is excessive

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

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

--- Comment #9 from Jakub Jelinek  ---
r5-3553 uses if {![catch {open $path {RDWR CREAT EXCL} 0600} fd]} { to
determine which make check invocation should be given a particular batch of
tests (in an initially empty directory), could you use that instead?

[Bug testsuite/66005] libgomp make check time is excessive

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

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from Thomas Schwinge  ---
> Resolved for GCC 14.  Not planning on backporting to release branches (but
> could, if desired).

Unfortunately not: flock is completely unportable.  It's not in
POSIX.1/XPG7, and none of Solaris, macOS, or AIX have it.

[Bug testsuite/91884] libgomp testsuite: (not) using a specific driver for C++, Fortran

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

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #7 from Thomas Schwinge  ---
Resolved for GCC 14.  Not planning on backporting to release branches (but
could, if desired).

[Bug testsuite/66005] libgomp make check time is excessive

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

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

Thomas Schwinge  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
  Component|libgomp |testsuite
   Keywords||openacc, openmp

--- Comment #7 from Thomas Schwinge  ---
Resolved for GCC 14.  Not planning on backporting to release branches (but
could, if desired).

[Bug libgomp/66005] libgomp make check time is excessive

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

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

commit r14-855-g6c3b30ef9e0578509bdaf59c13da4a212fe6c2ba
Author: Thomas Schwinge 
Date:   Tue Apr 25 23:53:12 2023 +0200

Support parallel testing in libgomp, part II [PR66005]

..., and enable if 'flock' is available for serializing execution testing.

Regarding the default of 19 parallel slots, this turned out to be a local
minimum for wall time when testing this on:

$ uname -srvi
Linux 4.2.0-42-generic #49~14.04.1-Ubuntu SMP Wed Jun 29 20:22:11 UTC
2016 x86_64
$ grep '^model name' < /proc/cpuinfo | uniq -c
 32 model name  : Intel(R) Xeon(R) CPU E5-2640 v3 @ 2.60GHz

... in two configurations: case (a) standard configuration, no offloading
configured, case (b) offloading for GCN and nvptx configured but no devices
available.  For both cases, default plus '-m32' variant.

$ \time make check-target-libgomp
RUNTESTFLAGS="--target_board=unix\{,-m32\}"

Case (a), baseline:

6432.23user 332.38system 47:32.28elapsed 237%CPU (0avgtext+0avgdata
505044maxresident)k
6382.43user 319.21system 47:06.04elapsed 237%CPU (0avgtext+0avgdata
505172maxresident)k

This is what people have been complaining about, rightly so, in
 "libgomp make check time is excessive" and
elsewhere.

Case (a), parallelized:

-j12 GCC_TEST_PARALLEL_SLOTS=10
3088.49user 267.74system 6:43.82elapsed 831%CPU (0avgtext+0avgdata
505188maxresident)k
-j15 GCC_TEST_PARALLEL_SLOTS=15
3308.08user 294.79system 5:56.04elapsed 1011%CPU (0avgtext+0avgdata
505360maxresident)k
-j17 GCC_TEST_PARALLEL_SLOTS=17
3539.93user 298.99system 5:27.86elapsed 1170%CPU (0avgtext+0avgdata
505112maxresident)k
-j18 GCC_TEST_PARALLEL_SLOTS=18
3697.50user 317.18system 5:14.63elapsed 1275%CPU (0avgtext+0avgdata
505360maxresident)k
-j19 GCC_TEST_PARALLEL_SLOTS=19
3765.94user 324.27system 5:13.22elapsed 1305%CPU (0avgtext+0avgdata
505128maxresident)k
-j20 GCC_TEST_PARALLEL_SLOTS=20
3684.66user 312.32system 5:15.26elapsed 1267%CPU (0avgtext+0avgdata
505100maxresident)k
-j23 GCC_TEST_PARALLEL_SLOTS=23
4040.59user 347.10system 5:29.12elapsed 1333%CPU (0avgtext+0avgdata
505200maxresident)k
-j26 GCC_TEST_PARALLEL_SLOTS=26
3973.24user 377.96system 5:24.70elapsed 1340%CPU (0avgtext+0avgdata
505160maxresident)k
-j32 GCC_TEST_PARALLEL_SLOTS=32
4004.42user 346.10system 5:16.11elapsed 1376%CPU (0avgtext+0avgdata
505160maxresident)k

Yay!

Case (b), baseline; 2+ h:

7227.58user 700.54system 2:14:33elapsed 98%CPU (0avgtext+0avgdata
994264maxresident)k

Case (b), parallelized:

-j12 GCC_TEST_PARALLEL_SLOTS=10
7377.46user 777.52system 16:06.63elapsed 843%CPU (0avgtext+0avgdata
994344maxresident)k
-j15 GCC_TEST_PARALLEL_SLOTS=15
8019.18user 721.42system 12:13.56elapsed 1191%CPU (0avgtext+0avgdata
994228maxresident)k
-j17 GCC_TEST_PARALLEL_SLOTS=17
8530.11user 716.95system 10:45.92elapsed 1431%CPU (0avgtext+0avgdata
994176maxresident)k
-j18 GCC_TEST_PARALLEL_SLOTS=18
8776.79user 645.89system 10:27.20elapsed 1502%CPU (0avgtext+0avgdata
994248maxresident)k
-j19 GCC_TEST_PARALLEL_SLOTS=19
9332.37user 641.76system 10:15.09elapsed 1621%CPU (0avgtext+0avgdata
994260maxresident)k
-j20 GCC_TEST_PARALLEL_SLOTS=20
9609.54user 789.88system 10:26.94elapsed 1658%CPU (0avgtext+0avgdata
994284maxresident)k
-j23 GCC_TEST_PARALLEL_SLOTS=23
10362.40user 911.14system 10:44.47elapsed 1749%CPU (0avgtext+0avgdata
994208maxresident)k
-j26 GCC_TEST_PARALLEL_SLOTS=26
11159.44user 850.99system 11:09.25elapsed 1794%CPU (0avgtext+0avgdata
994256maxresident)k
-j32 GCC_TEST_PARALLEL_SLOTS=32
11453.50user 939.52system 11:00.38elapsed 1876%CPU (0avgtext+0avgdata
994240maxresident)k

On my Dell Precision 7530 laptop:

$ uname -srvi
Linux 5.15.0-71-generic #78-Ubuntu SMP Tue Apr 18 09:00:29 UTC 2023
x86_64
$ grep '^model name' < /proc/cpuinfo | uniq -c
 12 model name  : Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz
$ nvidia-smi -L
GPU 0: Quadro P1000 (UUID: GPU-e043973b-b52a-d02b-c066-a8fdbf64e8ea)

... in two configurations: case (c) standard configuration, no offloading
configured, case (d) offloading for nvptx configured and device available.
For both cases, only default variant, no '-m32'.

$ \time make check-target-libgomp

Case (c), baseline; roughly half of case (a) (just one variant):

1180.98user 110.80system 19:36.40elapsed 109%CPU (0avgtext+0avgdata
505148maxresident)k
1133.22user 

[Bug libgomp/66005] libgomp make check time is excessive

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

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

commit r14-854-ge797db5c744f7b4e110f23a495fca8e6b8aebe83
Author: Rainer Orth 
Date:   Thu May 7 13:26:57 2015 +0200

Support parallel testing in libgomp, part I [PR66005]

..., while still hard-coding the number of parallel slots to one.

PR testsuite/66005
libgomp/
* testsuite/Makefile.am (PWD_COMMAND): New variable.
(%/site.exp): New target.
(check_p_numbers0, check_p_numbers1, check_p_numbers2)
(check_p_numbers3, check_p_numbers4, check_p_numbers5)
(check_p_numbers6, check_p_numbers, gcc_test_parallel_slots)
(check_p_subdirs)
(check_DEJAGNU_libgomp_targets): New variables.
($(check_DEJAGNU_libgomp_targets)): New target.
($(check_DEJAGNU_libgomp_targets)): New dependency.
(check-DEJAGNU $(check_DEJAGNU_libgomp_targets)): New targets.
* testsuite/Makefile.in: Regenerate.
* testsuite/lib/libgomp.exp: For parallel testing,
'load_file ../libgomp-test-support.exp'.

Co-authored-by: Thomas Schwinge