[Bug tree-optimization/113134] gcc does not version loops with early break conditions that don't have side-effects

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #18 from Richard Biener  ---
The loop is rotated by header copying and the "combined" exit test looks like

  if (i_21 == 1001)
goto ; [1.00%]
  else
goto ; [99.00%]

   [local count: 1004539166]:
  i_18 = i_21 + 1;
  if (N_13(D) > i_18)
goto ; [94.50%]
  else
goto ; [5.50%]

this could be rewritten to use min(1002, N_13(D)) with the knowledge how
'i' evolves.  We get i_21 != 1001 || N_13(D) > (i_21 + 1) for the iteration
condition which I think we cannot combine in general.

The "easiest" way would be to have loop splitting split the loop on the
i_21 == 1001 condition I think.

[Bug tree-optimization/113265] New: [Regression] Missed optimization for redundancy computation elimination may be due to constant propagation about 0 too late

[652023330028 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 113265
   Summary: [Regression] Missed optimization for redundancy
computation elimination may be due to constant
propagation about 0 too late
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 652023330028 at smail dot nju.edu.cn
  Target Milestone: ---

Hello, we noticed that maybe there is a missed optimization for redundancy
computation elimination.

https://godbolt.org/z/drfejE5cP

int x,y,z;
void func(int a, int b){
a=b-x;
b=a;
y=0;
z=(y+a)/(-b);
}

GCC -O3 :
func(int, int):
mov ecx, DWORD PTR x[rip]
mov eax, esi
mov DWORD PTR y[rip], 0
sub eax, ecx
sub ecx, esi
cdq
idivecx
mov DWORD PTR z[rip], eax
ret

Earlier GCC versions get the expected optimizations:
Expected code (GCC 7.5):
func(int, int):
mov DWORD PTR y[rip], 0
mov DWORD PTR z[rip], -1
ret

The following code is optimized by gcc as expected:
void func2(int a, int b){
a=b-x;
b=a;
y=0;
z=(0+a)/(-b);
}

Comparing the code for func and func2 and their ccp1(tree), we suspect that
this issue may be caused by too late propagation about y=0.

Thank you very much for your time and effort! We look forward to hearing from
you

[Bug c++/113266] New: GCC rejects static global variable as non type template parameter

[jlame646 at gmail dot com via Gcc-bugs]

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

Bug ID: 113266
   Summary: GCC rejects static global variable as non type
template parameter
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jlame646 at gmail dot com
  Target Milestone: ---

The following valid program is rejected by gcc but accepted by other compilers.
https://godbolt.org/z/x1eG9dhc3

```
#include 
#include 

template 
void printString()
{
std::cout << N << std::endl;
}

int a;
static int b;

template void printString(); //all accepts this
template void printString();//only gcc rejects this


int main()
{

}
```

GCC says:
```
error: the value of 'b' is not usable in a constant expression
   14 | template void printString();//only gcc rejects this
  |   ^
:11:12: note: 'int b' is not const
   11 | static int b;
  |^
```

[Bug ada/113195] [13/14 regression] internal error on anonymous access type equality

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

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

Eric Botcazou  changed:

   What|Removed |Added

Summary|gnat bug box when comparing |[13/14 regression] internal
   |access to subtype with  |error on anonymous access
   |access inside record|type equality
   Last reconfirmed||2024-01-08
 CC||ebotcazou at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
The record is actually irrelevant, this only comes from the designated types:

package P is
   subtype I is Integer;
   A : access I;

   Acc : access Integer;

   function F return Boolean is (A = Acc);
end P;

eric@fomalhaut:~/build/gcc/native> ~/install/gcc/bin/gcc -c p.ads 
+===GNAT BUG DETECTED==+
| 14.0.0 20240108 (experimental) [master r14-6995-g4d31d660620]
(x86_64-suse-linux) GCC error:|
| in build_binary_op, at ada/gcc-interface/utils2.cc:1147  |
| Error detected at p.ads:7:38 

This worked up to GCC 12.

[Bug ada/113195] [13/14 regression] internal error on anonymous access type equality

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

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
Investigating.

[Bug tree-optimization/112457] Possible better vectorization of different reduction min/max reduction

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

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

--- Comment #5 from Richard Biener  ---
You want to find the duplicate bugreport for the min/max + index reductions,
IIRC the issue is that we fail the reduction detection because of multi-use
and we should really have two conditional reductions, one on the value and
one on the index without trying to be too clever combining them into a single
one.

That is, don't try to invent sth completely new based on what LLVM does but
understand what's missing in GCCs handling of conditional reductions
(it can do conditional value and conditional index reductions just fine,
just not both at the same time IIRC).

[Bug rtl-optimization/109052] Unnecessary reload with -mfpmath=both

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #9 from Uroš Bizjak  ---
Implemented for gcc-14.

[Bug ipa/113203] __attribute__ ((always_inline)) fails with C99/LTO/-Og.

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
With -Og we specifically disable IPA inlining, not considering that
always-inline functions might only appear with LTO.  I don't think that
cross-TU
"always-inline" is sensible, and we probably should not merge the always-inline
definition with the not always-inline declaration that's effective for the
call in question.  So we should accept the code at compile-time but not
honor always-inline cross-TU in the way it is presented by the testcase.
The bool f(int); declaration should force an out-of-line copy of the C99
inline, right?  And GCC always-inline doesn't change that?

Btw, the same should happen with -O2 -flto but __attribute__((optimize(0))) on
main().

It might be worth amending the always-inline documentation as well.

[Bug tree-optimization/110176] [11/12/13/14 Regression] wrong code at -Os and above on x86_64-linux-gnu since r11-2446

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
comment#4 suggests the iteration order change just exposes the issue
highlighted in comment#1?

I will eventually investigate.

[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete

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

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

--- Comment #17 from Jonathan Wakely  ---
(In reply to Nicholas Miell from comment #14)
> Again, this version of tcmalloc predates aligned_alloc and the align_val_t
> versions of operator new and delete.
> 
> Again, the C++ standard does not require the application to displace
> aligned_malloc when it displaces operator new or delete.
> 
> Again, it is libstdc++ that is calling aligned_alloc, not the application.
> 
> Again, the application displaced all the versions of operator new and delete
> that were present in the version of the C++ standard that it targeted, in
> addition to all the C malloc functions in the C standard it targeted.

Replacing malloc and free is not allowed by the standard at all, so this is
already outside the standard.

> Again, libstdc++ broke the ABI when it introduced the align_val_t versions
> of operator new and delete because existing correctly functioning
> applications stopped working in the presence of the new version of libstdc++.
> 
> Again, libstdc++ has elected to provide only one version of the C++ runtime
> implementation that supports multiple versions of the C++ standard
> simultaneously, instead of forking the library for every new revision of the
> language standard.
> 
> Again, you could probably fix this issue by implementing all of the newly
> introduced versions of operator new and delete solely using the versions of
> operator new and delete that were present when libstdc++.so.6 was first
> introduced.

We could do that, or we could just implement the aligned new in terms of malloc
and over-allocate and manually align in the buffer (which is what we have to do
for some targets without aligned_alloc or anything similar). But that sucks,
and wastes memory and cycles.

If aligned_alloc is supported, we use it. And that means we use free too.



> Attempting to stick the blame on something other than libstdc++ doesn't even
> solve the problem of the application crashing at startup, ultimately it will
> have to be libstdc++ that works around this issue regardless. The
> application certainly isn't getting updated, nor should it require updating;
> that's the whole point of having ABIs in the first place.
> 
> The C++23 standard says that whether the default versions of operator new
> "involves a call to the C standard library functions malloc or aligned_alloc
> is unspecified." I assert that a C++ runtime that purports to simultaneously
> implement both C++14 and previous (which do not have aligned_alloc) and

It's irrelevant whether C++14 has aligned_alloc, since libstdc++ doesn't
provide that anyway. What matters is whether the underlying libc provides it.
If it does, we call it.

> C++17 and later (which do have aligned_alloc) must not call aligned_alloc in
> the default behavior of any version of operator new as a basic quality of
> implementation detail, given that C++14 and previous applications (which the
> C++ runtime explicitly supports) are allowed to displace operator new and
> delete without any knowledge of aligned_alloc.

The problem has ABSOLUTELY NOTHING to do with replacing new/delete, it's
ENTIRELY due to replacing malloc/free.

You would get exactly the same problem in C code if your library using an old
tcmalloc was called by a new application that used aligned_alloc and then
called free, resulting in a call to the old tcmalloc free.

This is not a libstdc++ problem, nor a C++ problem.

If you want to blame the ABI break on something, blame C11 for adding
aligned_alloc and requiring that free can handle it. Libstdc++ has no way to
know if the version of free present at runtime can handle aligned_alloc. All we
can tell is that aligned_alloc exists, we can't tell whether some library that
might be linked to later breaks the libc ABI by replacing free in a way that
makes aligned_alloc unusable.

[Bug tree-optimization/113210] [14 Regression] ICE: tree check: expected integer_cst, have cond_expr in get_len, at tree.h:6481

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

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

--- Comment #9 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #8)
> Created attachment 56993 [details]
> gcc14-pr113210.patch
> 
> So, I'd go with this patch (so far untested).

I think we want to keep the invariant that both are INTEGER_CST when one is.

If we can fold the add to 1 why can't we fold the original to 0?

That is, another fix might be to adjust NITERSM1 to NITERS - 1 when
NITERS went constant ...  (btw, I want to get rid of _NITERS and only
keep _NITERSM1 given _NITERS cannot be represented when the number of
latch iterations is TYPE_MAX_VALUE)

[Bug sanitizer/99476] 'PATH_MAX' was not declared in this scope

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

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

Ilya Leoshkevich  changed:

   What|Removed |Added

 CC||iii at linux dot ibm.com

--- Comment #3 from Ilya Leoshkevich  ---
I had a similar issue when compiling GCC targeting i686-linux on x86_64 debian,
and --includedir= helped, thanks! I had to do the following:

../configure --target=i686-linux-gnu --disable-bootstrap --prefix=/usr
--includedir=/usr/i686-linux-gnu/include

[Bug tree-optimization/108477] fwprop over-optimizes conversion from + to |

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Uroš Bizjak  ---
This conversion happens due to th following code in match.pd:

/* If we are XORing or adding two BIT_AND_EXPR's, both of which are and'ing
   with a constant, and the two constants have no bits in common,
   we should treat this as a BIT_IOR_EXPR since this may produce more
   simplifications.  */
(for op (bit_xor plus)
 (simplify
  (op (convert1? (bit_and@4 @0 INTEGER_CST@1))
  (convert2? (bit_and@5 @2 INTEGER_CST@3)))
  (if (tree_nop_conversion_p (type, TREE_TYPE (@0))
   && tree_nop_conversion_p (type, TREE_TYPE (@2))
   && (wi::to_wide (@1) & wi::to_wide (@3)) == 0)
   (bit_ior (convert @4) (convert @5)

[Bug tree-optimization/113210] [14 Regression] ICE: tree check: expected integer_cst, have cond_expr in get_len, at tree.h:6481

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

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

--- Comment #10 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #9)
> I think we want to keep the invariant that both are INTEGER_CST when one is.
> 
> If we can fold the add to 1 why can't we fold the original to 0?

Because fold generally isn't recursive, so either whatever created the
expression (niters analysis) would need to try to fold all subexpressions which
it clearly doesn't try to do so, or we rely on luck that something changed and
we fold something because of that, which is exactly what triggers it during the
+ 1 folding.

[Bug tree-optimization/113210] [14 Regression] ICE: tree check: expected integer_cst, have cond_expr in get_len, at tree.h:6481

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

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

--- Comment #11 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #9)
> That is, another fix might be to adjust NITERSM1 to NITERS - 1 when
> NITERS went constant ...  (btw, I want to get rid of _NITERS and only

Or we could only use fold_build2 for the PLUS_EXPR 1 computation if NITERSM1 is
INTEGER_CST, otherwise use build2...

[Bug libstdc++/112997] _Unwind_Exception conflicts with void*. failed to build with clang

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

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #11 from Thomas Schwinge  ---
ACK; I had the same change in my WIP tree:

In my GCN and nvptx target libstdc++ work (WIP), I see:

[...]/source-gcc/libstdc++-v3/libsupc++/eh_call.cc:39:1: error:
conflicting C language linkage declaration ‘void __cxa_call_terminate(void*)’
[-Werror]
   39 | __cxa_call_terminate(void* ue_header_in) throw ()
  | ^~~~
In file included from
[...]/source-gcc/libstdc++-v3/libsupc++/eh_call.cc:28:
[...]/source-gcc/libstdc++-v3/libsupc++/unwind-cxx.h:170:17: note:
previous declaration ‘void
__cxxabiv1::__cxa_call_terminate(_Unwind_Exception*)’
  170 | extern "C" void __cxa_call_terminate (_Unwind_Exception*) throw
()
  | ^~~~
cc1plus: all warnings being treated as errors
make[4]: *** [eh_call.lo] Error 1

[Bug libstdc++/113258] Pre-C++17 code that supplies operator new/delete crashes when mixed with post-C+17 code that uses the align_val_t variants of new/delete

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

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

--- Comment #18 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #17)
> (In reply to Nicholas Miell from comment #14)
> > Again, you could probably fix this issue by implementing all of the newly
> > introduced versions of operator new and delete solely using the versions of
> > operator new and delete that were present when libstdc++.so.6 was first
> > introduced.
> 
> We could do that, or we could just implement the aligned new in terms of
> malloc and over-allocate and manually align in the buffer (which is what we
> have to do for some targets without aligned_alloc or anything similar). But
> that sucks, and wastes memory and cycles.

To be clear, just like implementing it purely in terms of malloc, implementing
aligned-new in terms of the C++98 new/delete would also require over-allocating
and then aligning within the buffer, which wastes up to A-1 bytes in every
allocation (where A is the requested alignment).

If libc provides one of aligned_alloc, posix_memalign, memalign etc. then it's
much better to use that. And if we do that, then providing multiple different
libstdc++ runtimes for each version of the C++ standard would not help in the
slightest, because there's still only one std::free, because that doesn't come
from libstdc++ anyway.

And multiple libstdc++ runtimes would cause problems when trying to combine a
C++14 library into a C++17 application, because there would be more than one
std::cout and other globals. Unlike the Windows model, the ELF linkage model
doesn't support that well. It's not clear to me that it would solve any
problems, certainly not the one being reported here, but it would cause new
ones.

[Bug tree-optimization/113210] [14 Regression] ICE: tree check: expected integer_cst, have cond_expr in get_len, at tree.h:6481

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

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

--- Comment #12 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #11)
> (In reply to Richard Biener from comment #9)
> > That is, another fix might be to adjust NITERSM1 to NITERS - 1 when
> > NITERS went constant ...  (btw, I want to get rid of _NITERS and only
> 
> Or we could only use fold_build2 for the PLUS_EXPR 1 computation if NITERSM1
> is INTEGER_CST, otherwise use build2...

I think we should see where the original expression is built but not folded.

[Bug tree-optimization/113210] [14 Regression] ICE: tree check: expected integer_cst, have cond_expr in get_len, at tree.h:6481

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

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

--- Comment #13 from Richard Biener  ---
(In reply to Richard Biener from comment #12)
> (In reply to Jakub Jelinek from comment #11)
> > (In reply to Richard Biener from comment #9)
> > > That is, another fix might be to adjust NITERSM1 to NITERS - 1 when
> > > NITERS went constant ...  (btw, I want to get rid of _NITERS and only
> > 
> > Or we could only use fold_build2 for the PLUS_EXPR 1 computation if NITERSM1
> > is INTEGER_CST, otherwise use build2...
> 
> I think we should see where the original expression is built but not folded.

Hmm, probably in estimate_numbers_of_iterations,

  if (TREE_CODE (niter_desc.may_be_zero) != INTEGER_CST)
niter = build3 (COND_EXPR, type, niter_desc.may_be_zero,
build_int_cst (type, 0),
niter);

I vaguely remember code trying to pattern match the COND_EXPR created
by this (though it should instead use number_of_iterations_exit).  It
should be safe to replace the above with fold_build3.

[Bug tree-optimization/113210] [14 Regression] ICE: tree check: expected integer_cst, have cond_expr in get_len, at tree.h:6481

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

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

--- Comment #14 from Richard Biener  ---
(In reply to Richard Biener from comment #13)
> (In reply to Richard Biener from comment #12)
> > (In reply to Jakub Jelinek from comment #11)
> > > (In reply to Richard Biener from comment #9)
> > > > That is, another fix might be to adjust NITERSM1 to NITERS - 1 when
> > > > NITERS went constant ...  (btw, I want to get rid of _NITERS and only
> > > 
> > > Or we could only use fold_build2 for the PLUS_EXPR 1 computation if 
> > > NITERSM1
> > > is INTEGER_CST, otherwise use build2...
> > 
> > I think we should see where the original expression is built but not folded.
> 
> Hmm, probably in estimate_numbers_of_iterations,
> 
>   if (TREE_CODE (niter_desc.may_be_zero) != INTEGER_CST)
> niter = build3 (COND_EXPR, type, niter_desc.may_be_zero,
> build_int_cst (type, 0),
> niter);
> 
> I vaguely remember code trying to pattern match the COND_EXPR created
> by this (though it should instead use number_of_iterations_exit).  It
> should be safe to replace the above with fold_build3.

No, it's not that.  The COND_EXPR is folded, but we see

(short unsigned int) (a.0_1 + 255) + 1 > 256 ? ~(short unsigned int) (a.0_1 +
255) : 0

and that isn't catched.

#0  0x014d3464 in fold_build3_loc (loc=0, code=COND_EXPR, 
type=, 
op0=, op1=, 
op2=)
at /space/rguenther/src/gcc/gcc/fold-const.cc:14174
#1  0x014d0513 in fold_ternary_loc (loc=0, code=COND_EXPR, 
type=, 
op0=, op1=, 
op2=)
at /space/rguenther/src/gcc/gcc/fold-const.cc:13238
#2  0x014d3436 in fold_build3_loc (loc=0, code=COND_EXPR, 
type=, 
op0=, op1=, 
op2=)
at /space/rguenther/src/gcc/gcc/fold-const.cc:14172
#3  0x01d4de50 in vect_get_loop_niters (loop=0x771e3600, 
main_exit=0x77203990, assumptions=0x7fffd200, 
number_of_iterations=0x7fffd1f0, number_of_iterationsm1=0x7fffd1f8)
at /space/rguenther/src/gcc/gcc/tree-vect-loop.cc:919

So I suggest to either try fixing that or, when adding one folds to a constant
make sure M1 is constant as well.

[Bug c/113267] New: pragma novector ICEs when no loop condition

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

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

Bug ID: 113267
   Summary: pragma novector ICEs when no loop condition
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---

The following:

void f (char *a, int i)
{
#pragma GCC novector
  for (;;i++)
a[i] *= 2;
}

segfaults:

pragma.c: In function 'f':
pragma.c:4:3: internal compiler error: Segmentation fault
4 |   for (;;i++)
  |   ^~~
0x17d238f crash_signal
/data/tamchr01/gnu-work-b1/src/gcc/gcc/toplev.cc:316
0x7fb59e26451f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xd9b626 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/data/tamchr01/gnu-work-b1/src/gcc/gcc/tree.h:3757
0xe4600a c_parser_for_statement
/data/tamchr01/gnu-work-b1/src/gcc/gcc/c/c-parser.cc:8446
0xe59e57 c_parser_pragma
/data/tamchr01/gnu-work-b1/src/gcc/gcc/c/c-parser.cc:14676
0xe42daa c_parser_compound_statement_nostart
/data/tamchr01/gnu-work-b1/src/gcc/gcc/c/c-parser.cc:7201
0xe40b00 c_parser_compound_statement
/data/tamchr01/gnu-work-b1/src/gcc/gcc/c/c-parser.cc:6527
0xe37915 c_parser_declaration_or_fndef

because there's no loop condition to attach the pragma too.

[Bug c/113267] pragma novector ICEs when no loop condition

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

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

Tamar Christina  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2024-01-08
   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Tamar Christina  ---
mine.

[Bug tree-optimization/113268] New: (i + (i + 1) * CST) AND (i + i * CST + 1 * CST) not folded the same way

[denis.campredon at gmail dot com via Gcc-bugs]

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

Bug ID: 113268
   Summary: (i + (i + 1) * CST) AND (i + i * CST + 1 * CST) not
folded the same way
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.campredon at gmail dot com
  Target Milestone: ---

The two following functions should produce the same assembly with optimizations
enabled.

This lead, for exemple, to missed optimization with -Oz

---
#define CST 36

int foo(int i)
{
return i + (i + 1) * CST;
}

int bar(int i)
{
return i + i * CST + 1 * CST;
}
---

foo:
lea eax, [rdi+1]
imuleax, eax, 36
add eax, edi
ret
bar:
imuleax, edi, 37
add eax, 36
ret

[Bug target/113257] -march=native or -mcpu=native are ineffective, but -march=native -mcpu=native works on arm64 M2 Ultra

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

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

--- Comment #2 from Richard Earnshaw  ---
For -mcpu=native, the manual says:

Additionally on native AArch64 GNU/Linux systems the value
@samp{native} tunes performance to the host system.  This option has no effect
if the compiler is unable to recognize the processor of the host system.

With similar working for -march=native

Since nobody has contributed patches to recognize the Apple Silicon cores, I
suspect that is the source of the problem.

[Bug c/113267] pragma novector ICEs when no loop condition

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

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

Tamar Christina  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug libstdc++/59508] std::find could use specialized container's find

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

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Oleg Endo from comment #6)
> Right.  If, then std::find should not invoke std::set::find (or
> std::map::find etc) but the library's internal function to search the rb
> tree.

If that internal function exists, then it means the specialization is using the
primary template, and in that case we could just use std::set::find anyway.

> Of course users might still provide specializations of std::find for
> particular iterator types but that shouldn't be a problem I think.

That's not allowed since C++20.

FWIW we already optimize std::distance this way for std::list iterators, where
it's possible to obtain the container from the iterator. But I don't think
we're likely to do this for other containers and std::find. I'm inclined to
close this as WONTFIX.

Anyway, if we did do this for std::find we should do it for ranges::find, at
least when a container is passed directly to ranges::find (rather than a pair
of iterators).

[Bug tree-optimization/108477] fwprop over-optimizes conversion from + to |

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Uroš Bizjak  ---
If we consider the following testcase:

--cut here--
unsigned int foo (unsigned int a, unsigned int b)
{
  unsigned int r = a & 0x1;
  unsigned int p = b & ~0x3;

  return r + p + 2;
}

unsigned int bar (unsigned int a, unsigned int b)
{
  unsigned int r = a & 0x1;
  unsigned int p = b & ~0x3;

  return r | p | 2;
}
--cut here--

the above testcase compiles (x86_64 -O2) to:

foo:
andl$1, %edi
andl$-4, %esi
orl %esi, %edi
leal2(%rdi), %eax
ret

bar:
andl$1, %edi
andl$-4, %esi
orl %esi, %edi
movl%edi, %eax
orl $2, %eax
ret

So, there is no further simplification in any case, we can't combine OR with a
PLUS in the first case, and we don't have OR instruction with multiple inputs
in the second case.

If we switch around the logic in the conversion and convert from IOR/XOR to
PLUS, as is the case in the following patch:

--cut here--
diff --git a/gcc/match.pd b/gcc/match.pd
index 7b4b15acc41..deac18a7635 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -1830,18 +1830,18 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
&& element_precision (type) <= element_precision (TREE_TYPE (@1)))
(bit_not (rop (convert @0) (convert @1))

-/* If we are XORing or adding two BIT_AND_EXPR's, both of which are and'ing
+/* If we are ORing or XORing two BIT_AND_EXPR's, both of which are and'ing
with a constant, and the two constants have no bits in common,
-   we should treat this as a BIT_IOR_EXPR since this may produce more
+   we should treat this as a PLUS_EXPR since this may produce more
simplifications.  */
-(for op (bit_xor plus)
+(for op (bit_ior bit_xor)
  (simplify
   (op (convert1? (bit_and@4 @0 INTEGER_CST@1))
   (convert2? (bit_and@5 @2 INTEGER_CST@3)))
   (if (tree_nop_conversion_p (type, TREE_TYPE (@0))
&& tree_nop_conversion_p (type, TREE_TYPE (@2))
&& (wi::to_wide (@1) & wi::to_wide (@3)) == 0)
-   (bit_ior (convert @4) (convert @5)
+   (plus (convert @4) (convert @5)

 /* (X | Y) ^ X -> Y & ~ X*/
 (simplify
--cut here--

then the resulting assembly reads:

foo:
andl$-4, %esi
andl$1, %edi
leal2(%rsi,%rdi), %eax
ret

bar:
andl$1, %edi
andl$-4, %esi
leal(%rdi,%rsi), %eax
orl $2, %eax
ret

On x86, the conversion can now use LEA instruction, which is much more usable
than OR instruction. In the first case, LEA implements three input PLUS
instruction, while in the second case, even though the instruction can't be
combined with a follow-up OR, the non-destructive LEA avoids a move.

[Bug target/113257] -march=native or -mcpu=native are ineffective, but -march=native -mcpu=native works on arm64 M2 Ultra

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

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

--- Comment #3 from Sam James  ---
(In reply to Richard Earnshaw from comment #2)
I'm missing why the combination then works though?

[Bug rust/113056] [14 regression] Build failure in libgrust

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

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by Thomas Schwinge :

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

commit r14-6998-gcde6f1085b7027f6a42fdb71c786d422606a8765
Author: Thomas Schwinge 
Date:   Mon Dec 18 16:27:39 2023 +0100

libgrust: 'AM_ENABLE_MULTILIB' only for target builds [PR113056]

..., but not for host builds, which don't need it, and it may cause the
build
to fail.

Use what appears to be the standard pattern for that (see
'libbacktrace/configure.ac', 'zlib/configure.ac').

PR rust/113056
libgrust/
* configure.ac: 'AM_ENABLE_MULTILIB' only for target builds.
* configure: Regenerate.

[Bug libstdc++/113260] missing from_chars/to_chars for __float128

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #8 from Jonathan Wakely  ---
Since GCC 13 you can use _Float128 in older -std modes, and prior to GCC 13
there's no chance we're going to add this anyway.

The only thing missing here is that the _Float128 overloads are not declared
before C++23. They do exist in the library though, so if we declared them they
would be usable:

#include 

#if __cplusplus <= 202002L
namespace std
{
  from_chars_result
  from_chars(const char* __first, const char* __last, _Float128& __value,
 chars_format __fmt = chars_format::general) noexcept;

  to_chars_result
  to_chars(char* __first, char* __last, _Float128 __value) noexcept;
}
#endif

int main()
{
  char str[] = "0.5";
  _Float128 d = 2.0;
  std::to_chars(str, str+3, d);
  std::from_chars(str, str+3, d);
}

We could also add inline overloads for __float128 that forward to the _Float128
functions. The difficulty would be detecting when that's safe to do. We only
define the _Float128 overloads when that type is supported, and every time we
touch the macros around this something breaks.

Confirming as an enhancement, but I don't intent to work on this myself.

[Bug libstdc++/113260] Add overloads of from_chars/to_chars for __float128

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

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

--- Comment #9 from Jonathan Wakely  ---
I've changed the summary, because they're not "missing", since they're not
required/supposed to exist anyway.

[Bug rust/113056] [14 regression] Build failure in libgrust

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

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #14 from Thomas Schwinge  ---
Should be fixed.  If not, please re-open providing more data.

[Bug target/113269] New: X86_64 generates extra mov (and xchg) when passing struct with constant value to function

[denis.campredon at gmail dot com via Gcc-bugs]

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

Bug ID: 113269
   Summary: X86_64 generates extra mov (and xchg) when passing
struct with constant value to function
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.campredon at gmail dot com
  Target Milestone: ---

On today's trunk, compiled with g++

---
typedef struct s{
char *key, *value;
}s;

s *search(s);

s *find(char *word)
{
return search((s){.key = word});
}

s *find2(char *word)
{
s a = {.key = word, .value = 0};
return search(a);
}


compiled with -O2 produces a useless mov instruction in each function :
--
find(char*):
xor edx, edx
mov rsi, rdx
jmp search(s)
find2(char*):
xor edx, edx
mov rsi, rdx
jmp search(s)
--

compiled with -Oz, a useless mov and two useless xchg instructions are
produced.
---
find(char*):
xchgrdi, rax
xor edx, edx
xchgrax, rdi
mov rsi, rdx
jmp search(s)
find2(char*):
xchgrdi, rax
xor edx, edx
xchgrax, rdi
mov rsi, rdx
jmp search(s)


If the code is compiled with gcc, the mov instruction is not generated for
find2.

[Bug target/112952] avr: attribute address not working with -fdata-sections -fno-common

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Georg-Johann Lay :

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

commit r14-6999-gc131b1d5da412b9b0f0681fc5704cdc9b7cafb04
Author: Georg-Johann Lay 
Date:   Mon Jan 8 12:20:45 2024 +0100

AVR: PR target/112952: Fix attribute "address", "io" and "io_low"

so they work with all combinations of -f[no-]data-sections -f[no-]common.
The patch also improves some diagnostics and adds additional checks, for
example these attributes must only be applied to variables in static
storage.

gcc/
PR target/112952
* config/avr/avr.cc (avr_handle_addr_attribute): Also print valid
range when diagnosing attribute "io" and "io_low" are out of range.
(avr_eval_addr_attrib): Don't ICE on empty address at that place.
(avr_insert_attributes): Reject if attribute "address", "io" or
"io_low"
in contexts other than static storage.
(avr_asm_output_aligned_decl_common): Move output of decls with
attribute "address", "io", and "io_low" to...
(avr_output_addr_attrib): ...this new function.
(avr_asm_asm_output_aligned_bss): Remove output for decls with
attribute "address", "io", and "io_low".
(avr_encode_section_info): Rectify handling of decls with attribute
"address", "io", and "io_low".

gcc/testsuite/
PR target/112952
* gcc.target/avr/attribute-io.h: New file.
* gcc.target/avr/pr112952-0.c: New test.
* gcc.target/avr/pr112952-1.c: New test.
* gcc.target/avr/pr112952-2.c: New test.
* gcc.target/avr/pr112952-3.c: New test.

[Bug target/113257] -march=native or -mcpu=native are ineffective, but -march=native -mcpu=native works on arm64 M2 Ultra

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

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

--- Comment #4 from Richard Earnshaw  ---
I'm not sure.  My understanding was that -march=native started by looking up
the CPU ID first and then using the internal mapping of that CPU to the
architecture (which can't work if we don't recognize the CPU), but perhaps we
try a bit harder when both are specified.

[Bug target/113270] New: [14 Regression] AArch64 ICEs in register_tuple_type

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

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

Bug ID: 113270
   Summary: [14 Regression] AArch64 ICEs in register_tuple_type
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Several packages in Fedora ICE with PCH.
A simple reproducer is e.g.
cat ppp.h
extern int i;
cat ppp.C
#include 
./cc1plus.r14-6751 -quiet -v -iprefix
/usr/src/gcc/objaa/gcc/../lib/gcc/aarch64-linux/14.0.0/ -isystem ./include
-isystem ./include-fixed -D_GNU_SOURCE ppp.h -quiet -dumpbase ppp.h.h
-dumpbase-ext .h -mlittle-endian -mabi=lp64 -Winvalid-pch -version -o
/tmp/ccGpU4JW.s --output-pch ppp.h.gch
./cc1plus.r14-6751 -quiet -v -iprefix
/usr/src/gcc/objaa/gcc/../lib/gcc/aarch64-linux/14.0.0/ -isystem ./include
-isystem ./include-fixed -D_GNU_SOURCE -isystem include/ -include ppp.h
-isystem /usr/include ppp.C -quiet -dumpdir a- -dumpbase ppp.C -dumpbase-ext .C
-mlittle-endian -mabi=lp64 -Winvalid-pch -version -o /tmp/ccwJQz4y.s
GNU C++17 (GCC) version 14.0.0 20231220 (experimental) (aarch64-linux-gnu)
compiled by GNU C version 12.1.1 20220507 (Red Hat 12.1.1-1), GMP
version 6.2.1, MPFR version 4.1.0-p13, MPC version 1.2.1, isl version
isl-0.16.1-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring duplicate directory "include/"
ignoring nonexistent directory
"/usr/src/gcc/objaa/gcc/../lib/gcc/aarch64-linux/14.0.0/../../../../aarch64-linux-gnu/include/c++/14.0.0"
ignoring nonexistent directory
"/usr/src/gcc/objaa/gcc/../lib/gcc/aarch64-linux/14.0.0/../../../../aarch64-linux-gnu/include/c++/14.0.0/aarch64-linux-gnu"
ignoring nonexistent directory
"/usr/src/gcc/objaa/gcc/../lib/gcc/aarch64-linux/14.0.0/../../../../aarch64-linux-gnu/include/c++/14.0.0/backward"
ignoring nonexistent directory
"/usr/src/gcc/objaa/gcc/../lib/gcc/aarch64-linux/14.0.0/include"
ignoring nonexistent directory
"/usr/src/gcc/objaa/gcc/../lib/gcc/aarch64-linux/14.0.0/include-fixed"
ignoring nonexistent directory
"/usr/src/gcc/objaa/gcc/../lib/gcc/aarch64-linux/14.0.0/../../../../aarch64-linux-gnu/sys-include"
ignoring nonexistent directory
"/usr/src/gcc/objaa/gcc/../lib/gcc/aarch64-linux/14.0.0/../../../../aarch64-linux-gnu/include"
ignoring nonexistent directory
"/usr/local/lib/../aarch64-linux-gnu/include/c++/14.0.0"
ignoring nonexistent directory
"/usr/local/lib/../aarch64-linux-gnu/include/c++/14.0.0/aarch64-linux-gnu"
ignoring nonexistent directory
"/usr/local/lib/../aarch64-linux-gnu/include/c++/14.0.0/backward"
ignoring nonexistent directory
"/usr/local/lib/gcc/aarch64-linux-gnu/14.0.0/include"
ignoring nonexistent directory
"/usr/local/lib/gcc/aarch64-linux-gnu/14.0.0/include-fixed"
ignoring nonexistent directory
"/usr/local/lib/../aarch64-linux-gnu/sys-include"
ignoring nonexistent directory "/usr/local/lib/../aarch64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 ./include
 ./include-fixed
 /usr/include
End of search list.
Compiler executable checksum: 99072b28e2767f6b7a4ea027ec31d235
In file included from ppp.C:1:
./include/arm_neon.h:33:21: internal compiler error: Segmentation fault
   33 | #pragma GCC aarch64 "arm_neon.h"
  | ^~~~
0x1b247a2 crash_signal
../../gcc/toplev.cc:316
0x1efe6bd tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
../../gcc/tree.cc:9004
0xddec4b tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../../gcc/tree.h:3767
0x1ef7e72 build_array_type_1(tree_node*, tree_node*, bool, bool, bool)
../../gcc/tree.cc:7344
0x1ef815d build_array_type(tree_node*, tree_node*, bool)
../../gcc/tree.cc:7378
0x1ef821d build_array_type_nelts(tree_node*, poly_int<2u, unsigned long>)
../../gcc/tree.cc:7395
0x21753d3 register_tuple_type
../../gcc/config/aarch64/aarch64-builtins.cc:1482
0x21759a8 handle_arm_neon_h()
../../gcc/config/aarch64/aarch64-builtins.cc:1555
0x1352ab5 aarch64_pragma_aarch64
../../gcc/config/aarch64/aarch64-c.cc:351
0x13102d5 c_invoke_pragma_handler(unsigned int)
../../gcc/c-family/c-pragma.cc:1741
0x10fb1d7 cp_parser_pragma
../../gcc/cp/parser.cc:50704
0x109cc21 cp_parser_toplevel_declaration
../../gcc/cp/parser.cc:15392
0x1084a34 cp_parser_translation_unit
../../gcc/cp/parser.cc:5273
0x10fb45b c_parse_file()
../../gcc/cp/parser.cc:50798
0x1309a22 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1301
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.

This worked fine in r14-1.
(gdb) p aarch64_simd_types[0]
$1 = {type = Int8x8_t, name = 0x35d32

[Bug target/113270] [14 Regression] AArch64 ICEs in register_tuple_type

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org
   Target Milestone|--- |14.0
   Priority|P3  |P1

[Bug target/112952] avr: attribute address not working with -fdata-sections -fno-common

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

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

--- Comment #3 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Georg-Johann Lay
:

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

commit r13-8197-g5d0d592c486c31bd9c26af0d1f0a7b6a3d68c22b
Author: Georg-Johann Lay 
Date:   Mon Jan 8 12:20:45 2024 +0100

AVR: PR target/112952: Fix attribute "address", "io" and "io_low"

so they work with all combinations of -f[no-]data-sections -f[no-]common.
The patch also improves some diagnostics and adds additional checks, for
example these attributes must only be applied to variables in static
storage.

gcc/
PR target/112952
* config/avr/avr.cc (avr_handle_addr_attribute): Also print valid
range when diagnosing attribute "io" and "io_low" are out of range.
(avr_eval_addr_attrib): Don't ICE on empty address at that place.
(avr_insert_attributes): Reject if attribute "address", "io" or
"io_low"
in contexts other than static storage.
(avr_asm_output_aligned_decl_common): Move output of decls with
attribute "address", "io", and "io_low" to...
(avr_output_addr_attrib): ...this new function.
(avr_asm_asm_output_aligned_bss): Remove output for decls with
attribute "address", "io", and "io_low".
(avr_encode_section_info): Rectify handling of decls with attribute
"address", "io", and "io_low".

gcc/testsuite/
PR target/112952
* gcc.target/avr/attribute-io.h: New file.
* gcc.target/avr/pr112952-0.c: New test.
* gcc.target/avr/pr112952-1.c: New test.
* gcc.target/avr/pr112952-2.c: New test.
* gcc.target/avr/pr112952-3.c: New test.

(cherry picked from commit c131b1d5da412b9b0f0681fc5704cdc9b7cafb04)

[Bug target/113270] [14 Regression] AArch64 ICEs in register_tuple_type since r14-6524

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-08
 Status|UNCONFIRMED |NEW
Summary|[14 Regression] AArch64 |[14 Regression] AArch64
   |ICEs in register_tuple_type |ICEs in register_tuple_type
   ||since r14-6524
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r14-6524-gc535360788e142a92e1d8b1db25bf4452e26f5fb

[Bug tree-optimization/113271] New: [Regression] Wrong code at -O1/2/3 since GCC-9 (could be due to wrong optimization)

[652023330028 at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 113271
   Summary: [Regression] Wrong code at -O1/2/3 since GCC-9 (could
be due to wrong optimization)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 652023330028 at smail dot nju.edu.cn
  Target Milestone: ---

Hello, we note that gcc may introduce erroneous code due to optimization:

https://godbolt.org/z/8vbn3KdqP

#include 
int a, b, c;
void func() {
a=-b;
//std::cout<<-a<
int a, b, c;
void func() {
a=-b;
std::cout<<-a<

[Bug target/112952] avr: attribute address not working with -fdata-sections -fno-common

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

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Priority|P3  |P5
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |13.3

--- Comment #4 from Georg-Johann Lay  ---
Fixed in v13.3+

[Bug tree-optimization/113271] [Regression] Wrong code at -O1/2/3 since GCC-9 (could be due to wrong optimization)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Garbage in, garbage out.
This is UB, as can be seen if you compile with -fsanitize=undefined:
runtime error: negation of -2147483648 cannot be represented in type 'int';
cast to an unsigned type to negate this value to itself

[Bug target/113270] [14 Regression] AArch64 ICEs in register_tuple_type since r14-6524

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I don't really know why, not sure if GTY types simply must not appear in target
headers other than the main one or one needs to mark such headers somehow such
that gengtype is aware of those, but the generated gt-aarch64-builtins.h after
the change loses:
@@ -58,34 +58,6 @@ EXPORTED_CONST struct ggc_root_tab gt_gg
 >_pch_nx_tree_node
   },
   {
-&aarch64_simd_types[0].name,
-1 * ARRAY_SIZE (aarch64_simd_types),
-sizeof (aarch64_simd_types[0]),
-(gt_pointer_walker) >_ggc_m_S,
-(gt_pointer_walker) >_pch_n_S
-  },
-  {
-&aarch64_simd_types[0].mangle,
-1 * ARRAY_SIZE (aarch64_simd_types),
-sizeof (aarch64_simd_types[0]),
-(gt_pointer_walker) >_ggc_m_S,
-(gt_pointer_walker) >_pch_n_S
-  },
-  {
-&aarch64_simd_types[0].itype,
-1 * ARRAY_SIZE (aarch64_simd_types),
-sizeof (aarch64_simd_types[0]),
->_ggc_mx_tree_node,
->_pch_nx_tree_node
-  },
-  {
-&aarch64_simd_types[0].eltype,
-1 * ARRAY_SIZE (aarch64_simd_types),
-sizeof (aarch64_simd_types[0]),
->_ggc_mx_tree_node,
->_pch_nx_tree_node
-  },
-  {
 &aarch64_builtin_decls[0],
 1 * (AARCH64_BUILTIN_MAX),
 sizeof (aarch64_builtin_decls[0]),
@@ -95,8 +67,3 @@ EXPORTED_CONST struct ggc_root_tab gt_gg
   LAST_GGC_ROOT_TAB
 };

-EXPORTED_CONST struct ggc_root_tab gt_pch_rs_gt_aarch64_builtins_h[] = {
-  { &aarch64_simd_types, 1, sizeof (aarch64_simd_types), NULL, NULL },
-  LAST_GGC_ROOT_TAB
-};
-
where the former is I believe what breaks the PCH.

[Bug target/113070] [14 regression] [AArch64] [PGO/LTO] Miscompilation of go compiler

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org

[Bug target/113270] [14 Regression] AArch64 ICEs in register_tuple_type since r14-6524

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

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

--- Comment #3 from Jakub Jelinek  ---
--- gcc/config.gcc.jj   2024-01-03 11:51:24.640826829 +0100
+++ gcc/config.gcc  2024-01-08 13:40:08.583405822 +0100
@@ -350,7 +350,7 @@ aarch64*-*-*)
cxx_target_objs="aarch64-c.o"
d_target_objs="aarch64-d.o"
extra_objs="aarch64-builtins.o aarch-common.o aarch64-sve-builtins.o
aarch64-sve-builtins-shapes.o aarch64-sve-builtins-base.o
aarch64-sve-builtins-sve2.o aarch64-sve-builtins-sme.o
cortex-a57-fma-steering.o aarch64-speculation.o
falkor-tag-collision-avoidance.o aarch-bti-insert.o aarch64-cc-fusion.o
aarch64-early-ra.o aarch64-ldp-fusion.o"
-   target_gtfiles="\$(srcdir)/config/aarch64/aarch64-builtins.cc
\$(srcdir)/config/aarch64/aarch64-sve-builtins.h
\$(srcdir)/config/aarch64/aarch64-sve-builtins.cc"
+   target_gtfiles="\$(srcdir)/config/aarch64/aarch64-builtins.h
\$(srcdir)/config/aarch64/aarch64-builtins.cc
\$(srcdir)/config/aarch64/aarch64-sve-builtins.h
\$(srcdir)/config/aarch64/aarch64-sve-builtins.cc"
target_has_targetm_common=yes
;;
 alpha*-*-*)
doesn't seem to help unfortunately.

[Bug target/113077] [14 Regression] ICE in dwarf2out_frame_debug_cfa_offset with `-O2 -fstack-protector-strong -fstack-clash-protection`

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Priority|P3  |P1

[Bug target/113114] [14 Regression] ICE compiling gcc.c-torture/execute/pr59643.cwith -mabi=ilp32; in try_promote_writeback aarch64-ldp-fusion.cc

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org

[Bug target/113089] [14 Regression][aarch64] ICE in process_uses_of_deleted_def, at rtl-ssa/changes.cc:252 since r14-6605-gc0911c6b357ba9

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org

[Bug target/113221] [14 Regression][aarch64]ICE in extract_insn, at recog.cc:2812 since r14-6605-gc0911c6b357ba9

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
   Priority|P3  |P1

[Bug tree-optimization/113119] ICE: verify_ssa failed: definition in block 18 does not dominate use in block 4 at -O1 with _BitInt

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

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

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

https://gcc.gnu.org/g:7590d975ecfdae4f112b5086c017101c08f07e3e

commit r14-7000-g7590d975ecfdae4f112b5086c017101c08f07e3e
Author: Jakub Jelinek 
Date:   Mon Jan 8 13:57:26 2024 +0100

lower-bitint: Punt .*_OVERFLOW optimization if cast from IMAGPART_EXPR
appears before REALPART_EXPR [PR113119]

_BitInt lowering for .{ADD,SUB,MUL}_OVERFLOW calls which have both
REALPART_EXPR and IMAGPART_EXPR used and have a cast from the IMAGPART_EXPR
to a boolean or normal integral type lowers them at the point of
the REALPART_EXPR statement (which is especially needed if the lhs of
the call is complex with large/huge _BitInt element type); we emit the
stmt to set the lhs of the cast at the same spot as well.
Normally, the lowering of __builtin_{add,sub,mul}_overflow arranges
the REALPART_EXPR to come before IMAGPART_EXPR, followed by cast from that,
but as the testcase shows, a redundant __builtin_*_overflow call and VN
can reorder those and we then ICE because the def-stmt of the former cast
from IMAGPART_EXPR may appear after its uses.
We already check that all of REALPART_EXPR, IMAGPART_EXPR and the cast
from the latter appear in the same bb as the .{ADD,SUB,MUL}_OVERFLOW call
in the optimization, the following patch just extends it to make sure
cast appears after REALPART_EXPR; if not, we punt on the optimization and
expand it as a store of a complex _BitInt on the location of the ifn call.
Only the testcase in the testsuite is changed by the patch, all other
__builtin_*_overflow* calls in the bitint* tests (and there are quite a
few)
have REALPART_EXPR first.

2024-01-08  Jakub Jelinek  

PR tree-optimization/113119
* gimple-lower-bitint.cc (optimizable_arith_overflow): Punt if
both REALPART_EXPR and cast from IMAGPART_EXPR appear, but cast
is before REALPART_EXPR.

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

[Bug tree-optimization/113120] during GIMPLE pass: bitintlower ICE: SIGSEGV with _BitInt() at -O2

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

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

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

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

commit r14-7001-gefef8d7ff43c6c489fd6e7c52d71494d21324c87
Author: Jakub Jelinek 
Date:   Mon Jan 8 13:58:28 2024 +0100

lower-bitint: Fix up lowering of huge _BitInt 0 PHI args [PR113120]

The PHI argument expansion of INTEGER_CSTs where bitint_min_cst_precision
returns significantly smaller precision than the PHI result precision is
optimized by loading the much smaller constant (if any) from memory and
then either setting the remaining limbs to {} or calling memset with -1.
The case where no constant is loaded (i.e. c == NULL) is when the
INTEGER_CST is 0 or all_ones - in that case we can just set all the limbs
to {} or call memset with -1 on everything.
While for the all ones extension case that is what the code was already
doing, I missed one spot in the zero extension case, where constricting
the offset of the MEM_REF lhs of the = {} store it was using
unconditionally
the byte size of c, which obviously doesn't work if c is NULL.  In that
case
we want to use zero offset.

2024-01-08  Jakub Jelinek  

PR tree-optimization/113120
* gimple-lower-bitint.cc (gimple_lower_bitint): Fix handling of
very
large _BitInt zero INTEGER_CST PHI argument.

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

[Bug middle-end/113228] [14 Regression] ICE: recalculate_side_effects, at gimplify.cc:3347 since r14-6420

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

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

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

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

commit r14-7002-g8c0dd8a6ff85d6e7b38957f2da400f5cfa8fef6b
Author: Jakub Jelinek 
Date:   Mon Jan 8 13:59:15 2024 +0100

gimplify: Fix ICE in recalculate_side_effects [PR113228]

The following testcase ICEs during regimplificatgion since the addition of
(convert (eqne zero_one_valued_p@0 INTEGER_CST@1))
simplification.  That simplification is novel in the sense that in
gimplify_expr it can turn an expression (comparison in particular) into
a SSA_NAME.  Normally when gimplify_expr sees originally a SSA_NAME, it
does
case SSA_NAME:
  /* Allow callbacks into the gimplifier during optimization.  */
  ret = GS_ALL_DONE;
  break;
and doesn't try to recalculate side effects because of that, but in this
case gimplify_expr normally enters the:
default:
  switch (TREE_CODE_CLASS (TREE_CODE (*expr_p)))
{
case tcc_comparison:
then does
  *expr_p = gimple_boolify (*expr_p);
and then
  *expr_p = fold_convert_loc (input_location,
  org_type, *expr_p);
with this new match.pd simplification turns that tcc_comparison class
into SSA_NAME.  Unlike the outer SSA_NAME handling though, this falls
through into
  recalculate_side_effects (*expr_p);

dont_recalculate:
  break;
but unfortunately recalculate_side_effects doesn't handle SSA_NAME and ICEs
on it.
SSA_NAMEs don't ever have TREE_SIDE_EFFECTS set on those, so the following
patch fixes it by handling it similarly to the tcc_constant case.

2024-01-08  Jakub Jelinek  

PR tree-optimization/113228
* gimplify.cc (recalculate_side_effects): Do nothing for SSA_NAMEs.

* gcc.c-torture/compile/pr113228.c: New test.

[Bug middle-end/113228] [14 Regression] ICE: recalculate_side_effects, at gimplify.cc:3347 since r14-6420

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #16 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/113120] during GIMPLE pass: bitintlower ICE: SIGSEGV with _BitInt() at -O2

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.

[Bug tree-optimization/113119] ICE: verify_ssa failed: definition in block 18 does not dominate use in block 4 at -O1 with _BitInt

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed.

[Bug target/112952] avr: attribute address not working with -fdata-sections -fno-common

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-12 branch has been updated by Georg-Johann Lay
:

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

commit r12-10085-gebae82f35033be6e022dce65cea0148ddf9df025
Author: Georg-Johann Lay 
Date:   Mon Jan 8 12:20:45 2024 +0100

AVR: PR target/112952: Fix attribute "address", "io" and "io_low"

so they work with all combinations of -f[no-]data-sections -f[no-]common.
The patch also improves some diagnostics and adds additional checks, for
example these attributes must only be applied to variables in static
storage.

gcc/
PR target/112952
* config/avr/avr.cc (avr_handle_addr_attribute): Also print valid
range when diagnosing attribute "io" and "io_low" are out of range.
(avr_eval_addr_attrib): Don't ICE on empty address at that place.
(avr_insert_attributes): Reject if attribute "address", "io" or
"io_low"
in contexts other than static storage.
(avr_asm_output_aligned_decl_common): Move output of decls with
attribute "address", "io", and "io_low" to...
(avr_output_addr_attrib): ...this new function.
(avr_asm_asm_output_aligned_bss): Remove output for decls with
attribute "address", "io", and "io_low".
(avr_encode_section_info): Rectify handling of decls with attribute
"address", "io", and "io_low".

gcc/testsuite/
PR target/112952
* gcc.target/avr/attribute-io.h: New file.
* gcc.target/avr/pr112952-0.c: New test.
* gcc.target/avr/pr112952-1.c: New test.
* gcc.target/avr/pr112952-2.c: New test.
* gcc.target/avr/pr112952-3.c: New test.

(cherry picked from commit c131b1d5da412b9b0f0681fc5704cdc9b7cafb04)

[Bug target/112952] avr: attribute address not working with -fdata-sections -fno-common

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

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

--- Comment #6 from Georg-Johann Lay  ---
Also fixed on the v12 branch for v12.4+

[Bug c++/113272] New: Wrong specialization of class template selected

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 113272
   Summary: Wrong specialization of class template selected
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

This program

#include 

template 
struct A;

template 
  requires std::same_as
struct A : std::false_type {};

template 
  requires std::same_as
struct A : std::true_type {};

int x = 0;
static_assert( A<&x>::value ); ///< try to comment this line
static_assert( !A<(const int *)&x>::value ); ///< GCC fails here

is accepted by Clang and MSVC, but GCC erroneously evaluates the last line.
Online demo: https://godbolt.org/z/5Pqx6TG3W

But if one comments the previous static_assert, then it starts working.

[Bug target/113270] [14 Regression] AArch64 ICEs in register_tuple_type since r14-6524

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

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

--- Comment #4 from Jakub Jelinek  ---
Of course, another bug is that the declaration of aarch64_simd_types isn't GTY
marked:
--- gcc/config/aarch64/aarch64-builtins.h.jj2024-01-03 12:01:17.852557952
+0100
+++ gcc/config/aarch64/aarch64-builtins.h   2024-01-08 14:07:00.475944698
+0100
@@ -94,6 +94,6 @@ struct GTY(()) aarch64_simd_type_info
   enum aarch64_type_qualifiers q;
 };

-extern aarch64_simd_type_info aarch64_simd_types[];
+extern GTY(()) aarch64_simd_type_info aarch64_simd_types[];

 #endif
which means it is then ignored on the definition as well.
But with the above 2 patches it fails to build because it then tries to include
aarch64_simd_types references in gtype-desc.cc but doesn't include there that
header.

[Bug target/113270] [14 Regression] AArch64 ICEs in register_tuple_type since r14-6524

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

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

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

This seems to work by making the type static to the aarch64-builtins.cc TU
and using an exported function to get at the data.

If anyone has ideas how to make gengtype work for this case, it might be
cleaner than this...

[Bug tree-optimization/113026] Bogus -Wstringop-overflow warning on simple memcpy type loop

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

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

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

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

commit r14-7003-gb3cc5a1efead520bc977b4ba51f1328d01b3e516
Author: Richard Biener 
Date:   Fri Dec 15 10:32:29 2023 +0100

tree-optimization/113026 - avoid vector epilog in more cases

The following avoids creating a niter peeling epilog more consistently,
matching what peeling later uses for the skip_vector condition, in
particular when versioning is required which then also ensures the
vector loop is entered unless the epilog is vectorized.  This should
ideally match LOOP_VINFO_VERSIONING_THRESHOLD which is only computed
later, some refactoring could make that better matching.

The patch also makes sure to adjust the upper bound of the epilogues
when we do not have a skip edge around the vector loop.

PR tree-optimization/113026
* tree-vect-loop.cc (vect_need_peeling_or_partial_vectors_p):
Avoid an epilog in more cases.
* tree-vect-loop-manip.cc (vect_do_peeling): Adjust the
epilogues niter upper bounds and estimates.

* gcc.dg/torture/pr113026-1.c: New testcase.
* gcc.dg/torture/pr113026-2.c: Likewise.

[Bug tree-optimization/113026] Bogus -Wstringop-overflow warning on simple memcpy type loop

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

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

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

Bug 113026 Summary: Bogus -Wstringop-overflow warning on simple memcpy type loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113026

   What|Removed |Added

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

[Bug target/113273] New: [14 Regression][x86][asan] ICE Segmentation fault since r14-6946-ge66dc37b299cac

[mjires at suse dot cz via Gcc-bugs]

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

Bug ID: 113273
   Summary: [14 Regression][x86][asan] ICE Segmentation fault
since r14-6946-ge66dc37b299cac
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mjires at suse dot cz
CC: iii at linux dot ibm.com
  Target Milestone: ---
Target: x86

Compiling (not only) empty file results in ICE since r14-6946-ge66dc37b299cac.

$ g++ empty.cc -mfunction-return=thunk -fsanitize=address
empty.cc:1: internal compiler error: Segmentation fault
0x1af49f8 crash_signal
/home/mjires/git/GCC/master/gcc/toplev.cc:316
0x1b0fa03 asan_function_start()
/home/mjires/git/GCC/master/gcc/asan.cc:1484
0x1f4da41 assemble_function_label_raw(_IO_FILE*, char const*)
/home/mjires/git/GCC/master/gcc/varasm.cc:1849
0x1f9278a ix86_asm_output_function_label(_IO_FILE*, char const*, tree_node*)
/home/mjires/git/GCC/master/gcc/config/i386/i386.cc:1643
0x1f9f8c3 output_indirect_thunk_function
/home/mjires/git/GCC/master/gcc/config/i386/i386.cc:6208
0x1f9fa23 ix86_code_end
/home/mjires/git/GCC/master/gcc/config/i386/i386.cc:6263
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --disable-bootstrap
--enable-languages=c,c++,fortran,lto --disable-multilib --disable-libsanitizer
--enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20240108 (experimental) (GCC)

[Bug target/113115] [14 Regression] ICE In extract_constrain_insn_cached recog.cc with ppc64le-linux-gnu crosscompiler from r14-3592-g9ea1248604d7b6

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-08
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed by bisection.

[Bug target/113273] [14 Regression][x86][asan] ICE Segmentation fault since r14-6946-ge66dc37b299cac

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

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

--- Comment #1 from Ilya Leoshkevich  ---
Hi, sorry about the regression.  Could you please check if
https://inbox.sourceware.org/gcc-patches/20240108092434.554918-1-...@linux.ibm.com/
fixes that for you?

[Bug tree-optimization/113126] [14 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:325 at -O1

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Mine.

[Bug target/113140] [13/14 regression] segmentation fault during delay slot scheduling

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|14.0|13.3
Summary|[13 regression] |[13/14 regression]
   |segmentation fault during   |segmentation fault during
   |delay slot scheduling   |delay slot scheduling

[Bug sanitizer/113151] Need for a TBAA / strict aliasing sanitizer (TySan)

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
IIRC Jakub tried to implement something at some point.

Note what's needed is runtime tracking of the effective dynamic type of
objects (memory) and enforcing access rules.  Language frontend rules
are not 1:1 compatible and the middle-end implements something common.

It's going to be difficult when not the whole program including runtime
is instrumented.

[Bug target/113273] [14 Regression][x86][asan] ICE Segmentation fault since r14-6946-ge66dc37b299cac

[mjires at suse dot cz via Gcc-bugs]

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

--- Comment #2 from Michal Jireš  ---
(In reply to Ilya Leoshkevich from comment #1)
> Hi, sorry about the regression.  Could you please check if
> https://inbox.sourceware.org/gcc-patches/20240108092434.554918-1-iii@linux.
> ibm.com/ fixes that for you?

Thanks, yes, that fixes all my regressed tests.

[Bug target/113273] [14 Regression][x86][asan] ICE Segmentation fault since r14-6946-ge66dc37b299cac

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

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

--- Comment #3 from Ilya Leoshkevich  ---
Thank you for the confirmation.  I will push the fix as soon as my regtests
finish.

[Bug target/113156] [14 Regression] AVR build broken due to ICE while compiling libgcc, started with r14-6201-gf0a90c7d7333fc

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 CC||aoliva at gcc dot gnu.org
   Keywords||build
Summary|AVR build broken due to ICE |[14 Regression] AVR build
   |while compiling libgcc, |broken due to ICE while
   |started with|compiling libgcc, started
   |r14-6201-gf0a90c7d7333fc|with
   ||r14-6201-gf0a90c7d7333fc
   Priority|P3  |P1

[Bug middle-end/113164] [missed optimization] struct fields should not alias

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-08
 Ever confirmed|0   |1
 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Richard Biener  ---
This would rely on TBAA btw, with -fno-strict-aliasing we allow *a and *b
to overlap, aka

 a = &b->b;

confirmed.  I think we have all the bits in aliasing_component_refs_p and
friends, it just would need to be factored/wired up for addresses.

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug sanitizer/113151] Need for a TBAA / strict aliasing sanitizer (TySan)

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

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

--- Comment #3 from Jakub Jelinek  ---
I was just contemplating its implementation (and/or hoping somebody else would
handle it), never actually implemented anything.

[Bug other/113190] Alert not to report bugs against EOL releases

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

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

--- Comment #3 from Richard Biener  ---
The issue is we allow "unknown" as Version (we have a web component and share a
bugzilla instance with classpath), so disabling versions for new bug reporting
which is a thing doesn't really help.

[Bug ada/113195] [13/14 regression] internal error on anonymous access type equality

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |13.3

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
(In reply to John David Anglin from comment #5)
> The problem is TREE_SYMBOL_REFERENCED is not set for libfuncs.  This fixes
> problem on hppa64-hpux:
> 
> bash-5.1$ git diff gcc/varasm.cc
> diff --git a/gcc/varasm.cc b/gcc/varasm.cc
> index 69f8f8ee018..0a1cc022023 100644
> --- a/gcc/varasm.cc
> +++ b/gcc/varasm.cc
> @@ -2527,9 +2527,7 @@ process_pending_assemble_externals (void)
>for (rtx list = pending_libcall_symbols; list; list = XEXP (list, 1))
>  {
>rtx symbol = XEXP (list, 0);
> -  tree id = get_identifier (XSTR (symbol, 0));
> -  if (TREE_SYMBOL_REFERENCED (id))
> -   targetm.asm_out.external_libcall (symbol);
> +  targetm.asm_out.external_libcall (symbol);
>  }
> 
>pending_assemble_externals = 0;
> 
> If you don't care about libfuncs, you could move the TREE_SYMBOL_REFERENCED
> check into the bpf target.

Then the bug is that it isn't set when they are actually referenced.
The whole point of the patch was avoid referencing something that isn't really
referenced.  And it wasn't specific to one backend, many backends simply used
to emit say externs for both signed and unsigned division when expansion saw
range of operands would allow both signed and unsigned division and so expanded
both to pick the cheaper one.

[Bug ipa/113197] [14 Regression] ICE in in handle_call_arg, at tree-ssa-structalias.cc:4119

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto, needs-bisection
  Component|lto |ipa
   Target Milestone|--- |14.0
Summary|[14 Regressiion] ICE in in  |[14 Regression] ICE in in
   |handle_call_arg, at |handle_call_arg, at
   |tree-ssa-structalias.cc:411 |tree-ssa-structalias.cc:411
   |9   |9
 CC||hubicka at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #4 from Richard Biener  ---
Looks like an issue with IPA modref and WPA?

[Bug lto/113204] lto1: error: qsort comparator non-negative on sorted output: 64

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

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

--- Comment #4 from Richard Biener  ---
it's really odd, I don't see how it could fail.  The only suspicious bit is

  int file_order1 = n1->lto_file_data ? n1->lto_file_data->order : -1;
  int file_order2 = n2->lto_file_data ? n2->lto_file_data->order : -1;

  /* Order files same way as they appeared in the command line to reduce
 seeking while copying sections.  */
  if (file_order1 != file_order2)
return file_order1 - file_order2;

the non-presence of n{1,2}->lto_file_data represented as -1 makes whether
non-presence is first dependent on the value of the order of the other.

Maybe explicitly spelling that out would be better.

  if (file_order1 != file_order2)
{
  if (file_order1 == -1)
return -1;
  if (file_order2 == -1)
return 1;
  return file_order1 - file_order2;
}

or so.

[Bug middle-end/113205] [14 Regression] internal compiler error: in backward_pass, at tree-vect-slp.cc:5346

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection,
   ||needs-reduction
   Target Milestone|--- |14.0

[Bug c/113215] gimple FE can't handle static local variable with initializer

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-01-08
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug testsuite/113226] [14 Regression] testsuite/std/ranges/iota/max_size_type.cc fails for cris-elf after r14-6888-ga138b99646a555

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug target/113229] [14 Regression] gcc.dg/torture/pr70083.c ICEs when compiled with -march=armv9-a+sve2

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug target/113077] [14 Regression] ICE in dwarf2out_frame_debug_cfa_offset with `-O2 -fstack-protector-strong -fstack-clash-protection`

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

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

--- Comment #4 from Alex Coplan  ---
So pro_and_epilogue has:

```
(insn/f 55 54 56 2 (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 16 [0x10])) [2  S8 A8])
(reg:DI 19 x19)) "t.c":2:28 -1
 (expr_list:REG_CFA_OFFSET (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 16 [0x10])) [2  S8 A8])
(reg:DI 19 x19))
(nil)))
(insn/f 56 55 57 2 (set (reg:DI 13 x13)
(plus:DI (reg/f:DI 31 sp)
(const_int -1048576 [0xfff0]))) "t.c":2:28 -1
 (expr_list:REG_CFA_DEF_CFA (plus:DI (reg:DI 13 x13)
(const_int 1048576 [0x10]))
(nil)))
(insn/f 57 56 58 2 (set (reg/f:DI 31 sp)
(unspec_volatile:DI [
(reg/f:DI 31 sp)
(reg:DI 13 x13)
] UNSPECV_PROBE_STACK_RANGE)) "t.c":2:28 -1
 (expr_list:REG_CFA_DEF_CFA (plus:DI (reg/f:DI 31 sp)
(const_int 1048576 [0x10]))
(nil)))
```

which seems fine because in insn 55 the sp is the CFA, insn 56
changes the CFA to x13, and insn 57 changes it back to sp.
But by the time we get to dwarf2 we have:

```
(insn/f 56 54 55 (set (reg:DI 13 x13)
(plus:DI (reg/f:DI 31 sp)
(const_int -1048576 [0xfff0]))) "t.c":2:28 120
{*adddi3_aarch64}
 (expr_list:REG_CFA_DEF_CFA (plus:DI (reg:DI 13 x13)
(const_int 1048576 [0x10]))
(nil)))
(insn/f:TI 55 56 57 (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 16 [0x10])) [2  S8 A8])
(reg:DI 19 x19)) "t.c":2:28 70 {*movdi_aarch64}
 (expr_list:REG_DEAD (reg:DI 19 x19)
(expr_list:REG_CFA_OFFSET (set (mem/c:DI (plus:DI (reg/f:DI 31 sp)
(const_int 16 [0x10])) [2  S8 A8])
(reg:DI 19 x19))
(nil
(insn/f 57 55 58 (set (reg/f:DI 31 sp)
(unspec_volatile:DI [
(reg/f:DI 31 sp)
(reg:DI 13 x13)
] UNSPECV_PROBE_STACK_RANGE)) "t.c":2:28 1151 {probe_stack_range}
 (expr_list:REG_DEAD (reg:DI 13 x13)
(expr_list:REG_CFA_DEF_CFA (plus:DI (reg/f:DI 31 sp)
(const_int 1048576 [0x10]))
(nil
```

i.e. the insns have been re-ordered, so now the CFA gets changed to
x13 in insn 56 and so the `REG_CFA_OFFSET` note in insn 55 becomes invalid,
because the CFA is no longer the sp when we process that insn.

Not immediately sure what the right fix is, will investigate further.

[Bug c++/113274] New: Memoization in template parameters is overly aggressive; false memoization for const pointers

[janschultke at googlemail dot com via Gcc-bugs]

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

Bug ID: 113274
   Summary: Memoization in template parameters is overly
aggressive; false memoization for const pointers
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: janschultke at googlemail dot com
  Target Milestone: ---

## Minimal Reproducible Example (https://godbolt.org/z/Y7Kr9o546)

template 
struct A {
static constexpr bool value = false;
};

template 
  requires __is_same(decltype(p), int*)
struct A {
static constexpr bool value = false;
};

int x = 0;
//static_assert( A<&x>::value );
static_assert( A(&x)>::value == false );

## Explanation

Uncommenting the first static_assert causes compilation failure of the second
static_assert.
This should definitely not happen, as the following instantiations should be
distinct:

- A<(int*) &x>
- A<(const int*) &x>

GCC aggressively memoizes the first instantiation in A<&x>, which results in
the subsequent A<(const int*)&x>::value being identical, even though it should
not be.

[Bug target/113235] SMHasher SHA3-256 benchmark is almost 40% slower vs. Clang (not enough complete loop peeling)

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #7 from Richard Biener  ---
IMO it should be purely growth/unrolled-insns bound, the bound on the actual
unrolled iterations is somewhat artificial (to avoid really large unrolls
when we estimate the unrolled body to be zero, thus never hit any of the other
limits).  That said, I think we should get better at estimating growth - I
don't
think we get that the reads from the constant arrays get elided?  (though
that's
not always an optimal thing)

See the proposal on better estimation I had last year.

[Bug target/113235] SMHasher SHA3-256 benchmark is almost 40% slower vs. Clang (not enough complete loop peeling)

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

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

--- Comment #8 from Richard Biener  ---
Created attachment 57006
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57006&action=edit
unroll heuristics

this one

[Bug tree-optimization/113239] [13/14 regression] After 822a11a1e64, bogus -Warray-bounds warnings in std::vector

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|[13 regression] After   |[13/14 regression] After
   |822a11a1e64, bogus  |822a11a1e64, bogus
   |-Warray-bounds warnings in  |-Warray-bounds warnings in
   |std::vector |std::vector
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-01-08
   Target Milestone|--- |13.3

--- Comment #4 from Richard Biener  ---
Confirmed.

[Bug target/113077] [14 Regression] ICE in dwarf2out_frame_debug_cfa_offset with `-O2 -fstack-protector-strong -fstack-clash-protection`

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

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

--- Comment #5 from Jakub Jelinek  ---
I think generally one shouldn't be reordering frame related instructions or
needs to be extremely careful when doing so.

[Bug c++/113274] Memoization in template parameters is overly aggressive; false memoization for const pointers

[janschultke at googlemail dot com via Gcc-bugs]

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

--- Comment #1 from Jan Schultke  ---
Original problem and more discussion:
https://stackoverflow.com/q/4976/5740428

[Bug target/113077] [14 Regression] ICE in dwarf2out_frame_debug_cfa_offset with `-O2 -fstack-protector-strong -fstack-clash-protection`

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

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

--- Comment #6 from Alex Coplan  ---
Looks like sched_fusion is doing the re-ordering.

[Bug target/112937] [14 Regression] GCN: FAILs due to unconditional 'f->use_flat_addressing = true;'

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

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

--- Comment #3 from Thomas Schwinge  ---
The GCN offloading 'libgomp.fortran/target1.f90' regression has been cured by
commit r14-6996-gc5c3aab38132ea34dc1ee69d93fded787e6ac7a4 "amdgcn: Don't
double-count AVGPRs" (..., but not the GCN target regressions that I initially
reported here).

[Bug c++/113274] Memoization in template parameters is overly aggressive; false memoization for const pointers

[janschultke at googlemail dot com via Gcc-bugs]

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

--- Comment #2 from Jan Schultke  ---
OOPS, I've messed up the repro. It should be true in the partial
specialization.

https://godbolt.org/z/11dW3cTfc

[Bug target/113275] New: tests pr110268-1.c pr110268-2.c csinc-1.c csinv-1.c fail after gcc-14-5396-ged52bc2e30c

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

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

Bug ID: 113275
   Summary: tests pr110268-1.c pr110268-2.c csinc-1.c csinv-1.c
fail after gcc-14-5396-ged52bc2e30c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

After commit g:ed52bc2e30c (arm: testsuite: avoid hard-float ABI
incompatibility with -march) a few testcases started to fail on arm-eabi:

* when targeting cortex-m33
(-mthumb/-march=armv8-m.main+dsp+fp/-mtune=cortex-m33/-mfloat-abi=hard/-mfpu=auto)
FAIL: gcc.target/arm/pr110268-1.c (test for excess errors)
FAIL: gcc.target/arm/pr110268-2.c (test for excess errors)

* when targeting cortex-m7
(-mthumb/-march=armv7e-m+fp.dp/-mtune=cortex-m7/-mfloat-abi=hard/-mfpu=auto)
FAIL: gcc.target/arm/csinc-1.c scan-assembler csinc\tr[0-9]*.*ne
FAIL: gcc.target/arm/csinv-1.c scan-assembler csinv\tr[0-9]*.*ne
FAIL: gcc.target/arm/pr110268-1.c (test for excess errors)
FAIL: gcc.target/arm/pr110268-2.c (test for excess errors)

GCC is configured with
--disable-multilib --with-mode=thumb --with-cpu=cortex-m7 --with-float=hard
(or with --with-cpu=cortex-m33)

For gcc.target/arm/pr110268-[12].c, gcc.log says:
Executing on host:
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-eabi-gcc
 
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.target/arm/pr110268-1.c
 -mthumb -march=armv7e-m+fp.dp -mtune=cortex-m7 -mfloat-abi=hard -mfpu=auto  
-fdiagnostics-plain-output   -ansi -pedantic-errors -mfloat-abi=softfp
-mfpu=auto -march=armv8.1-m.main+mve -mthumb --save-temps -O2 -flto  
-specs=rdimon.specs  -lm  -o pr110268-1.exe(timeout = 600)
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/lib/gcc/arm-eabi/14.0.0/../../../../arm-eabi/bin/ld:
error: pr110268-1.exe uses VFP register arguments,
./pr110268-1.ltrans0.ltrans.o does not
/home/tcwg-buildslave/workspace/tcwg_gnu_0/abe/builds/destdir/x86_64-pc-linux-gnu/lib/gcc/arm-eabi/14.0.0/../../../../arm-eabi/bin/ld:
failed to merge target specific data of file ./pr110268-1.ltrans0.ltrans.o

[Bug c++/113274] Memoization in template parameters is overly aggressive; false memoization for const pointers

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Dup of bug 113272.

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

[Bug c++/113272] Wrong specialization of class template selected

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||janschultke at googlemail dot 
com

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

[Bug middle-end/113182] [14 Regression] FAIL: g++.dg/cpp0x/udlit-namespace.C -std=c++14 execution test

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #7 from dave.anglin at bell dot net ---
On 2024-01-08 9:29 a.m., jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113182
>
> Jakub Jelinek  changed:
>
> What|Removed |Added
> 
>   CC||jakub at gcc dot gnu.org
>
> --- Comment #6 from Jakub Jelinek  ---
> (In reply to John David Anglin from comment #5)
>> The problem is TREE_SYMBOL_REFERENCED is not set for libfuncs.  This fixes
>> problem on hppa64-hpux:
>>
>> bash-5.1$ git diff gcc/varasm.cc
>> diff --git a/gcc/varasm.cc b/gcc/varasm.cc
>> index 69f8f8ee018..0a1cc022023 100644
>> --- a/gcc/varasm.cc
>> +++ b/gcc/varasm.cc
>> @@ -2527,9 +2527,7 @@ process_pending_assemble_externals (void)
>> for (rtx list = pending_libcall_symbols; list; list = XEXP (list, 1))
>>   {
>> rtx symbol = XEXP (list, 0);
>> -  tree id = get_identifier (XSTR (symbol, 0));
>> -  if (TREE_SYMBOL_REFERENCED (id))
>> -   targetm.asm_out.external_libcall (symbol);
>> +  targetm.asm_out.external_libcall (symbol);
>>   }
>>
>> pending_assemble_externals = 0;
>>
>> If you don't care about libfuncs, you could move the TREE_SYMBOL_REFERENCED
>> check into the bpf target.
> Then the bug is that it isn't set when they are actually referenced.
Exactly.  This has been a problem for a long time.  There is a work around in
the define
for ASM_OUTPUT_EXTERNAL_LIBCALL in pa/som.h.  Issue is also mentioned in
sol2.cc.

[Bug target/113270] [14 Regression] AArch64 ICEs in register_tuple_type since r14-6524

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

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

--- Comment #6 from Richard Sandiford  ---
I think we want the patch in comment 3, but in addition, I then also needed to
use the following for a similar SVE case:

extern GTY(()) tree scalar_types[NUM_VECTOR_TYPES + 1];
tree scalar_types[NUM_VECTOR_TYPES + 1];

In this case that would mean adding:

extern GTY(()) aarch64_simd_type_info aarch64_simd_types[];

just above the definition in aarch64-builtins.cc.

[Bug tree-optimization/113210] [14 Regression] ICE: tree check: expected integer_cst, have cond_expr in get_len, at tree.h:6481

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #56993|0   |1
is obsolete||

--- Comment #15 from Jakub Jelinek  ---
Created attachment 57007
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57007&action=edit
gcc14-pr113210.patch

So like this instead?