[Bug preprocessor/109534] -fdirectives-only does not work with assembler-with-cpp

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #7 from Boris Kolpackov  ---
BTW, my understanding of the rationale for the original patch (the one that
forces -fno-directives-only) is to paper over some underlying issue with
-fdirectives-only when used on .S files, potentially the same as the one I've
encountered with a broken line directive. And the intend of the patch was to
make builds that use -fdirectives-only on .S files to work transparently by
forcing full preprocessing instead. But that "transparently" part doesn't seem
to hold (using the same test.S):


$ gcc -E -fdirectives-only -o test.Si test.S
$ 
$ gcc -x assembler-with-cpp -fpreprocessed -fdirectives-only -c -o test.o
test.Si
test.Si:1: Error: junk at end of line, first unrecognized character is `0'


The error is due to -fno-directives-only cancelling out -fdirectives-only and
just -fpreprocessed means the file is fully preprocessed.

[Bug preprocessor/109534] -fdirectives-only does not work with assembler-with-cpp

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #6 from Boris Kolpackov  ---
> The documentation says specifically-fdirectives-only is ignored if 
> -fpreprocessed is supplied.

Hm, that's not how it works, IME. Specifically, just "-fpreprocessed" means the
source code is fully preprocessed (and no further preprocessing is required)
while "-fpreprocessed -fdirectives-only" means the source code is preprocessed
to directives only (and further preprocessing is required). Here is a
demonstration:

$ cat test.c
#define FOO 2
int f () {return FOO;}
EOF

$ gcc -E -fdirectives-only -o test.i test.c

$ tail -3 test.i
# 1 "test.c"
#define FOO 2
int f () {return FOO;}

$ gcc -fpreprocessed -fdirectives-only -c -o test.o test.i

$ gcc -fpreprocessed -c -o test.o test.i
test.c: In function ‘f’:
test.c:2:18: error: ‘FOO’ undeclared (first use in this function)
2 | int f () {return FOO;}

About initialization of automatic variables

[naoki ueda via Gcc-bugs]

The attached code says "int a = 100;", but it should normally be
initialized with an "undefined value", but in the case of gcc-10, it is
initialized with "0". Isn't this a bug in gcc-10?
#include 

int main(void)
{
int n;

for (n = 1;n <= 5;n++) {
switch (n)
{   int a = 100;
static int b = 200;
a = 111;
b = 222;
case 1:
++a; ++b;
printf("case1: a = %d b = %d\n", a, b);
break;
case 3:
++a; ++b;
printf("case3: a = %d b = %d\n", a, b);
}
}
for (n = 1;n <= 3;n++) {
int c = 300;
static int d = 400;
++c; ++d;
printf("for: c = %d d = %d\n", c, d);
}
return 0;
}

[Bug preprocessor/81745] missing warning with -pedantic when a C file does not end with a newline character [-Wnewline-eof]

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

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

--- Comment #16 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #15)
> (In reply to Vincent Lefèvre from comment #14)
> > Even though GCC decides to add a newline to the logical file, so that the
> > missing diagnostic can be regarded as correct, I think that an optional
> > warning would be useful for portability.
> > https://gcc.gnu.org/legacy-ml/gcc-patches/2007-04/msg00651.html was
> > suggesting "add -W(no-)eof-newline". So why hasn't -Wno-eof-newline been
> > added?
> 
> Because it was decided the warning was not needed at all so why have an
> option to turn it on/off if it was not a good warning.

It might not have been *needed*, but some people still might *want* it anyways.
I think it's a good warning anyways just for style purposes, even if it isn't
strictly necessary.

RE: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values

[Puneet Kumar Yatnal (QUIC) via Gcc-bugs]

What is next step here? How do I post this in Bugzilla and get support.

Regards
Puneet

From: Jonathan Wakely 
Sent: Monday, April 17, 2023 1:06 PM
To: Puneet Kumar Yatnal (QUIC) 
Cc: Andrew Pinski ; gcc-help ; 
gcc-bugs@gcc.gnu.org
Subject: Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has 
impact on time values


On Mon, 17 Apr 2023, 09:27 Puneet Kumar Yatnal (QUIC), 
mailto:quic_pune...@quicinc.com>> wrote:
Here issue is weakref symbol in gcc not using the __asm_ function pointed by 
pthread.h instead its calling directly ___pthread_cond_timedwait which is 
exposed by version_symbol in pthread_cond_wait.c of glibc

Yes, I understand that.

Like Andrew said, please file it in bugzilla. Somebody will create your account 
later today.




From: Jonathan Wakely mailto:jwakely@gmail.com>>
Sent: Monday, April 17, 2023 12:53 PM
To: Andrew Pinski mailto:pins...@gmail.com>>
Cc: Puneet Kumar Yatnal (QUIC) 
mailto:quic_pune...@quicinc.com>>; gcc-help 
mailto:gcc-h...@gcc.gnu.org>>; 
gcc-bugs@gcc.gnu.org
Subject: Re: Y2038: GCC gthr-posix.h weakref symbol invoking function has 
impact on time values


WARNING: This email originated from outside of Qualcomm. Please be wary of any 
links or attachments, and do not enable macros.

On Mon, 17 Apr 2023, 07:54 Andrew Pinski via Gcc-help, 
mailto:gcc-h...@gcc.gnu.org>> wrote:
On Sun, Apr 16, 2023 at 10:41 PM Puneet Kumar Yatnal (QUIC) via
Gcc-bugs mailto:gcc-bugs@gcc.gnu.org>> wrote:
>
>
> ++
> From: Puneet Kumar Yatnal (QUIC)
> Sent: Monday, April 17, 2023 9:26 AM
> To: gcc-h...@gcc.gnu.org
> Subject: Y2038: GCC gthr-posix.h wekref symbol invoking function has impact 
> on time values

First gcc-bugs@ is not the right place to report a bug report as
gcc-bugs is mainly for automated emails from bugzilla. Please use
bugzilla first.

>
> All
>
> if we fallowed https://sourceware.org/glibc/wiki/Y2038ProofnessDesign for 
> Y2038 fix(where all timer related variable moved to 64 bit instead of 32 bit 
> ), pthread_cond_timedwait function from gthr_posix.h is calling different 
> function in pthrea_cond_wait.c of glibc(due to weakref of symbol 
> pthread_cond_timedwait())  which impacting the time value.

Note libstdc++ does ABI changes too which is NOT part of that ABI design.
This is where the symbol
__gthread_cond_timedwait/__gthrw_pthread_cond_timedwait are used. So
any changes you might do to fix __gthrw_pthread_cond_timedwait is not
really going to work without wider ABI fixes to libstdc++.
I don't know any one who is making those changes/fixes. So you should
file an bug requesting it. And maybe even have a design document ready
for it. There are many/some classes which have timespec inside them

I don't think that's true. We don't use timespec members, they're just local 
variables, and very occasionally function parameters.



and not just the mutex related ones.

Thanks,
Andrew

>
> From pthread.h
> extern int pthread_cond_timedwait (pthread_cond_t *__restrict __cond, 
> pthread_mutex_t *__restrict __mutex, const struct timespec *__restrict 
> __abstime) __asm__ ("" "__pthread_cond_timedwait64")
>
> From gthread_posix.h:
> static __typeof(pthread_cond_timedwait) __gthrw_pthread_cond_timedwait 
> __attribute__ ((__weakref__("pthread_cond_timedwait"), __copy__ 
> (pthread_cond_timedwait)));
>
>
> __gthrw_(pthread_cond_timedwait) --> ___pthread_cond_timedwait   invoking in 
> glibc instead of   __pthread_cond_timedwait64 which is impacting time value 
> as __pthread_cond_timedwait is converting value from 32 bit to 64 bit.
>
> normal pthread_cond_timedwait is invoking __pthread_cond_timedwait64 properly 
> and its working fine.
>
> From: pthread_cond_wait.c
>
> #if __TIMESIZE == 64
> strong_alias (___pthread_cond_timedwait64, ___pthread_cond_timedwait)
> #else
> strong_alias (___pthread_cond_timedwait64, __pthread_cond_timedwait64)
> libc_hidden_def (__pthread_cond_timedwait64)
>
> int
> ___pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex,
> const struct timespec *abstime)
> {
>   struct __timespec64 ts64 = valid_timespec_to_timespec64 (*abstime);
>
>   return __pthread_cond_timedwait64 (cond, mutex, );
> }
> #endif /* __TIMESIZE == 64 */
> versioned_symbol (libc, ___pthread_cond_timedwait,
>   pthread_cond_timedwait, GLIBC_2_3_2);
> libc_hidden_ver (___pthread_cond_timedwait, __pthread_cond_timedwait)
> #ifndef SHARED
> strong_alias (___pthread_cond_timedwait, __pthread_cond_timedwait)
> #endif
>
> if add  #defing GTHREAD_USE_WEAK 0  in libgcc/gthr-posix.h issue is resolved 
> but that is not correct way as it disable weakref for all symbol, please let 
> me know what is correct way to fix this, this i observed with   gcc-9.3.0 gcc 
> and glibc 2.34
>
> Regards
> Puneet
>

[Bug libstdc++/109442] Dead local copy of std::vector not removed from function

[richard-gccbugzilla at metafoo dot co.uk via Gcc-bugs]

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

--- Comment #16 from Richard Smith  
---
(In reply to Richard Biener from comment #15)
> I was specifically looking at C++20 7.6.2.7/10 to /14 (but maybe also
> others and of course the relevant parts of the delete expression).  In
> particular the extra leeway the standard provides to new/delete _expressions_
> vs. calls of the global replaceable operators directly - do the
> __builtin_operator_{new,delete} in this regard behave like new/delete
> _expressions_ or like direct calls to the operators?

They permit the same optimizations as new/delete expressions. The sections of
the C++ standard that you referred to are what the documentation for the
builtins means when it says:

"[__builtin_operator_new] allows certain optimizations that the C++ standard
does not permit for a direct function call to ::operator new (in particular,
removing new / delete pairs and merging allocations)"

> Do the builtins call one of the replaceable global new/delete operators
> and thus users can reliably override them?

If the implementation doesn't provide storage in some other way, optimize away
the allocation, or merge it with another allocation, then yes, the storage is
obtained by calling the corresponding replaceable global new/delete operators.
Per the documentation:

"A call to __builtin_operator_new(args) is exactly the same as a call to
::operator new(args), except that [text quoted above]"

> How do the builtins behave during constexpr evaluation?  new/delete
> expressions have their behavior documented in the standard.

They behave exactly like a direct call to the replaceable global allocation
function.

In Clang's implementation, direct calls to ::operator new and ::operator delete
are permitted within calls to std::allocator::allocate and
std::allocator::deallocate during constant evaluation, and are treated as
allocating or deallocating arrays of T; consequently, calls to
__builtin_operator_new and __builtin_operator_delete are permitted in the same
contexts. In all other contexts, Clang rejects such calls, because the callee
is not declared `constexpr`.

[Bug target/109535] internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #9 from JuzheZhong  ---
Confirm it is VSETVL pass bug in RISC-V port backend.
Fix patch here:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615882.html
Hopefully, it will be merged soon.

[Bug testsuite/105267] [12/13/14 regression] gcc.target/powerpc/pr56605.c fails after r12-8128-g6b7cc7294770ec

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

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #6 from Kewen Lin  ---
As https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146#c22, this issue should
be gone on gcc-13 and latest trunk, we don't want to backport that fix as the
test case is quite fragile as Segher pointed out.

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

[Bug target/102146] [11 regression] several test cases fails after r11-8940

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

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

--- Comment #23 from Kewen Lin  ---
*** Bug 105267 has been marked as a duplicate of this bug. ***

[Bug c++/108165] -Wdangling-reference false positive

[mrsam--- via Gcc-bugs]

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

Sam Varshavchik  changed:

   What|Removed |Added

 CC||mr...@courier-mta.com

--- Comment #16 from Sam Varshavchik  ---
*** Bug 109538 has been marked as a duplicate of this bug. ***

[Bug c++/109538] Spurious -Werror=dangling-reference false positive

[mrsam--- via Gcc-bugs]

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

Sam Varshavchik  changed:

   What|Removed |Added

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

--- Comment #2 from Sam Varshavchik  ---
Eh, I'll just close it myself, this is clearly the same bug.

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

[Bug target/108589] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1932 with -mtune=ampere1a -fno-split-wide-types

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Philipp Tomsich
:

https://gcc.gnu.org/g:28fc1297adde1be51f25a13e110d38dd9e804320

commit r10-11299-g28fc1297adde1be51f25a13e110d38dd9e804320
Author: Philipp Tomsich 
Date:   Mon Jan 30 23:40:26 2023 +0100

PR target/108589 - Check REG_P for AARCH64_FUSE_ADDSUB_2REG_CONST1

This adds a check for REG_P on SET_DEST for the new idiom recognizer
for AARCH64_FUSE_ADDSUB_2REG_CONST1.  The reported ICE is only
observable with checking=rtl.

Bootstrapped/regtested aarch64-linux, committed.

PR target/108589

gcc/ChangeLog:

* config/aarch64/aarch64.c (aarch_macro_fusion_pair_p): Check
REG_P on SET_DEST.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/pr108589.c: New test.

(cherry picked from commit a39c6ec97906766ad65d15d4856fd41121ee7a45)

[Bug target/108589] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1932 with -mtune=ampere1a -fno-split-wide-types

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Philipp Tomsich
:

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

commit r11-10634-gb54061569221e678e99e9e49dc0ac79228d9c407
Author: Philipp Tomsich 
Date:   Mon Jan 30 23:40:26 2023 +0100

PR target/108589 - Check REG_P for AARCH64_FUSE_ADDSUB_2REG_CONST1

This adds a check for REG_P on SET_DEST for the new idiom recognizer
for AARCH64_FUSE_ADDSUB_2REG_CONST1.  The reported ICE is only
observable with checking=rtl.

Bootstrapped/regtested aarch64-linux, committed.

PR target/108589

gcc/ChangeLog:

* config/aarch64/aarch64.c (aarch_macro_fusion_pair_p): Check
REG_P on SET_DEST.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/pr108589.c: New test.

(cherry picked from commit a39c6ec97906766ad65d15d4856fd41121ee7a45)

[Bug target/108589] ICE: RTL check: expected code 'reg', have 'subreg' in rhs_regno, at rtl.h:1932 with -mtune=ampere1a -fno-split-wide-types

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

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

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

https://gcc.gnu.org/g:0f7ca8a3f50b0c34183a92a1b6c15ff5aacbf449

commit r12-9418-g0f7ca8a3f50b0c34183a92a1b6c15ff5aacbf449
Author: Philipp Tomsich 
Date:   Mon Jan 30 23:40:26 2023 +0100

PR target/108589 - Check REG_P for AARCH64_FUSE_ADDSUB_2REG_CONST1

This adds a check for REG_P on SET_DEST for the new idiom recognizer
for AARCH64_FUSE_ADDSUB_2REG_CONST1.  The reported ICE is only
observable with checking=rtl.

Bootstrapped/regtested aarch64-linux, committed.

PR target/108589

gcc/ChangeLog:

* config/aarch64/aarch64.cc (aarch_macro_fusion_pair_p): Check
REG_P on SET_DEST.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/pr108589.c: New test.

(cherry picked from commit a39c6ec97906766ad65d15d4856fd41121ee7a45)

[Bug c++/109538] Spurious -Werror=dangling-reference false positive

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

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

--- Comment #1 from Andrew Pinski  ---
I suspect this will be closed as a dup of bug 108165 really. Because the
warning is doing it is expected of it and it is hard to figure out without the
full code available at the time (which the warning does not take that into
account). It just knows the function declaration rather than what is inside the
function itself.

[Bug c++/109538] New: Spurious -Werror=dangling-reference false positive

[mrsam--- via Gcc-bugs]

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

Bug ID: 109538
   Summary: Spurious -Werror=dangling-reference false positive
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mr...@courier-mta.com
  Target Milestone: ---

gcc 13.0.1 would like to register a complaint:

t.C:17:14: error: possibly dangling reference to a temporary
[-Werror=dangling-reference]
   17 |   const int =optional_arg_or(def, 0);
  |  ^
t.C:17:31: note: the temporary was destroyed at the end of the full expression
‘optional_arg_or(def, 0)’
   17 |   const int =optional_arg_or(def, 0);
  |~~~^~~~

for:

#include 
#include 

const int _arg_or(std::optional ,
   int &_val)
{
  def = def_val;

  return *def;
}


int gimme()
{
  std::optional def;

  const int =optional_arg_or(def, 0);

  int bologna=v;

  return bologna;
}

Changing optional_arg_or's parameter to "int def_val" silences the complaint.
gcc appears to be voicing an objection that optional_arg_or returns a reference
to a temporary that gets created during the function call and destroyed at the
conclusion of the function call. However that temporary gets placed into a
std::optional, and then a reference to the std::optional gets returned.

[Bug c++/100131] [meta-bug] internal compiler error: in hashtab_chk_error, at hash-table.c:137

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

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

Bug 109531 Summary: [13/14 Regression] Checking ICE with  hash table checking 
failed: equal operator returns true for a pair of values with a different hash 
value since r13-3292-gc2565a31c1622a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109531

   What|Removed |Added

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

[Bug c++/109531] [13/14 Regression] Checking ICE with hash table checking failed: equal operator returns true for a pair of values with a different hash value since r13-3292-gc2565a31c1622a

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
 Resolution|--- |FIXED

--- Comment #15 from Patrick Palka  ---
Fixed for GCC 13.

[Bug c++/109531] [13/14 Regression] Checking ICE with hash table checking failed: equal operator returns true for a pair of values with a different hash value since r13-3292-gc2565a31c1622a

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Patrick Palka
:

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

commit r13-7208-gc895eb11c8c95aa5714fa4043194b1001336567e
Author: Patrick Palka 
Date:   Mon Apr 17 18:52:07 2023 -0400

c++: bound ttp level lowering [PR109531]

Here when level lowering the bound ttp TT via the
substitution T=C, we're neglecting to canonicalize (and thereby strip
of simple typedefs) the substituted template arguments {A} before
determining the new canonical type via hash table lookup.  This leads to
a hash mismatch ICE for the two equivalent types TT and TT>
since iterative_hash_template_arg assumes type arguments are already
canonicalized.

We can fix this by canonicalizing or coercing the substituted arguments
directly, but seeing as creation and ordinary substitution of bound ttps
both go through lookup_template_class, which in turn performs the desired
coercion/canonicalization, it seems preferable to make this code path go
through lookup_template_class as well.

PR c++/109531

gcc/cp/ChangeLog:

* pt.cc (tsubst) :
In the level-lowering case just use lookup_template_class
to rebuild the bound ttp.

gcc/testsuite/ChangeLog:

* g++.dg/template/canon-type-20.C: New test.
* g++.dg/template/ttp36.C: New test.

(cherry picked from commit 2245459c85a3f4cde3d33bf3e4edaff08f3b2404)

[Bug c++/109531] [13/14 Regression] Checking ICE with hash table checking failed: equal operator returns true for a pair of values with a different hash value since r13-3292-gc2565a31c1622a

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

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

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

https://gcc.gnu.org/g:2245459c85a3f4cde3d33bf3e4edaff08f3b2404

commit r14-11-g2245459c85a3f4cde3d33bf3e4edaff08f3b2404
Author: Patrick Palka 
Date:   Mon Apr 17 18:52:07 2023 -0400

c++: bound ttp level lowering [PR109531]

Here when level lowering the bound ttp TT via the
substitution T=C, we're neglecting to canonicalize (and thereby strip
of simple typedefs) the substituted template arguments {A} before
determining the new canonical type via hash table lookup.  This leads to
a hash mismatch ICE for the two equivalent types TT and TT>
since iterative_hash_template_arg assumes type arguments are already
canonicalized.

We can fix this by canonicalizing or coercing the substituted arguments
directly, but seeing as creation and ordinary substitution of bound ttps
both go through lookup_template_class, which in turn performs the desired
coercion/canonicalization, it seems preferable to make this code path go
through lookup_template_class as well.

PR c++/109531

gcc/cp/ChangeLog:

* pt.cc (tsubst) :
In the level-lowering case just use lookup_template_class
to rebuild the bound ttp.

gcc/testsuite/ChangeLog:

* g++.dg/template/canon-type-20.C: New test.
* g++.dg/template/ttp36.C: New test.

[Bug tree-optimization/98856] [11/12/13/14 Regression] botan AES-128/XTS is slower by ~17% since r11-6649-g285fa338b06b804e72997c4d876ecf08a9c083af

[lukebenes at hotmail dot com via Gcc-bugs]

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

--- Comment #43 from Luke  ---
@Richard Biener 
Polite ping. Are you still working on this regression?

[Bug libstdc++/109536] Failure to compile constexpr std::vector with -D_GLIBCXX_DEBUG

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

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

--- Comment #2 from Jakub Jelinek  ---
r12-5187-g1ae8edf5f73ca5c3 even.

[Bug libstdc++/109536] Failure to compile constexpr std::vector with -D_GLIBCXX_DEBUG

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
12-5187-g1ae8edf5f73ca5c3 acknowledged that:
libstdc++: Implement constexpr std::vector for C++20

This implements P1004R2 ("Making std::vector constexpr") for C++20.

For now, debug mode vectors are not supported in constant expressions.
To make that work we might need to disable all attaching/detaching of
safe iterators. That can be fixed later.

[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value

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

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Leandro Lupori from comment #10)
> Wouldn't it be better to turn this into a warning?
> 
> Although using the result of a function as an allocatable argument doesn't
> conform with Fortran standards, it has been supported by gfortran for quite
> some time. This change may break existing code.

Well, then the existing code seems to violate the Fortran standard,
and it seems it was a bug that gfortran accepted it silently.

The code in comment#0 seems to be silently accepted by the Intel classic
Fortran compiler (ifort), but crashes the new one (ifx).  I've asked
Intel on their opinion.

I've also learned that the same happens for the case of passing f() to
a subroutine, as in:

  call s(f())
[...]
contains
  subroutine s(p)
integer, allocatable :: p
  end subroutine s
[...]

This is rejected by NAG and also Nvidia and AMD flang, and crashes ifx.

Do you have anybody else supporting the view that the code in question
should work as an extension?

As I said before, there are legal ways to return from a procedure with
the result variable either allocated or not, but this cannot be a function.

[Bug fortran/106999] [11/12/13/14 Regression] ICE tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_class_data_get, at fortran/trans-expr.cc:233

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-04-17

--- Comment #3 from anlauf at gcc dot gnu.org ---
FWIW, it is -fcheck=pointer triggering the ICE.

[Bug fortran/100297] FAIL: gfortran.dg/allocatable_function_1.f90 gfortran.dg/reshape_8.f90

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

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to Andreas Schwab from comment #3)
> "\.data" is the same as ".data", you want either "\\.data" or {\.data}.  But
> it still doesn't lower the probability to match a filename by much.

True.

I've compared the dump generated by gfortran <= 10 vs. >= 11, looked at
PR96624 again and came to the conclusion that the absence of the following
was probably intended:

(*(integer(kind=4)[0] * restrict) atmp.0.data)[0] = 1;
(*(integer(kind=4)[0] * restrict) atmp.0.data)[1] = 2;

The following pattern variant succeeds with 11+ and fails with 10-branch:

diff --git a/gcc/testsuite/gfortran.dg/reshape_8.f90
b/gcc/testsuite/gfortran.dg/reshape_8.f90
index 01799ac5c19..56812124cb8 100644
--- a/gcc/testsuite/gfortran.dg/reshape_8.f90
+++ b/gcc/testsuite/gfortran.dg/reshape_8.f90
@@ -11,4 +11,4 @@ program test
   a = reshape([1,2,3,4], [2,0])
   print *, a
 end
-! { dg-final { scan-tree-dump-times "data" 4 "original" } }
+! { dg-final { scan-tree-dump-not "data..0. =" "original" } }

This should be safe enough...

[Bug target/106602] riscv: suboptimal codegen for zero_extendsidi2_shifted w/o bitmanip

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

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

--- Comment #28 from CVS Commits  ---
The trunk branch has been updated by Palmer Dabbelt :

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

commit r14-5-g8c010f6fe5ebe80d2e054b31e04ae0e9f12ae368
Author: Palmer Dabbelt 
Date:   Tue Apr 11 11:04:56 2023 -0700

RISC-V: Clean up the pr106602.c testcase

The test case that was added is rv64i-specific, as there's better ways
to generate this code on rv32i (where the long/int cast is a NOP) and on
rv64i_zba (where we have word shifts).  This renames the original test
case and adds two more for those targets.

gcc/testsuite/ChangeLog:
PR target/106602
* gcc.target/riscv/pr106602.c: Moved to...
* gcc.target/riscv/pr106602-rv64i.c: ...here.
* gcc.target/riscv/pr106602-rv32i.c: New test.
* gcc.target/riscv/pr106602-rv64i_zba.c: New test.

[Bug libgomp/107041] [13/14 Regression] C '-Wenum-int-mismatch' diagnostic for OpenACC 'acc_on_device'

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

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

--- Comment #4 from Jakub Jelinek  ---
I think this is less important as it normally should trigger only with -Wall
-Wsystem-headers.

Anyway, one fix could be e.g.
--- gcc/omp-builtins.def.jj 2023-04-17 19:11:55.065865863 +0200
+++ gcc/omp-builtins.def2023-04-17 19:14:45.433406545 +0200
@@ -52,7 +52,7 @@ DEF_GOACC_BUILTIN (BUILT_IN_GOACC_DECLAR
   BT_FN_VOID_INT_SIZE_PTR_PTR_PTR, ATTR_NOTHROW_LIST)

 DEF_GOACC_BUILTIN_COMPILER (BUILT_IN_ACC_ON_DEVICE, "acc_on_device",
-   BT_FN_INT_INT, ATTR_CONST_NOTHROW_LEAF_LIST)
+   BT_FN_INT_VAR, ATTR_CONST_NOTHROW_LEAF_LIST)

 DEF_GOACC_BUILTIN_ONLY (BUILT_IN_GOACC_PARLEVEL_ID, "goacc_parlevel_id",
BT_FN_INT_INT, ATTR_NOTHROW_LEAF_LIST)
--- gcc/c-family/c-common.cc.jj 2023-03-28 17:47:46.769970692 +0200
+++ gcc/c-family/c-common.cc2023-04-17 19:28:31.037488778 +0200
@@ -6493,6 +6493,25 @@ check_builtin_function_arguments (locati
}
   return false;

+case BUILT_IN_ACC_ON_DEVICE:
+  if (builtin_function_validate_nargs (loc, fndecl, nargs, 1))
+   {
+ if (TREE_CODE (TREE_TYPE (args[0])) != INTEGER_TYPE
+ && (TREE_CODE (TREE_TYPE (args[0])) != ENUMERAL_TYPE
+ || (TREE_CODE (TREE_TYPE (TREE_TYPE (args[0])))
+ != INTEGER_TYPE)
+ || (TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (args[0])))
+ != integer_type_node)))
+   {
+ error_at (ARG_LOCATION (0), "argument %u in call to function "
+   "%qE does not have integer or enumerated type",
+   1, fndecl);
+ return false;
+   }
+ return true;
+   }
+  return false;
+
 default:
   return true;
 }
--- gcc/fortran/types.def.jj2023-04-17 19:11:55.065865863 +0200
+++ gcc/fortran/types.def   2023-04-17 19:14:45.433406545 +0200
@@ -264,6 +264,7 @@ DEF_FUNCTION_TYPE_11 (BT_FN_VOID_OMPFN_P
  BT_ULONGLONG, BT_ULONGLONG, BT_ULONGLONG)

 DEF_FUNCTION_TYPE_VAR_0 (BT_FN_VOID_VAR, BT_VOID)
+DEF_FUNCTION_TYPE_VAR_0 (BT_FN_INT_VAR, BT_INT)

 DEF_FUNCTION_TYPE_VAR_1 (BT_FN_VOID_LONG_VAR,
 BT_VOID, BT_LONG)
plus testsuite changes.
But that would break
#include 
struct S { operator acc_device_t () { return acc_device_none; } };

int
foo ()
{
  S s;
  return acc_on_device (s);
}
Another option would be just disable the warning for this particular builtin
where the warning is reported.

[Bug c++/109506] [10/11/12/13/14 regression] -fchecking=2 causes some template constructor not be instantiated when used with NSDMI

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #10 from Patrick Palka  ---
Seems the problem is that we instantiate NSDMIs on demand and only once, and so
the instantiation ends up being inadvertently sensitive to whether the
instantiation was first performed from a template context.

In the comment #1 testcase, with -fchecking=2 we end up instantiating the NSDMI
for bar<1>::alloc_ for the first time from the template context func1, via
fold_non_dependent_expr.  During this instantiation we call mark_used for
foo<2>'s default ctor but in_template_function() is true at this point and
mark_used exits early without scheduling the ctor for instantiation.  We never
call mark_used again for foo<2>'s default ctor since we process/instantiate an
NSDMI once.

I guess we need to somehow make sure in_template_function() always returns
false from maybe_instantiate_nsdmi_init and/or synthesized_method_walk..

[Bug middle-end/109537] Improve code generation for dynamic loop unrolling

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug tree-optimization/105545] [12/13/14 Regression] Warning for string assignment with _GLIBCXX_ASSERTIONS since r12-3347-g8af8abfbbace49e6

[jvb at cyberscience dot com via Gcc-bugs]

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

--- Comment #10 from John Buddery  ---
I can confirm this works on the gcc-13 branch, for both c++17 and c++20 - feel
free to close this issue.

[Bug preprocessor/81745] missing warning with -pedantic when a C file does not end with a newline character [-Wnewline-eof]

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

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

--- Comment #15 from Andrew Pinski  ---
(In reply to Vincent Lefèvre from comment #14)
> Even though GCC decides to add a newline to the logical file, so that the
> missing diagnostic can be regarded as correct, I think that an optional
> warning would be useful for portability.
> https://gcc.gnu.org/legacy-ml/gcc-patches/2007-04/msg00651.html was
> suggesting "add -W(no-)eof-newline". So why hasn't -Wno-eof-newline been
> added?

Because it was decided the warning was not needed at all so why have an option
to turn it on/off if it was not a good warning.

[Bug tree-optimization/106293] [13/14 Regression] 456.hmmer at -Ofast -march=native regressed by 19% on zen2 and zen3 in July 2022

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

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

--- Comment #12 from Martin Jambor  ---
My understanding of comment #2 and #3 is that we end up with what are very
likely bogus BB counts that we should check and perhaps attempt to fix.

[Bug libgomp/107041] [13/14 Regression] C '-Wenum-int-mismatch' diagnostic for OpenACC 'acc_on_device'

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

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

--- Comment #3 from Jakub Jelinek  ---
If this is really just because it is a builtin, I think another possibility
would be
make it BT_FN_INT_VAR instead of BT_FN_INT_INT and verify it has just one
argument which
is either int or the particularly named enum say in builtins.cc folding or so.

[Bug target/102027] [11/12/13/14 Regression] ABI break when using vector type in function arg/return value

[woodard at redhat dot com via Gcc-bugs]

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

--- Comment #10 from Ben Woodard  ---
Currently Libabigail is not able to detect this kind of ABI break. We would be
able to detect this if https://dwarfstd.org/issues/221105.1.html were
implemented. As mentioned in the DWARF issue, this would also other languages
and may even simplify some work that debuggers need to do. Since it is just an
ignorable attribute, can we start supporting it even before it is standardized.

[Bug d/109231] [13/14 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|13.0|13.2

--- Comment #38 from Jakub Jelinek  ---
As nobody but Rainer managed to reproduce this and we don't know what's going
on, postponing for 13.2.

[Bug target/109535] internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471

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

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
Can you quote a dump of the new insn pattern?  Or just:

  dump(change);

in function_info::finalize_new_accesses should do.

[Bug tree-optimization/106293] [13/14 Regression] 456.hmmer at -Ofast -march=native regressed by 19% on zen2 and zen3 in July 2022

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #11 from Jakub Jelinek  ---
So, what is left in tHIS PR?  Shall we retarget it for GCC 14?

[Bug testsuite/106227] [13/14 regression] g++.dg/modules/loc-prune-4.C fails after r13-1506-g069f46c71e9432

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
I don't see this failing on aarch64-linux, s390x-linux, x86_64-linux,
i686-linux, powerpc64le-linux.  What exactly you see in the dump instead?

[Bug target/109535] internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #7 from JuzheZhong  ---
(In reply to rsand...@gcc.gnu.org from comment #2)
> The assert in question fires if the pass creates an instruction
> whose pattern uses a register or memory and if the pass doesn't
> provide associated use information.  Let me know if it looks like
> a bug in rtl-ssa rather than a bug in the vsetvl pass.

Hi, Richard.

As Li Pan said, the vsetvl pass is trying to remove regno = 8 in
old uses = [0,8,66,67,]

Here is the code:

access_array_builder uses_builder (attempt);
uses_builder.reserve (insn->num_uses () - 1);
for (use_info *use : insn->uses ())
if (use != find_access (insn->uses (), REGNO (avl)))
  uses_builder.quick_push (use);
use_array new_uses = use_array (uses_builder.finish ());
change.new_uses = new_uses;

You can see here, I add all uses except the use which has the same regno with
"avl". 

Am I using RTL_SSA in a wrong way ? Or I should remove RTL_SSA updating when
removing operands of uses ?

Looking forward your suggestions.
Thanks.

[Bug target/109535] internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471

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

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

Kito Cheng  changed:

   What|Removed |Added

   Last reconfirmed||2023-04-17
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |juzhe.zhong at rivai 
dot ai

[Bug preprocessor/109534] -fdirectives-only does not work with assembler-with-cpp

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Boris Kolpackov from comment #4)
> Thanks for the link to the patch submission though I find the
> "-fdirectives-only option is incompatible with assembly" statement puzzling.
> 
> > So from what I understand this part is what you want:
> >
> > -   "%(trad_capable_cpp) -lang-asm %(cpp_options) -fno-directives-only\
> > +   "%(trad_capable_cpp) -lang-asm %(cpp_options) 
> > %{!E:-fno-directives-only} \
> >
> > Because -fno-directives-only is needed without -E.
> 
> Hm, wouldn't that still break the second invocation (-fpreprocessed
> -fdirectives-only)?
> 
> I think the correct fix is to remove -fno-directives-only altogether
> (provided the second issue is fixed, of course) leaving the user-specified
> -fdirectives-only to take effect regardless of the mode.

The documentation says specifically-fdirectives-only is ignored if
-fpreprocessed is supplied. So it will never break the second invocation.

[Bug libstdc++/105440] c++20: std::string's destructor not a constant expression when it should

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #2 from Patrick Palka  ---
Seems this is ultimately an FE bug which is fixed by:

diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc
index d1097764b10..9dbbf6eec03 100644
--- a/gcc/cp/constexpr.cc
+++ b/gcc/cp/constexpr.cc
@@ -3213,7 +3213,12 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree
t,
&& CLASS_TYPE_P (TREE_TYPE (res))
&& !is_empty_class (TREE_TYPE (res)))
  if (replace_decl (, res, ctx->object))
-   cacheable = false;
+   {
+ cacheable = false;
+ result = cxx_eval_constant_expression (ctx, result, lval,
+non_constant_p,
+overflow_p);
+   }
}
   else
/* Couldn't get a function copy to evaluate.  */

In some cases we can simplify a call result further after replacing RESULT_DECL
with the current object under construction throughout the call result, which
allows fold_binary_loc etc to later successfully fold comparisons involving the
call result such as _M_data() == _M_local_data() in this case.

[Bug ipa/107769] [12 Regression] -flto with -Os/-O2/-O3 emitted code with gcc 12.x segfaults via mutated global in .rodata since r12-2887-ga6da2cddcf0e959d

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

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

Martin Jambor  changed:

   What|Removed |Added

Summary|[12/13/14 Regression] -flto |[12 Regression] -flto with
   |with -Os/-O2/-O3 emitted|-Os/-O2/-O3 emitted code
   |code with gcc 12.x  |with gcc 12.x segfaults via
   |segfaults via mutated   |mutated global in .rodata
   |global in .rodata since |since
   |r12-2887-ga6da2cddcf0e959d  |r12-2887-ga6da2cddcf0e959d

--- Comment #9 from Martin Jambor  ---
This has been fixed on master just in time to get into gcc 13 RC.  Backport to
gcc-12 will follow.

[Bug ipa/109318] [12 Regression] csmith: -fipa-cp seems to cause trouble since r12-2523-g13586172d0b70c

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

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

Martin Jambor  changed:

   What|Removed |Added

Summary|[12/13/14 Regression]   |[12 Regression] csmith:
   |csmith: -fipa-cp seems to   |-fipa-cp seems to cause
   |cause trouble since |trouble since
   |r12-2523-g13586172d0b70c|r12-2523-g13586172d0b70c

--- Comment #12 from Martin Jambor  ---
This has been fixed on master just in time to get into gcc 13 RC.  Backport to
gcc-12 will follow.

[Bug target/109535] internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471

[pan2.li at intel dot com via Gcc-bugs]

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

Li Pan  changed:

   What|Removed |Added

 CC||pan2.li at intel dot com

--- Comment #6 from Li Pan  ---
(In reply to rsand...@gcc.gnu.org from comment #2)
> The assert in question fires if the pass creates an instruction
> whose pattern uses a register or memory and if the pass doesn't
> provide associated use information.  Let me know if it looks like
> a bug in rtl-ssa rather than a bug in the vsetvl pass.

Just sync with juzhe for the assertion failure. It tries to find the regno=8 in
the shared_uses=[0, 66, 67] in function_info::finalize_new_accesses. And then
it will hit the NOT_NULL assert.

While in the pass_vsetvl::cleanup_insns, it will clean up the AVL use similar
as below.

AVL regno 8
Before Uses Reg Nums => [0,8,66,67,]
After  Uses Reg Nums => [0,66,67,]

After vsetvl, the avl-related use, aka use Regno=8 will be removed, because the
instruction pattern in RVV will eliminate the dependencies of the operand.

Juzhe can help to correct me if any misleading or misunderstanding.

Thanks.

[Bug target/108910] [12 Regression] Further ICE in aarch64_layout_arg

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #20 from rsandifo at gcc dot gnu.org  
---
Backported to GCC 12 without the assert.

[Bug target/108910] [12 Regression] Further ICE in aarch64_layout_arg

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

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

--- Comment #19 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Sandiford
:

https://gcc.gnu.org/g:66700dde0dfb2c2b07d771f90df1fe16d1d61ce9

commit r12-9416-g66700dde0dfb2c2b07d771f90df1fe16d1d61ce9
Author: Richard Sandiford 
Date:   Mon Apr 17 14:41:00 2023 +0100

aarch64: Don't trust TYPE_ALIGN for pointers [PR108910]

The aarch64 PCS rules ignore user alignment for scalars and
vectors and use the "natural" alignment of the type.  GCC tried
to calculate that natural alignment using:

  TYPE_ALIGN (TYPE_MAIN_VARIANT (type))

But as discussed in the PR, it's possible that the main variant
of a pointer type is an overaligned type (although that's usually
accidental).

This isn't known to be a problem for other types, so this patch
changes the bare minimum.  It might be that we need to ignore
TYPE_ALIGN in other cases too.

gcc/
PR target/108910
* config/aarch64/aarch64.cc (aarch64_function_arg_alignment): Do
not trust TYPE_ALIGN for pointer types; use POINTER_SIZE instead.

gcc/testsuite/
PR target/108910
* gcc.dg/torture/pr108910.c: New test.

(cherry picked from commit 66946624b96b762985de56444d726a0ebd4e0df5)

[Bug middle-end/109537] Improve code generation for dynamic loop unrolling

[helijia.i at foxmail dot com via Gcc-bugs]

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

--- Comment #1 from Li Jia He  ---
Update gcc's assembly as gcc did not turn on auto vectorization during O2,
The compilation command for gcc is 'cc1 unroll.c -O3 -funroll-loops',
The compilation command for clang is 'clang unroll.c -O3 -S'
'''
$ cat unroll.gcc.s
.file   "unroll.c"
.text
.p2align 4
.globl  matrix_add_const
.type   matrix_add_const, @function
matrix_add_const:
.LFB0:
.cfi_startproc
movl%edi, %ecx
movl%edx, %edi
testl   %ecx, %ecx
jle .L1
leal-1(%rcx), %eax
cmpl$2, %eax
jbe .L6
movl%ecx, %r9d
movd%edx, %xmm2
movq%rsi, %r10
shrl$2, %r9d
pshufd  $0, %xmm2, %xmm0
salq$4, %r9
leaq(%r9,%rsi), %r8
subq$16, %r9
shrq$4, %r9
addq$1, %r9
andl$7, %r9d
je  .L4
cmpq$1, %r9
je  .L29
cmpq$2, %r9
je  .L30
cmpq$3, %r9
je  .L31
cmpq$4, %r9
je  .L32
cmpq$5, %r9
je  .L33
cmpq$6, %r9
jne .L45
.L34:
movdqu  (%r10), %xmm3
addq$16, %r10
paddd   %xmm0, %xmm3
movups  %xmm3, -16(%r10)
.L33:
movdqu  (%r10), %xmm4
addq$16, %r10
paddd   %xmm0, %xmm4
movups  %xmm4, -16(%r10)
.L32:
movdqu  (%r10), %xmm5
addq$16, %r10
paddd   %xmm0, %xmm5
movups  %xmm5, -16(%r10)
.L31:
movdqu  (%r10), %xmm6
addq$16, %r10
paddd   %xmm0, %xmm6
movups  %xmm6, -16(%r10)
.L30:
movdqu  (%r10), %xmm7
addq$16, %r10
paddd   %xmm0, %xmm7
movups  %xmm7, -16(%r10)
.L29:
movdqu  (%r10), %xmm8
addq$16, %r10
paddd   %xmm0, %xmm8
movups  %xmm8, -16(%r10)
cmpq%r8, %r10
je  .L43
.L4:
movdqu  (%r10), %xmm9
movdqu  16(%r10), %xmm10
subq$-128, %r10
movdqu  -96(%r10), %xmm11
movdqu  -80(%r10), %xmm12
movdqu  -64(%r10), %xmm13
paddd   %xmm0, %xmm9
paddd   %xmm0, %xmm10
movdqu  -48(%r10), %xmm14
movdqu  -32(%r10), %xmm15
movdqu  -16(%r10), %xmm2
paddd   %xmm0, %xmm11
paddd   %xmm0, %xmm12
paddd   %xmm0, %xmm13
paddd   %xmm0, %xmm14
movups  %xmm9, -128(%r10)
paddd   %xmm0, %xmm15
paddd   %xmm0, %xmm2
movups  %xmm10, -112(%r10)
movups  %xmm11, -96(%r10)
movups  %xmm12, -80(%r10)
movups  %xmm13, -64(%r10)
movups  %xmm14, -48(%r10)
movups  %xmm15, -32(%r10)
movups  %xmm2, -16(%r10)
cmpq%r8, %r10
jne .L4
.L43:
movl%ecx, %edx
andl$-4, %edx
testb   $3, %cl
je  .L46
.L3:
movslq  %edx, %r11
leal1(%rdx), %eax
salq$2, %r11
addl%edi, (%rsi,%r11)
cmpl%eax, %ecx
jle .L1
addl$2, %edx
addl%edi, 4(%rsi,%r11)
cmpl%edx, %ecx
jle .L1
addl%edi, 8(%rsi,%r11)
.L1:
ret
.p2align 4,,10
.p2align 3
.L46:
ret
.p2align 4,,10
.p2align 3
.L45:
movdqu  (%rsi), %xmm1
leaq16(%rsi), %r10
paddd   %xmm0, %xmm1
movups  %xmm1, (%rsi)
jmp .L34
.L6:
xorl%edx, %edx
jmp .L3
.cfi_endproc
.LFE0:
.size   matrix_add_const, .-matrix_add_const
.ident  "GCC: (GNU) 13.0.0 20221022 (experimental)"
.section.note.GNU-stack,"",@progbits
'''

[Bug target/109104] [13/14 Regression] ICE: in gen_reg_rtx, at emit-rtl.cc:1171 with -fzero-call-used-regs=all -march=rv64gv

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

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

Kito Cheng  changed:

   What|Removed |Added

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

--- Comment #7 from Kito Cheng  ---
Fixed on trunk

[Bug middle-end/109537] New: Improve code generation for dynamic loop unrolling

[helijia.i at foxmail dot com via Gcc-bugs]

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

Bug ID: 109537
   Summary: Improve code generation for dynamic loop unrolling
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: helijia.i at foxmail dot com
  Target Milestone: ---

For the current dynamic loop unrolling implementation, we will try to do the
followng transform:
'''
for (i = 0; i < n; i++)
 body;

   ==>  (LOOP->LPT_DECISION.TIMES == 3)

   i = 0;
   mod = n % 4;

   switch (mod)
 {
   case 3:
 body; i++;
   case 2:
 body; i++;
   case 1:
 body; i++;
   case 0: ;
 }

   while (i < n)
 {
   body; i++;
   body; i++;
   body; i++;
   body; i++;
 }
'''

It would be better if we could carry out loop unrolling in the following way (R
== # unrolls)

'''
i=0; if (i > n-R-1) goto remain (not needed with loop bounds as shown)
for(; i< n-R-1; i+= R)
  {
  body;
  body;
  ...
  body;  // R times
  }
remain:
if (i < n)
  for(; i < n; i++)
body
'''

For the following sample code:
'''
void matrix_add_const(int N1, int* A, int val)
{
  int i, j;
  for (j = 0; j < N1; j++)
A[j] += val;
}
'''

Gcc will generate more jump instructions compared to clang.

gcc's assemly
'''
$ cat unroll.gcc.s 
.file   "unroll.c"
.text
.p2align 4
.globl  matrix_add_const
.type   matrix_add_const, @function
matrix_add_const:
.LFB0:
.cfi_startproc
testl   %edi, %edi
jle .L1
movslq  %edi, %rdi
leaq-4(,%rdi,4), %rax
leaq(%rsi,%rdi,4), %rcx
shrq$2, %rax
addq$1, %rax
andl$7, %eax
je  .L3
cmpq$1, %rax
je  .L26
cmpq$2, %rax
je  .L27
cmpq$3, %rax
je  .L28
cmpq$4, %rax
je  .L29
cmpq$5, %rax
je  .L30
cmpq$6, %rax
jne .L41
.L31:
addl%edx, (%rsi)
addq$4, %rsi
.L30:
addl%edx, (%rsi)
addq$4, %rsi
.L29:
addl%edx, (%rsi)
addq$4, %rsi
.L28:
addl%edx, (%rsi)
addq$4, %rsi
.L27:
addl%edx, (%rsi)
addq$4, %rsi
.L26:
addl%edx, (%rsi)
addq$4, %rsi
cmpq%rcx, %rsi
je  .L42
.L3:
addl%edx, (%rsi)
addl%edx, 4(%rsi)
addl%edx, 8(%rsi)
addl%edx, 12(%rsi)
addl%edx, 16(%rsi)
addl%edx, 20(%rsi)
addl%edx, 24(%rsi)
addl%edx, 28(%rsi)
addq$32, %rsi
cmpq%rcx, %rsi
jne .L3
.L1:
ret
.p2align 4,,10
.p2align 3
.L41:
addl%edx, (%rsi)
addq$4, %rsi
jmp .L31
.L42:
ret
.cfi_endproc
.LFE0:
.size   matrix_add_const, .-matrix_add_const
.ident  "GCC: (GNU) 13.0.0 20221022 (experimental)"
.section.note.GNU-stack,"",@progbits
'''

clang's assembly
'''
$ cat unroll.clang.s 
.text
.file   "unroll.c"
.globl  matrix_add_const# -- Begin function matrix_add_const
.p2align4, 0x90
.type   matrix_add_const,@function
matrix_add_const:   # @matrix_add_const
.cfi_startproc
# %bb.0:
testl   %edi, %edi
jle .LBB0_11
# %bb.1:
movl%edi, %r9d
cmpl$8, %edi
jae .LBB0_3
# %bb.2:
xorl%ecx, %ecx
jmp .LBB0_10
.LBB0_3:
movl%r9d, %ecx
andl$-8, %ecx
movd%edx, %xmm0
pshufd  $0, %xmm0, %xmm0# xmm0 = xmm0[0,0,0,0]
leaq-8(%rcx), %rax
movq%rax, %rdi
shrq$3, %rdi
addq$1, %rdi
movl%edi, %r8d
andl$1, %r8d
testq   %rax, %rax
je  .LBB0_4
# %bb.5:
movq%r8, %rax
subq%rdi, %rax
xorl%edi, %edi
.p2align4, 0x90
.LBB0_6:# =>This Inner Loop Header: Depth=1
movdqu  (%rsi,%rdi,4), %xmm1
movdqu  16(%rsi,%rdi,4), %xmm2
movdqu  32(%rsi,%rdi,4), %xmm3
movdqu  48(%rsi,%rdi,4), %xmm4
paddd   %xmm0, %xmm1
paddd   %xmm0, %xmm2
movdqu  %xmm1, (%rsi,%rdi,4)
movdqu  %xmm2, 16(%rsi,%rdi,4)
paddd   %xmm0, %xmm3
paddd   %xmm0, %xmm4
movdqu  %xmm3, 32(%rsi,%rdi,4)
movdqu  %xmm4, 48(%rsi,%rdi,4)
addq$16, %rdi
addq$2, %rax
jne .LBB0_6
# %bb.7:
testq   %r8, %r8
je  .LBB0_9
.LBB0_8:
movdqu  (%rsi,%rdi,4), %xmm1
movdqu  16(%rsi,%rdi,4), %xmm2
paddd   %xmm0, %xmm1

[Bug tree-optimization/104515] [11/12/13 Regression] trivially-destructible destructors interfere with loop optimization - maybe related to lifetime-dse.

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

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

--- Comment #7 from Richard Biener  ---
(In reply to Richard Biener from comment #1)
> Confirmed.  The issue is that store motion of v_7(D)->end cannot be
> performed on
> 
>[local count: 955630225]:
>   # i_13 = PHI 
>   _1 = v_7(D)->end;
>   _2 = _1 + 18446744073709551612;
>   v_7(D)->end = _2;
>   MEM[(T *)_1 + -4B] ={v} {CLOBBER};   // <- inserted by -flifetime-dse
>   i_10 = i_13 + 1;
>   if (n_6(D) > i_10)
> goto ; [89.00%]
>   else
> goto ; [11.00%]
> 
>[local count: 850510901]:
>   goto ; [100.00%]

It's possible to perform store-motion of the above as the following,
preserving the CLOBBER in the loop but necessarily re-issueing the
last iteration CLOBBER on the exit edge.  I _think_ that's fine to do.
The oacc-kernels pipeline does LIM quite early before IPA.  For the
later LIM passes we might as well go with eliminating the non-decl
CLOBBERs earlier - but the issue also exists for decl CLOBBERs of course.

Note duplicating "lifetime" CLOBBERs might prove bad (we only have EOL
clobbers right now).

   [local count: 955630225]:
  # i_13 = PHI 
  # v__end_lsm.3_4 = PHI 
  _1 = v__end_lsm.3_4;
  _2 = _1 + 18446744073709551612;
  v__end_lsm.3_12 = _2;
  MEM[(int *)_1 + -4B] ={v} {CLOBBER};
  i_10 = i_13 + 1;
  if (n_6(D) > i_10)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 850510901]:
  goto ; [100.00%]

   [local count: 105119324]:
  # _17 = PHI <_1(3)>
  # v__end_lsm.3_19 = PHI 
  v_7(D)->end = v__end_lsm.3_19;
  MEM[(int *)_17 + -4B] ={v} {CLOBBER};

   [local count: 118111600]:
  return;

[Bug rtl-optimization/106594] [13 Regression] sign-extensions no longer merged into addressing mode

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2

--- Comment #24 from Jakub Jelinek  ---
.

[Bug c++/109531] [13 Regression] Checking ICE with hash table checking failed: equal operator returns true for a pair of values with a different hash value since r13-3292-gc2565a31c1622a

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

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

--- Comment #12 from Patrick Palka  ---
I suppose we're just neglecting to canonicalize a bound ttp's substituted args
before determining its canonical type.  Adding a call to coerce_template_parms
or canonicalize_type_argument seems to fix it:

diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index fcc8e0d1d57..5ff91414f69 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -16285,9 +16285,18 @@ tsubst (tree t, tree args, tsubst_flags_t complain,
tree in_decl)
  return error_mark_node;
tree argvec = tsubst (TI_ARGS (tinfo), args,
  complain, in_decl);
+   // this fixes it
+   tree tparms = DECL_INNERMOST_TEMPLATE_PARMS (tmpl);
+   argvec = coerce_template_parms (tparms, argvec,
+   tmpl, complain);
if (argvec == error_mark_node)
  return error_mark_node;

+   // or this
+   for (tree& arg : tree_vec_range (argvec))
+ if (TYPE_P (arg))
+   arg = canonicalize_type_argument (arg, complain);
+
TEMPLATE_TEMPLATE_PARM_TEMPLATE_INFO (r)
  = build_template_info (tmpl, argvec);
  }

[Bug libstdc++/109536] New: Failure to compile constexpr std::vector with -D_GLIBCXX_DEBUG

[terra at gnome dot org via Gcc-bugs]

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

Bug ID: 109536
   Summary: Failure to compile constexpr std::vector with
-D_GLIBCXX_DEBUG
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terra at gnome dot org
  Target Milestone: ---

Created attachment 54875
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54875=edit
Preprocessed source code

The following program fails to compile with -std=gnu++20 -D_GLIBCXX_DEBUG
due to the debug version of std::vector::~vector not being constexpr.

It compiles just fine without -D_GLIBCXX_DEBUG.  FWIW, clang 15 sees no problem
(without -D...) other than "farm" being unused.

-

#include 

constexpr int
foo ()
{
  std::vector v { 1, 2, 3 };
  return v.size();
}

constexpr int farm = foo ();

-

# /usr/local/products/gcc/12.1.0/bin/g++ -D_GLIBCXX_DEBUG  -std=gnu++20 -Wall
-c www.C
www.C: In function ‘constexpr int foo()’:
www.C:7:20: error: variable ‘v’ of non-literal type ‘std::__debug::vector’
in ‘constexpr’ function only available with ‘-std=c++2b’ or ‘-std=gnu++2b’
7 |   std::vector v { 1, 2, 3 };
  |^
In file included from
/usr/local/products/gcc/12.1.0/include/c++/12.1.0/vector:74,
 from www.C:1:
/usr/local/products/gcc/12.1.0/include/c++/12.1.0/debug/vector:117:11: note:
‘std::__debug::vector’ is not literal because:
  117 | class vector
  |   ^~
/usr/local/products/gcc/12.1.0/include/c++/12.1.0/debug/vector:117:11: note:  
‘std::__debug::vector’ does not have ‘constexpr’ destructor
www.C: At global scope:
www.C:11:26: error: ‘constexpr int foo()’ called in a constant expression
   11 | constexpr int farm = foo ();
  |  ^~
www.C:5:1: note: ‘constexpr int foo()’ declared here
5 | foo ()
  | ^~~

[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value

[leandro.lupori at linaro dot org via Gcc-bugs]

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

--- Comment #10 from Leandro Lupori  ---
Wouldn't it be better to turn this into a warning?

Although using the result of a function as an allocatable argument doesn't
conform with Fortran standards, it has been supported by gfortran for quite
some time. This change may break existing code.

[Bug rtl-optimization/106594] [13 Regression] sign-extensions no longer merged into addressing mode

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

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

--- Comment #23 from Jakub Jelinek  ---
This is just missed optimization and likely to be resolved only for GCC 14 and
perhaps later backported.  Downgrading to P2.

[Bug preprocessor/81745] missing warning with -pedantic when a C file does not end with a newline character [-Wnewline-eof]

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #14 from Vincent Lefèvre  ---
(In reply to Andrew Pinski from comment #13)
> GCC removed the pedwarning on purpose (between GCC 4.1 and 4.4), see PR
> 14331 and PR 68994. 

No, PR 14331 was just asking to remove the warning by default, not that
`-pedantic` shouldn't warn: "I checked through the gcc manual, and didn't found
any option to suppress the warning message "no newline at end of file".

And PR 68994 was complaining about the missing warning.

> https://gcc.gnu.org/legacy-ml/gcc-patches/2007-04/msg00651.html
> is the specific one about GCC's behavior and since it is considered
> undefined at compile time (not a runtime one) GCC behavior is correct so is
> clang

Even though GCC decides to add a newline to the logical file, so that the
missing diagnostic can be regarded as correct, I think that an optional warning
would be useful for portability.
https://gcc.gnu.org/legacy-ml/gcc-patches/2007-04/msg00651.html was suggesting
"add -W(no-)eof-newline". So why hasn't -Wno-eof-newline been added?

[Bug tree-optimization/109154] [13 regression] jump threading de-optimizes nested floating point comparisons

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P1  |P2

--- Comment #53 from Jakub Jelinek  ---
Downgrading to P2 for the rest of the changes which aren't appropriate for GCC
13.

[Bug ipa/107769] [12/13 Regression] -flto with -Os/-O2/-O3 emitted code with gcc 12.x segfaults via mutated global in .rodata since r12-2887-ga6da2cddcf0e959d

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

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

commit r13-7206-g8e08c7886eed5824bebd0e011526ec302d622844
Author: Martin Jambor 
Date:   Mon Apr 17 12:59:51 2023 +0200

ipa: Fix double reference-count decrements for the same edge (PR 107769, PR
109318)

It turns out that since addition of the code that can identify globals
which are only read from, the code that keeps track of the references
can decrement their count for the same calls, once during IPA-CP and
then again during inlining.  Fixed by adding a special flag to the
pass-through variant and simply wiping out the reference to the
refdesc structure from the constant ones.

Moreover, during debugging of the issue I have discovered that the
code removing references could remove a reference associated with the
same statement but of a wrong type.  In all cases it wanted to remove
an IPA_REF_ADDR reference so removing a lesser one instead should do
no harm in practice, but we should try to be consistent and so this
patch extends symtab_node::find_reference so that it searches for a
reference of a given type only.

gcc/ChangeLog:

2023-04-14  Martin Jambor  

PR ipa/107769
PR ipa/109318
* cgraph.h (symtab_node::find_reference): Add parameter use_type.
* ipa-prop.h (ipa_pass_through_data): New flag refdesc_decremented.
(ipa_zap_jf_refdesc): New function.
(ipa_get_jf_pass_through_refdesc_decremented): Likewise.
(ipa_set_jf_pass_through_refdesc_decremented): Likewise.
* ipa-cp.cc (ipcp_discover_new_direct_edges): Provide a value for
the new parameter of find_reference.
(adjust_references_in_caller): Likewise. Make sure the constant
jump
function is not used to decrement a refdec counter again.  Only
decrement refdesc counters when the pass_through jump function
allows
it.  Added a detailed dump when decrementing refdesc counters.
* ipa-prop.cc (ipa_print_node_jump_functions_for_edge): Dump new
flag.
(ipa_set_jf_simple_pass_through): Initialize the new flag.
(ipa_set_jf_unary_pass_through): Likewise.
(ipa_set_jf_arith_pass_through): Likewise.
(remove_described_reference): Provide a value for the new parameter
of
find_reference.
(update_jump_functions_after_inlining): Zap refdesc of new jfunc if
the previous pass_through had a flag mandating that we do so.
(propagate_controlled_uses): Likewise.  Only decrement refdesc
counters when the pass_through jump function allows it.
(ipa_edge_args_sum_t::duplicate): Provide a value for the new
parameter of find_reference.
(ipa_write_jump_function): Assert the new flag does not have to be
streamed.
* symtab.cc (symtab_node::find_reference): Add parameter use_type,
use
it in searching.

gcc/testsuite/ChangeLog:

2023-04-06  Martin Jambor  

PR ipa/107769
PR ipa/109318
* gcc.dg/ipa/pr109318.c: New test.
* gcc.dg/lto/pr107769_0.c: Likewise.

[Bug ipa/109318] [12/13 Regression] csmith: -fipa-cp seems to cause trouble since r12-2523-g13586172d0b70c

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

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

commit r13-7206-g8e08c7886eed5824bebd0e011526ec302d622844
Author: Martin Jambor 
Date:   Mon Apr 17 12:59:51 2023 +0200

ipa: Fix double reference-count decrements for the same edge (PR 107769, PR
109318)

It turns out that since addition of the code that can identify globals
which are only read from, the code that keeps track of the references
can decrement their count for the same calls, once during IPA-CP and
then again during inlining.  Fixed by adding a special flag to the
pass-through variant and simply wiping out the reference to the
refdesc structure from the constant ones.

Moreover, during debugging of the issue I have discovered that the
code removing references could remove a reference associated with the
same statement but of a wrong type.  In all cases it wanted to remove
an IPA_REF_ADDR reference so removing a lesser one instead should do
no harm in practice, but we should try to be consistent and so this
patch extends symtab_node::find_reference so that it searches for a
reference of a given type only.

gcc/ChangeLog:

2023-04-14  Martin Jambor  

PR ipa/107769
PR ipa/109318
* cgraph.h (symtab_node::find_reference): Add parameter use_type.
* ipa-prop.h (ipa_pass_through_data): New flag refdesc_decremented.
(ipa_zap_jf_refdesc): New function.
(ipa_get_jf_pass_through_refdesc_decremented): Likewise.
(ipa_set_jf_pass_through_refdesc_decremented): Likewise.
* ipa-cp.cc (ipcp_discover_new_direct_edges): Provide a value for
the new parameter of find_reference.
(adjust_references_in_caller): Likewise. Make sure the constant
jump
function is not used to decrement a refdec counter again.  Only
decrement refdesc counters when the pass_through jump function
allows
it.  Added a detailed dump when decrementing refdesc counters.
* ipa-prop.cc (ipa_print_node_jump_functions_for_edge): Dump new
flag.
(ipa_set_jf_simple_pass_through): Initialize the new flag.
(ipa_set_jf_unary_pass_through): Likewise.
(ipa_set_jf_arith_pass_through): Likewise.
(remove_described_reference): Provide a value for the new parameter
of
find_reference.
(update_jump_functions_after_inlining): Zap refdesc of new jfunc if
the previous pass_through had a flag mandating that we do so.
(propagate_controlled_uses): Likewise.  Only decrement refdesc
counters when the pass_through jump function allows it.
(ipa_edge_args_sum_t::duplicate): Provide a value for the new
parameter of find_reference.
(ipa_write_jump_function): Assert the new flag does not have to be
streamed.
* symtab.cc (symtab_node::find_reference): Add parameter use_type,
use
it in searching.

gcc/testsuite/ChangeLog:

2023-04-06  Martin Jambor  

PR ipa/107769
PR ipa/109318
* gcc.dg/ipa/pr109318.c: New test.
* gcc.dg/lto/pr107769_0.c: Likewise.

[Bug middle-end/109520] compiler never terminates with an inline-asm goto and an output with high register pressure

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #3 from Sam James  ---
(In reply to Richard Biener from comment #2)
> ISTR a duplicate.  We're looping in lra ()

My guess is PR109137.

[Bug c/68994] GCC doesn't issue any diagnostic for missing end-of-line marker

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

Vincent Lefèvre  changed:

   What|Removed |Added

 CC||vincent-gcc at vinc17 dot net

--- Comment #2 from Vincent Lefèvre  ---
(In reply to l3x from comment #1)
> Found a duplicate: #14331.
> 
> *** This bug has been marked as a duplicate of bug 14331 ***

PR 14331 is actually about the *opposite* behavior: the diagnostic has been
removed.

[Bug c++/109531] [13 Regression] Checking ICE with hash table checking failed: equal operator returns true for a pair of values with a different hash value since r13-3292-gc2565a31c1622a

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

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

--- Comment #11 from Jakub Jelinek  ---
Better don't reuse U for two different parameters:
template 
using A = int *;
template  class U>
struct B { typedef U  type; };
struct C { typedef int *type; };
template 
struct D {
  D  foo () { return D  (); }
  template  class V>
  V  bar ();
};
struct E { typedef int type; };
D > d;

The ICE is on
(gdb) p debug_tree (*entry)
 
unsigned DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea157b28>>
   index 0 level 1 orig_level 2
chain >
$14 = void
(gdb) p debug_tree (comparable)
 
unsigned DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea157b28>>
   index 0 level 1 orig_level 2
chain >
$15 = void
Both of these BOUND_TEMPLATE_TEMPLARE_PARMs are created in
#4  0x01462bbc in copy_node (node=) at ../../gcc/tree.cc:1334
#5  0x005d9d68 in copy_type (type=) at ../../gcc/cp/lex.cc:1067
#6  0x00767b5f in tsubst (t=, args=, complain=1,
in_decl=)
at ../../gcc/cp/pt.cc:16262
#7  0x00765155 in tsubst_function_type (t=,
args=, complain=1, in_decl=)
at ../../gcc/cp/pt.cc:15649
#8  0x007687af in tsubst (t=,
args=, complain=1, in_decl=) at ../../gcc/cp/pt.cc:16468
#9  0x0075afd2 in tsubst_function_decl (t=, args=, complain=1, lambda_fntype=)
at ../../gcc/cp/pt.cc:14419
#10 0x0075df67 in tsubst_template_decl (t=, args=, complain=1, lambda_fntype=)
at ../../gcc/cp/pt.cc:14730
#11 0x007613a1 in tsubst_decl (t=,
args=, complain=1) at ../../gcc/cp/pt.cc:14892
#12 0x00765f8e in tsubst (t=,
args=, complain=1, in_decl=) at
../../gcc/cp/pt.cc:15933
and
#4  0x01462bbc in copy_node (node=) at ../../gcc/tree.cc:1334
#5  0x005d9d68 in copy_type (type=) at ../../gcc/cp/lex.cc:1067
#6  0x00767b5f in tsubst (t=, args=, complain=1,
in_decl=)
at ../../gcc/cp/pt.cc:16262
#7  0x00765155 in tsubst_function_type (t=,
args=, complain=1, in_decl=)
at ../../gcc/cp/pt.cc:15649
#8  0x007687af in tsubst (t=,
args=, complain=1, in_decl=) at ../../gcc/cp/pt.cc:16468
#9  0x0075afd2 in tsubst_function_decl (t=, args=, complain=1, lambda_fntype=)
at ../../gcc/cp/pt.cc:14419
#10 0x0075df67 in tsubst_template_decl (t=, args=, complain=1, lambda_fntype=)
at ../../gcc/cp/pt.cc:14730
#11 0x007613a1 in tsubst_decl (t=,
args=, complain=1) at ../../gcc/cp/pt.cc:14892
#12 0x00765f8e in tsubst (t=,
args=, complain=1, in_decl=) at
../../gcc/cp/pt.cc:15933
The first one being bar instantiation with C arg, the latter with B arg.

When hashing those, the difference is in
if (TREE_CODE (t) == BOUND_TEMPLATE_TEMPLATE_PARM)
  val = iterative_hash_template_arg (TYPE_TI_ARGS (t), val);
which is a TREE_VEC containing
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea14f5e8 precision:32 min  max

pointer_to_this >
unsigned DI
size  constant 64>
unit-size  constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea157b28>
in one case and
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea14f5e8 precision:32 min  max

pointer_to_this >
unsigned DI
size  constant 64>
unit-size  constant 8>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea157b28>
in another.
In the second case it triggers
  if (tree ats = alias_template_specialization_p (arg, nt_transparent))
{
  // We want an alias specialization that survived strip_typedefs
  // to hash differently from its TYPE_CANONICAL, to avoid hash
  // collisions that compare as different in template_args_equal.
  // These could be dependent specializations that strip_typedefs
  // left alone, or untouched specializations because
  // coerce_template_parms returns the unconverted template
  // arguments if it sees incomplete argument packs.
  tree ti = TYPE_ALIAS_TEMPLATE_INFO (ats);
  return hash_tmpl_and_args (TI_TEMPLATE (ti), TI_ARGS (ti));
}
in iterative_hash_template_arg, while in the first case it doesn't and it gets
default:
  if (tree canonical = TYPE_CANONICAL (arg))
val = iterative_hash_object (TYPE_HASH (canonical), val);
and so they hash differently.  But apparently structural_comptypes thinks they
are equal.

[Bug target/109137] [12 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2

--- Comment #27 from Richard Biener  ---
The actual regression is fixed, the latent issue remains, I'm at least removing
P1 now.

[Bug c++/106740] [11/12 Regression] ICE in instantiate_decl at gcc/cp/pt.cc:26515 since r12-8467-ge057d454db4dcf

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

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

--- Comment #5 from Richard Biener  ---
Note this is P1 on the GCC 11 branch only.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 109434 Summary: [12 Regression] std::optional weird -Wmaybe-uninitialized 
and behaviour with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109434

   What|Removed |Added

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

[Bug tree-optimization/109434] [12 Regression] std::optional weird -Wmaybe-uninitialized and behaviour with -O2

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||12.2.1
 Resolution|--- |FIXED

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

[Bug tree-optimization/109491] [11 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail||11.3.0
 Resolution|--- |FIXED
  Known to work||11.3.1

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

[Bug tree-optimization/104450] [11 Regression] ICE: verify_flow_info failed: BB 2 cannot throw but has an EH edge with -O -fnon-call-exceptions -fsanitize=thread -mavx512f

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||11.3.0
  Known to work||11.3.1
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

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

[Bug target/105484] [11 Regression] ICE: verify_flow_info failed: BB 2 cannot throw but has an EH edge with -Os -march=cannonlake -fnon-call-exceptions -fno-tree-dce -fno-tree-forwprop since r11-5074-

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

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

commit r11-10632-gcaf0a30b17a639ee19ff4c138d3be0325d0be745
Author: Richard Biener 
Date:   Thu May 5 09:34:59 2022 +0200

tree-optimization/105484 - VEC_SET and EH

When the IL representation of VEC_SET is marked as throwing
(unnecessarily), we need to clean that when replacing it with
the .VEC_SET internal function call which cannot throw.

2022-05-05  Richard Biener  

PR tree-optimization/105484
* gimple-isel.cc (gimple_expand_vec_set_expr): Clean EH, return
whether the CFG changed.
(gimple_expand_vec_exprs): When the CFG changed, clean it up.

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

(cherry picked from commit e1a41143a2e24c65d94364fd82b165ff71a759d8)

[Bug target/105484] [11 Regression] ICE: verify_flow_info failed: BB 2 cannot throw but has an EH edge with -Os -march=cannonlake -fnon-call-exceptions -fno-tree-dce -fno-tree-forwprop since r11-5074-

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail||11.3.0
 Resolution|--- |FIXED
  Known to work||11.3.1

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

[Bug tree-optimization/104464] [12 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:268 with -O -fnon-call-exceptions -fno-tree-dce -fno-tree-forwprop -fsignaling-nans

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

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

commit r11-10631-gcfd4a86221bc647eaa1c418eb777499250804df6
Author: Richard Biener 
Date:   Wed Feb 9 14:52:24 2022 +0100

middle-end/104464 - ISEL and non-call EH #2

The following adjusts the earlier change to still allow an
uncritical replacement.

2022-02-09  Richard Biener  

PR middle-end/104464
* gimple-isel.cc (gimple_expand_vec_cond_expr): Postpone
throwing check to after unproblematic replacement.

* gcc.dg/pr104464.c: New testcase.

(cherry picked from commit 8f8f8c68b434eb32756284dd8e80cfbdff524a20)

[Bug tree-optimization/109434] [12 Regression] std::optional weird -Wmaybe-uninitialized and behaviour with -O2

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-9415-g3d2210dafd872e8470e2a6ae5eea74d2669bc055
Author: Richard Biener 
Date:   Tue Apr 11 15:06:59 2023 +0200

tree-optimization/109434 - bogus DSE of throwing call LHS

The byte tracking of call LHS didn't properly handle possibly
throwing calls correctly which cases bogus DSE and in turn, for the
testcase a bogus uninit diagnostic and (unreliable) wrong-code.

PR tree-optimization/109434
* tree-ssa-dse.cc (initialize_ao_ref_for_dse): Properly
handle possibly throwing calls when processing the LHS
and may-defs are not OK.  Add mode to initialize a may-def.
(dse_optimize_stmt): Query may-defs.

* g++.dg/opt/pr109434.C: New testcase.

[Bug tree-optimization/104450] [11 Regression] ICE: verify_flow_info failed: BB 2 cannot throw but has an EH edge with -O -fnon-call-exceptions -fsanitize=thread -mavx512f

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

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

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

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

commit r11-10630-g9dcc5d68cd935c9ff0ef023fe8b3bd7ab67d0687
Author: Richard Biener 
Date:   Wed Feb 9 09:11:28 2022 +0100

middle-end/104450 - ISEL and non-call EH

The following avoids merging a vector compare with EH with a
VEC_COND_EXPR.  We should be able to do fallback expansion and if
we really are for the optimization we need quite some shuffling
to arrange for the proper EH redirection in all cases, IMHO not
worth it.

2022-02-09  Richard Biener  

PR middle-end/104450
* gimple-isel.cc: Pass cfun around.
(+gimple_expand_vec_cond_expr): Do not combine a throwing
comparison with the select.

* g++.dg/torture/pr104450.C: New testcase.

(cherry picked from commit 871afdc512be0510cbd4fa0928e5a1bd0681766e)

[Bug tree-optimization/109491] [11 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

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

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

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

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

commit r11-10629-gbb400f9916beab1a650d59c73672ef48aaf71b11
Author: Richard Biener 
Date:   Thu Apr 13 14:09:30 2023 +0200

tree-optimization/109491 - ICE in expressions_equal_p

At some point I elided the NULL pointer check in expressions_equal_p
because it shouldn't be necessary not realizing that for example
TARGET_MEM_REF has optional operands we cannot substitute with
something non-NULL with the same semantics.  The following does the
simple thing and restore the check removed in r11-4982.

PR tree-optimization/109491
* tree-ssa-sccvn.c (expressions_equal_p): Restore the
NULL operands test.

(cherry picked from commit a37783de23c067d6a26374ff29c014e49604035c)

[Bug target/109535] internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471

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

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

--- Comment #5 from Kito Cheng  ---
Confirmed the the output is text file, it's just suffixed with .out

[Bug c++/109531] [13 Regression] Checking ICE with hash table checking failed: equal operator returns true for a pair of values with a different hash value since r13-3292-gc2565a31c1622a

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/109531] [13 Regression] Checking ICE with hash table checking failed: equal operator returns true for a pair of values with a different hash value since r13-3292-gc2565a31c1622a

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

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

--- Comment #10 from Jakub Jelinek  ---
Slightly cleaned up:

template 
using A = int *;
template  class U>
struct B { typedef U  type; };
struct C { typedef int *type; };
template 
struct D {
  D  foo () { return D  (); }
  template  class U>
  U  bar ();
};
struct E { typedef int type; };
D > d;

As no floating point types are involved, I think this had to be latent before.

[Bug target/109535] internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #4 from JuzheZhong  ---
(In reply to Mathieu Malaterre from comment #1)
> Created attachment 54874 [details]
> preprocessed source
> 
> % gcc-13 --version
> gcc-13 (Debian 13-20230411-1) 13.0.1 20230411 (experimental) [master
> r13-7137-gb8e32978e3d]

Hi, it seems that your attatchment is an excution file instead of 
a source code. It may not be easy for us to debug it.

Can you give me the source code? Thanks.

[Bug tree-optimization/109502] [11 Regression] wrong code with -O -ftree-vectorize -fvect-cost-model=unlimited on aarch64

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|12.3|11.4
  Known to work||12.2.1
Summary|[12 Regression] wrong code  |[11 Regression] wrong code
   |with -O -ftree-vectorize|with -O -ftree-vectorize
   |-fvect-cost-model=unlimited |-fvect-cost-model=unlimited
   |on aarch64  |on aarch64
  Known to fail|12.2.1  |12.2.0

--- Comment #8 from Richard Biener  ---
Also picks to 11.

[Bug c++/109531] [13 Regression] Checking ICE with hash table checking failed: equal operator returns true for a pair of values with a different hash value since r13-3292-gc2565a31c1622a

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
Summary|Checking ICE with  hash |[13 Regression] Checking
   |table checking failed:  |ICE with  hash table
   |equal operator returns true |checking failed: equal
   |for a pair of values with a |operator returns true for a
   |different hash value|pair of values with a
   ||different hash value since
   ||r13-3292-gc2565a31c1622a

--- Comment #9 from Martin Liška  ---
Started with r13-3292-gc2565a31c1622a.

[Bug target/109535] internal compiler error: in finalize_new_accesses, at rtl-ssa/changes.cc:471

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

--- Comment #3 from JuzheZhong  ---
Thanks for reporting it. We will take a look at it.

[Bug tree-optimization/109469] [12 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2) when building xdvik

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug ipa/105676] [12 Regression] Bogus `-Wsuggest-attribute=pure` on function marked `__attribute__((const))` since r12-5437-g09a4ffb72aa2f513

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to work||12.2.1
 Status|ASSIGNED|RESOLVED

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

[Bug tree-optimization/109219] [12 Regression] csmith: ice in vect_slp_analyze_node_operations_1, at tree-vect-slp.cc:5954 since r13-1106-g8c2733e16ec1c0cd

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

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

Richard Biener  changed:

   What|Removed |Added

 Resolution|--- |FIXED
  Known to work||12.2.1
 Status|ASSIGNED|RESOLVED

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

[Bug tree-optimization/109473] [10/11/12 Regression] ICE during GIMPLE pass: vect: verify_gimple failed with -O1 -ftree-loop-vectorize since r10-4076-g82e8e335f917b9

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:053668dbf11bb61c63fa7db5b3bccd0fdac9e726

commit r12-9412-g053668dbf11bb61c63fa7db5b3bccd0fdac9e726
Author: Richard Biener 
Date:   Wed Apr 12 10:22:08 2023 +0200

tree-optimization/109473 - ICE with reduction epilog adjustment op

The following makes sure to carry out the reduction epilog adjustment
in the original computation type which for pointers is an unsigned
integer type.  There's a similar issue with signed vs. unsigned ops
and overflow which is fixed by this as well.

PR tree-optimization/109473
* tree-vect-loop.cc (vect_create_epilog_for_reduction):
Convert scalar result to the computation type before performing
the reduction adjustment.

* gcc.dg/vect/pr109473.c: New testcase.

(cherry picked from commit df7f55cb2ae550adeda339a57b657ebe1ad39367)

[Bug tree-optimization/109469] [12 regression] ICE: internal compiler error: verify_flow_info failed (error: returns_twice call is not first in basic block 2) when building xdvik

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

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

commit r12-9411-g9cc16b95d5d63b18cbc0aa780ffb6b460c791351
Author: Richard Biener 
Date:   Tue Apr 11 16:06:12 2023 +0200

tree-optimization/109469 - SLP with returns-twice region start

The following avoids an SLP region starting with a returns-twice
call where we cannot insert stmts at the head.

PR tree-optimization/109469
* tree-vect-slp.cc (vect_slp_function): Skip region starts with
a returns-twice call.

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

(cherry picked from commit 2d7ad38707e1fd71193d440198cc0726092b9015)

[Bug tree-optimization/109502] [12 Regression] wrong code with -O -ftree-vectorize -fvect-cost-model=unlimited on aarch64

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:08605396d164c57eb3c80051001b86b96da0405c

commit r12-9414-g08605396d164c57eb3c80051001b86b96da0405c
Author: Richard Biener 
Date:   Fri Apr 14 09:55:27 2023 +0200

tree-optimization/109502 - vector conversion between mask and non-mask

The following fixes a check that should have rejected vectorizing
a conversion between a mask and non-mask type.  Those should be
done via pattern statements.

PR tree-optimization/109502
* tree-vect-stmts.cc (vectorizable_assignment): Fix
check for conversion between mask and non-mask types.

* gcc.dg/vect/pr109502.c: New testcase.

(cherry picked from commit bf24f2db2841b97bc5e86bf9294d61eef32f83b3)

[Bug lto/109263] [10/11/12 Regression] '-g0 -ggdb -flto' gives linker error

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

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

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

https://gcc.gnu.org/g:42b3d387f7335a4bc8846e3b7a2a78fb47be68b2

commit r12-9410-g42b3d387f7335a4bc8846e3b7a2a78fb47be68b2
Author: Richard Biener 
Date:   Thu Mar 23 16:56:53 2023 +0100

lto/109263 - lto-wrapper and -g0 -ggdb

The following makes lto-wrapper deal with non-combined debug
disabling / enabling option combinations properly.  Interestingly
-gno-dwarf also enables debug.

PR lto/109263
* lto-wrapper.cc (run_gcc): Parse alternate debug options
as well, they always enable debug.

(cherry picked from commit 4cbd5ef0350d8ab04993eb4c48ab80999fb4f358)

[Bug tree-optimization/109491] [11/12 Regression] Segfault in tree-ssa-sccvn.cc:expressions_equal_p()

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

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

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

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

commit r12-9413-gba02c6706cc502ee64b9c5d32b08409c44fe967d
Author: Richard Biener 
Date:   Thu Apr 13 14:09:30 2023 +0200

tree-optimization/109491 - ICE in expressions_equal_p

At some point I elided the NULL pointer check in expressions_equal_p
because it shouldn't be necessary not realizing that for example
TARGET_MEM_REF has optional operands we cannot substitute with
something non-NULL with the same semantics.  The following does the
simple thing and restore the check removed in r11-4982.

PR tree-optimization/109491
* tree-ssa-sccvn.cc (expressions_equal_p): Restore the
NULL operands test.

(cherry picked from commit a37783de23c067d6a26374ff29c014e49604035c)

[Bug tree-optimization/109219] [12 Regression] csmith: ice in vect_slp_analyze_node_operations_1, at tree-vect-slp.cc:5954 since r13-1106-g8c2733e16ec1c0cd

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

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

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

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

commit r12-9409-gc2ab46f377313da5336748eb4fdc20020c047445
Author: Richard Biener 
Date:   Tue Mar 21 12:49:36 2023 +0100

tree-optimization/109219 - avoid looking at STMT_SLP_TYPE

The following avoids looking at STMT_SLP_TYPE apart from the only
place needing it - transform and analysis of non-SLP loop stmts.
In particular it doesn't have a reliable meaning on SLP representatives
which are also passed as stmt_vinfo to vectorizable_* routines.  The
proper way to check in those is to look for the slp_node argument
instead.

PR tree-optimization/109219
* tree-vect-loop.cc (vectorizable_reduction): Check
slp_node, not STMT_SLP_TYPE.
* tree-vect-stmts.cc (vectorizable_condition): Likewise.
* tree-vect-slp.cc (vect_slp_analyze_node_operations_1):
Remove assertion on STMT_SLP_TYPE.

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

(cherry picked from commit 26adc870e3675591050f37edab46850b97a3c122)

[Bug ipa/106124] [11/12 Regression] ICE in dwarf2out_abstract_function, at dwarf2out.cc:23254

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:377efe66243a3ec9d44707e3526742aa3d924094

commit r12-9408-g377efe66243a3ec9d44707e3526742aa3d924094
Author: Richard Biener 
Date:   Mon Mar 27 16:40:15 2023 +0200

ipa/106124 - ICE with -fkeep-inline-functions and OpenMP

The testcases in this bug reveal cases where an early generated
type is collected because it was unused but gets attempted to
be recreated later when a late DIE for a function (an OpenMP
reduction) is created.  That's unexpected and possibly the fault
of OpenMP but the following allows the re-creation of the context
type to succeed.

PR ipa/106124
* dwarf2out.cc (lookup_type_die): Reset TREE_ASM_WRITTEN
so we can re-create the DIE for the type if required.

* g++.dg/gomp/pr106124.C: New testcase.

(cherry picked from commit 36330e2e95564a360e6dbcfb4e7566d5c2177415)

[Bug ipa/105676] [12 Regression] Bogus `-Wsuggest-attribute=pure` on function marked `__attribute__((const))` since r12-5437-g09a4ffb72aa2f513

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

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

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

https://gcc.gnu.org/g:96785885ceed34638d4b58e88cba6e6e8368c0e3

commit r12-9407-g96785885ceed34638d4b58e88cba6e6e8368c0e3
Author: Richard Biener 
Date:   Wed Dec 7 10:26:01 2022 +0100

ipa/105676 - pure attribute suggestion for const function

When a function is declared const (even though it technically
accesses memory), ipa-modref discovering pureness shouldn't end
up suggesting that attribute.  The following thus exempts
'const' functions from ipa_make_function_pure handling.

PR ipa/105676
* ipa-pure-const.cc (ipa_make_function_pure): Skip also
for functions already being const.

* gcc.dg/pr105676.c: New testcase.

(cherry picked from commit 45e09c2eb9c2bdd34ef777e06ddc9908dd0664f9)

[Bug target/108807] [11/12 regression] gcc.target/powerpc/vsx-builtin-10d.c fails after r11-6857-gb29225597584b6 on power 9 BE

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

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #10 from Kewen Lin  ---
Fixed on trunk and related release branches.

[Bug target/108699] gcc.c-torture/execute/builtin-bitops-1.c fails on power 9 BE

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Kewen Lin :

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

commit r10-11291-gd88e488ec9321e44291fcaf2a3b14333f64aac01
Author: Kewen Lin 
Date:   Mon Apr 3 21:47:44 2023 -0500

rs6000: Fix vector parity support [PR108699]

The failures on the original failed case builtin-bitops-1.c
and the associated test case pr108699.c here show that the
current support of parity vector mode is wrong on Power.
The hardware insns vprtyb[wdq] which operate on the least
significant bit of each byte per element, they doesn't match
what RTL opcode parity needs, but the current implementation
expands it with them wrongly.

This patch is to fix the handling with one more insn vpopcntb.

PR target/108699

gcc/ChangeLog:

* config/rs6000/altivec.md (*p9v_parity2): Rename to ...
(rs6000_vprtyb2): ... this.
* config/rs6000/rs6000-builtin.def (VPRTYBD): Replace parityv2di2
with
rs6000_vprtybv2di2.
(VPRTYBW): Replace parityv4si2 with rs6000_vprtybv4si2.
(VPRTYBQ): Replace parityv1ti2 with rs6000_vprtybv1ti2.
* config/rs6000/vector.md (parity2 with VEC_IP): Expand with
popcountv16qi2 and the corresponding rs6000_vprtyb2.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/p9-vparity.c: Add scan-assembler-not for
vpopcntb
to distinguish parity byte from parity.
* gcc.target/powerpc/pr108699.c: New test.

(cherry picked from commit cdd2d6643f7fef40e335a7027edfea7276cde608)

[Bug target/108699] gcc.c-torture/execute/builtin-bitops-1.c fails on power 9 BE

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:6872f055d7d4fd36b804bdd9b5a8a128b01aacbc

commit r11-10628-g6872f055d7d4fd36b804bdd9b5a8a128b01aacbc
Author: Kewen Lin 
Date:   Sun Apr 16 22:31:01 2023 -0500

rs6000: Fix vector parity support [PR108699]

The failures on the original failed case builtin-bitops-1.c
and the associated test case pr108699.c here show that the
current support of parity vector mode is wrong on Power.
The hardware insns vprtyb[wdq] which operate on the least
significant bit of each byte per element, they doesn't match
what RTL opcode parity needs, but the current implementation
expands it with them wrongly.

This patch is to fix the handling with one more insn vpopcntb.

PR target/108699

gcc/ChangeLog:

* config/rs6000/altivec.md (*p9v_parity2): Rename to ...
(rs6000_vprtyb2): ... this.
* config/rs6000/rs6000-builtin.def (VPRTYBD): Replace parityv2di2
with
rs6000_vprtybv2di2.
(VPRTYBW): Replace parityv4si2 with rs6000_vprtybv4si2.
(VPRTYBQ): Replace parityv1ti2 with rs6000_vprtybv1ti2.
* config/rs6000/vector.md (parity2 with VEC_IP): Expand with
popcountv16qi2 and the corresponding rs6000_vprtyb2.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/p9-vparity.c: Add scan-assembler-not for
vpopcntb
to distinguish parity byte from parity.
* gcc.target/powerpc/pr108699.c: New test.

(cherry picked from commit cdd2d6643f7fef40e335a7027edfea7276cde608)

[Bug target/108807] [11/12 regression] gcc.target/powerpc/vsx-builtin-10d.c fails after r11-6857-gb29225597584b6 on power 9 BE

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:043cc707f449076ea704a12fff60e32f5861dfcb

commit r11-10627-g043cc707f449076ea704a12fff60e32f5861dfcb
Author: Kewen Lin 
Date:   Mon Apr 3 21:47:54 2023 -0500

rs6000: Fix vector_set_var_p9 by considering BE [PR108807]

As PR108807 exposes, the current handling in function
rs6000_expand_vector_set_var_p9 doesn't take care of big
endianness.  Currently the function is to rotate the
target vector by moving element to-be-set to element 0,
set element 0 with the given val, then rotate back.  To
get the permutation control vector for the rotation, it
makes use of lvsr and lvsl, but the element ordering is
different for BE and LE (like element 0 is the most
significant one on BE while the least significant one on
LE), this patch is to add consideration for BE and make
sure permutation control vectors for rotations are expected.

As tested, it helped to fix the below failures:

FAIL: gcc.target/powerpc/pr79251-run.p9.c execution test
FAIL: gcc.target/powerpc/pr89765-mc.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-10d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-11d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-14d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-16d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-18d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-9d.c execution test
PR target/108807

gcc/ChangeLog:

* config/rs6000/rs6000.c (rs6000_expand_vector_set_var_p9): Fix gen
function for permutation control vector by considering big
endianness.

(cherry picked from commit d634e6088f139ee700d79ec73b1ad6436096a6ff)

[Bug target/108699] gcc.c-torture/execute/builtin-bitops-1.c fails on power 9 BE

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

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

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

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

commit r12-9406-gde8f86e151d29c6c2ebb224b5587284714cd6cfa
Author: Kewen Lin 
Date:   Mon Apr 3 21:47:44 2023 -0500

rs6000: Fix vector parity support [PR108699]

The failures on the original failed case builtin-bitops-1.c
and the associated test case pr108699.c here show that the
current support of parity vector mode is wrong on Power.
The hardware insns vprtyb[wdq] which operate on the least
significant bit of each byte per element, they doesn't match
what RTL opcode parity needs, but the current implementation
expands it with them wrongly.

This patch is to fix the handling with one more insn vpopcntb.

PR target/108699

gcc/ChangeLog:

* config/rs6000/altivec.md (*p9v_parity2): Rename to ...
(rs6000_vprtyb2): ... this.
* config/rs6000/rs6000-builtins.def (VPRTYBD): Replace parityv2di2
with
rs6000_vprtybv2di2.
(VPRTYBW): Replace parityv4si2 with rs6000_vprtybv4si2.
(VPRTYBQ): Replace parityv1ti2 with rs6000_vprtybv1ti2.
* config/rs6000/vector.md (parity2 with VEC_IP): Expand with
popcountv16qi2 and the corresponding rs6000_vprtyb2.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/p9-vparity.c: Add scan-assembler-not for
vpopcntb
to distinguish parity byte from parity.
* gcc.target/powerpc/pr108699.c: New test.

(cherry picked from commit cdd2d6643f7fef40e335a7027edfea7276cde608)

[Bug target/108807] [11/12 regression] gcc.target/powerpc/vsx-builtin-10d.c fails after r11-6857-gb29225597584b6 on power 9 BE

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Kewen Lin :

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

commit r12-9405-gd39451523912981e897faa7942a2634c058524fb
Author: Kewen Lin 
Date:   Mon Apr 3 21:47:54 2023 -0500

rs6000: Fix vector_set_var_p9 by considering BE [PR108807]

As PR108807 exposes, the current handling in function
rs6000_expand_vector_set_var_p9 doesn't take care of big
endianness.  Currently the function is to rotate the
target vector by moving element to-be-set to element 0,
set element 0 with the given val, then rotate back.  To
get the permutation control vector for the rotation, it
makes use of lvsr and lvsl, but the element ordering is
different for BE and LE (like element 0 is the most
significant one on BE while the least significant one on
LE), this patch is to add consideration for BE and make
sure permutation control vectors for rotations are expected.

As tested, it helped to fix the below failures:

FAIL: gcc.target/powerpc/pr79251-run.p9.c execution test
FAIL: gcc.target/powerpc/pr89765-mc.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-10d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-11d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-14d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-16d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-18d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-9d.c execution test
PR target/108807

gcc/ChangeLog:

* config/rs6000/rs6000.cc (rs6000_expand_vector_set_var_p9): Fix
gen
function for permutation control vector by considering big
endianness.

(cherry picked from commit d634e6088f139ee700d79ec73b1ad6436096a6ff)