[Bug middle-end/117354] ICE: in extract_bit_field_1, at expmed.cc:1838 with _BitInt (and asan in some cases)

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

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

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

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

commit r15-4796-gb39f62ff739e9ffea0e6485667f15b985f8cd63d
Author: Jakub Jelinek 
Date:   Thu Oct 31 10:52:56 2024 +0100

expand: Fix up expansion of VIEW_CONVERT_EXPR to BITINT_TYPE [PR117354]

The following testcase ICEs, because when trying to expand the
VIEW_CONVERT_EXPR operand which is SSA_NAME defined to
V32QI or V4DI MEM_REF which is aligned just to 8 bytes we force
it as unaligned into a register, but then try to call extract_bit_field
from the V32QI or V4DI register to BLKmode.  extract_bit_field doesn't
obviously support BLKmode extraction and so ICEs.

The second hunk fixes the ICE by not calling extract_bit_field when
it can't handle it, the last if will handle it properly by storing
it to memory and using BLKmode access to the copy.

The first hunk is an optimization, if mode is BLKmode, by setting
inner_reference_p argument to expand_expr_real we avoid the
expand_misaligned_mem_ref calls which load it from memory into a register.

2024-10-31  Jakub Jelinek  

PR middle-end/117354
* expr.cc (expand_expr_real_1) : Pass
true as inner_reference_p argument to expand_expr_real if
mode is BLKmode.  Don't call extract_bit_field if mode is BLKmode.

* gcc.dg/bitint-113.c: New test.

[Bug target/117365] Captured this lost after assignment to std::function

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Almost certainly a duplicate of bug 77686

[Bug modula2/117371] [14.2 Regression] type incompatibility between ‘INTEGER’ and ‘CARDINAL’

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Priority|P3  |P4
   Target Milestone|--- |14.3

[Bug analyzer/117373] [15 regression] -Wunused-parameter warning in analyzer/infinite-loop.cc

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug fortran/115700] [12/13 regression] Bogus warning for associate with assumed-length character array

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

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

--- Comment #12 from Paul Thomas  ---
(In reply to GCC Commits from comment #11)
> The master branch has been updated by Paul Thomas :
> 
> https://gcc.gnu.org/g:159fb203231c503418e7ab9f45282957e40cb195
> 
> commit r15-4793-g159fb203231c503418e7ab9f45282957e40cb195
> Author: Paul Thomas 
> Date:   Thu Oct 31 07:22:36 2024 +
> 
> Fortran: Fix problem with substring selectors in ASSOCIATE [PR115700]
> 
> 2024-10-31  Paul Thomas  
> 
> gcc/fortran
> PR fortran/115700
> * resolve.cc (resolve_variable): The typespec of an expression,
> which is not a substring, can be shared with a deferred length
> associate name.
> (resolve_assoc_var): Extract a substring reference with non-
> constant start or end. Use it to flag up the need for array
> associate name to be a pointer.
> (resolve_block_construct): Change comment from past to future
> tense.
> 
> gcc/testsuite/
> PR fortran/115700
> * gfortran.dg/associate_70.f90: New test.

Having committed this patch, I have just noticed the commented out lines in
associate_69.f90. Mea culpa, mea maxima culpa - this part is still not fixed
:-( However, this new path touches the right place.

Paul

[Bug fortran/112459] gfortran -w option causes derived-type finalization at creation time

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #5)
> so this is "just" the backport to older versions missing?

Yes.  The fix backports cleanly here.

@Paul: push, set target milestone, and close?

[Bug tree-optimization/117385] Move phiopt away from doing a COND_EXPR with a comparison as first operand

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2024-10-31

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

[Bug fortran/117381] -fmax-identifier-length= is completely ignored

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #6 from Jerry DeLisle  ---
This begs the question whether we should support longer symbols as an
extension. Maybe give a warning and error on -pedantic. (which I really dont
like so open to other ideas)

Of course the real problem is Vulkan using stupidly long names and other
compilers out of compliance.

[Bug ipa/117350] [15 Regression] ICE with autoprofiledbootstrap and bootstrap-lto after r15-4610-gbf43fe6aa966ea

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

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

--- Comment #21 from ak at gcc dot gnu.org ---
Thanks. 

I'll see if this patch is enough:

diff --git a/gcc/tree.cc b/gcc/tree.cc
index b4c059d3b0db..92f99eaccd72 100644
--- a/gcc/tree.cc
+++ b/gcc/tree.cc
@@ -787,8 +787,9 @@ need_assembler_name_p (tree decl)
   || DECL_ASSEMBLER_NAME_SET_P (decl))
 return false;

-  /* Abstract decls do not need an assembler name.  */
-  if (DECL_ABSTRACT_P (decl))
+  /* Abstract decls do not need an assembler name, except they
+ can be looked up by autofdo.  */
+  if (DECL_ABSTRACT_P (decl) && !flag_auto_profile)
 return false;

   /* For VAR_DECLs, only static, public and external symbols need an

[Bug c/117245] [13/14/15 Regression] ICE: verify_ssa failed (error: definition in block 2 follows the use) with VLA types in struct with a vector type rebuild and nested functions since r13-6128-g4782

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

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

--- Comment #9 from GCC Commits  ---
The master branch has been updated by Martin Uecker :

https://gcc.gnu.org/g:9eae9268e41463927c9383004e58708048ec379f

commit r15-4812-g9eae9268e41463927c9383004e58708048ec379f
Author: Martin Uecker 
Date:   Tue Oct 22 23:25:00 2024 +0200

c: detect variably-modified types [PR117145,PR117245,PR100420]

This fixes two cases where variably-modified types were not recognized as
such.  The first is when building composite types and the other when a type
is reconstructed for the 'vector' attribute.  Construction of types in
the C FE is reorganized to use c_build_* functions which are responsible
for
setting C_TYPE_VARIABLE_SIZE, C_TYPE_VARIABLY_MODIFIED and
TYPE_TYPELESS_STORAGE
based on the properties of the type itself and these replace all other
logic
elsewhere (e.g. in grokdeclarator).  A new 'c_reconstruct_complex_type'
based
on these functions is introduced which is called via a language hook when
the
'vector' attribute is processed (as for C++).

One problem is are arrays of unspecified size 'T[*]' which were represented
identically to zero-sized arrays but with C_TYPE_VARIABLE_SIZE set.  To
avoid
having to create distinct type copies for this, the representation was
changed
to make it a natural VLA by giving it an upper bound of '(0, 0)'.  This
also
then allows fixing of PR100420 where such arrays were printed as 'T[0]'.

Finally, a new function 'c_verify_type' checks consistency of properties
specific to C FE and is called when checking is on.

PR c/117145
PR c/117245
PR c/100420

gcc/c/ChangeLog:
* c-decl.cc (c_build_pointer_type): Move to c-typeck.cc
(grokdeclarator): Simplify logic.
(match_builtin_function_types): Adapt.
(push_decl): Adapt.
(implicitly_declare): Adapt.
(c_update_type_canonical): Adapt.
(c_make_fname_decl): Adapt.
(start_function): Adapt.
* c-objc-common.h: Add LANG_HOOKS_RECONSTRUCT_COMPLEX_TYPE.
* c-tree.h: Add prototypes.
* c-typeck.cc (c_verify_type): New function.
(c_set_type_bits). New function.
(c_build_pointer_type): Moved from c-decl.cc.
(c_build_pointer_type_for_mode): New function.
(c_build_function_type): New function.
(c_build_array_type): New function.
(c_build_type_attribute_variant): New function.
(c_reconstruct_complex_type): New function.
(c_build_functype_attribute_variant): Renamed.
(array_to_pointer_conversion): Simplify logic.
(composite_type_internal): Simplify logic..
(build_unary_op): Simplify logic..
(comptypes_verify): Add checking assertions.
(c_build_qualified_type): Add checking assertions.
(c_build_function_call_vec): Adapt.
(qualify_type): Adapt.
(build_functype_attribute_variant): Adapt.
(common_pointer_type): Adapt.
(c_common_type): Adapt.
(convert_for_assignment): Adapt.
(type_or_builtin_type): Adapt.
(build_access_with_size_for_counted_by): Adapt.
(build_conditional_expr): Adapt.
(build_modify_expr): Adapt.
(build_binary_op): Adapt.
(build_omp_array_section): Adapt.
(handle_omp_array_sections): Adapt.
(c_finish_omp_clauses): Adapt.
* c-parser.cc (c_parser_typeof_specifier): Adapt.
(c_parser_generic_selection): Adapt.

gcc/c-family/ChangeLog:
* c-pretty-print.cc (c_pretty_printer::direct_abstract_declarator):
Detect arrays of unspecified size.

gcc/testsuite/ChangeLog:
* gcc.dg/c23-tag-composite-11.c: New test.
* gcc.dg/Warray-parameter-4.c: Resolve xfails.
* gcc.dg/Wvla-parameter-2.c: Resolve xfails.
* gcc.dg/Wvla-parameter-3.c: Resolve xfails.
* gcc.dg/pr117145-1.c: New test.
* gcc.dg/pr117145-2.c: New test.
* gcc.dg/pr117245.c: New test.

[Bug c/117145] [14/15 Regression] ICE: in make_ssa_name_fn, at tree-ssanames.cc:355 at -O1 and above with vector_size and VLA in struct argument since r14-1143-g42d1612eb5c3b2

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

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

--- Comment #12 from GCC Commits  ---
The master branch has been updated by Martin Uecker :

https://gcc.gnu.org/g:9eae9268e41463927c9383004e58708048ec379f

commit r15-4812-g9eae9268e41463927c9383004e58708048ec379f
Author: Martin Uecker 
Date:   Tue Oct 22 23:25:00 2024 +0200

c: detect variably-modified types [PR117145,PR117245,PR100420]

This fixes two cases where variably-modified types were not recognized as
such.  The first is when building composite types and the other when a type
is reconstructed for the 'vector' attribute.  Construction of types in
the C FE is reorganized to use c_build_* functions which are responsible
for
setting C_TYPE_VARIABLE_SIZE, C_TYPE_VARIABLY_MODIFIED and
TYPE_TYPELESS_STORAGE
based on the properties of the type itself and these replace all other
logic
elsewhere (e.g. in grokdeclarator).  A new 'c_reconstruct_complex_type'
based
on these functions is introduced which is called via a language hook when
the
'vector' attribute is processed (as for C++).

One problem is are arrays of unspecified size 'T[*]' which were represented
identically to zero-sized arrays but with C_TYPE_VARIABLE_SIZE set.  To
avoid
having to create distinct type copies for this, the representation was
changed
to make it a natural VLA by giving it an upper bound of '(0, 0)'.  This
also
then allows fixing of PR100420 where such arrays were printed as 'T[0]'.

Finally, a new function 'c_verify_type' checks consistency of properties
specific to C FE and is called when checking is on.

PR c/117145
PR c/117245
PR c/100420

gcc/c/ChangeLog:
* c-decl.cc (c_build_pointer_type): Move to c-typeck.cc
(grokdeclarator): Simplify logic.
(match_builtin_function_types): Adapt.
(push_decl): Adapt.
(implicitly_declare): Adapt.
(c_update_type_canonical): Adapt.
(c_make_fname_decl): Adapt.
(start_function): Adapt.
* c-objc-common.h: Add LANG_HOOKS_RECONSTRUCT_COMPLEX_TYPE.
* c-tree.h: Add prototypes.
* c-typeck.cc (c_verify_type): New function.
(c_set_type_bits). New function.
(c_build_pointer_type): Moved from c-decl.cc.
(c_build_pointer_type_for_mode): New function.
(c_build_function_type): New function.
(c_build_array_type): New function.
(c_build_type_attribute_variant): New function.
(c_reconstruct_complex_type): New function.
(c_build_functype_attribute_variant): Renamed.
(array_to_pointer_conversion): Simplify logic.
(composite_type_internal): Simplify logic..
(build_unary_op): Simplify logic..
(comptypes_verify): Add checking assertions.
(c_build_qualified_type): Add checking assertions.
(c_build_function_call_vec): Adapt.
(qualify_type): Adapt.
(build_functype_attribute_variant): Adapt.
(common_pointer_type): Adapt.
(c_common_type): Adapt.
(convert_for_assignment): Adapt.
(type_or_builtin_type): Adapt.
(build_access_with_size_for_counted_by): Adapt.
(build_conditional_expr): Adapt.
(build_modify_expr): Adapt.
(build_binary_op): Adapt.
(build_omp_array_section): Adapt.
(handle_omp_array_sections): Adapt.
(c_finish_omp_clauses): Adapt.
* c-parser.cc (c_parser_typeof_specifier): Adapt.
(c_parser_generic_selection): Adapt.

gcc/c-family/ChangeLog:
* c-pretty-print.cc (c_pretty_printer::direct_abstract_declarator):
Detect arrays of unspecified size.

gcc/testsuite/ChangeLog:
* gcc.dg/c23-tag-composite-11.c: New test.
* gcc.dg/Warray-parameter-4.c: Resolve xfails.
* gcc.dg/Wvla-parameter-2.c: Resolve xfails.
* gcc.dg/Wvla-parameter-3.c: Resolve xfails.
* gcc.dg/pr117145-1.c: New test.
* gcc.dg/pr117145-2.c: New test.
* gcc.dg/pr117245.c: New test.

[Bug c/100420] unspecified VLA bound formatted as [0] instead of [*] in -Wvla-parameter

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

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

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

https://gcc.gnu.org/g:9eae9268e41463927c9383004e58708048ec379f

commit r15-4812-g9eae9268e41463927c9383004e58708048ec379f
Author: Martin Uecker 
Date:   Tue Oct 22 23:25:00 2024 +0200

c: detect variably-modified types [PR117145,PR117245,PR100420]

This fixes two cases where variably-modified types were not recognized as
such.  The first is when building composite types and the other when a type
is reconstructed for the 'vector' attribute.  Construction of types in
the C FE is reorganized to use c_build_* functions which are responsible
for
setting C_TYPE_VARIABLE_SIZE, C_TYPE_VARIABLY_MODIFIED and
TYPE_TYPELESS_STORAGE
based on the properties of the type itself and these replace all other
logic
elsewhere (e.g. in grokdeclarator).  A new 'c_reconstruct_complex_type'
based
on these functions is introduced which is called via a language hook when
the
'vector' attribute is processed (as for C++).

One problem is are arrays of unspecified size 'T[*]' which were represented
identically to zero-sized arrays but with C_TYPE_VARIABLE_SIZE set.  To
avoid
having to create distinct type copies for this, the representation was
changed
to make it a natural VLA by giving it an upper bound of '(0, 0)'.  This
also
then allows fixing of PR100420 where such arrays were printed as 'T[0]'.

Finally, a new function 'c_verify_type' checks consistency of properties
specific to C FE and is called when checking is on.

PR c/117145
PR c/117245
PR c/100420

gcc/c/ChangeLog:
* c-decl.cc (c_build_pointer_type): Move to c-typeck.cc
(grokdeclarator): Simplify logic.
(match_builtin_function_types): Adapt.
(push_decl): Adapt.
(implicitly_declare): Adapt.
(c_update_type_canonical): Adapt.
(c_make_fname_decl): Adapt.
(start_function): Adapt.
* c-objc-common.h: Add LANG_HOOKS_RECONSTRUCT_COMPLEX_TYPE.
* c-tree.h: Add prototypes.
* c-typeck.cc (c_verify_type): New function.
(c_set_type_bits). New function.
(c_build_pointer_type): Moved from c-decl.cc.
(c_build_pointer_type_for_mode): New function.
(c_build_function_type): New function.
(c_build_array_type): New function.
(c_build_type_attribute_variant): New function.
(c_reconstruct_complex_type): New function.
(c_build_functype_attribute_variant): Renamed.
(array_to_pointer_conversion): Simplify logic.
(composite_type_internal): Simplify logic..
(build_unary_op): Simplify logic..
(comptypes_verify): Add checking assertions.
(c_build_qualified_type): Add checking assertions.
(c_build_function_call_vec): Adapt.
(qualify_type): Adapt.
(build_functype_attribute_variant): Adapt.
(common_pointer_type): Adapt.
(c_common_type): Adapt.
(convert_for_assignment): Adapt.
(type_or_builtin_type): Adapt.
(build_access_with_size_for_counted_by): Adapt.
(build_conditional_expr): Adapt.
(build_modify_expr): Adapt.
(build_binary_op): Adapt.
(build_omp_array_section): Adapt.
(handle_omp_array_sections): Adapt.
(c_finish_omp_clauses): Adapt.
* c-parser.cc (c_parser_typeof_specifier): Adapt.
(c_parser_generic_selection): Adapt.

gcc/c-family/ChangeLog:
* c-pretty-print.cc (c_pretty_printer::direct_abstract_declarator):
Detect arrays of unspecified size.

gcc/testsuite/ChangeLog:
* gcc.dg/c23-tag-composite-11.c: New test.
* gcc.dg/Warray-parameter-4.c: Resolve xfails.
* gcc.dg/Wvla-parameter-2.c: Resolve xfails.
* gcc.dg/Wvla-parameter-3.c: Resolve xfails.
* gcc.dg/pr117145-1.c: New test.
* gcc.dg/pr117145-2.c: New test.
* gcc.dg/pr117245.c: New test.

[Bug fortran/117381] -fmax-identifier-length= is completely ignored

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #8 from kargls at comcast dot net ---
(In reply to Jerry DeLisle from comment #6)
> This begs the question whether we should support longer symbols as an
> extension.

This likely would require a big change to the frontend.  There are
145 static buffers that use GFC_SYMBOL_LEN.  These would need to be
replaced by either dynamic memory allocation or static buffers that
waste memory.

% grep SYMBOL_LEN *cc | grep char | wc -l
 145
...
trans-types.cc:  char name[8 + 2*GFC_RANK_DIGITS + 1 + GFC_MAX_SYMBOL_LEN];
trans-types.cc:   char caf_name[GFC_MAX_SYMBOL_LEN + 6];
trans-types.cc:  char name[GFC_MAX_SYMBOL_LEN + 1];
trans-types.cc:  char name[GFC_MAX_SYMBOL_LEN + 1];

One could set GFC_MAX_SYMBOL_LEN to a value larger than 63, but what
value makes sense?  (Note it will be less than 1, which is the
longest statement length allowed under the standard)

[Bug testsuite/38833] RFE - Need Makefile to test coverage of Testsuite

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

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

--- Comment #1 from Andrew Pinski  ---
--enable-coverage has been there (and documented) since
r0-44516-g22aa533ee7d277 (which was in 2002, 7 years before this bug was
filed).

So the first part of this bug was already existing.

The second part of handling automated checking the resulting coverage is not
there though.

[Bug fortran/117381] -fmax-identifier-length= is completely ignored

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

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #8)
> One could set GFC_MAX_SYMBOL_LEN to a value larger than 63, but what
> value makes sense?  (Note it will be less than 1, which is the
> longest statement length allowed under the standard)

You sure?

F2023: 6.3.2.1 ... A line shall contain at most ten thousand characters.

But can't you break a line like in:

a&
&b&
&c = 1

?

So do we want a limit close to

6.3.2.6  ... A statement shall not have more than one million characters.

?

[Bug middle-end/31980] ICE in cancel_option() for Negative marked options

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code,
   ||internal-improvement
   Last reconfirmed||2024-10-31

--- Comment #5 from Andrew Pinski  ---
Note patches should sent to gcc-patches@ .

But this seems like still a bug.

[Bug tree-optimization/19831] Missing DSE/malloc/free optimization

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

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

Sam James  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Keywords||patch

--- Comment #22 from Sam James  ---
https://inbox.sourceware.org/gcc-patches/zyorgnihj5qq3...@kam.mff.cuni.cz/

[Bug fortran/117381] -fmax-identifier-length= is completely ignored

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #10 from kargls at comcast dot net ---
(In reply to anlauf from comment #9)
> (In reply to kargls from comment #8)
> > One could set GFC_MAX_SYMBOL_LEN to a value larger than 63, but what
> > value makes sense?  (Note it will be less than 1, which is the
> > longest statement length allowed under the standard)
> 
> You sure?
> 
> F2023: 6.3.2.1 ... A line shall contain at most ten thousand characters.
> 
> But can't you break a line like in:
> 
> a&
> &b&
> &c = 1
> 
> ?

Ugh, indeed, you are correct!  I forgot that one could split
a token across a line.  The question still remains.  What
value does one use; especially given the 145 static buffers?

[Bug c++/31158] wrong line number in warning: overflow in implicit constant conversion

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

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

--- Comment #6 from Andrew Pinski  ---
Looks fixed in GCC 9, Let me see if I can find the commit.

[Bug c++/57342] [C++11] Warning for narrowing conversion has ugly formatting for floating point number

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

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

Bug 31158 Summary: wrong line number in warning: overflow in implicit constant 
conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31158

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/88375] Vague source location for bad initialization

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=31158
 CC||msebor at gcc dot gnu.org

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

[Bug fortran/117381] -fmax-identifier-length= is completely ignored

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
While Nvidia and flang seem to allow the sample code, even the latest
Intel ifx 2025.0 rejects it:

pr117381.f90(5): error #6439: This symbol has too many characters.  
[VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ACCELERAT]
  integer ::
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_PROPERTIES_KHR = 1
-^
compilation aborted for pr117381.f90 (code 1)


With the following patch we could adjust the documentation:

diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index ff4040732d8..b25976c7026 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -407,8 +407,9 @@ lines in the source file. The default value is 132.

 @opindex fmax-identifier-length=@var{n}
 @item -fmax-identifier-length=@var{n}
-Specify the maximum allowed identifier length. Typical values are
-31 (Fortran 95) and 63 (Fortran 2003 and later).
+Specify the maximum allowed identifier length.  Standard values are
+31 (Fortran 95) and 63 (Fortran 2003 and later).  Values larger than
+63 are not supported.

 @opindex fimplicit-none
 @item -fimplicit-none

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

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

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

--- Comment #64 from Sam James  ---
I think the bug was kept open for other targets to check if they needed
adaptation.

jakub's guess in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114175#c24 said:
> aarch64, alpha, arc, maybe arm, csky, maybe epiphany, maybe fr30, maybe frv, 
> maybe ft32, ia64, loongarch, maybe m32r, maybe mcore, mips, mmix, maybe 
> nds32, nios2, riscv, maybe rs6000, maybe sh, visium need similar fix.

rs6000 is done, alpha is done, loong is done, arc is done, riscv is done, csky
is done, epiphany is done, ft32 is done, m32r is done, nds32 is done, nios2 is
done, visium is done, mips is done. aarch64 seems unaffected.

That means we need to check:
* frv
* mcore
* mmix
* sh

I think?

[Bug c/117380] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in get_unwidened, at tree.cc:8019

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||ice-checking
   Last reconfirmed||2024-10-31
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
The problem is we get:
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x77822738 precision:64 min  max 
pointer_to_this >

arg:0 

arg:0 
used public static read SI t6.c:2:8
size 
unit-size 
align:32 warn_if_not_align:0 context  chain >>
arg:1  constant 503359447364223024>
t6.c:5:12 start: t6.c:5:10 finish: t6.c:5:31>


But note the error_mark as the type for b.
The problem is we don't prop error_mark backwards which would have "fixed" the
issue.

I have an idea on how to fix this and others like this. But since this is error
recovery, it is low on my plate to fix it.

[Bug tree-optimization/115274] [14/15 regression] Bogus -Wstringop-overread in SQLite source code

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

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

--- Comment #15 from Sam James  ---
On the original with Qing's v3 patch, quoting output from bundled copy in
nodejs but it happens with upstream too:
```
../../deps/sqlite/sqlite3.c:35003:28: warning: ‘strlen’ reading 1 or more bytes
from a region of size 0 [-Wstringop-overread]
35003 |   return 0x3fff & (int)strlen(z);
  |^
  ‘sqlite3ColumnSetColl’: events 1-2
 35003 |   return 0x3fff & (int)strlen(z);
   |~
   ||
   |(2) out of array bounds here
...
122109 |   if( pCol->colFlags & COLFLAG_HASTYPE ){
   | ^
   | |
   | (1) when the condition is evaluated to true
In function ‘sqlite3ColumnSetColl’:
```

[Bug fortran/117381] -fmax-identifier-length= is completely ignored

[kargls at comcast dot net via Gcc-bugs]

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

--- Comment #7 from kargls at comcast dot net ---
(In reply to anlauf from comment #5)
> While Nvidia and flang seem to allow the sample code, even the latest
> Intel ifx 2025.0 rejects it:
> 
> pr117381.f90(5): error #6439: This symbol has too many characters.  
> [VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ACCELERAT]
>   integer ::
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_PROPERTIES_KHR = 1
> -^
> compilation aborted for pr117381.f90 (code 1)
> 
> 
> With the following patch we could adjust the documentation:
> 
> diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
> index ff4040732d8..b25976c7026 100644
> --- a/gcc/fortran/invoke.texi
> +++ b/gcc/fortran/invoke.texi
> @@ -407,8 +407,9 @@ lines in the source file. The default value is 132.
>  
>  @opindex fmax-identifier-length=@var{n}
>  @item -fmax-identifier-length=@var{n}
> -Specify the maximum allowed identifier length. Typical values are
> -31 (Fortran 95) and 63 (Fortran 2003 and later).
> +Specify the maximum allowed identifier length.  Standard values are
> +31 (Fortran 95) and 63 (Fortran 2003 and later).  Values larger than
> +63 are not supported.
>  
>  @opindex fimplicit-none
>  @item -fimplicit-none

I was making a similar change, then discovered that one can
use -fmax-identifier-length=0.  I gets a lot of errors. :-).
I have a patch building at the moment that checks that the
specified value is not less than 6, which is the old Fortran
77 limit.

[Bug target/100165] fmov could be used to zero out the upper bits instead of movi/zip or movi/ins with __builtin_shuffle and zero vector

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-October
   ||/667088.html
   Assignee|pinskia at gcc dot gnu.org |pzheng at gcc dot 
gnu.org
   Keywords||patch

--- Comment #6 from Andrew Pinski  ---
Patch was posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/667088.html

[Bug testsuite/117183] gcc.dg/c23-constexpr-2a.c: comment mismatch with dg-do

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

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

--- Comment #4 from GCC Commits  ---
The master branch has been updated by Sam James :

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

commit r15-4813-g2a4ee57b04398e54284e3d6b5ed4f8842ee26a5c
Author: Sam James 
Date:   Thu Oct 31 18:37:30 2024 +

testsuite: fix c23-constexpr-2a.c test to use dg-do run

The comment at the top of the test indicates it should be an execution
test,
but it was only using 'dg-do link'. Correct that.

The only change in test results is as expected:
```
+PASS: gcc.dg/c23-constexpr-2a.c execution test
```

gcc/testsuite/ChangeLog:
PR testsuite/117183

* gcc.dg/c23-constexpr-2a.c: Use dg-do run.

[Bug testsuite/117183] gcc.dg/c23-constexpr-2a.c: comment mismatch with dg-do

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #5 from Sam James  ---
Fixed.

[Bug testsuite/117183] gcc.dg/c23-constexpr-2a.c: comment mismatch with dg-do

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

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

Sam James  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Sam James  ---
Patch posted:
https://inbox.sourceware.org/gcc-patches/2a4ee57b04398e54284e3d6b5ed4f8842ee26a5c.1730399917.git@gentoo.org/

[Bug testsuite/117183] gcc.dg/c23-constexpr-2a.c: comment mismatch with dg-do

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

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug ipa/108040] -fdevirtualize causes part of function to be missing in output

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

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2024-10-31

[Bug target/109494] inline const variables interfere with source_location

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

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

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed|2023-04-13 00:00:00 |2024-10-31
 Status|UNCONFIRMED |WAITING

--- Comment #13 from Sam James  ---
(In reply to Oliver Rosten from comment #12)
> Yes, I am aware that I homebrewed gcc. What I don't understand is the
> extent to which this a homebrew problem and not a gcc problem. Forgive my
> ignorance but I would like to understand what submitting this issue to
> homebrew implies/achieves. I simply don't have much awareness of the
> broader context.
> 

They might be applying patches. For example, they definitely use Iain's branch
for at least some versions of macOS.

They can also help triage it in a macOS/Darwin-specific way before bringing it
to us.

[Bug c++/31158] wrong line number in warning: overflow in implicit constant conversion

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|10.0|9.0

[Bug c++/88375] Vague source location for bad initialization

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug fortran/117381] -fmax-identifier-length= is completely ignored

[kargls at comcast dot net via Gcc-bugs]

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

kargls at comcast dot net changed:

   What|Removed |Added

 CC||kargls at comcast dot net

--- Comment #4 from kargls at comcast dot net ---
(In reply to Jordan from comment #3)
> I tested this:
> 
> program main
>   use, intrinsic :: iso_c_binding
>   implicit none
> 
>   integer ::
> VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_PROPERTIES_KHR = 1
> end program main
> 
> with:
> gfortran -std=f95 -fmax-identifier-length=80 ./app/main.f90 
> 
> with result:
> f951: Fatal Error: Maximum supported identifier length is 63
> compilation terminated.

The option should likely by removed or the documentation improved.
It can be set to any value up to and including 63.  Anything larger
will not work.

% cd gcc/gcc/fortran
% grep GFC_MAX_SYMBOL_LEN *.cc | grep + | wc -l
 149

There are 149 instances of the symbol and many of those
appear in declarations of buffers such as in match.cc

   /* Match an ELSE IF statement.  */

   match
   gfc_match_elseif (void)
   {
 char name[GFC_MAX_SYMBOL_LEN + 1];

As a side note, the Fortran 2023 standard has a numbered constraint

   F2023:C601 (R603) The maximum length of a name is 63 characters.

which means a Fortran compiler is oblige to detect and report the
issue.

As an additional side note, you don't need to create a custom vulkan.
You can create a custom gfortran with this patch.

diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index dd599bc97a2..85f0597bed0 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -54,7 +54,7 @@ not after.

 /* Major control parameters.  */

-#define GFC_MAX_SYMBOL_LEN 63   /* Must be at least 63 for F2003.  */
+#define GFC_MAX_SYMBOL_LEN 127   /* Must be at least 63 for F2003.  */
 #define GFC_LETTERS 26 /* Number of letters in the alphabet.  */

 #define MAX_SUBRECORD_LENGTH 2147483639   /* 2**31-9 */

Change 127 to whatever you want.

[Bug rtl-optimization/117360] [15 regression] ext-dce.cc:573:15: runtime error: shift exponent 127 is too large for 64-bit type 'long long unsigned int'

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

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

--- Comment #3 from Jeffrey A. Law  ---
What's interesting is I did a bootstrap with ubsan a while back to chase down
this stuff.  Could be something recently introduced or a path we didn't trigger
before.  Regardless I'll case it down.

Yes, we need to change some of those constants to HOST_WIDE_INT_UC and such.  I
think Andrew pointed that out a little while ago.

Finally, yes, checking the shift constants for validity is done elsewhere in
ext-dce to catch problems early.  Those checks probably aren't as
pervasive/consistent as they need to be.

[Bug ipa/117350] [15 Regression] ICE with autoprofiledbootstrap and bootstrap-lto after r15-4610-gbf43fe6aa966ea

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

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

--- Comment #17 from ak at gcc dot gnu.org ---
http://firstfloor.org/~andi/fbdata.afdo is the gcov file for the reproducer
above.

[Bug middle-end/117375] ICE with -fdiagnostics-details patch in sink pass when building opus-1.5.2

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

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

qinzhao at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #8 from qinzhao at gcc dot gnu.org ---
fixed in my 4th version of the patch.

[Bug tree-optimization/117363] [15 regression] ICE during GIMPLE pass: ldist since r15-4763-g4af8db3eca12b2

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-October
   ||/667063.html
   Keywords||patch

--- Comment #13 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/667063.html

[Bug libstdc++/77686] [6/7 Regression] wrong code on arm-linux-gnueabi and arm-linux-gnueabihf

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||Koen.Poppe at vandewiele dot 
com

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

[Bug target/117365] Captured this lost after assignment to std::function

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|WAITING |RESOLVED

--- Comment #3 from Andrew Pinski  ---
Yes it is the same.

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

[Bug c++/101887] [12/13/14/15 Regression] ICE with invalid declaration of 'operator delete'

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

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

Simon Martin  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=104846
   Assignee|unassigned at gcc dot gnu.org  |simartin at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #6 from Simon Martin  ---
This is a dupe of PR c++/104846, and has been fixed via
r12-7599-gac8310dd122172. I'll submit a patch to add this specific case to the
testsuite.

[Bug tree-optimization/117093] Missing detection of REV64 vector permute

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

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

Jennifer Schmitz  changed:

   What|Removed |Added

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

--- Comment #5 from Jennifer Schmitz  ---
.

[Bug tree-optimization/117176] [15 regression] ICE when building netpbm-11.8.0

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

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

--- Comment #13 from Sergei Trofimovich  ---
The change fixed netpbm-11.8.0 build for me. Thank you!

[Bug rtl-optimization/117360] [15 regression] ext-dce.cc:573:15: runtime error: shift exponent 127 is too large for 64-bit type 'long long unsigned int'

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

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

--- Comment #4 from Martin Jambor  ---
(In reply to Jeffrey A. Law from comment #3)
> What's interesting is I did a bootstrap with ubsan a while back to chase
> down this stuff.  Could be something recently introduced or a path we didn't
> trigger before.  Regardless I'll case it down.
> 

I have bisected a recent UBSAN failure on this line when compiling pr114883.f90
to r15-4532-g36e91df7716d34 (Jeff Law: [committed][PR rtl-optimization/116488]
Fix SIGN_EXTEND source handling in ext-dce).

[Bug ipa/117350] [15 Regression] ICE with autoprofiledbootstrap and bootstrap-lto after r15-4610-gbf43fe6aa966ea

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

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

--- Comment #19 from Andrew Pinski  ---
(In reply to ak from comment #18)
> Okay I looked into need_assembler_name_p. For __ct function_decl it bails
> out due to

> I assume that means HAS_DECL_ASSEMBLER_NAME_P returns false.

HAS_DECL_ASSEMBLER_NAME_P is:
#define HAS_DECL_ASSEMBLER_NAME_P(NODE) \
  (CODE_CONTAINS_STRUCT (TREE_CODE (NODE), TS_DECL_WITH_VIS))

FUNCTION_DECL is defined as:
DEFTREECODE (FUNCTION_DECL, "function_decl", tcc_declaration, 0)

#define MARK_TS_DECL_WITH_VIS(C)\
  (MARK_TS_DECL_WRTL (C),   \
   tree_contains_struct[C][TS_DECL_WITH_VIS] = true)

#define MARK_TS_DECL_NON_COMMON(C)  \
  (MARK_TS_DECL_WITH_VIS (C),   \
   tree_contains_struct[C][TS_DECL_NON_COMMON] = true)

initialize_tree_contains_struct does:
  code = (enum tree_code) i;
  ts_code = tree_node_structure_for_code (code);

  /* Mark the TS structure itself.  */
  tree_contains_struct[code][ts_code] = 1;

  /* Mark all the structures that TS is derived from.  */
  switch (ts_code)
...
case TS_TYPE_DECL:
case TS_FUNCTION_DECL:
  MARK_TS_DECL_NON_COMMON (code);
  break;


tree_node_structure_for_code  is defined by:
static inline enum tree_node_structure_enum
tree_node_structure_for_code (enum tree_code code)
{
  switch (TREE_CODE_CLASS (code))
{
case tcc_declaration:
  switch (code)
{
case CONST_DECL:return TS_CONST_DECL;
case DEBUG_EXPR_DECL:   return TS_DECL_WRTL;
case FIELD_DECL:return TS_FIELD_DECL;
case FUNCTION_DECL: return TS_FUNCTION_DECL;




So the answer to `HAS_DECL_ASSEMBLER_NAME_P return false` is no it does not.

Are you sure looking at the correct `__ct` function_decl? There are a couple of
clones of the constructor decl due to in-charge ABI reasons.

[Bug target/114801] [14/15 Regression] arm: ICE in find_cached_value, at rtx-vector-builder.cc:100 with MVE intrinsics

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

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

--- Comment #36 from Richard Earnshaw  ---
I've been looking at this.  I think the real problem is that trunc_int_for mode
is doing something incompatible with what the later code expects.  We have

  /* Canonicalize BImode to 0 and STORE_FLAG_VALUE.  */
  if (smode == BImode)
return c & 1 ? STORE_FLAG_VALUE : 0;

But this doesn't handle other boolen modes, such as B2I or B4I.  This then
causes the assertion later on because we expect a bool value to be in a fixed
form.

[Bug middle-end/117384] [15 regression] ICE when building gwenhywfar-5.10.1 (error: non-trivial conversion in ‘var_decl’)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 59514
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59514&action=edit
gcc15-pr117384.patch

Seems tree_output_constant_def intentionally allows some type mismatches, and
the other gimplify.cc caller of that function already deals with that using
VCE.

[Bug middle-end/117375] ICE with -fdiagnostics-details patch in sink pass when building opus-1.5.2

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

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

--- Comment #7 from qinzhao at gcc dot gnu.org ---
The reason for the ICE is:

The destination of the code movement due to tree sinking might not be the
immediate destination block of the block in which the statement locates. 

for example:
B2
   /  \
  V\
 B3 \
 / \ \
V   \>V
   B4 B7

A statement in B2 will be sinked to B4, which is not the immediate destination
block of B2, as a result, find_edge (B2,B4) will return NULL.

In order to resolve this issue, we need to find the edge chain from B2 to B4,
i.e, both the edges B2->B3, and B3->B4 are identified.  and both the conditions
in B2 and B3 need to be recorded as move_history of the statement.

[Bug ipa/117350] [15 Regression] ICE with autoprofiledbootstrap and bootstrap-lto after r15-4610-gbf43fe6aa966ea

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

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

--- Comment #16 from ak at gcc dot gnu.org ---
I'm not sure the revision in the subject is right. Given the reproduction in
gcc 13 it seems to me this is a latent bug that is just triggered by changes in
the bootstrapped input source. Strangely it is now triggered by at least two
places, so something else might have changed.

The initial failure comes from this assert failing

1194  /* If not, it should be either in the global namespace, or
directly
1195 in a local function scope.  A lambda can also be mangled in
the
1196 scope of a default argument.  */
1197  gcc_assert (context == global_namespace
1198  || TREE_CODE (context) == PARM_DECL
1199  || TREE_CODE (context) == FUNCTION_DECL);

When i look at it in rr I see

(rr) p context
$5 = 
(rr) p decl
$7 = 

This doesn't look like garbage from freed data, more some logic problem.

[Bug ipa/117350] [15 Regression] ICE with autoprofiledbootstrap and bootstrap-lto after r15-4610-gbf43fe6aa966ea

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

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

--- Comment #18 from ak at gcc dot gnu.org ---

Okay I looked into need_assembler_name_p. For __ct function_decl it bails out
due to


784   /* If DECL already has its assembler name set, it does not need a
785  new one.  */
786   if (!HAS_DECL_ASSEMBLER_NAME_P (decl)
787   || DECL_ASSEMBLER_NAME_SET_P (decl))
788 return false;

 >
QI
size 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fc0883d0930 method basetype 
arg-types 
chain 
chain 
chain 
pointer_to_this >
used public abstract external QI ../gu.cc:3:3 align:16 warn_if_not_align:0
context  abstract_origin 
full-name "tuple<_T1, _T2>::tuple(_T1, _T2) [with _T1 = int; _T2 = int]"
template-info 
VOID ../gu.cc:3:3
align:1 warn_if_not_align:0 context  result 
parms 
value 
length:2
elt:0 >
elt:1 >>>
full-name "template tuple<_T1,
_T2>::tuple(_T1, _T2)">
args  elt:1 >
   pending_template>
use_template=1 chain >

I assume that means HAS_DECL_ASSEMBLER_NAME_P returns false.

[Bug tree-optimization/117358] [12/13/14/15 Regression] ICE: in execute_todo, at passes.cc:2138 at -O2 and above with const attribute

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE: in execute_todo, at|[12/13/14/15 Regression]
   |passes.cc:2138 at -O2 and   |ICE: in execute_todo, at
   |above with const attribute  |passes.cc:2138 at -O2 and
   ||above with const attribute
  Known to work||9.5.0
  Known to fail||10.1.0
   Target Milestone|--- |12.5

[Bug ipa/117350] [15 Regression] ICE with autoprofiledbootstrap and bootstrap-lto after r15-4610-gbf43fe6aa966ea

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #20 from Jason Merrill  ---
The problem seems to be

  /* Abstract decls do not need an assembler name.  */
  if (DECL_ABSTRACT_P (decl))
=>  return false;

in need_assembler_name_p combined with

  if (DECL_FROM_INLINE (decl))
return get_index_by_decl (DECL_ABSTRACT_ORIGIN (decl));

in get_index_by_decl.  These two functions are making incompatible assumptions;
the latter causes autofdo to rely on the assembler name for the abstract
maybe-in-charge constructor that the former decided wasn't needed.

[Bug bootstrap/117361] [15 Regression] GCC build fails with "gcc/opts-diagnostic.cc:599: test_output_arg_parsing: FAIL: ASSERT_STREQ (pt.get_diagnostic_text ()" when using some locales

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

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

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-10-31

--- Comment #2 from Sam James  ---
Confirmed via
https://inbox.sourceware.org/gcc-patches/4a270f324f4f7d7dd0b1b0dda3c24c5d88b0da7d.ca...@xry111.site/.

[Bug tree-optimization/117385] New: Move phiopt away from doing a COND_EXPR with a comparison as first operand

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

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

Bug ID: 117385
   Summary: Move phiopt away from doing a COND_EXPR with a
comparison as first operand
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: internal-improvement
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

As mentioned on
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/666831.html :
```
The biggest offender still present is phiopt building a GENERIC
comparison for the
piecewise COND_EXPR simplification in gimple_simplify_phiopt (so
genmatch needs to
create both GIMPLE and GENERIC match variants for COND_EXPR conditions).
maybe_fold_comparisons_from_match_pd uses on-stack temporary GIMPLE for
a similar (more complex) case.
```

[Bug target/114175] [13/14] Execution test failures on gcc.dg/c23-stdarg-6.c on multiple targets

[ewlu at rivosinc dot com via Gcc-bugs]

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

Edwin Lu  changed:

   What|Removed |Added

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

--- Comment #63 from Edwin Lu  ---
forgot to close. fixed on trunk

[Bug target/117383] New: gcc relies on RISC-V vcompress instruction undefined behaviour

[anton at ozlabs dot org via Gcc-bugs]

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

Bug ID: 117383
   Summary: gcc relies on RISC-V vcompress instruction undefined
behaviour
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anton at ozlabs dot org
  Target Milestone: ---

I think gcc is relying on undefined behaviour with the vcompress instruction.
This thread explains how vcompress is different in that the tail starts after
the last mask selected field:

https://github.com/riscvarchive/riscv-v-spec/issues/796

There was a bug in QEMU that I just fixed that prevented the all 1s tail
agnostic option (rvv_ta_all_1s) from poisoning these bits:

https://lists.nongnu.org/archive/html/qemu-riscv/2024-10/msg00561.html

With that fix, I see problems with the test case below until I modify the
previous setvli from ta to tu. I think 9aabf81f40f0 ("RISC-V: Optimize
permutation codegen with compress") is one place we need to set tail
undisturbed.

Build with:

gcc -march=rv64gcv -mabi=lp64d -mrvv-vector-bits=zvl -O3

QEMU without all 1s tail agnostic poisoning:

-1
-2
-3
-5
-7
-9
-10
-11
-12
-14
-15
-17
-19
-21
-22
-23
-26
-28
-30
-31
-37
-38
-41
-46
-47
-53
-54
-55
-60
-61
-62
-63
52
53
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

QEMU with all 1s tail agnostic poisoning:

-1
-2
-3
-5
-7
-9
-10
-11
-12
-14
-15
-17
-19
-21
-22
-23
-26
-28
-30
-31
-37
-38
-41
-46
-47
-53
-54
-55
-60
-61
-62
-63
52
53
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1
-1

Not sure where the 52/53 values are coming from either.


#include 
#include 

typedef int8_t vnx64i __attribute__ ((vector_size (64)));
#define MASK_64   
\
  1, 2, 3, 5, 7, 9, 10, 11, 12, 14, 15, 17, 19, 21, 22, 23, 26, 28, 30, 31,   
\
37, 38, 41, 46, 47, 53, 54, 55, 60, 61, 62, 63, 76, 77, 78, 79, 80, 81,   
\
82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99,   
\
100, 101, 102, 103, 104, 105, 106, 107
void __attribute__ ((noinline, noclone)) test_1 (int8_t *x, int8_t *y, int8_t
*out)
{
  vnx64i v1 = *(vnx64i*)x;
  vnx64i v2 = *(vnx64i*)y;
  vnx64i v3 = __builtin_shufflevector (v1, v2, MASK_64);
  *(vnx64i*)out = v3;
}

int main(void)
{
  int8_t x[64];
  int8_t y[64];
  int8_t out[64];

  for (int i = 0; i < 64; i++) {
x[i] = -i;
y[i] = i;
  }

  test_1(x, y, out);

  for (int i = 0; i < 64; i++) {
printf("%d\n", out[i]);
  }
}

[Bug rtl-optimization/116783] Wrong code at -O2 with late pair fusion pass (wrong alias analysis)

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

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

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #9 from Alex Coplan  ---
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1080974#40 confirms this
fixes the Debian issue, closing as fixed.

[Bug target/63783] [4.9/5 Regression] [SH] Miscompilation of boolean negation on SH4 using -O2

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #26 from John Paul Adrian Glaubitz  ---
(In reply to Richard Biener from comment #25)
> Fixed I assume.

Yes, I just verified that the original reproducer does no longer trigger the
assertion both with GCC 14  and GCC 15.

[Bug c++/110137] implement clang -fassume-sane-operator-new

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #18 from Jakub Jelinek  ---
So, I think the first step should be document the new option and explain what
extra guarantees it provides over what the C++ standard already guarantees.
I think the C++ standard should already guarantee that the return doesn't alias
anything, I mean our current declarations already say that with malloc, and
alloc_size (and sometimes alloc_align attributes).
So, do I understand it right that -fassume-sane-operator-new mainly just says
that ::operator new/::operator delete don't have other side-effects besides
allocation like Richi wrote in #c1, something we assume for malloc?
Basically assume that the implementation of those operators is a black box, not
LTO optimized together with the rest?

I must say I'm a little bit confused about the __attribute__s used in ,
some ::operator new versions just have externally_visible attribute, others
have also alloc_size + malloc, others have alloc_size + alloc_align + malloc,
but I don't see it applied consistently, e.g. alloc_align whenever there is
align_val_t argument.

Is malloc attribute all that guarantees it doesn't modify the global state?
Then I'd be afraid if a program replaces those global replaceable definition
with his own it can violate that.  Or alloc_size?

Given the __builtin_operator_{new,delete} calls clang has, should we flag the
assume-sane-operator-new property on CALL_EXPRs/GIMPLE_CALLs/CALL_INSNs and
making that the property of those calls?

If so, I think we first want to implement -fassume-sane-operator-new by setting
those flags on CALL_EXPRs to DECL_IS_REPLACEABLE_OPERATOR functions according
to the option (and perhaps make it default to on), and then implement those 2
builtins as BUILT_IN_FRONTEND varargs builtins which lower in the FE to
::operator new/delete calls with the same arguments (error if such operator
isn't declared) and only if it turns out calls to the
DECL_IS_REPLACEABLE_OPERATOR functions, set the new flag on CALL_EXPR even when
-fno-assume-sane-operator-new.

[Bug tree-optimization/117363] [15 regression] ICE during GIMPLE pass: ldist since r15-4763-g4af8db3eca12b2

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

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

--- Comment #12 from Sergei Trofimovich  ---
(In reply to Andrew Pinski from comment #11)
> Created attachment 59512 [details]
> Fixed up patch

That fixes `waybar-0.11.0` build for me. Thank you!

[Bug middle-end/117384] New: [15 regression] ICE when building gwenhywfar-5.10.1 (error: non-trivial conversion in ‘var_decl’)

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

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

Bug ID: 117384
   Summary: [15 regression] ICE when building gwenhywfar-5.10.1
(error: non-trivial conversion in ‘var_decl’)
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
  Target Milestone: ---

Created attachment 59513
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59513&action=edit
gwentest.i.xz

Originally reported downstream in Gentoo at https://bugs.gentoo.org/942593.

```
$ gcc -c ./gwentest.i
gwentest.c: In function ‘testDES3’:
gwentest.c:3902:5: error: non-trivial conversion in ‘var_decl’
 3902 | int testDES3(void)
  | ^~~~
unsigned char[144]
char[144]
MEM  [(void *)&testString] = *.LC0;
gwentest.c:3902:5: internal compiler error: ‘verify_gimple’ failed
0x5e526a4be91e internal_error(char const*, ...)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/diagnostic-global-context.cc:518
0x5e5268de4903 verify_gimple_in_seq(gimple*, bool)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/tree-cfg.cc:5333
0x5e526a71052b gimplify_body(tree_node*, bool)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimplify.cc:19548
0x5e526a70cbbf gimplify_function_tree(tree_node*)
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/gimplify.cc:19666
0x5e526a70abc1 cgraph_node::analyze()
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cgraphunit.cc:688
0x5e526ae987ba analyze_functions
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cgraphunit.cc:1252
0x5e526ae98223 symbol_table::finalize_compilation_unit()
   
/usr/src/debug/sys-devel/gcc-15.0./gcc-15.0./gcc/cgraphunit.cc:2561
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.
```

---

```
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/15/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/15
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/15/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/15/include/g++-v15
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/15/python
--enable-objc-gc --enable-languages=c,c++,d,go,objc,obj-c++,fortran,ada,m2,rust
--enable-obsolete --enable-secureplt --disable-werror --with-system-zlib
--enable-nls --without-included-gettext --disable-libunwind-exceptions
--enable-checking=yes,extra,rtl --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo Hardened 15.0. p, commit
a0691e3578dcab1c745e963bb4f9ffe2a3889cf3' --with-gcc-major-version-only
--enable-libstdcxx-time --enable-lto --disable-libstdcxx-pch --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-multilib --with-multilib-list=m32,m64 --disable-fixed-point
--enable-targets=all --enable-libgomp --disable-libssp --enable-libada
--disable-cet --disable-systemtap --enable-valgrind-annotations
--disable-vtable-verify --disable-libvtv --with-zstd --with-isl
--disable-isl-version-check --enable-default-pie --enable-host-pie
--enable-host-bind-now --enable-default-ssp --disable-fixincludes
--with-build-config='bootstrap-O3 bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241029 (experimental)
7f622ee83fbbcf4a4ca70e020db8a0ce4b556b61 (Gentoo Hardened 15.0. p, commit
a0691e3578dcab1c745e963bb4f9ffe2a3889cf3)
```

[Bug fortran/115700] [12/13 regression] Bogus warning for associate with assumed-length character array

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

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

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

https://gcc.gnu.org/g:159fb203231c503418e7ab9f45282957e40cb195

commit r15-4793-g159fb203231c503418e7ab9f45282957e40cb195
Author: Paul Thomas 
Date:   Thu Oct 31 07:22:36 2024 +

Fortran: Fix problem with substring selectors in ASSOCIATE [PR115700]

2024-10-31  Paul Thomas  

gcc/fortran
PR fortran/115700
* resolve.cc (resolve_variable): The typespec of an expression,
which is not a substring, can be shared with a deferred length
associate name.
(resolve_assoc_var): Extract a substring reference with non-
constant start or end. Use it to flag up the need for array
associate name to be a pointer.
(resolve_block_construct): Change comment from past to future
tense.

gcc/testsuite/
PR fortran/115700
* gfortran.dg/associate_70.f90: New test.

[Bug c/117380] New: ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in get_unwidened, at tree.cc:8019

[iamanonymous.cs at gmail dot com via Gcc-bugs]

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

Bug ID: 117380
   Summary: ICE: tree check: expected class 'type', have
'exceptional' (error_mark) in get_unwidened, at
tree.cc:8019
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---

***
OS and Platform:
$ uname -a:
Linux 65dac7c84719 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC
2023 x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
Using built-in specs.
COLLECT_GCC=/home/software/gcc-trunk-3aa004f/bin/gcc
COLLECT_LTO_WRAPPER=/home/software/gcc-trunk-3aa004f/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++ --prefix=/home/software/gcc-trunk-3aa004f
--enable-coverage
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240630 (experimental) (GCC) 

***
Program:
$ cat mutant.c
int a, b;
void c()
{
a >> b + 503359447364223024; 
}
__attribute__((vector_size(4))) b;

***
Command Lines:
$ gcc mutant.c
during GIMPLE pass: strlen
mutant.c:6:33: error: type defaults to 'int' in declaration of 'b'
[-Wimplicit-int]
6 | __attribute__((vector_size(4))) b;
  | ^
mutant.c:6:33: error: conflicting types for 'b'; have '__vector(1) int'
mutant.c:1:8: note: previous declaration of 'b' with type 'int'
1 | int a, b;
  |^
mutant.c: In function 'c':
mutant.c:4:7: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in get_unwidened, at tree.cc:8019
4 | a >> b + 503359447364223024;
  | ~~^
0x5071bcf diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x50724a1 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, int, char const*, __va_list_tag (*) [1],
diagnostic_t)
???:0
0x50924c7 internal_error(char const*, ...)
???:0
0x26856d2 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
???:0
0xd4a676 tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
???:0
0x267dac4 get_unwidened(tree_node*, tree_node*)
???:0
0x126cd01 convert_to_integer(tree_node*, tree_node*)
???:0
0xe4febf convert(tree_node*, tree_node*)
???:0
0xfd948f c_gimplify_expr(tree_node**, gimple**, gimple**)
???:0
0x1727e44 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0x16d5172 gimplify_stmt(tree_node**, gimple**)
???:0
0x1729b35 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0x16d5172 gimplify_stmt(tree_node**, gimple**)
???:0
0x17307ed gimplify_body(tree_node*, bool)
???:0
0x17319cc gimplify_function_tree(tree_node*)
???:0
0x124b024 cgraph_node::analyze()
???:0
0x125521b symbol_table::finalize_compilation_unit()
???:0
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.

Godbolt link: https://godbolt.org/z/snK9a7PPa

[Bug c++/86878] G++ should warn about invalid alignments passed to allocation functions

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:646b24efaa50b149c12d0ae432999cb5a0cd12f2

commit r15-4797-g646b24efaa50b149c12d0ae432999cb5a0cd12f2
Author: Jonathan Wakely 
Date:   Tue Jan 9 13:16:11 2024 +

libstdc++: Add align_alloc attribute to aligned operator new

The aligned versions of operator new should use the align_alloc
attribute to help the compiler.

PR c++/86878 requests that the compiler would use the attribute to warn
about invalid attributes, so an XFAILed test is added for that.

libstdc++-v3/ChangeLog:

* libsupc++/new (operator new): Add attribute align_alloc(2) to
overloads taking a std::align_val_t argument.
* testsuite/18_support/new_aligned_warn.cc: New test.

Reviewed-by: Jakub Jelinek 

[Bug middle-end/117354] ICE: in extract_bit_field_1, at expmed.cc:1838 with _BitInt (and asan in some cases)

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

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

--- Comment #12 from Jakub Jelinek  ---
Should be fixed now for 15.1+ so far.

[Bug target/117353] [15 regression] RISC-V: ICE when building libcrypt since r15-3228-g771256bcb9ddc4

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

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

--- Comment #6 from Jeffrey A. Law  ---
So my approach would be to note the insn number, then set a conditional
breakpoint  in make_insn_raw (after it initializes INSN_UID in the new insn). 
The condition would be insn->u2.insn_uid ==  or something close to
that.

That gives us a handle on precisely where it's created, then walk up the frames
into the RISC-V code.  As Robin noted, could easily be a missed
can_create_pseudos_p test.

[Bug fortran/117381] -fmax-identifier-length= is completely ignored

[8e3g6jay6 at mozmail dot com via Gcc-bugs]

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

--- Comment #3 from Jordan <8e3g6jay6 at mozmail dot com> ---
I tested this:

program main
  use, intrinsic :: iso_c_binding
  implicit none

  integer ::
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_PROPERTIES_KHR = 1
end program main

with:
gfortran -std=f95 -fmax-identifier-length=80 ./app/main.f90 

with result:
f951: Fatal Error: Maximum supported identifier length is 63
compilation terminated.

[Bug c++/110137] implement clang -fassume-sane-operator-new

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

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

--- Comment #19 from Jason Merrill  ---
As I was suggesting on IRC, I think CALL_FROM_NEW_OR_DELETE_P already has the
semantics we want, we could also set it on direct calls when assuming sane op
new/delete.  And maybe rename it to something like
CALL_REMOVABLE_NEW_OR_DELETE_P?

[Bug c++/110137] implement clang -fassume-sane-operator-new

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

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

--- Comment #22 from Jason Merrill  ---
But as Jonathan says in comment 10, the replaceable operator new is shared by
the whole program, so I don't see why we would need a per-call flag for the
global memory aliasing property; either the function touches global memory or
it doesn't.

[Bug c++/110137] implement clang -fassume-sane-operator-new

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

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

--- Comment #23 from Jakub Jelinek  ---
I've just tried:
int i, j, k;

void *
foo ()
{
  i = 1;
  j = 2;
  void *p = __builtin_operator_new (32);
  j = 3;
  k = i;
  return p;
}

void *
bar ()
{
  i = 1;
  j = 2;
  void *p = __builtin_malloc (32);
  j = 3;
  k = i;
  return p;
}

void *
baz ()
{
  i = 1;
  j = 2;
  void *p = ::operator new (32);
  j = 3;
  k = i;
  return p;
}
and it seems that both g++ and clang++ for the malloc case optimize j = 2; away
and k = i; into k = 1;, i.e. malloc is assumed not to read nor write global
state visible to the program except the allocation itself.
While __builtin_operator_new results just in k = i; to k = 1; optimization and
not the removal of j = 2; (i.e. __builtin_operator_new is assumed not to modify
global state but is assumed to read it).
And ::operator new isn't optimized either way, no matter whether with
-fassume-sane-operator-new or -fno-assume-sane-operator-new (those flags don't
change foo behavior either).
So I wonder if we really should follow what clang++ does because it doesn't
make much sense, lacks consistency and design.

[Bug c++/110137] implement clang -fassume-sane-operator-new

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

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

--- Comment #20 from Richard Biener  ---
Whether a call clobbers or uses memory is controlled by fnspec these days
and a malloc attribute does _not_ indicate this.  It works for malloc/free
because we make it so via the builtins in builtin_fnspec where the C++
new/delete expressions are handled in gimple_call_fnspec (but not indicating
not using/clobbering global memory).

Note we do treat C++ delete as not escaping the pointer and only writing to
it and not reading.  It still uses/clobbers global memory though.

[Bug c++/117382] Conversion of integral to enumeration outside of range is UB but works in consteval context

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

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

--- Comment #3 from Jonathan Wakely  ---
[dcl.enum] p5:

Each enumeration also has an underlying type. The underlying type can be
explicitly specified using an enum-base. For a scoped enumeration type, the
underlying type is int if it is not explicitly specified. In both of these
cases, the underlying type is said to be
fixed.

[Bug middle-end/117384] [15 regression] ICE when building gwenhywfar-5.10.1 (error: non-trivial conversion in ‘var_decl’)

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

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

Sam James  changed:

   What|Removed |Added

   Keywords|needs-reduction |
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Sam James  ---
```
void testDES2() {
  char testString[] = {
  0x90, 0x80, 0x70, 0x60, 0x50, 0x40, 0x30, 0x20, 1,2,3,4,
  5,6,7,8,9,0x18, 0x27, 0x36, 0x45, 0x54, 0x63, 0x72,
  0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0x88, 0x77, 0x66,
  0x55, 0x44, 0x33, 0x22, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88,
  0x99, 0x88, 0x77, 0x66, 0x55, 0x44, 0x33, 0x22, 0x11, 0x22, 0x33, 0x44,
  0x55, 0x66, 0x77, 0x88, 0x99, 0x88, 0x77, 0x66, 0x55, 0x44, 0x33, 0x22,
  0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0x88, 0x77, 0x66,
  0x55, 0x44, 0x33, 0x22, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88,
  0x99, 0x88, 0x77, 0x66, 0x55, 0x44, 0x33, 0x22, 0x11, 0x22, 0x33, 0x44,
  0x55, 0x66, 0x77, 0x88, 0x99, 0x88, 0x77, 0x66, 0x55, 0x44, 0x33, 0x22,
  0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0x88, 0x77, 0x66,
  0x55, 0x44, 0x33, 0x22, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88};
}
void testDES3() {
  unsigned char testString[] = {
  0x90, 0x80, 0x70, 0x60, 0x50, 0x40, 0x30, 0x20, 1,2,3,4,
  5,6,7,8,9,0x18, 0x27, 0x36, 0x45, 0x54, 0x63, 0x72,
  0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0x88, 0x77, 0x66,
  0x55, 0x44, 0x33, 0x22, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88,
  0x99, 0x88, 0x77, 0x66, 0x55, 0x44, 0x33, 0x22, 0x11, 0x22, 0x33, 0x44,
  0x55, 0x66, 0x77, 0x88, 0x99, 0x88, 0x77, 0x66, 0x55, 0x44, 0x33, 0x22,
  0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88, 0x99, 0x88, 0x77, 0x66,
  0x55, 0x44, 0x33, 0x22, 0x11, 0x22, 0x33, 0x44, 0x55, 0x66, 0x77, 0x88,
  0x99, 0x88, 0x77, 0x66, 0x55, 0x44, 0x33, 0x22, 0x11, 0x22, 0x33, 0x44,
  0x55, 102,  119,  136,  153,  136,  119,  102,  85,   68,   51,   34,
  17,   34,   51,   68,   85,   102,  119,  136,  153,  136,  119,  102,
  85,   68,   51,   34,   17,   34,   51,   68,   85,   102,  119,  136};
}
```

[Bug c++/117382] Conversion of integral to enumeration outside of range is UB but works in consteval context

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Tilir from comment #0)
> [expr.static.cast] / 10
> 
> If the enumeration type does not have a fixed underlying type,

A scoped enumeration type (i.e. "enum class) always has a fixed underlying
type, and all values of the underlying type are valid values of the enum.

[Bug c++/110137] implement clang -fassume-sane-operator-new

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

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

--- Comment #21 from Jason Merrill  ---
(In reply to Richard Biener from comment #20)
> It still uses/clobbers global memory though.

Hmm, I guess that's a separate issue from being able to elide the calls
entirely, which is what CALL_FROM_NEW_OR_DELETE_P (and apparently
__builtin_operator_new) means.

If the calls aren't elided, they could still mess with global memory, and
that's what -fassume-sane-operator-new is for?  The testcase in comment 15
suggests that -fassume-sane-operator-new doesn't also imply elidability.

So I suppose using the same flag won't work after all, they seem to be
different properties.

[Bug middle-end/117384] [15 regression] ICE when building gwenhywfar-5.10.1 (error: non-trivial conversion in ‘var_decl’)

[schwab--- via Gcc-bugs]

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

--- Comment #4 from Andreas Schwab  ---
s/unsigned/signed/ to make it fail the same with -funsigned-char.

[Bug tree-optimization/106073] [12/13/14/15 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-3903-g0288527f47cec669

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

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

--- Comment #14 from GCC Commits  ---
The master branch has been updated by Sam James :

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

commit r15-4803-gdf09173e355f30089b97090b19c095907242b35e
Author: Sam James 
Date:   Thu Oct 31 03:36:23 2024 +

testsuite: add testcase for fixed PR106073

This was fixed by r12-8835-ge8d5f3a1b5a583 which surely made it latent
but richi points out it was likely an instance of PR90348. -fstack-reuse
continues to be a menace, so let's add the testcase.

gcc/testsuite/ChangeLog:
PR middle-end/90348
PR tree-optimization/106073

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

[Bug c++/110137] implement clang -fassume-sane-operator-new

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

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

--- Comment #25 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #24)
> Well, to be precise, it would need to be a per-call property if we want to
> allow people to redefine those and don't use those call flags within the TUs
> where they define it but want to use it in other TUs where the state it
> modifies is just an implementation detail.

Does LTO support per-TU flags?

[Bug middle-end/90348] [11 Regression] Partition of char arrays is incorrect in some cases

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

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

--- Comment #38 from GCC Commits  ---
The master branch has been updated by Sam James :

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

commit r15-4803-gdf09173e355f30089b97090b19c095907242b35e
Author: Sam James 
Date:   Thu Oct 31 03:36:23 2024 +

testsuite: add testcase for fixed PR106073

This was fixed by r12-8835-ge8d5f3a1b5a583 which surely made it latent
but richi points out it was likely an instance of PR90348. -fstack-reuse
continues to be a menace, so let's add the testcase.

gcc/testsuite/ChangeLog:
PR middle-end/90348
PR tree-optimization/106073

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

[Bug c++/110137] implement clang -fassume-sane-operator-new

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #26 from rguenther at suse dot de  ---
On Thu, 31 Oct 2024, jason at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110137
> 
> --- Comment #25 from Jason Merrill  ---
> (In reply to Jakub Jelinek from comment #24)
> > Well, to be precise, it would need to be a per-call property if we want to
> > allow people to redefine those and don't use those call flags within the TUs
> > where they define it but want to use it in other TUs where the state it
> > modifies is just an implementation detail.
> 
> Does LTO support per-TU flags?

LTO supports per function flags (those marked 'Optimization').

[Bug middle-end/117384] [15 regression] ICE when building gwenhywfar-5.10.1 (error: non-trivial conversion in ‘var_decl’)

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

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

--- Comment #2 from Sam James  ---
```
void a() {
  char b[] = {
  144, 128, 112, 96,  80, 64, 48, 32,  1,  2,  3,  4,  5,  6,   7,   8,
  9,   24,  39,  54,  69, 84, 99, 114, 17, 34, 51, 68, 85, 102, 119, 136,
  153, 136, 119, 102, 85, 68, 51, 34,  17, 34, 51, 68, 85, 102, 119, 136,
  153, 136, 119, 102, 85, 68, 51, 34,  17, 34, 51, 68, 85, 102, 119, 136,
  153, 136, 119, 102, 85, 68, 51, 34,  17, 34, 51, 68, 85, 102, 119, 136,
  153, 136, 119, 102, 85, 68, 51, 34,  17, 34, 51, 68, 85, 102, 119, 136,
  153, 136, 119, 102, 85, 68, 51, 34,  17, 34, 51, 68, 85, 102, 119, 136,
  153, 136, 119, 102, 85, 68, 51, 34,  17, 34, 51, 68, 85, 102, 119, 136,
  153, 136, 119, 102, 85, 68, 51, 34,  17, 34, 51, 68, 85, 102, 119, 136};
}
void c() {
  unsigned char b[] = {
  144, 128, 112, 96,  80, 64, 48, 32,  1,  2,  3,  4,  5,  6,   7,   8,
  9,   24,  39,  54,  69, 84, 99, 114, 17, 34, 51, 68, 85, 102, 119, 136,
  153, 136, 119, 102, 85, 68, 51, 34,  17, 34, 51, 68, 85, 102, 119, 136,
  153, 136, 119, 102, 85, 68, 51, 34,  17, 34, 51, 68, 85, 102, 119, 136,
  153, 136, 119, 102, 85, 68, 51, 34,  17, 34, 51, 68, 85, 102, 119, 136,
  153, 136, 119, 102, 85, 68, 51, 34,  17, 34, 51, 68, 85, 102, 119, 136,
  153, 136, 119, 102, 85, 68, 51, 34,  17, 34, 51, 68, 85, 102, 119, 136,
  153, 136, 119, 102, 85, 68, 51, 34,  17, 34, 51, 68, 85, 102, 119, 136,
  153, 136, 119, 102, 85, 68, 51, 34,  17, 34, 51, 68, 85, 102, 119, 136};
}
```

[Bug middle-end/117384] [15 regression] ICE when building gwenhywfar-5.10.1 (error: non-trivial conversion in ‘var_decl’)

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

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

--- Comment #3 from Sam James  ---
Works with -funsigned-char.

[Bug c++/110137] implement clang -fassume-sane-operator-new

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

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

--- Comment #28 from Jan Hubicka  ---
We could make -fassume-sane-operator-new optimization attribute, but then we
would need to prevent inlining functions with insane operators to functions
with sane operators, or drop the sanity on caller.

[Bug tree-optimization/117176] [15 regression] ICE when building netpbm-11.8.0

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

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

--- Comment #11 from GCC Commits  ---
The master branch has been updated by Tamar Christina :

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

commit r15-4802-gd2f9159cfe7ea904e6476cabefea0c6ac9532e29
Author: Tamar Christina 
Date:   Thu Oct 31 12:50:23 2024 +

middle-end: Lower all gconds during vector pattern matching [PR117176]

I have been taking a look at boolean handing once more in the vectorizer.

There are two situation to consider:

  1. when the boolean being created are created from comparing data inputs
then
 for the resulting vector boolean we need to know the vector type and
the
 precision.  In this case, when we have an operation such as NOT on the
data
 element, this has to be lowered to XOR because the truncation to the
vector
 precision needs to be explicit.
  2. when the boolean being created comes from another boolean operation,
then
 we don't need to lower NOT, as the precision doesn't change.  We don't
do
 any lowering for these (as denoted in check_bool_pattern) and instead
the
 precision is copied from the element feeding the boolean statement
during
 VF analysis.

For early break gcond lowering in order to correctly handle the second
scenario
above we punted the lowering of VECT_SCALAR_BOOLEAN_TYPE_P comparisons that
were
already in the right shape.  e.g. e != 0 where e is a boolean does not need
any
lowering.

The issue however is that the statement feeding e may need to be lowered in
the
case where it's a data expression.

This patch changes a bit how we do the lowering.  We now always emit an
additional compare. e.g. if the input is;

  if (e != 0)

where is a boolean we would punt on thi before, but now we generate

  f = e != 0
  if (f != 0)

We then use the same infrastructre as recog_bool to ask it to lower f, and
in
doing so handle and boolean conversions that need to be lowered.

Because we now guarantee that f is an internal def we can also simplify the
SLP building code.

When e is a boolean, the precision we build for f needs to reflect the
precision
of the operation feeding e.  To get this value we use integer_type_for_mask
the
same way recog_bool does, and if it's defined (e.g. we have a data
conversions
somewhere) we pass that precision on instead.  This gets us the correct VF
on the newly lowered boolean expressions.

gcc/ChangeLog:

PR tree-optimization/117176
* tree-vect-patterns.cc (vect_recog_gcond_pattern): Lower all
gconds.
* tree-vect-slp.cc (vect_analyze_slp): No longer check for in vect
def.

gcc/testsuite/ChangeLog:

PR tree-optimization/117176
* gcc.dg/vect/vect-early-break_130-pr117176.c: New test.

[Bug c++/110137] implement clang -fassume-sane-operator-new

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

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

--- Comment #24 from Jakub Jelinek  ---
(In reply to Jason Merrill from comment #22)
> But as Jonathan says in comment 10, the replaceable operator new is shared
> by the whole program, so I don't see why we would need a per-call flag for
> the global memory aliasing property; either the function touches global
> memory or it doesn't.

Well, to be precise, it would need to be a per-call property if we want to
allow people to redefine those and don't use those call flags within the TUs
where they define it but want to use it in other TUs where the state it
modifies is just an implementation detail.
But if we explain it well (and I think we need to do the same for malloc etc.
already) that if one overrides those (whether malloc or ::operator new or
::operator delete) that the implementation should be compiled without -flto and
for the latter two with -fno-sane-operator-new, it could be a global flag,
because for everything else it is really a property of those calls, if it is
sane (doesn't modify nor read global state from POV of other TUs) for a single
call, then it should be sane for all other calls (except the implementation).

[Bug c++/110137] implement clang -fassume-sane-operator-new

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

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

--- Comment #27 from Jan Hubicka  ---
This is somewhat weird testcase which makes two allocations which compiler can
track as non-escaping and tests its ability to disambiguate them:

int test3(int *data)
{
int *val = new int;
*val = 12345;
#ifdef NEW
int *a = new int [1000];
#else
int *a = (int *)::operator new (1000 * sizeof (int));
#endif
for (int i = 0; i < 1000; i++)
data[i]=0;
for (int i = 0; i < 1000; i++)
a[data[i]]=1;
int sum = 0;
for (int i = 0; i < 1000; i++)
sum += a[i];
#ifdef NEW
delete[] a;
#else
::operator delete ((void *)val);
#endif
return *val + sum;
}


If I use the operator new I get:
jan@padlo:/tmp> clang -O2 tt2.C -fassume-sane-operator-new tt2.C -S -DNEW ;
grep 12345 tt2.s
addl$12345, %ebx# imm = 0x3039
jan@padlo:/tmp> clang -O2 tt2.C -fno-assume-sane-operator-new tt2.C -S -DNEW ;
grep 12345 tt2.s
movl$12345, (%rax)  # imm = 0x3039
jan@padlo:/tmp> clang -O2 tt2.C  tt2.C -S -DNEW ; grep 12345 tt2.s
addl$12345, %ebx# imm = 0x3039

so clang assumes sanity by default and needs it to determine that there is no
aliasing between the two returned blocks. As discussed in Comment #14 without
sane operator new, clang is even more conservative then we do about aliasing of
return value.

jan@padlo:/tmp> clang -O2 tt2.C -fassume-sane-operator-new tt2.C -S  ; grep
12345 tt2.s
movl$12345, (%rax)  # imm = 0x3039
jan@padlo:/tmp> clang -O2 tt2.C -fno-assume-sane-operator-new tt2.C -S  ; grep
12345 tt2.s
movl$12345, (%rax)  # imm = 0x3039
jan@padlo:/tmp> clang -O2 tt2.C  tt2.C -S  ; grep 12345 tt2.s
movl$12345, (%rax)  # imm = 0x3039

If functions are called directly, flag has no effect.

jan@padlo:/tmp> gcc -O2 tt2.C  tt2.C -S -DNEW ; grep 12345 tt2.s
leal12345(%rbx), %eax
jan@padlo:/tmp> gcc -O2 tt2.C  tt2.C -S  ; grep 12345 tt2.s
movl$12345, (%rax)

GCC also disambiguates only with sane operator new. I can see we can not
optimize out the store but it is not quite clear to me why we do not propagate
the constant.

[Bug c++/110137] implement clang -fassume-sane-operator-new

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

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

--- Comment #29 from Jan Hubicka  ---
For completeness note that we can also stick info into FUNCTION_DECLs (i.e. by
an attribute) to avoid flags pollution. Then it could be TU sensitive since
lto-symtab knows that in certain cases it should not merge the declaration and
keeps multiple decls for single symbol.
But this does not play well with the observation that at least clang's version
seem to make difference between operator use and direct calls.

[Bug c++/99576] [coroutines] destructor of a temporary called too early within co_await expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||sunsijie at buaa dot edu.cn

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

[Bug c++/117389] std::string that is value-captured by lambda cannot be deconstruct correctly when the lamda is passed as a coroutine argument

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

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

--- Comment #4 from Andrew Pinski  ---
Actually it is a dup of bug 101367.

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

[Bug c++/101367] [coroutines] destructor for capture in lambda temporary operand to co_yield expression called twice

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||sunsijie at buaa dot edu.cn

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

[Bug c++/101367] [coroutines] destructor for capture in lambda temporary operand to co_yield expression called twice

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/117389] std::string that is value-captured by lambda cannot be deconstruct correctly when the lamda is passed as a coroutine argument

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> Actually it is a dup of bug 101367.

And it describes what you found with lambda captures (of strings) to the tee
too.

[Bug testsuite/100272] some incomplete dg-commands

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

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

Sam James  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=116163,
   ||https://github.com/libffi/l
   ||ibffi/pull/859
 CC||sjames at gcc dot gnu.org

--- Comment #7 from Sam James  ---
(In reply to Richard Biener from comment #3)
> This and libffi.complex/complex_int.c is left (libffi is imported from
> upstream).

Fixed in https://github.com/libffi/libffi/pull/859.

[Bug c++/117390] Error message for trying to call an constructor with template arguments should be improved

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
I should mention I found this while looking into PR 29427 (which is about
template constructors with some non deductible template arguments.

[Bug c++/117390] New: Error message for trying to call an constructor with template arguments should be improved

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

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

Bug ID: 117390
   Summary: Error message for trying to call an constructor with
template arguments should be improved
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
struct foo {
template
foo(T i)  {}
};

struct foo1 : foo {
foo1 () : foo(1) {}
};
```

Currently the error message we get is:
```
: In constructor 'foo1::foo1()':
:7:15: error: 'struct foo foo::foo' is not a non-static data member of
'foo1'
7 | foo1 () : foo(1) {}
  |   ^~~
:7:18: error: expected '(' before '<' token
7 | foo1 () : foo(1) {}
  |  ^
```

But it is not obvious why from the error message the code is invalid. Basically
you can't call a constructor with template arguments, only have them deduced.

Note clang is just produces a `error: expected '(' or '{'` and pointing to the
`<` so it is slightly worse.

EDG is only slightly better than both GCC and clang:
```
"", line 7: error: foo is not a template
  foo1 () : foo(1) {}
^
```

[Bug target/29838] should an option to disable use of TLS for -fstack-protector

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 Target||sparc s390
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81708
Summary|-fstack-protector shouldn't |should an option to disable
   |use TLS in freestanding |use of TLS for
   |mode|-fstack-protector
   Last reconfirmed||2024-11-01

--- Comment #15 from Andrew Pinski  ---
X86 has options (PR 81708):
https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/x86-Options.html#index-mstack-protector-guard-reg-3

PPC, aarch64, riscv and arm has options too.

while s390 and sparc does not.

MIPS and sh does not use TLS for the stack guard variable.

[Bug fortran/116668] A very strange error when trying to copy substrings from a select type generic

[kargls at comcast dot net via Gcc-bugs]

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

kargls at comcast dot net changed:

   What|Removed |Added

 CC||kargls at comcast dot net

--- Comment #3 from kargls at comcast dot net ---
Did you try the code you posted in comment #2?

After ordering the modules in a correct order and continue the
long line that violates the Fortran standard, it compiles.

[Bug fortran/117381] -fmax-identifier-length= is completely ignored

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

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #10)
> (In reply to anlauf from comment #9)
> > (In reply to kargls from comment #8)
> > > One could set GFC_MAX_SYMBOL_LEN to a value larger than 63, but what
> > > value makes sense?  (Note it will be less than 1, which is the
> > > longest statement length allowed under the standard)
> > 
> > You sure?
> > 
> > F2023: 6.3.2.1 ... A line shall contain at most ten thousand characters.
> > 
> > But can't you break a line like in:
> > 
> > a&
> > &b&
> > &c = 1
> > 
> > ?
> 
> Ugh, indeed, you are correct!  I forgot that one could split
> a token across a line.  The question still remains.  What
> value does one use; especially given the 145 static buffers?

I am not sure.  We could use 255 as a hard limit, and emit a warning for any
-std=fxyz option when the respective limit is exceeded, at least for -pedantic.