[Bug bootstrap/54659] [4.8 Regression] Bootstrap with --disable-nls broken under Windows

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rolf.ebert.gcc at gmx dot de

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

[Bug bootstrap/56644] --disable-nls requires symbols from libintl

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
Dup.

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

[Bug c++/99610] GCC thinks member function template is a deduction guide

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-source
 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #6 from Andrew Pinski  ---
No testcase in the last 3 years so closing as invalid.

[Bug bootstrap/79120] lm32 ICE in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1747

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID
   Keywords||needs-source

--- Comment #2 from Andrew Pinski  ---
No testcase in the last 3 years so closing as invalid.

[Bug target/118276] Adding empty c'tor to struct of C-array and integer improves codegen

[benfrantzdale at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Ben FrantzDale  ---
I think I understand. You are saying that gcc wants to (or must?) zero-out the
entire struct in the trivial case, which includes `S() = default;` but with
`S() noexcept {}` it winds up on a code path where it knows it doesn't have to
zero the padding, which leads to the xmm version which on the quick-bench.com
CPU turned out faster?

This is backed up by the fact that if I do
```
S() noexcept {
std::memset(this, 0, sizeof(*this));
}
```
I get the `stosq` version, and if I leave c and x uninitialized but `memset`
just them to zero, I still get the xmm version. https://godbolt.org/z/bbnc8a66E



So, is this inconsistency a bug, or just that the optimizer honestly thinks
it's faster to use `stosq` (which may be true on some CPUs)?

FWIW Clang generates the XMM version for all cases:
https://godbolt.org/z/EjGEcd4rv

[Bug tree-optimization/118154] [15 Regression] RISC-V: Miscompile with -march=rv64gcv -O3 since r15-5117-g0b27a7dd050

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #4 from Patrick O'Neill  ---
(In reply to Robin Dapp from comment #3)
> Uh, what a nice small test case ;)  I'll have a look when I'm back mid next
> week.

With a bit more handholding of creduce/cvise:
long a;
char b;
char c[22][484];
int main() {
  for (int e = 4; e < 33; e++) {
for (int f = 0; f < 3; f++)
  for (int g = 0; g < 18; g++) {
c[f][g * 22] = 1;
a = ({ a > 1 ? a : 1; });
  }
for (int i = 0; i < 33; i++)
  for (int h = 0; h < 6; h++)
for (int j = 0; j < 17; j++)
  b = ({ b > 17 ? b : 17; });
  }
  if (c[1][44] != 1)
return 1;
}

Still complex but a few less iterations :-/

[Bug c++/102749] ambigous call on different std::variant types with iterators

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED
   Keywords||needs-source

--- Comment #2 from Andrew Pinski  ---
No testcase in the last 3 years so closing as invalid.

[Bug c++/109936] error: extended character ≠ is not valid in an identifier

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||luigighiron at gmail dot com

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

[Bug preprocessor/118281] Characters and universal character names that are not valid in identifiers are incorrectly rejected before preprocessing

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c++/118277] g++ ICEs with depedent inline-asm string

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

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

--- Comment #7 from Andrew Pinski  ---
static_assert does:
  /* Parse the message expression.  */
  bool string_lit = true;
  for (unsigned int i = 1; ; ++i)
{
  cp_token *tok = cp_lexer_peek_nth_token (parser->lexer, i);
  if (cp_parser_is_pure_string_literal (tok))
continue;
  else if (tok->type == CPP_CLOSE_PAREN)
break;
  string_lit = false;
  break;
}

  if (!string_lit)
{
  location_t loc = cp_lexer_peek_token (parser->lexer)->location;
  if (cxx_dialect < cxx26)
pedwarn (loc, OPT_Wc__26_extensions,
 "% with non-string message only "
 "available with %<-std=c++2c%> or %<-std=gnu++2c%>");

  message = cp_parser_conditional_expression (parser);
  if (TREE_CODE (message) == STRING_CST)
message = build1_loc (loc, PAREN_EXPR, TREE_TYPE (message),
  message);
}
  else if (cxx_dialect >= cxx26)
message = cp_parser_unevaluated_string_literal (parser);
  else
message = cp_parser_string_literal (parser, /*translate=*/false,
/*wide_ok=*/true);
...
  /* Complete the static assertion, which may mean either processing
 the static assert now or saving it for template instantiation.  */
  finish_static_assert (condition, message, assert_loc, member_p,
/*show_expr_p=*/false);



Inside finish_static_assert then does:
  cexpr_str cstr(message);
  if (!cstr.type_check (location))
return;

  /* Save the condition in case it was a concept check.  */
  tree orig_condition = condition;

  if (instantiation_dependent_expression_p (condition)
  || instantiation_dependent_expression_p (message))
{
  /* We're in a template; build a STATIC_ASSERT and put it in
 the right place. */
defer:
  tree assertion = make_node (STATIC_ASSERT);
  STATIC_ASSERT_CONDITION (assertion) = orig_condition;
  STATIC_ASSERT_MESSAGE (assertion) = cstr.message;
  STATIC_ASSERT_SOURCE_LOCATION (assertion) = location;

  if (member_p)
maybe_add_class_template_decl_list (current_class_type,
assertion,
/*friend_p=*/0);
  else
add_stmt (assertion);

  return;
}
...
  int len;
  const char *msg = NULL;
  if (!cstr.extract (location, msg, len))
return;


And finish_static_assert is called again from pt.c for STATIC_ASSERT.

Notice instantiation_dependent_expression_p (message) here.

So the processing of the const expr is left outside and done during semantics
rather than inside the parser to handle dependent arguments and such.

[Bug c/117629] Redefinition of bool type in C23 could have better diagnostic

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

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

--- Comment #10 from GCC Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:321983033d621e3f75e11d380c4463956a3f6e1e

commit r15-6507-g321983033d621e3f75e11d380c4463956a3f6e1e
Author: David Malcolm 
Date:   Thu Jan 2 15:10:15 2025 -0500

c: special-case some "bool" errors with C23 (v2) [PR117629]

Changed in v2:
- distinguish between "bool" and "_Bool" when determining
  standard version

This patch attempts to provide better error messages for
code compiled with C23 that hasn't been updated for
"bool", "true", and "false" becoming keywords.

Specifically:

(1) with "typedef int bool;" previously we emitted:

t1.c:7:13: error: two or more data types in declaration specifiers
7 | typedef int bool;
  | ^~~~
t1.c:7:1: warning: useless type name in empty declaration
7 | typedef int bool;
  | ^~~

whereas with this patch we emit:

t1.c:7:13: error: 'bool' cannot be defined via 'typedef'
7 | typedef int bool;
  | ^~~~
t1.c:7:13: note: 'bool' is a keyword with '-std=c23' onwards
t1.c:7:1: warning: useless type name in empty declaration
7 | typedef int bool;
  | ^~~

(2) with "int bool;" previously we emitted:

t2.c:7:5: error: two or more data types in declaration specifiers
7 | int bool;
  | ^~~~
t2.c:7:1: warning: useless type name in empty declaration
7 | int bool;
  | ^~~

whereas with this patch we emit:

t2.c:7:5: error: 'bool' cannot be used here
7 | int bool;
  | ^~~~
t2.c:7:5: note: 'bool' is a keyword with '-std=c23' onwards
t2.c:7:1: warning: useless type name in empty declaration
7 | int bool;
  | ^~~

(3) with "typedef enum { false = 0, true = 1 } _Bool;" previously we
emitted:

t3.c:7:16: error: expected identifier before 'false'
7 | typedef enum { false = 0, true = 1 } _Bool;
  |^
t3.c:7:38: error: expected ';', identifier or '(' before '_Bool'
7 | typedef enum { false = 0, true = 1 } _Bool;
  |  ^
t3.c:7:38: warning: useless type name in empty declaration

whereas with this patch we emit:

t3.c:7:16: error: cannot use keyword 'false' as enumeration constant
7 | typedef enum { false = 0, true = 1 } _Bool;
  |^
t3.c:7:16: note: 'false' is a keyword with '-std=c23' onwards
t3.c:7:38: error: expected ';', identifier or '(' before '_Bool'
7 | typedef enum { false = 0, true = 1 } _Bool;
  |  ^
t3.c:7:38: warning: useless type name in empty declaration

gcc/c/ChangeLog:
PR c/117629
* c-decl.cc (declspecs_add_type): Special-case attempts to use
bool as a typedef name or declaration name.
* c-errors.cc (get_std_for_keyword): New.
(add_note_about_new_keyword): New.
* c-parser.cc (report_bad_enum_name): New, split out from...
(c_parser_enum_specifier): ...here, adding handling for RID_FALSE
and RID_TRUE.
* c-tree.h (add_note_about_new_keyword): New decl.

gcc/testsuite/ChangeLog:
PR c/117629
* gcc.dg/auto-type-2.c: Update expected output with _Bool.
* gcc.dg/c23-bool-errors-1.c: New test.
* gcc.dg/c23-bool-errors-2.c: New test.
* gcc.dg/c23-bool-errors-3.c: New test.

Signed-off-by: David Malcolm 

[Bug c++/118277] g++ ICEs with depedent inline-asm string

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

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

ak at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #4 from ak at gcc dot gnu.org ---
Most likely it's latent, asm constexpr just reuses the existing constexpr
machinery.

5271static tree
5272initialized_type (tree t)
5273{
5274  if (TYPE_P (t))
5275return t;
5276  tree type = TREE_TYPE (t);
5277  if (TREE_CODE (t) == CALL_EXPR)
5278{
(rr)
5279  /* A constructor call has void type, so we need to look deeper. 
*/
5280  tree fn = get_function_named_in_call (t);
5281  if (fn && TREE_CODE (fn) == FUNCTION_DECL
5282  && DECL_CXX_CONSTRUCTOR_P (fn))
5283type = DECL_CONTEXT (fn);
5284}
5285  else if (TREE_CODE (t) == COMPOUND_EXPR)
5286return initialized_type (TREE_OPERAND (t, 1));
5287  else if (TREE_CODE (t) == AGGR_INIT_EXPR)
5288type = TREE_TYPE (AGGR_INIT_EXPR_SLOT (t));
(rr)
5289  return cv_unqualified (type);
5290}

but t is an unexpected scope_ref with no type which is not handled:

(rr) pt t
 
template-info 
args 
readonly constant decl 
   index 0 level 1 orig_level 1>>>
full-name "struct to_str"
no-binfo use_template=1 interface-unknown
chain >
arg:1 >
../../tsrc/conste.cc:5:23 start: ../../tsrc/conste.cc:5:23 finish:
../../tsrc/conste.cc:5:27>

[Bug target/23093] base class template specialization in library

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Andrew Pinski  ---
No feedback in over 3 years so closing as invalid.

There has been many fixes to both binutils and gcc since 2005 even.
It is also not obvious that it was a bug in GCC 3.4.x rather than a binutils
difference used with GCC 3.3.x and 3.4.x here.

[Bug libstdc++/65042] gcc5 has a template depth problem that was fine in gcc4

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #9 from Andrew Pinski  ---
As mentioned a lower limit is not going to work with newer libstdc++. Plus no
feedback in over 3 years.

[Bug other/83826] Fixinclude creates redefinitions

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Andrew Pinski  ---
So stdint.h here ginclude/stdint-wrap.h:
```
#ifndef _GCC_WRAP_STDINT_H
#if __STDC_HOSTED__
# if defined __cplusplus && __cplusplus >= 201103L
#  undef __STDC_LIMIT_MACROS
#  define __STDC_LIMIT_MACROS
#  undef __STDC_CONSTANT_MACROS
#  define __STDC_CONSTANT_MACROS
# endif
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wpedantic" // include_next
# include_next 
#pragma GCC diagnostic pop
#else
# include "stdint-gcc.h"
#endif
#define _GCC_WRAP_STDINT_H
#endif
```

__STDC_HOSTED__ is not defined because of ffreestanding which then includes
stdint-gcc.h.

But later on sys/time.h will cause to include parts of netbsd's stdint.h.


That is if you use -ffreestanding you can't use netbsd's headers too.  Maybe
-ffreestanding should imply nostdinc but the problem is really in netbsd
headers that partialy use sys/stdint.h and partly stdint.h.  And not really a
GCC issue.


Note it is NOT an issue with fixinclude of sys/time.h here either but rather
dealing with stdint.h.

[Bug fortran/106692] [12/13/14/15 Regression] Cray pointer comparison wrongly optimized away

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2025-01-02

--- Comment #17 from anlauf at gcc dot gnu.org ---
Submitted the version with TREE_THIS_VOLATILE:

https://gcc.gnu.org/pipermail/fortran/2025-January/061479.html

[Bug target/118276] memset 88 uses rep stosq while 80 uses SSE

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
Not on the data type but on the alignment.

[Bug tree-optimization/118279] gcc fails to eliminate unnecessary guards around switch()

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

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

ak at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ak at gcc dot gnu.org,
   ||amacleod at redhat dot com

--- Comment #3 from ak at gcc dot gnu.org ---
Seems like a ranger issue?

[Bug tree-optimization/118279] gcc fails to eliminate unnecessary guards around switch()

[arseny.kapoulkine at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Arseny Kapoulkine  ---
Noted re: godbolt, sorry!

Applying your suggested workaround seems to make the codegen worse? Adding

[[assume(hoff >= 0 && hoff <= 2)]];

before the loop retains the guards for the interior jumps but also changes the
first switch dispatch in the loop to also carry the guard (.L27 is the loop
start):

.L27:
mov rax, r9
shr rax, 2
movzx   eax, BYTE PTR [rdi+rax]
mov edx, eax
and edx, 3
add edx, esi
cmp edx, 5
ja  .L3
jmp [QWORD PTR .L5[0+rdx*8]]

(this is using g++
(Compiler-Explorer-Build-gcc-a8781c4151136968ad38a40344d16940e4ccb700-binutils-2.42)
15.0.0 20250102 (experimental))

[Bug target/118276] memset 88 uses rep stosq while 80 uses SSE

[benfrantzdale at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Ben FrantzDale  ---
Interesting. It looks like the behavior depends on the data type... If I make
11 `long`s it's different from `11 * sizeof(long)` `char`s:
https://godbolt.org/z/nKPcYv4MG

[Bug target/95692] PPC64, suspicious store in front of inline assembly section

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

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

--- Comment #4 from Andrew Pinski  ---
Note the patcher is still broken upstream too:
https://github.com/open-mpi/ompi/blob/0bccfcdf17dc10b0c9c4b7090fe8825d899ac3d8/opal/mca/patcher/patcher.h#L31

[Bug target/95692] PPC64, suspicious store in front of inline assembly section

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://github.com/open-mpi
   ||/ompi/issues/13014

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> Note the patcher is still broken upstream too:
> https://github.com/open-mpi/ompi/blob/
> 0bccfcdf17dc10b0c9c4b7090fe8825d899ac3d8/opal/mca/patcher/patcher.h#L31

Filed https://github.com/open-mpi/ompi/issues/13014 .

[Bug c++/118190] [12/13/14/15 Regression] ICE: in tsubst_expr, at cp/pt.cc:22244

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Keywords|needs-bisection |

--- Comment #3 from Patrick Palka  ---
Started with r10-1280-g78f7607db4c53f

[Bug c++/118245] [14/15 Regression] ICE: in convert_nontype_argument, Passing a lambda as a template argument and base class

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||nshead at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org

--- Comment #7 from Patrick Palka  ---
Started with r14-9232-g3685fae23bb008

[Bug target/63545] ICE when building GCC for ia64-hp-hpux11.23 in hash_table::find_slot_with_hash

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |SUSPENDED

--- Comment #11 from Andrew Pinski  ---
# Obsolete configurations.
case ${target} in
 ia64*-*-hpux* | ia64*-*-*vms* | ia64*-*-elf*   \
 )

[Bug middle-end/61577] [12/13/14/15 Regression] can't compile on hp-ux v3 ia64

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |SUSPENDED

--- Comment #281 from Andrew Pinski  ---
# Obsolete configurations.
case ${target} in
 ia64*-*-hpux* | ia64*-*-*vms* | ia64*-*-elf*   \
 )

[Bug bootstrap/67022] ia64-hpux failed to compile libcpp/charset.c with -O2 optimization

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

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

--- Comment #6 from Andrew Pinski  ---
# Obsolete configurations.
case ${target} in
 ia64*-*-hpux* | ia64*-*-*vms* | ia64*-*-elf*   \
 )

[Bug bootstrap/64919] bootstrap failure of gcc-4.9.2 on ia64-hpux in libgcc

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

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

--- Comment #40 from Andrew Pinski  ---
# Obsolete configurations.
case ${target} in
 ia64*-*-hpux* | ia64*-*-*vms* | ia64*-*-elf*   \
 )

[Bug go/58075] Unable to build go on ia64-hp-hpux11.31

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |SUSPENDED

--- Comment #4 from Andrew Pinski  ---
# Obsolete configurations.
case ${target} in
 ia64*-*-hpux* | ia64*-*-*vms* | ia64*-*-elf*   \
 )

[Bug target/95666] gcc 9.3.0 generates incorrect code with -O3 on HP-UX IA64

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |SUSPENDED
   Last reconfirmed||2025-01-03

--- Comment #1 from Andrew Pinski  ---
# Obsolete configurations.
case ${target} in
 ia64*-*-hpux* | ia64*-*-*vms* | ia64*-*-elf*   \
 )

[Bug target/20094] gcc.dg/transparent-union-* fail on ia64-hpux

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |SUSPENDED

--- Comment #9 from Andrew Pinski  ---
# Obsolete configurations.
case ${target} in
 ia64*-*-hpux* | ia64*-*-*vms* | ia64*-*-elf*   \
 )

[Bug target/39562] when compiling -g gcc and g++ are one byte ahead for the source file name

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-01-03
 Status|UNCONFIRMED |SUSPENDED
 Ever confirmed|0   |1

--- Comment #6 from Andrew Pinski  ---
# Obsolete configurations.
case ${target} in
 ia64*-*-hpux* | ia64*-*-*vms* | ia64*-*-elf*   \
 )

[Bug libgcc/91379] internal compiler error __gcov_fork

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |SUSPENDED

--- Comment #5 from Andrew Pinski  ---
# Obsolete configurations.
case ${target} in
 ia64*-*-hpux* | ia64*-*-*vms* | ia64*-*-elf*   \
 )

[Bug c/118281] New: Characters and universal character names that are not valid in identifiers are incorrectly rejected before preprocessing

[luigighiron at gmail dot com via Gcc-bugs]

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

Bug ID: 118281
   Summary: Characters and universal character names that are not
valid in identifiers are incorrectly rejected before
preprocessing
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luigighiron at gmail dot com
  Target Milestone: ---

C allows using characters (to be clear, character means a unicode scalar value)
or universal character names that would not be valid to start a normal token to
be their own special token:

> The categories of preprocessing tokens are: header names, identifiers,
> preprocessing numbers, character constants, string literals, punctuators, and
> both single universal character names as well as single non-white-space
> characters that do not lexically match the other preprocessing token
> categories.
Section 6.4 "Lexical elements" Paragraph 3 ISO/IEC 9899:2024

For example, given a macro such as #define STR(X)#X it is valid to do STR(@)
even though @ otherwise wouldn't be a valid preprocessing token. However, the
following program is incorrectly rejected:

#include
#define STR(X)#X
int main(){
puts(STR(̈));
}

There is a combining diaresis character U+0308 there which cannot start an
identifier, so the invocation of STR should create a string literal that
contains a combining diaresis character. GCC will also incorrectly reject this
if the combining diaresis is replaced with \u0308. Furthermore, GCC even
rejects universal character names that name characters that would be valid when
used directly:

#include
#define STR(X)#X
int main(){
puts(STR(\u263A));
}

This program is incorrectly rejected, even though replacing \u263A with ☺ (the
character it names) results in GCC accepting the program.

[Bug fortran/118059] [15 Regression] ubsan instrumented gcc: valid value for type 'expr_t' in gcc/fortran/trans-expr.cc

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

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

--- Comment #5 from Martin Jambor  ---
Indeed, our UBSAN testsuite results are green again, thanks for the fix!

[Bug c/118191] missing option to read __float128 from command line argument or string

[newbie-02 at gmx dot de via Gcc-bugs]

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

--- Comment #6 from newbie-02  ---
(In reply to Jonathan Wakely from comment #1)
> Glibc has strtof128 for this purpose.

think typo, strtoflt128 works better!

[Bug target/118184] [14 backport] glibc regression on aarch64 due to early_ra deleting movti instruction since r15-5422-g279475fd7236a9

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

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

Richard Sandiford  changed:

   What|Removed |Added

Summary|[15 regression] glibc   |[14 backport] glibc
   |regression on aarch64 due   |regression on aarch64 due
   |to early_ra deleting movti  |to early_ra deleting movti
   |instruction since   |instruction since
   |r15-5422-g279475fd7236a9|r15-5422-g279475fd7236a9

--- Comment #11 from Richard Sandiford  ---
I'll backport this to GCC 14 after a grace period, since the underlying bug is
present there too.

[Bug libstdc++/118280] New: undefined symbol __atomic_test_and_set in libstdc++.so on Microblaze

[thomas.petazzoni--- via Gcc-bugs]

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

Bug ID: 118280
   Summary: undefined symbol __atomic_test_and_set in libstdc++.so
on Microblaze
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.petazz...@free-electrons.com
  Target Milestone: ---

Since gcc 14.x, the libstdc++ library uses __atomic_test_and_set, and this
symbol isn't available on Microblaze, causing build failures such as:

configure:2557: checking for C++ compiler default output file name
configure:2579:
/home/thomas/buildroot/buildroot/outputs/gcc14-microblaze/host/bin/microblazeel-buildroot-linux-gnu-g++
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -O2 -g0 
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  conftest.cpp 
>&5
/home/thomas/buildroot/buildroot/outputs/gcc14-microblaze/host/lib/gcc/microblazeel-buildroot-linux-gnu/14.2.0/../../../../microblazeel-buildroot-linux-gnu/bin/ld:
/home/thomas/buildroot/buildroot/outputs/gcc14-microblaze/host/lib/gcc/microblazeel-buildroot-linux-gnu/14.2.0/../../../../microblazeel-buildroot-linux-gnu/lib/libstdc++.so:
undefined reference to `__atomic_test_and_set'
collect2: error: ld returned 1 exit status
configure:2583: $? = 1
configure:2621: result:
configure: failed program was:
| /* confdefs.h.  */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE "acpitool"
| #define VERSION "0.5.1"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;

The exact same code builds fine with gcc 13.x.

Reproducer:

$ git clone https://gitlab.com/buildroot.org/buildroot.git
$ cat > .config<

[Bug c++/118277] g++ ICEs with depedent inline-asm string

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #60033|0   |1
is obsolete||

--- Comment #3 from Andrew Pinski  ---
Created attachment 60035
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60035&action=edit
Further reduced

[Bug tree-optimization/118279] gcc fails to eliminate unnecessary guards around switch()

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 60036
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60036&action=edit
Testcase from godbolt

Next time please attach or place inline the testcase

[Bug tree-optimization/118279] gcc fails to eliminate unnecessary guards around switch()

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

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

--- Comment #2 from Andrew Pinski  ---
Adding:

if (hoff > 2 || hoff < 0)
  __builtin_unreachable();

Before the loop fixed it.
Note you can do  `[[assume(hoff >= 0 && hoff <= 2)]];`

It looks like GCC does not figure that out from the switch statement ...

[Bug tree-optimization/118279] gcc fails to eliminate unnecessary guards around switch()

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug target/95692] PPC64, suspicious store in front of inline assembly section

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #3 from Andrew Pinski  ---
Doing this fixes the issue:
int
intercept_munmap(void *start, size_t length)
{
unsigned long toc_save;
asm volatile ("std 2, %0" : "=m" (toc_save) :: "memory");
asm volatile ("nop; nop; nop; nop; nop" ::: "memory");;
volatile MyFunction_t fn;
fn = foo;
fn();
int result = syscall(
91
  , start, length);
asm volatile ("ld  2, %0" : : "m" (toc_save) : "memory");;
return result;
}

That is you need to also mark the asm as clobbering memory. Otherwise the asm
can be moved.

As mentioned in the manual volatile can still move inline-asm around with
volatile:
https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Extended-Asm.html#Volatile-1 :
```
Note that the compiler can move even volatile asm instructions relative to
other code, including across jump instructions. For example, on many targets
there is a system register that controls the rounding mode of floating-point
operations. Setting it with a volatile asm statement, as in the following
PowerPC example, does not work reliably.


```

[Bug c++/118277] avr-g++ segfaults in constexpr string calculation

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||inline-asm

--- Comment #1 from Andrew Pinski  ---
register.cpp:20:48: internal compiler error: Segmentation fault
0x264524e internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:518
0x13cf23f crash_signal
../../gcc/toplev.cc:323
0xd4e114 strip_array_types(tree_node*)
../../gcc/tree.h:5008
0xd4e114 cp_type_quals(tree_node const*)
../../gcc/cp/typeck.cc:11700
0xd41f77 cv_unqualified(tree_node*)
../../gcc/cp/tree.cc:1510
0xd41f77 cv_unqualified(tree_node*)
../../gcc/cp/tree.cc:1503
0xaffd66 cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.cc:8769
0xb00e6f cxx_constant_value(tree_node*, tree_node*, int)
../../gcc/cp/constexpr.cc:9025
0xc4cc2e cxx_constant_value(tree_node*, int)
../../gcc/cp/cp-tree.h:8721
0xc4cc2e cp_parser_asm_string_expression
../../gcc/cp/parser.cc:22973
0xc6c0de cp_parser_asm_definition
../../gcc/cp/parser.cc:23137
0xc89c7d cp_parser_declaration_statement
../../gcc/cp/parser.cc:15117
0xc5765b cp_parser_statement
../../gcc/cp/parser.cc:13003
0xc5aa70 cp_parser_statement_seq_opt
../../gcc/cp/parser.cc:13544
0xc5ad08 cp_parser_compound_statement
../../gcc/cp/parser.cc:13391
0xc7ff6d cp_parser_function_body
../../gcc/cp/parser.cc:26332
0xc7ff6d cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.cc:26383
0xc8244a cp_parser_function_definition_after_declarator
../../gcc/cp/parser.cc:33196
0xc83984 cp_parser_late_parsing_for_member
../../gcc/cp/parser.cc:34068
0xc66fcf cp_parser_class_specifier
../../gcc/cp/parser.cc:27545
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/118277] avr-g++ segfaults in constexpr string calculation

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2025-01-02
   Keywords||ice-on-valid-code
 CC||andi-gcc at firstfloor dot org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Reduced to:
```
template  struct to_str;
template 
void set()
{
  asm((to_str<"" + rname>::value));
}

```


This is valid code at this point since it is unknown what the value of
to_str<"" + rname>::value wil be.

[Bug target/118276] memset 88 uses rep stosq while 80 uses SSE

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Adding empty c'tor to   |memset 88 uses rep stosq
   |struct of C-array and   |while 80 uses SSE
   |integer improves codegen|

--- Comment #7 from Andrew Pinski  ---
The difference comes down to:

```
void g(void*);
void f11()
{
  long a[11]={}
  g(a);
}
void f10()
{
  long a[10] = {};
  g(a);
}
```

[Bug c/117629] Redefinition of bool type in C23 could have better diagnostic

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #11 from David Malcolm  ---
Marking this as resolved, due to the above patch.

Please let me know if other improvements are needed/worthwhile.

[Bug c++/118271] GCC complains on valid friend declaration of overloaded type conversion operator in a derived class

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2025-01-02
 Blocks||65608

--- Comment #1 from Andrew Pinski  ---
A neat little workaround is to supply the fully qualified name for A.  That is
for the reduced testcase is:
friend B::operator ::A *() const;


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608
[Bug 65608] [meta-bug] friend issues

[Bug c++/118277] g++ ICEs with depedent inline-asm string

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

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

--- Comment #5 from Jason Merrill  ---
Seems like cp_parser_asm_string_expression needs to handle template context.

[Bug c++/118271] Friend of operator thinking the injected name is the name of private/protected base class constructor

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Friend of operator thinking |Friend of operator thinking
   |the injected name is the|the injected name is the
   |name of private base class  |name of private/protected
   |constructor |base class constructor

--- Comment #2 from Andrew Pinski  ---
More complete testcase:
```
class A{};
struct B {
  operator A *() const;
};

struct C : protected A {
friend B::operator A *() const;
};

```
s/protected// and the access error is gone even.

[Bug target/118268] bc-1.07.1 fails to build with -masm=intel

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #12 from LIU Hao  ---
(In reply to Antoni from comment #11)
> Oh, I didn't try with bc, I only tried with this code:
> 
> void byte() {}
> 
> The error is the same as without this patch:
> 
> /tmp/ccX2cpcq.s: Error: .size expression for byte does not evaluate to a
> constant

looks like GCC doesn't emit a `.size` directive for *-x64-mingw32..

[Bug c++/118277] g++ ICEs with depedent inline-asm string

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

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

--- Comment #6 from ak at gcc dot gnu.org ---
Can you expand? None of the other callers of cp_parser_constant_expression seem
to do anything special for templates.

[Bug target/118184] [15 regression] glibc regression on aarch64 due to early_ra deleting movti instruction since r15-5422-g279475fd7236a9

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

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

--- Comment #10 from GCC Commits  ---
The trunk branch has been updated by Richard Sandiford :

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

commit r15-6503-g2b687ad95de61091105d040d6bc06cb3d44ac3d1
Author: Richard Sandiford 
Date:   Thu Jan 2 11:34:52 2025 +

aarch64: Detect word-level modification in early-ra [PR118184]

REGMODE_NATURAL_SIZE is set to 64 bits for everything except
VLA SVE modes.  This means that it's possible to modify (say)
the highpart of a TI pseudo or a V2DI pseudo independently
of the lowpart.  Modifying such highparts requires a reload
if the highpart ends up in the upper 64 bits of an FPR,
since RTL semantics do not allow the highpart of a single
hard register to be modified independently of the lowpart.

early-ra missed a check for this case, which meant that it
effectively treated an assignment to (subreg:DI (reg:TI R) 0)
as an assignment to the whole of R.

gcc/
PR target/118184
* config/aarch64/aarch64-early-ra.cc (allocno_assignment_is_rmw):
New function.
(early_ra::record_insn_defs): Mark the live range information as
untrustworthy if an assignment would change part of an allocno
but preserve the rest.

gcc/testsuite/
* gcc.dg/torture/pr118184.c: New test.

[Bug c++/118276] New: Adding empty c'tor to struct of std::array and integer improves codegen

[benfrantzdale at gmail dot com via Gcc-bugs]

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

Bug ID: 118276
   Summary: Adding empty c'tor to struct of std::array and integer
improves codegen
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: benfrantzdale at gmail dot com
  Target Milestone: ---

Given https://godbolt.org/z/exKd1snTM
```
struct S {
long int c[10] = {};
int x{};
#if MODE == 0
#elif MODE == 1
S() = default;
#elif MODE == 2
S() noexcept {}
#endif
};
```
I get different (!) and better(!) codegen for the `S() noexcept {}` version
than the other two versions.

Perf: https://quick-bench.com/q/9hMTq-umqhLawEZDMVXH4qKr6XU

I think (?) `S() noexcept {}` is semantically the same as `S() = default;` or
as no c'tor, so it's a surprise that `S() noexcept {}` leads to
```
pxorxmm0, xmm0
mov DWORD PTR [rdi+80], 0
mov rax, rdi
movups  XMMWORD PTR [rdi], xmm0
movups  XMMWORD PTR [rdi+16], xmm0
movups  XMMWORD PTR [rdi+32], xmm0
movups  XMMWORD PTR [rdi+48], xmm0
movups  XMMWORD PTR [rdi+64], xmm0
ret
```
versus
```
mov rdx, rdi
xor eax, eax
mov ecx, 11
rep stosq
mov rax, rdx
ret
```
Furthermore, my sense is contemporary style is to provide no c'tor or `=
default;` rather than `S() noexcept {}`, so here the code with better style
performs worse for no apparent reason.

[Bug tree-optimization/118194] [12/13/14/15 regression] spurious warning with -Wmaybe-uninitialized with mlock since r11-959-gb825a22890740f

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

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

--- Comment #6 from Sam James  ---
(In reply to vvinayag from comment #5)
> (In reply to Sam James from comment #4)
> > (In reply to Xi Ruoyao from comment #1)
> > > I suppose Glibc should add __attribute__((access(1, none))) for mlock.
> > 
> > commit 013106ae677af9836614ace1a01d25b63fa555a7 (HEAD -> master,
> > origin/master, origin/HEAD)
> > Author: Xi Ruoyao 
> > Date:   Thu Dec 26 12:51:18 2024 +0800
> > 
> > mlock, mlock2, munlock: Tell the compiler we don't dereference the
> > pointer
> > 
> > Since https://gcc.gnu.org/r11-959, the compiler emits
> > -Wmaybe-uninitialized if a const pointer to an uninitialized buffer is
> > passed.  Tell the compiler we don't dereference the pointer to remove
> > the false alarm.
> > 
> > Link: https://gcc.gnu.org/PR118194
> > Signed-off-by: Xi Ruoyao 
> > Reviewed-by: Sam James 
> 
> 
> After this commit, there is a build failure :
> 
> ../sysdeps/unix/sysv/linux/bits/mman-shared.h:60:5: error: attribute
> ‘access’ invalid mode ‘__none__’; expected one of ‘read_only’, ‘read_write’,
> or ‘write_only’
>60 | __attr_access ((__none__, 1));
>   | ^

Can you replace the line with:
__attr_access_none (1);
and let me know if it helps?

[Bug middle-end/118272] [15 Regression] ICE when expanding a constructor of > 2 VLA vectors

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

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

Tamar Christina  changed:

   What|Removed |Added

  Component|tree-optimization   |middle-end
   Target Milestone|--- |15.0

[Bug tree-optimization/118272] New: [15 Regression] ICE when expanding a constructor of > 2 VLA vectors

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

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

Bug ID: 118272
   Summary: [15 Regression] ICE when expanding a constructor of >
2 VLA vectors
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: tnfchris at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---

#pragma GCC target ("+sve")
extern char __attribute__ ((simd, const)) fn3 (int, short);
void test_fn3 (float *a, float *b, double *c, int n)
{
  for (int i = 0; i < n; ++i)
a[i] = fn3 (b[i], c[i]);
}


compiled with -Ofast -march=armv9-a ices with:

during RTL pass: expand
dump file: /app/output.c.270r.expand
: In function 'test_fn3':
:34:12: internal compiler error: in store_constructor, at expr.cc:8065
   34 | a[i] = fn3 (b[i], c[i]);
  |^~~~

which has both a target and an expand bug.

Mine.

[Bug tree-optimization/118154] [15 Regression] RISC-V: Miscompile with -march=rv64gcv -O3 since r15-5117-g0b27a7dd050

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
So we do

t.c:15:31: optimized: loop vectorized using variable length vectors
t.c:10:33: optimized: loop vectorized using variable length vectors

but when disabling either vectorization via -fdbg-cnt=vect_loop:1-1 or 2-2
the code works as expected.  The loops are not unrolled so it seems to me
the vectorized code might be OK and optimizations afterwards wreck it somehow.

Interestingly the first vector loop has an epilogue, we're using VLA
vectors but not a fully masked loop.

It's also interesting the loop computing b is relevant at all.

This needs to be analyzed by somebody more familiar with RISC-V, it might
bisect to a vectorizer change but the fault seems to be entirely elsewhere.

Confirmed at least.

[Bug target/118268] bc-1.07.1 fails to build with -masm=intel

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

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

--- Comment #11 from Antoni  ---
Oh, I didn't try with bc, I only tried with this code:

void byte() {}

The error is the same as without this patch:

/tmp/ccX2cpcq.s: Error: .size expression for byte does not evaluate to a
constant

[Bug target/118276] Adding empty c'tor to struct of C-array and integer improves codegen

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

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

--- Comment #1 from Andrew Pinski  ---
Is the memset using sse better than rep stosq?

If rep stosq is worse, I suspect you need to specify which core you are running
on. And it depends on that too.

[Bug rtl-optimization/117938] [15 Regression] wrong code with -O2 --param=max-cse-insns=1 with late-combine (since r15-1735-ge62ea4fb8ffcab)

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

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

Richard Sandiford  changed:

   What|Removed |Added

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

--- Comment #14 from Richard Sandiford  ---
Testing a patch.

[Bug c++/118275] New: [15 Regression] ICE in size_binop_loc

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

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

Bug ID: 118275
   Summary: [15 Regression] ICE in size_binop_loc
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

struct A { int a; char b[]; };
void bar (A *);

void
foo ()
{
  static struct A a = { .a = 1, .b = {
#embed __FILE__
 } };
  bar (&a);
}

ICEs in C++ starting with r15-5958.
Similarly,
struct A { int a; char b[]; };
void bar (A *);

void
foo ()
{
  static struct A a = { .a = 1, .b = {
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
 } };
  bar (&a);
}
started to ICE with r15-6339 but doesn't ICE since r15-6448 (temporary
reversion).

[Bug c++/118275] [15 Regression] ICE in size_binop_loc

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |15.0
   Last reconfirmed||2025-01-02
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Priority|P3  |P1

[Bug tree-optimization/118171] [15 Regression] during GIMPLE pass: pre ICE: verify_gimple failed: non-top-level 'realpart_expr' at -O2

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

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

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

https://gcc.gnu.org/g:6488d5b86126a538ebb8560556dd462ec3d5d62e

commit r15-6504-g6488d5b86126a538ebb8560556dd462ec3d5d62e
Author: Richard Biener 
Date:   Wed Jan 1 16:07:03 2025 +0100

tree-optimization/118171 - GENERIC folding in PRE results in invalid GIMPLE

PRE applies GENERIC folding to some component ref components which
might result in invalid GIMPLE, like a VIEW_CONVERT_EXPR wrapping
a REALPART_EXPR as in the PR.  The following removes all GENERIC
folding in the code re-constructing a GENERIC component-ref from
the PRE VN IL.

PR tree-optimization/118171
* tree-ssa-pre.cc (create_component_ref_by_pieces_1): Do not
fold any component ref parts.

* gcc.dg/torture/pr118171.c: New testcase.

[Bug tree-optimization/118171] [15 Regression] during GIMPLE pass: pre ICE: verify_gimple failed: non-top-level 'realpart_expr' at -O2

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed.

[Bug target/118252] i386 should implement CASE_VECTOR_SHORTEN_MODE

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
IIRC one issue is the insn lengths are not reliable (on the conservative side).

[Bug c++/118275] [15 Regression] ICE in size_binop_loc

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

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

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

Untested fix.  The PR117190 assumption was not correct, the FEs aren't
consistent in the type of CONSTRUCTOR_ELTS indexes for arrays.

[Bug target/118268] bc-1.07.1 fails to build with -masm=intel

[lh_mouse at 126 dot com via Gcc-bugs]

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

--- Comment #10 from LIU Hao  ---
(In reply to Antoni from comment #9)
> This doesn't seem to work.
> 
> From what I can see, it seems we might need to define ASM_OUTPUT_LABELREF
> for i386. Would that make sense?

What's the error? I tried building bc on {i686,x86_64}-w64-mingw32 [1] and
there were no errors. But I suspect it's because labels in directives are
usually not quoted:

   .def byte;   .scl2;  .type   32; .endef

If you meant that it should be quoted, I'd like to say yes, it makes sense to
do so.


[1] https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-bc

[Bug tree-optimization/118279] New: gcc fails to eliminate unnecessary guards around switch()

[arseny.kapoulkine at gmail dot com via Gcc-bugs]

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

Bug ID: 118279
   Summary: gcc fails to eliminate unnecessary guards around
switch()
   Product: gcc
   Version: 14.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arseny.kapoulkine at gmail dot com
  Target Milestone: ---

When a switch is duplicated 4 times, gcc and clang "inline" the switch dispatch
for subsequent switches into the previous switch cases tail. This is correct
and expected. However, clang consistently uses a dispatch sequence without a
conditional branch; gcc does not guard the first switch dispatch, but does keep
unnecessary guards in subsequent switches.

Small example; the problem is visible at line 33 for gcc, where it emits:

cmp edx, 5
ja  .L3
jmp [QWORD PTR .L11[0+rdx*8]]

vs clang that emits, at line 25:

movsxd  r10, dword ptr [r8 + 4*r10]
add r10, r8
jmp r10

Note that clang's dispatch sequence uses an extra `add` because clang seems to
default to PIE; using `-fpie` for gcc produces equivalent code with the guard
retained as well:

cmp edx, 5
ja  .L3
movsx   rdx, DWORD PTR [r10+rdx*4]
add rdx, r10
jmp rdx


https://gcc.godbolt.org/z/P86shdno9

[Bug target/111814] [SH] __builtin_nan* returns signalling NaNs instead of quiet NaNs and vice versa

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

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

--- Comment #8 from Joseph S. Myers  ---
See https://sourceware.org/legacy-ml/libc-alpha/2018-02/msg00440.html and
https://sourceware.org/bugzilla/show_bug.cgi?id=30973 regarding glibc fixes
that should preferably be done in sync with a GCC fix for this issue.

[Bug target/111814] [SH] __builtin_nan* returns signalling NaNs instead of quiet NaNs and vice versa

[jiaxun.yang at flygoat dot com via Gcc-bugs]

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

--- Comment #9 from Jiaxun Yang  ---
(In reply to Joseph S. Myers from comment #8)
> See https://sourceware.org/legacy-ml/libc-alpha/2018-02/msg00440.html and
> https://sourceware.org/bugzilla/show_bug.cgi?id=30973 regarding glibc fixes
> that should preferably be done in sync with a GCC fix for this issue.

I'll try on glibc side.

[Bug target/118184] [14 backport] glibc regression on aarch64 due to early_ra deleting movti instruction since r15-5422-g279475fd7236a9

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

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

--- Comment #12 from GCC Commits  ---
The trunk branch has been updated by Richard Sandiford :

https://gcc.gnu.org/g:99d5ef700619c28904846399a6f6692af4c56b1b

commit r15-6506-g99d5ef700619c28904846399a6f6692af4c56b1b
Author: Richard Sandiford 
Date:   Thu Jan 2 17:33:49 2025 +

Use _Float128 in test for PR118184

The test was failing on x86 because longdouble128 only checks sizeof,
rather than a full 128-bit payload.  Using _Float128 is more portable
and still exposes the original bug.

gcc/testsuite/
PR target/118184
* gcc.dg/torture/pr118184.c: Use _Float128 instead of long double.

[Bug tree-optimization/118194] [12/13/14/15 regression] spurious warning with -Wmaybe-uninitialized with mlock since r11-959-gb825a22890740f

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

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

--- Comment #7 from Sam James  ---
I committed that fix to glibc.

[Bug target/118252] i386 should implement CASE_VECTOR_SHORTEN_MODE

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

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

ak at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ak at gcc dot gnu.org

--- Comment #2 from ak at gcc dot gnu.org ---
I suspect most switches are small, so even with a safety factor of 2 or 4 it
would still be useful.

Or alternatively could push the decision  to the assembler with some .if, but
that would definitely be more code.

[Bug tree-optimization/103680] Jump threading and switch corrupts profile

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

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

Alex Coplan  changed:

   What|Removed |Added

 CC||acoplan at gcc dot gnu.org

--- Comment #13 from Alex Coplan  ---
I came across the following testcase (reduced from
gcc/testsuite/g++.dg/torture/pr116902.C) which shows profile mismatches
starting in jump threading:

$ cat t.cc
unsigned a;
long i_d;
void i(char c[][4]) {
  for (char e; e; e += ~0)
for (bool h = 0; h < bool(i_d); h = 1)
  a = c[2][1] - c[2][2];
}

I see:

$ ./xgcc -B . -c t.cc -O2 -S -o /dev/null
-fdump-tree-threadfull1-blocks-details=- | grep -B 1 "Invalid sum"
;;   basic block 3, loop depth 1, count 955630224 (estimated locally, freq
65.4628), maybe hot
;;   Invalid sum of incoming counts 114571471 (estimated locally, freq 7.8484),
should be 955630224 (estimated locally, freq 65.4628)
--
;;   basic block 5, loop depth 1, count 118111600 (estimated locally, freq
8.0909), maybe hot
;;   Invalid sum of incoming counts 959170353 (estimated locally, freq
65.7053), should be 118111600 (estimated locally, freq 8.0909)


where the profile was at least consistent in the previous pass:

$ ./xgcc -B . -c t.cc -O2 -S -o /dev/null
-fdump-tree-mergephi2-blocks-details=- | grep -B 1 "Invalid sum"

looking at the jump threading dump I see:

> Jump threading proved that the probability of edge 4->5 was originally 
> estimated too small. (it is 11.0% (guessed) should be 89.0% (guessed))

which suggests that jump threading is just exposing a problem in the profile
that was introduced earlier, but didn't manifest as an inconsistent profile.

[Bug ada/118274] New: expression function fails when normal equivalent ones don't.

[00120260a at gmail dot com via Gcc-bugs]

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

Bug ID: 118274
   Summary: expression function fails when normal equivalent ones
don't.
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 00120260a at gmail dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

This is not normal:
> q09.ada:19:61: error: there is no applicable operator "*" for type "Rates" 
> defined at line 3

procedure Main is
  type Money is delta 0.01 digits 12;
  type Rates is delta 0.0001 digits 11;
  Conversion: constant array(1..2, 1..2) of Rates := ((1.0, 0.5059), (1.9767,
1.0));
  Special: constant Rates := 1.1;
  Extra: Boolean := True;
  function "*"(Left, Right: Rates) return Rates is
  begin
if Extra then
  return Standard."*"(Left, Right+0.01);
else 
  return Standard."*"(Left, Right);
end if;
  end "*";
  function "-"(Left, Right: Rates) return Rates is
  begin
  return Standard."*"(Left, Right+(if Extra then 0.01 else 0.0));
  end "-";
  function "+"(Left, Right: Rates) return Rates is (Standard."*"(Left,
Right+(if Extra then 0.01 else 0.0))); -- FAILS
begin
 null;
end Main;

[Bug tree-optimization/118194] [12/13/14/15 regression] spurious warning with -Wmaybe-uninitialized with mlock since r11-959-gb825a22890740f

[vvinayag at arm dot com via Gcc-bugs]

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

vvinayag at arm dot com changed:

   What|Removed |Added

 CC||vvinayag at arm dot com

--- Comment #5 from vvinayag at arm dot com ---
(In reply to Sam James from comment #4)
> (In reply to Xi Ruoyao from comment #1)
> > I suppose Glibc should add __attribute__((access(1, none))) for mlock.
> 
> commit 013106ae677af9836614ace1a01d25b63fa555a7 (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Xi Ruoyao 
> Date:   Thu Dec 26 12:51:18 2024 +0800
> 
> mlock, mlock2, munlock: Tell the compiler we don't dereference the
> pointer
> 
> Since https://gcc.gnu.org/r11-959, the compiler emits
> -Wmaybe-uninitialized if a const pointer to an uninitialized buffer is
> passed.  Tell the compiler we don't dereference the pointer to remove
> the false alarm.
> 
> Link: https://gcc.gnu.org/PR118194
> Signed-off-by: Xi Ruoyao 
> Reviewed-by: Sam James 


After this commit, there is a build failure :

../sysdeps/unix/sysv/linux/bits/mman-shared.h:60:5: error: attribute ‘access’
invalid mode ‘__none__’; expected one of ‘read_only’, ‘read_write’, or
‘write_only’
   60 | __attr_access ((__none__, 1));
  | ^
In file included from ../include/sys/mman.h:2,
 from ../sysdeps/generic/ldsodefs.h:34,
 from ../sysdeps/aarch64/ldsodefs.h:47,
 from ../sysdeps/gnu/ldsodefs.h:46,
 from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
 from :2:
../misc/sys/mman.h:104:5: error: attribute ‘access’ invalid mode ‘__none__’;
expected one of ‘read_only’, ‘read_write’, or ‘write_only’
  104 | __attr_access ((__none__, 1));
  | ^
../misc/sys/mman.h:108:5: error: attribute ‘access’ invalid mode ‘__none__’;
expected one of ‘read_only’, ‘read_write’, or ‘write_only’
  108 | __attr_access ((__none__, 1));
  | ^

I am trying to build for aarch64-none-linux-gnu target on an
aarch64-none-linux-gnu machine. The gcc version on the build machine is 7.5.0.

[Bug target/118268] bc-1.07.1 fails to build with -masm=intel

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

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

--- Comment #9 from Antoni  ---
(In reply to LIU Hao from comment #8)
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59639 should solve this
> issue. The unfortunate fact is that nobody is taking care of it so you
> probably have to build GCC yourself.

This doesn't seem to work.

>From what I can see, it seems we might need to define ASM_OUTPUT_LABELREF for
i386. Would that make sense?

[Bug c++/118277] New: avr-g++ segfaults in constexpr string calculation

[crab.delicieux at pm dot me via Gcc-bugs]

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

Bug ID: 118277
   Summary: avr-g++ segfaults in constexpr string calculation
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crab.delicieux at pm dot me
  Target Milestone: ---

Created attachment 60033
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60033&action=edit
Archive containing original source code + .ii output from GCC + full build
output (output.log)

Hello,

I encountered a weird bug when compiling a file using avr-g++ (with a version I
built myself, that otherwise works normally...). The bug seems to appear during
the translation to assembler (the avr-g++ -S call fails, i.e. before assembly).

It is to be noted that the code should not compile anyway, for various reason.
On "normal" g++ (from Debian 12 repo) the compiler does indeed terminate and
yield various (expected) errors.

I think the main problem comes from an uncanny use of template parameters (and
especially strings in non-type template parameters and compile-time string
calculation used in asm clauses (don't ask)), or maybe because of the use of
auto?


If you have any question/remark please do not hesitate to come back to me.

Note that imho the bug is not blocking (I have to fix the errors and I have
plenty of workarounds to test).


Thanks!


Best regards,
krab.

[Bug tree-optimization/118273] New: [15 Regression] ICE when vectorizing uniform vector function

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

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

Bug ID: 118273
   Summary: [15 Regression] ICE when vectorizing uniform vector
function
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: tnfchris at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---

#pragma GCC target ("+sve")
extern char __attribute__ ((simd, const)) fn3 (short);
void test_fn3 (float *a, float *b, double *c, int n)
{
  for (int i = 0; i < n; ++i)
a[i] = fn3 (c[i]);
}

segfaults when compiling with -Ofast -march=armv9-a with:

during GIMPLE pass: vect
dump file: /app/output.c.182t.vect
: In function 'test_fn3':
:21:6: internal compiler error: Segmentation fault
   21 | void test_fn3 (float *a, float *b, double *c, int n)
  |  ^~~~

Which happens in vect_get_loop_mask, the vectorizer registers a VNx16QI mode
mask and asks for 2 VNx8BI mode ones, which should be ok.

The rgroup is correctly created for two masks but the second entry's type is
NULL.

Mine.

[Bug tree-optimization/118273] [15 Regression] ICE when vectorizing uniform vector function

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

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

Tamar Christina  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug c++/118278] New: [15 Regression] ICE in write_template_arg_literal

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

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

Bug ID: 118278
   Summary: [15 Regression] ICE in write_template_arg_literal
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

// { dg-do compile { target c++20 } }
// { dg-options -fabi-compat-version=0 }

struct C { unsigned char a[5], b[5], c[128]; };
template  struct Y { };

typedef Y Tca;
void g (Tca) { }
// { dg-final { scan-assembler
"_Z1g1YIXtl1CtlA5_hLh1ELh2EEtlS1_EtlA128_h(?:Lh\[0-9]*E){128}" } }

typedef Y Tcs;
void h (Tcs) { }
// { dg-final { scan-assembler
"_Z1h1YIXtl1CtlA5_hLh1ELh2EEtlS1_EtlA128_h(?:Lh\[0-9]*E){128}" } }

ICEs starting with r15-5958.
Similarly,
// Verify that class literals are mangled the same way regardless
// of the underlying type.
// { dg-do compile { target c++20 } }
// { dg-additional-options -fabi-compat-version=0 }

struct I { int a[5], b[5], c[144]; };
template  struct X { };

typedef X Ti;
void f (Ti) { }
// { dg-final { scan-assembler
"_Z1f1XIXtl1ItlA5_iLi1ELi2EEtlS1_EtlA144_i(?:Li101ELi102ELi103ELi104ELi105ELi106ELi255ELi254ELi253ELi252ELi251ELi0ELi1ELi2ELi3ELi4E){8}Li101ELi102E"
} }

struct C { unsigned char a[5], b[5], c[144]; };
template  struct Y { };

typedef Y Tca;
void g (Tca) { }
// { dg-final { scan-assembler
"_Z1g1YIXtl1CtlA5_hLh1ELh2EEtlS1_EtlA144_h(?:Lh101ELh102ELh103ELh104ELh105ELh106ELh255ELh254ELh253ELh252ELh251ELh0ELh1ELh2ELh3ELh4E){8}Lh101ELh102E"
} }

typedef Y Tcs;
void h (Tcs) { }
// { dg-final { scan-assembler
"_Z1h1YIXtl1CtlA5_hLh1ELh2EEtlS1_EtlA144_h(?:Lh101ELh102ELh103ELh104ELh105ELh106ELh255ELh254ELh253ELh252ELh251ELh0ELh1ELh2ELh3ELh4E){8}Lh101ELh102E"
} }

struct S { signed char a[5], b[5], c[144]; };
template  struct Z { };

typedef Z Tsc;

void i (Tsc) { }
// { dg-final { scan-assembler
"_Z1i1ZIXtl1StlA5_aLa1ELa2EEtlS1_EtlA144_a(?:La101ELa102ELa103ELa104ELa105ELa106ELa95ELa94ELa93ELa92ELa91ELa0ELa1ELa2ELa3ELa4E){8}La101ELa102E"
} }

started to ICE with r15-6339 but doesn't ICE since r15-6448 (temporary
reversion).

[Bug c++/118278] [15 Regression] ICE in write_template_arg_literal

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

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

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

Untested fix.

[Bug c++/118278] [15 Regression] ICE in write_template_arg_literal

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Last reconfirmed||2025-01-02
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Priority|P3  |P1
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

[Bug target/118276] Adding empty c'tor to struct of C-array and integer improves codegen

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> The difference is one is zeroing out the padding while the other is not.

The difference comes down to a trivial constructor vs not trivial. (at least
internal to GCC). Basically with the defauled constructor (and since GCC can
see those are all value initialized to 0), it is still considered a trivial
constructor so it zeros out the whole struct including the padding bits/byte.
Anyways the `rep stosq` vs using SSE is a target issue of expanding memset of 0
and it depends on the processor which is faster.

[Bug target/118276] Adding empty c'tor to struct of C-array and integer improves codegen

[benfrantzdale at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Ben FrantzDale  ---
@Andrew Pinski, the quick-bench link shows the `stosq` version running slower.
Regardless, the code-gen shouldn't be different, should it? (Is there any
semantic difference I'm missing?)

[Bug target/118276] Adding empty c'tor to struct of C-array and integer improves codegen

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Ben FrantzDale from comment #2)
> @Andrew Pinski, the quick-bench link shows the `stosq` version running
> slower. Regardless, the code-gen shouldn't be different, should it? (Is
> there any semantic difference I'm missing?)

Yes, even though both are standard layout structs, they is a difference when it
comes to if they are pod in the sense of the abi.

[Bug tree-optimization/118154] [15 Regression] RISC-V: Miscompile with -march=rv64gcv -O3 since r15-5117-g0b27a7dd050

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

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

--- Comment #3 from Robin Dapp  ---
Uh, what a nice small test case ;)  I'll have a look when I'm back mid next
week.

[Bug target/118276] Adding empty c'tor to struct of C-array and integer improves codegen

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

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

--- Comment #4 from Andrew Pinski  ---
The difference is one is zeroing out the padding while the other is not.