[Bug c++/106572] A programmatic list of all possible compiler warnings

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

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

--- Comment #7 from Richard Biener  ---
There's also -Wfoo={1,2,3} and the like, not sure what "everything" would be
here?  The "strictest" level (if the levels order by strictness?)

[Bug rtl-optimization/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

[malat at debian dot org via Gcc-bugs]

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

--- Comment #51 from Mathieu Malaterre  ---
(In reply to Richard Earnshaw from comment #50)
> Fixed on master so far.

Not clear how this is possible. I reported an issue against gcc-11 which could
not be reproduced using gcc-12. Are you saying the issue crept back in gcc-13.x
?

[Bug rtl-optimization/106187] armhf: Miscompilation at O2 level (O0 / O1 are working)

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

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

--- Comment #52 from Andrew Pinski  ---
(In reply to Mathieu Malaterre from comment #51)
> (In reply to Richard Earnshaw from comment #50)
> > Fixed on master so far.
> 
> Not clear how this is possible. I reported an issue against gcc-11 which
> could not be reproduced using gcc-12. Are you saying the issue crept back in
> gcc-13.x ?

The bug became latent in gcc 12.1.0 and on the trunk. The real fix for the
problem is on the trunk now.

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

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

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

--- Comment #4 from Richard Biener  ---
(In reply to Michael Hudson-Doyle from comment #3)
> Certainly this could be "handled" by bumping the tolerance I guess. Not sure
> how to tell if that is appropriate though...

You have to look what GCC actually does, like if it is constant folding as
suggested or sth else.

[Bug other/106575] new test case gcc.dg/fold-eqandshift-4.c fails with its introduction in r13-2005-g6fc14f1963dfef

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug fortran/104382] Finalization of parent components not compliant with standard

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

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #4 from Thomas Koenig  ---
To add some variety to the tests, nagfor gives

 destructor4(complicated)   2.000   2.000
 destructor5 (simple2) 5
 destructor5 (simple2) 6
 destructor2(simple) 1 1
 final_count after assignment =  4
 destructor4(complicated)   4.000   5.000
 destructor5 (simple2) -1
 destructor5 (simple2) -2
 destructor2(simple) 3 4
 final_count after deallocation =  8

[Bug middle-end/106504] [OpenMP] 'for simd linear(i:1)' should be rejected with 'parallel private(i)'

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

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

--- Comment #1 from Jakub Jelinek  ---
There have been discussions about this in several F2Fs.
For linear it is desirable to allow private outer var because linear
is the implicit behavior of simd iterators and people want to be able to use
them
even if they are private outer (say even simple
void foo (int *a) { int i;
#pragma omp simd
for (i = 0; i < 16; i++)
a[i] = i;
}
would be then invalid).
Some people wanted to just drop the requirements even for lastprivate etc.
(silently not assign to outer var).

[Bug fortran/106576] New: Finalization of temporaries from functions not occuring

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

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

Bug ID: 106576
   Summary: Finalization of temporaries from functions not
occuring
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Test case:

$ cat g2.f90
module y
  implicit none
  type foo
 integer :: n
   contains
 final :: cleanup
  end type foo
  interface assignment (=)
 module procedure assign
  end interface assignment (=)
contains

  subroutine assign (rop, op)
type(foo), intent(inout) :: rop
type(foo), intent(in) :: op
rop%n = op%n + 1
print '(A12,I3)',"assign", rop%n
  end subroutine assign

  function to_foo(n) result(res)
integer, intent(in) :: n
type (foo) :: res
res%n = n
print '(A12,I3)', "to_foo", res%n
  end function to_foo

  subroutine cleanup (self)
type (foo), intent(inout) :: self
print '(A12,I3)', "cleanup", self%n
  end subroutine cleanup
end module y

program memain
  use y
  implicit none
  call chk
contains
  subroutine chk
type (foo) :: a
a = to_foo(3)
  end subroutine chk
end program memain
$ gfortran g2.f90 && ./a.out
  to_foo  3
  assign  4
 cleanup  4
$ nagfor g2.f90 && ./a.out
NAG Fortran Compiler Release 7.1(Hanzomon) Build 7101
[NAG Fortran Compiler normal termination]
  to_foo  3
  assign  4
 cleanup  3
 cleanup  4

NAG is in fact correct, the temporary from the function results should also
be finalized.

This actually blocks my little FMPFR library, so I might have a stab
at this myself.

[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow

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

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

--- Comment #3 from Jakub Jelinek  ---
Looks like a bug in the sanopt pass.
For -O2, we have before sanopt in main:
  b.0_1 = b;
  e.2_3 = e;
  c.5_4 = c;
  .ASAN_CHECK (7, c.5_4, 8, 8);
  *c.5_4 = e.2_3;
  b.7_5 = b;
  .ASAN_CHECK (7, b.7_5, 4, 4);
  *b.7_5 = 2;
  .ASAN_CHECK (7, b.0_1, 4, 4);
  *b.0_1 = 2;
  return 2;
and in sanopt:
Leaving: .ASAN_CHECK (7, c.5_4, 8, 8);
Leaving: .ASAN_CHECK (7, b.7_5, 4, 4);
Optimizing out: .ASAN_CHECK (7, b.0_1, 4, 4);
Expanded: .ASAN_CHECK (7, c.5_4, 8, 8);
Expanded: .ASAN_CHECK (7, b.7_5, 4, 4);
Even that is incorrect, we don't generally know what b points to before the *c
store and after it, so neither of the stores is redundant because *c store can
change the value of b.
At -O1 we have before sanopt:
  b.0_1 = b;
  e.2_6 = e;
  e.3_7 = (long int) e.2_6;
  _9 = (int) e.3_7;
  .ASAN_CHECK (7, b.0_1, 4, 4);
  *b.0_1 = _9;
  c.5_10 = c;
  e.6_11 = e;
  .ASAN_CHECK (7, c.5_10, 8, 8);
  *c.5_10 = e.6_11;
  b.7_12 = b;
  .ASAN_CHECK (7, b.7_12, 4, 4);
  *b.7_12 = 2;
  *b.0_1 = 2;
  b.1_2 = b;
  .ASAN_CHECK (6, b.1_2, 4, 4);
  _5 = *b.1_2;
  return _5;
because we optimize less at that optimization level, and sanopt:
Leaving: .ASAN_CHECK (7, b.0_1, 4, 4);
Leaving: .ASAN_CHECK (7, c.5_10, 8, 8);
Optimizing out: .ASAN_CHECK (7, b.7_12, 4, 4);
Optimizing out: .ASAN_CHECK (6, b.1_2, 4, 4);
Expanded: .ASAN_CHECK (7, b.0_1, 4, 4);
Expanded: .ASAN_CHECK (7, c.5_10, 8, 8);
The b.1_2 .ASAN_CHECK is IMHO redundant (b couldn't change between b.7_12 = b
and b.1_2 = b;) but the b.7_12 .ASAN_CHECK is not redundant.

[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||ygribov at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
This is due to the
https://gcc.gnu.org/legacy-ml/gcc-patches/2014-12/msg00242.html
r5-5530-ge28f2090dbbb5072 optimization, which is incorrect.
If we want to track pointers which live in memory, we'd need to ask the alias
oracle on each store or call whether the store or call couldn't change the
value of such a pointer and if yes, invalidate them.
Not really sure it is worth it though.

[Bug tree-optimization/106322] [12/13 Regression] tree-vectorize: Wrong code at O2 level (-fno-tree-vectorize is working) since r12-2404-ga1d27560770818c5

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

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

--- Comment #41 from Kewen Lin  ---
(In reply to Kewen Lin from comment #40)
> > >diff --git a/gcc/internal-fn.cc b/gcc/internal-fn.cc
> > >index d666f67..7d8b4ac2200 100644
> > >--- a/gcc/internal-fn.cc
> > >+++ b/gcc/internal-fn.cc
> > >@@ -3750,7 +3750,12 @@ static bool
> > > direct_optab_supported_p (direct_optab optab, tree_pair types,
> > > optimization_type opt_type)
> > > {
> > >-  machine_mode mode = TYPE_MODE (types.first);
> > >+  tree type = types.first;
> > >+  machine_mode mode = TYPE_MODE (type);
> > >+  /* Scalar mode optab can't work for vector type, return false if
> > >+ the given type is vector type but the mode isn't vector mode.  */
> > >+  if (VECTOR_TYPE_P (type) != VECTOR_MODE_P (mode))
> > >+return false;
> > 
> > There are a few which scalar mode and vector types can differ and still
> > work: IOR, XOR, and AND. I wonder if those should be special cased here or
> > somewhere else.
> 
> Good point! This is overkill then. Not sure if there is this kind of routine
> to special case them.

When I was cooking one function to special case Andrew's concerns, I realized
that the touched functions direct_optab_supported_p, convert_optab_supported_p
and multi_vector_optab_supported_p are only for optabs used in internal-fn.def,
for now there are not {and,ior,xor}_optab or their similars (I quickly went
through binary/unary ones). So it seems we don't need to consider this for now?

[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow

[tetra2005 at gmail dot com via Gcc-bugs]

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

Yuri Gribov  changed:

   What|Removed |Added

 CC||tetra2005 at gmail dot com

--- Comment #5 from Yuri Gribov  ---
Ok, seems my 2014 patch will need to be reverted then. Do you want me to submit
a PR?

[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow

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

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

--- Comment #6 from Jakub Jelinek  ---
Or perhaps could we ask the alias oracle in can_remove_asan_check
for the *base_checks case if base_addr lives in memory whether base_addr could
change in between the stmt in the vector and current stmt, with some low limit
on  how much we walk to find that out?

[Bug sanitizer/106558] ASan failed to detect a global-buffer-overflow

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

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

--- Comment #7 from Jakub Jelinek  ---
Perhaps either a quick check that for base ptrs that live in memory gimple_vuse
is the same for both statements or if not, do walk_aliased_vdefs with low
constant limit?
We'd want to stop if we reach the vdef of the stmt in base_checks vector (then
we didn't find anything that could clobber it and can therefore use the cached
check) or when we see a stmt that may clobber it (then we can't use the cached
check).

[Bug target/106342] [12/13 Regression] internal compiler error: in extract_insn, at recog.cc:2791 since r12-4240-g2b8453c401b699

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

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

--- Comment #8 from Jakub Jelinek  ---
commit r13-1955-g2f17f489de47d46626ed85804c3b810547ef550e   
Author: Ilya Leoshkevich
 
Date:   Fri Jul 29 16:14:10 2022 +0200  

PR106342 - IBM zSystems: Provide vsel for all vector modes  

dg.exp=pr104612.c fails with an ICE on s390x, because copysignv2sf3 
produces an insn that vsel is supposed to recognize, but can't,   
because it's not defined for V2SF.  Fix by defining it for all vector   
modes supported by copysign3. 

gcc/ChangeLog:  

* config/s390/vector.md (V_HW_FT): New iterator.
* config/s390/vx-builtins.md (vsel): Use V_HW_FT instead  
of V_HW.

Unfortunately the commit didn't contain the PR number in the format hooks want.

Are you going to backport this to 12.2 (RC this Friday)?

[Bug c++/88174] Make __real__ += __val usable in constexpr context.

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Backport doesn't work in 12 for multiple reasons and it isn't a regression
anyway, so fixed for 13+.

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 88174 Summary: Make __real__ += __val usable in constexpr context.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88174

   What|Removed |Added

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

[Bug modula2/106443] Many 32-bit tests FAIL to link on Solaris/sparcv9

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

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

--- Comment #3 from Gaius Mulley  ---
Thanks for the report and reminder/patch - I've now pushed the patch to gcc.cc.

[Bug target/106577] New: [13 Regression] during RTL pass: subreg3 ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -O -mavx

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 106577
   Summary: [13 Regression] during RTL pass: subreg3 ICE: in
extract_insn, at recog.cc:2791 (unrecognizable insn)
with -O -mavx
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 53429
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53429&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -O -mavx testcase.c
testcase.c: In function 'foo':
testcase.c:4:1: error: unrecognizable insn:
4 | }
  | ^
(insn 28 27 30 2 (parallel [
(set (reg:TI 98)
(and:TI (reg:V4SI 100)
(reg:TI 99)))
(clobber (reg:CC 17 flags))
]) "testcase.c":3:8 -1
 (nil))
during RTL pass: subreg3
testcase.c:4:1: internal compiler error: in extract_insn, at recog.cc:2791
0x77b2c8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/repo/gcc-trunk/gcc/rtl-error.cc:108
0x77b34b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/repo/gcc-trunk/gcc/rtl-error.cc:116
0x769bfd extract_insn(rtx_insn*)
/repo/gcc-trunk/gcc/recog.cc:2791
0x24ab7b7 decompose_multiword_subregs
/repo/gcc-trunk/gcc/lower-subreg.cc:1555
0x24ac8dd execute
/repo/gcc-trunk/gcc/lower-subreg.cc:1820
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-2009-20220810070724-gc16d9f78dc8-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-2009-20220810070724-gc16d9f78dc8-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220810 (experimental) (GCC)

[Bug target/106577] [13 Regression] during RTL pass: subreg3 ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -O -mavx since r13-2006-ga56c1641e9d25e46

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
Summary|[13 Regression] during RTL  |[13 Regression] during RTL
   |pass: subreg3 ICE: in   |pass: subreg3 ICE: in
   |extract_insn, at|extract_insn, at
   |recog.cc:2791   |recog.cc:2791
   |(unrecognizable insn) with  |(unrecognizable insn) with
   |-O -mavx|-O -mavx since
   ||r13-2006-ga56c1641e9d25e46
   Last reconfirmed||2022-08-10
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org,
   ||sayle at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Started with r13-2006-ga56c1641e9d25e46.

[Bug tree-optimization/98709] gcc optimizes bitwise operations, but doesn't optimize logical ones

[vanyacpp at gmail dot com via Gcc-bugs]

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

Ivan Sorokin  changed:

   What|Removed |Added

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

--- Comment #3 from Ivan Sorokin  ---
This issue was fixed in PR106379 by Richard Biener.

https://gcc.gnu.org/g:375668e0508fbe173af1ed519d8ae2b79f388d94

[Bug middle-end/19987] [meta-bug] fold missing optimizations in general

[vanyacpp at gmail dot com via Gcc-bugs]

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

Bug 98709 Summary: gcc optimizes bitwise operations, but doesn't optimize 
logical ones
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98709

   What|Removed |Added

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

[Bug tree-optimization/101706] bool0^bool1^1 -> bool0 == bool1

[vanyacpp at gmail dot com via Gcc-bugs]

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

Ivan Sorokin  changed:

   What|Removed |Added

 CC||vanyacpp at gmail dot com

--- Comment #2 from Ivan Sorokin  ---
This issue was fixed in PR106379 by Richard Biener.

After https://gcc.gnu.org/g:375668e0508fbe173af1ed519d8ae2b79f388d94 for both
fa and fb we have:

fa(bool&, bool&, bool&):
movzx   eax, BYTE PTR [rsi]
cmp BYTE PTR [rdi], al
seteBYTE PTR [rdx]
ret
fb(bool&, bool&, bool&):
movzx   eax, BYTE PTR [rsi]
cmp BYTE PTR [rdi], al
seteBYTE PTR [rdx]
ret

I think the issue can be closed now.

[Bug lto/106328] Build doesn't respect -j N flag

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r13-2012-gfed766af32ed6cd371016cc24e931131e19b4eb1
Author: Martin Liska 
Date:   Tue Aug 9 13:59:39 2022 +0200

lto: respect jobserver in parallel WPA streaming

PR lto/106328

gcc/ChangeLog:

* opts-jobserver.h (struct jobserver_info): Add pipefd.
(jobserver_info::connect): New.
(jobserver_info::disconnect): Likewise.
(jobserver_info::get_token): Likewise.
(jobserver_info::return_token): Likewise.
* opts-common.cc: Implement the new functions.

gcc/lto/ChangeLog:

* lto.cc (wait_for_child): Decrement nruns once a process
finishes.
(stream_out_partitions): Use job server if active.
(do_whole_program_analysis): Likewise.

[Bug lto/106328] Build doesn't respect -j N flag

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Liška  ---
Implemented for GCC 13.

[Bug c/106571] Implement -Wsection diag

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

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

Michael Matz  changed:

   What|Removed |Added

 CC||matz at gcc dot gnu.org

--- Comment #4 from Michael Matz  ---
To elaborate: normally you don't need to know which section a variable will be
placed into when generating code to access it.  (In fact you don't even need to
know if it's defined in the same linking component at all)

So, for declarations the section is immaterial, and checking for a mismatch
between decl and def doesn't seem appropriate.  In the general case.  This is
not
the general case, the per-cpu sections of the kernel have special semantics,
and I agree with Andrew that checking would be better implemented with
something
orthogonal to the section attribute itself.

Boris: what does DECLARE_PER_CPU() expand into?  Are there other attributes
that could be usefully checked for mismatch between decl and def?

[Bug tree-optimization/106322] [12/13 Regression] tree-vectorize: Wrong code at O2 level (-fno-tree-vectorize is working) since r12-2404-ga1d27560770818c5

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

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

--- Comment #42 from Richard Biener  ---
I think this goes wrong in vectorizable_operation which does

  if (using_emulated_vectors_p
  && !vect_can_vectorize_without_simd_p (code))

to guard this but I'm not sure how this slips through?

[Bug tree-optimization/106322] [12/13 Regression] tree-vectorize: Wrong code at O2 level (-fno-tree-vectorize is working) since r12-2404-ga1d27560770818c5

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

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

--- Comment #43 from Richard Biener  ---
(In reply to Richard Biener from comment #42)
> I think this goes wrong in vectorizable_operation which does
> 
>   if (using_emulated_vectors_p
>   && !vect_can_vectorize_without_simd_p (code))
> 
> to guard this but I'm not sure how this slips through?

Ah, it's an internal function.  I think we should simply return false
during analysis for any vect_emulated_vector_p type in vectorizable_call.

Alternatively pattern recognition could also be made to fail but the above
is definitely more future proof.

[Bug lto/106328] Build doesn't respect -j N flag

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #8 from rguenther at suse dot de  ---
On Wed, 10 Aug 2022, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106328
> 
> Martin Liška  changed:
> 
>What|Removed |Added
> 
>  Resolution|--- |FIXED
>  Status|ASSIGNED|RESOLVED
> 
> --- Comment #7 from Martin Liška  ---
> Implemented for GCC 13.

Magically only with recent GNU make, otherwise needs proper prefixed
rules in the lto-wrapper generated makefile which I don't think we do.
Without either it's now slow by default?

[Bug lto/106328] Build doesn't respect -j N flag

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

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

--- Comment #9 from Martin Liška  ---
> Magically only with recent GNU make, otherwise needs proper prefixed
> rules in the lto-wrapper generated makefile which I don't think we do.

Wait, the cooperation works with older GNU make if a Makefile uses prefixed (+)
rules. WPA does not email any artificial Makefile for WPA streaming. It's a
Makefile we emit for LTRANS run, e.g.:

marxin@marxinbox:/dev/shm/objdir> cat /tmp/ccuhgkQs.mk
./a.ltrans0.ltrans.o:
@g++  '-xlto' '-c' '-fno-openmp' '-fno-openacc' '-fno-pie'
'-fcf-protection=none' '-mtune=generic' '-march=x86-64' '-O2' '-save-temps'
'-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a.'
'-dumpbase' './a.ltrans0.ltrans' '-fltrans' '-o' './a.ltrans0.ltrans.o'
'./a.ltrans0.o'
./a.ltrans1.ltrans.o:
@g++  '-xlto' '-c' '-fno-openmp' '-fno-openacc' '-fno-pie'
'-fcf-protection=none' '-mtune=generic' '-march=x86-64' '-O2' '-save-temps'
'-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a.'
'-dumpbase' './a.ltrans1.ltrans' '-fltrans' '-o' './a.ltrans1.ltrans.o'
'./a.ltrans1.o'
...

So what can be miss is jobserver detection on BSD that can fail for some
reason, but it should work fine apart from that. Or do I miss something?

[Bug lto/106328] Build doesn't respect -j N flag

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #10 from rguenther at suse dot de  ---
On Wed, 10 Aug 2022, marxin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106328
> 
> --- Comment #9 from Martin Liška  ---
> > Magically only with recent GNU make, otherwise needs proper prefixed
> > rules in the lto-wrapper generated makefile which I don't think we do.
> 
> Wait, the cooperation works with older GNU make if a Makefile uses prefixed 
> (+)
> rules. WPA does not email any artificial Makefile for WPA streaming. It's a
> Makefile we emit for LTRANS run, e.g.:
> 
> marxin@marxinbox:/dev/shm/objdir> cat /tmp/ccuhgkQs.mk
> ./a.ltrans0.ltrans.o:
> @g++  '-xlto' '-c' '-fno-openmp' '-fno-openacc' '-fno-pie'
> '-fcf-protection=none' '-mtune=generic' '-march=x86-64' '-O2' '-save-temps'
> '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a.'
> '-dumpbase' './a.ltrans0.ltrans' '-fltrans' '-o' './a.ltrans0.ltrans.o'
> './a.ltrans0.o'
> ./a.ltrans1.ltrans.o:
> @g++  '-xlto' '-c' '-fno-openmp' '-fno-openacc' '-fno-pie'
> '-fcf-protection=none' '-mtune=generic' '-march=x86-64' '-O2' '-save-temps'
> '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a.'
> '-dumpbase' './a.ltrans1.ltrans' '-fltrans' '-o' './a.ltrans1.ltrans.o'
> './a.ltrans1.o'
> ...
> 
> So what can be miss is jobserver detection on BSD that can fail for some
> reason, but it should work fine apart from that. Or do I miss something?

Ah, indeed.  That still leaves the question whether we execute the
WPA stage with the FDs open - I suppose you checked?  And whether
pex_* "properly" does this for all host OSs (how does make jobserver
work on mingw/cygwin?).  I wonder because Honza once said he didn't
implement jobserver support because it would require more fiddling
to get it actually work.

And IIRC BSD 'make' is not GNU make but I think gmake is available
from the ports repo.  The documentation about -flto=jobserver mentions
that already.

[Bug target/106577] [13 Regression] during RTL pass: subreg3 ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) with -O -mavx since r13-2006-ga56c1641e9d25e46

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/106369] [12 Regression] ICE in output_constructor_regular_field, at varasm.cc:5515 since r12-2975-g32c3a75390623a

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
  Known to work||13.0
  Known to fail||12.1.0
Summary|[12/13 Regression] ICE in   |[12 Regression] ICE in
   |output_constructor_regular_ |output_constructor_regular_
   |field, at varasm.cc:5515|field, at varasm.cc:5515
   |since   |since
   |r12-2975-g32c3a75390623a|r12-2975-g32c3a75390623a

--- Comment #13 from Richard Biener  ---
Good for 12.2?

[Bug c++/106395] [12/13 regression] [mingw] "redeclared without dllimport attribute: previous dllimport ignored" on C++ friend since r12-299-ga0fdff3cf33f72

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-10
 CC||jason at gcc dot gnu.org
   Priority|P3  |P2
Summary|[12/13 regression] [mingw]  |[12/13 regression] [mingw]
   |"redeclared without |"redeclared without
   |dllimport attribute:|dllimport attribute:
   |previous dllimport ignored" |previous dllimport ignored"
   |on C++ friend   |on C++ friend since
   ||r12-299-ga0fdff3cf33f72
   Keywords|needs-bisection |
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Thanks for the bisect.

[Bug ipa/101839] [10/11/12/13 Regression] Hang in C++ code with -fdevirtualize

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

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

--- Comment #9 from Jan Hubicka  ---
Thanks for looking into this.  
What happens here is that we start working from a call where we know that
outer_type is BA. We correctly find the BA::type and notice that it is final
and thus we do not need to look for sucessors to find something.

However we later decide to discard it here:

3241  if (type_possibly_instantiated_p (outer_type->type))
3244skipped = true;

This is trying to check, for anonymous types, the possibility that a given
target is never going to be taken since type was never instantiated. It is true
that BA is not instantiated however its successor is.  So we need to keep track
that we saw FINAL and in that case extend type_possibly_instantiated_p to also
look for all derived types. This is quite ugly mistake I got in as the
possibly_instantiated code was implemented before we got DECL_FINAl flag.

I will prepare patch.

[Bug tree-optimization/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

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

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

--- Comment #11 from Richard Biener  ---
The dump difference is easily explained by taming PRE when -ftree-vectorize is
on, it's not a "real" difference.

When I try with a cc1 cross I see

> ./cc1 -quiet t.i -fpreprocessed -O2 -g -std=gnu11 -fgnu89-inline 
> -fmerge-all-constants -frounding-math -fno-stack-protector -fno-common 
> -fmath-errno-fno-pie -fopt-info-vec

and nothing actually vectorized.  Besides the PRE there seems to be a missed
DSE at the end (when vectorization is enabled as after the change):

   # DEBUG BEGIN_STMT
   memset (&buf.__space.__c, 64, 1024);
   # DEBUG BEGIN_STMT
+  sizes[0] = 16;
   sizes[1] = 1024;
   sizes[2] = 1040;

otherwise I see nothing suspicious in differences in .optimized when
comparing -fdump-tree-optimized with/without -fno-tree-vectorize.

You could try if -fno-tree-pre reproduces it also before the change.

[Bug tree-optimization/106513] [10/11/12/13 Regression] bswap pass misses that >>56 for signed types can be replicate the sign bit

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

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

diff --git a/gcc/gimple-ssa-store-merging.cc b/gcc/gimple-ssa-store-merging.cc
index 0640168bcc4..b80b8eac444 100644
--- a/gcc/gimple-ssa-store-merging.cc
+++ b/gcc/gimple-ssa-store-merging.cc
@@ -263,7 +263,7 @@ do_shift_rotate (enum tree_code code,
 int count)
 {
   int i, size = TYPE_PRECISION (n->type) / BITS_PER_UNIT;
-  unsigned head_marker;
+  uint64_t head_marker;

   if (count < 0
   || count >= TYPE_PRECISION (n->type)

[Bug ipa/101839] [10/11/12/13 Regression] Hang in C++ code with -fdevirtualize

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

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

--- Comment #10 from Jan Hubicka  ---
Created attachment 53430
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53430&action=edit
Patch I am testing

[Bug analyzer/106203] Allow to emit diagnostics at return edges for the exit point as well as the call site

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

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

--- Comment #1 from David Malcolm  ---
I've been prototyping an implementation of PR 106147 (infinite loop detection),
and in some cases there aren't any statements at all for my warnings, just
location_t values (if that).  So as part of that I've been looking at a big
revamp of how source locations are tracked in the analyzer; I may be able to
fix this as part of that.

[Bug analyzer/106147] RFE: -fanalyzer could complain about some cases of infinite loops and infinite recursion

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

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

--- Comment #3 from David Malcolm  ---
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106203#c1 (w.r.t possible
revamp of how source locations are tracked in the analyzer, given that an
infinite loop might not contain any statements)

[Bug tree-optimization/106513] [10/11/12/13 Regression] bswap pass misses that >>56 for signed types can be replicate the sign bit

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

[Bug tree-optimization/106514] [12/13 Regression] ranger slowness in path query

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-10
 Ever confirmed|0   |1
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW

[Bug target/106524] [12/13 Regression] ICE in extract_insn, at recog.cc:2791 (error: unrecognizable insn) since r12-4349-ge36206c9940d22.

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug tree-optimization/106570] [12/13 Regression] DCE sometimes fails with depending if statements since r12-2305-g398572c1544d8b75

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Priority|P3  |P2

[Bug middle-end/106578] New: spurious -Wuse-after-free=2 after conditional free()

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

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

Bug ID: 106578
   Summary: spurious -Wuse-after-free=2 after conditional free()
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc.gnu.org at aydos dot de
  Target Milestone: ---

I am new to GCC's components, so feel free to rename the headers if I
classified the bug wrong.

The following code throws the `use-after-free` error:

```
#include 

void *buf = NULL;
size_t buf_size = 0;

int main() {
void *tmp = buf;

buf = realloc(tmp, 10);

// Realloc returns a pointer to the new object, or a null pointer if the
// new object could not be allocated. Free the original pointer
// to avoid memory leak in latter case.
if (!buf)
free(tmp);
}
```
```
$ gcc -Wall -Wuse-after-free=2 main.c
main.c: In function ‘main’:
main.c:15:17: warning: pointer ‘tmp’ may be used after ‘realloc’
[-Wuse-after-free]
   15 | free(tmp);
  | ^
main.c:9:15: note: call to ‘realloc’ here
9 | buf = realloc(tmp, 10);
  |   ^~~~
```

A workaround is to `realloc` directly `buf` and use `tmp` for the return value
of `realloc`:

```
#include 

void *buf = NULL;
size_t buf_size = 0;

int main() {
void *tmp = buf;

tmp = realloc(buf, 10);

if (!tmp)
free(buf);
}
```

>From what I saw in other bugs this one may also be related to the meta-bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075.

Can someone confirm this case?

[Bug middle-end/106578] spurious -Wuse-after-free=2 after conditional free()

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

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

--- Comment #1 from Gökçe Aydos  ---
FYI: [`realloc` behavior in the C11
standard](http://port70.net/~nsz/c/c11/n1570.html#7.22.3.5)

[Bug lto/106540] [10/11/12 Regression] lto -g ICE in dwarf2out_register_external_die at dwarf2out.cc:6076

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

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

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

https://gcc.gnu.org/g:4769ac6c5dfde2810a0266fe388211edc644e623

commit r12-8676-g4769ac6c5dfde2810a0266fe388211edc644e623
Author: Richard Biener 
Date:   Mon Aug 8 09:07:23 2022 +0200

lto/106540 - fix LTO tree input wrt dwarf2out_register_external_die

I've revisited the earlier two workarounds for
dwarf2out_register_external_die
getting duplicate entries.  It turns out that r11-525-g03d90a20a1afcb
added dref_queue pruning to lto_input_tree but decl reading uses that
to stream in DECL_INITIAL even when in the middle of SCC streaming.
When that SCC then gets thrown away we can end up with debug nodes
registered which isn't supposed to happen.  The following adjusts
the DECL_INITIAL streaming to go the in-SCC way, using lto_input_tree_1,
since no SCCs are expected at this point, just refs.

PR lto/106540
PR lto/106334
* lto-streamer-in.cc (lto_read_tree_1): Use lto_input_tree_1
to input DECL_INITIAL, avoiding to commit drefs.

(cherry picked from commit 2a1448f2763a72c83e2ec496f78243a975b0d44e)

[Bug lto/106334] [13 Regression] lto -g ICE in dwarf2out_register_external_die at dwarf2out.cc:6072

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

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

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

https://gcc.gnu.org/g:4769ac6c5dfde2810a0266fe388211edc644e623

commit r12-8676-g4769ac6c5dfde2810a0266fe388211edc644e623
Author: Richard Biener 
Date:   Mon Aug 8 09:07:23 2022 +0200

lto/106540 - fix LTO tree input wrt dwarf2out_register_external_die

I've revisited the earlier two workarounds for
dwarf2out_register_external_die
getting duplicate entries.  It turns out that r11-525-g03d90a20a1afcb
added dref_queue pruning to lto_input_tree but decl reading uses that
to stream in DECL_INITIAL even when in the middle of SCC streaming.
When that SCC then gets thrown away we can end up with debug nodes
registered which isn't supposed to happen.  The following adjusts
the DECL_INITIAL streaming to go the in-SCC way, using lto_input_tree_1,
since no SCCs are expected at this point, just refs.

PR lto/106540
PR lto/106334
* lto-streamer-in.cc (lto_read_tree_1): Use lto_input_tree_1
to input DECL_INITIAL, avoiding to commit drefs.

(cherry picked from commit 2a1448f2763a72c83e2ec496f78243a975b0d44e)

[Bug tree-optimization/106513] [10/11/12/13 Regression] bswap pass misses that >>56 for signed types can be replicate the sign bit

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r13-2013-gf675afa4eeac9910a2c085a95aa04d6d9f2fd8d6
Author: Richard Biener 
Date:   Wed Aug 10 15:45:22 2022 +0200

tree-optimization/106513 - fix mistake in bswap symbolic number shifts

This fixes a mistake in typing a local variable in the symbolic
shift routine.

PR tree-optimization/106513
* gimple-ssa-store-merging.cc (do_shift_rotate): Use uint64_t
for head_marker.

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

[Bug tree-optimization/106513] [10/11/12/13 Regression] bswap pass misses that >>56 for signed types can be replicate the sign bit

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

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

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

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

commit r12-8677-gab2ca2dbd528f0564b80fa0e6eda96e0237742bc
Author: Richard Biener 
Date:   Wed Aug 10 15:45:22 2022 +0200

tree-optimization/106513 - fix mistake in bswap symbolic number shifts

This fixes a mistake in typing a local variable in the symbolic
shift routine.

PR tree-optimization/106513
* gimple-ssa-store-merging.cc (do_shift_rotate): Use uint64_t
for head_marker.

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

(cherry picked from commit f675afa4eeac9910a2c085a95aa04d6d9f2fd8d6)

[Bug middle-end/106578] spurious -Wuse-after-free=2 after conditional free()

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2022-08-10
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
The pattern matching of the if (result == NULL) doesn't work reliably without
optimization because it goes through memory:

   :
  tmp_5 = buf;
  _1 = realloc (tmp_5, 10);
  buf = _1;
  buf.0_2 = buf;
  if (buf.0_2 == 0B)
goto ; [INV]
  else
goto ; [INV]

   :
  free (tmp_5);

   :
  _9 = 0;

   :
:
  return _9;

using 'tmp' instead makes it properly fire.  Could be fixed with extra
compile-time cycles doing virtual VN like we do for early uninit
analysis (note this is the late waccess pass).

[Bug tree-optimization/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

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

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

--- Comment #12 from dave.anglin at bell dot net ---
On 2022-08-10 9:30 a.m., rguenth at gcc dot gnu.org wrote:
> When I try with a cc1 cross I see
>
>> ./cc1 -quiet t.i -fpreprocessed -O2 -g -std=gnu11 -fgnu89-inline 
>> -fmerge-all-constants -frounding-math -fno-stack-protector -fno-common 
>> -fmath-errno-fno-pie -fopt-info-vec
> and nothing actually vectorized.  Besides the PRE there seems to be a missed
> DSE at the end (when vectorization is enabled as after the change):
>
> # DEBUG BEGIN_STMT
> memset (&buf.__space.__c, 64, 1024);
> # DEBUG BEGIN_STMT
> +  sizes[0] = 16;
> sizes[1] = 1024;
> sizes[2] = 1040;
>
> otherwise I see nothing suspicious in differences in .optimized when
> comparing -fdump-tree-optimized with/without -fno-tree-vectorize.
I had tried -fno-tree-vectorize and it made no difference to the test.  So, it
seems GCC is miscompiled
with the -ftree-vectorize change.  I thought of building GCC with
-fno-tree-vectorize as a test.

>
> You could try if -fno-tree-pre reproduces it also before the change.
>
Will try.

[Bug tree-optimization/106506] [13 Regression] g++.dg/opt/pr94589-2.C FAILS after enabling floats in VRP

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Those 2 checks were just trying to be careful, the (phires & 1) == phires and
variants it is folded to of course make only sense for the -1/0/1/2 result
spaceship, for -1/0/1 one can just use comparisons of phires.  We only floating
point spaceship if nans aren't honored, so the 2 case is ignored, and if it is,
with Aldy's changes we can simplify the 2 case away from the phi but the
(phires & 1) == phires stayed.  It is safe to treat the phires comparison as
phires >= 0 even then.

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #5 from joseph at codesourcery dot com  ---
It's possible code is being moved across SET_RESTORE_ROUNDL, in which case 
maybe math_opt_barrier needs to be used in glibc code to prevent that 
movement.

[Bug c/106571] Implement -Wsection diag

[bp at alien8 dot de via Gcc-bugs]

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

--- Comment #5 from Boris  ---
(In reply to Michael Matz from comment #4)
> Boris: what does DECLARE_PER_CPU() expand into?  Are there other attributes
> that could be usefully checked for mismatch between decl and def?

Unfortunately,

DECLARE_PER_CPU(u64, x86_spec_ctrl_current);

expands only to:

extern __attribute__((section(".data..percpu" ""))) __typeof__(u64)
x86_spec_ctrl_current;

[Bug fortran/106579] New: ieee_signaling_nan problem in fortran on powerpc64

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

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

Bug ID: 106579
   Summary: ieee_signaling_nan problem in fortran on powerpc64
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

There is an issue with ieee_signaling_nan as used in fortran on powerpc64 when
--with-long-double-format=ieee is used.

Extracted from gfortran.dg/ieee/signaling_3.f90:

program test
  use, intrinsic :: iso_c_binding
  use, intrinsic :: ieee_arithmetic
  implicit none

  real(kind=c_long_double) :: z

  if (ieee_support_nan(z)) then
z = ieee_value(z, ieee_signaling_nan)
if (ieee_class(z) /= ieee_signaling_nan) stop 100
  end if

end program test

seurer@fowler:~/gcc/git/build/gcc-12-test$
/home/seurer/gcc/git/build/gcc-12-test/gcc/testsuite/gfortran/../../gfortran
-B/home/seurer/gcc/git/build/gcc-12-test/gcc/testsuite/gfortran/../../
-B/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/./libgfortran/
signaling_3a.f90 -fdiagnostics-plain-output -fdiagnostics-plain-output -O0
-pedantic-errors -fintrinsic-modules-path
/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/./libgfortran/
-fno-unsafe-math-optimizations -frounding-math -fsignaling-nans
-B/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/./libatomic/.libs
-B/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home/seurer/gcc/git/build/gcc-12-test/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-lm -o ./signaling_3a.exe

seurer@fowler:~/gcc/git/build/gcc-12-test$ ./signaling_3a.exe 
STOP 100


This happens for both gcc 12 and 13 (trunk).

It occurs on powerpc64 LE with the compiler being tested configured with
--with-long-double-format=ieee on Fedora 36 which is the first powerpc64 distro
built with --with-long-double-format=ieee.  The distro compiler is gcc version
12.1.1 20220507 (Red Hat 12.1.1-1) (GCC).


Note the specific test case, signaling_3.f90, was added here but another test
case signaling_2.f90 fails the same way.

commit e89d0befe3ec3238fca6de2cb078eb403b8c7e99 (HEAD)
Author: Francois-Xavier Coudert 
Date:   Mon Jan 17 12:46:48 2022 +0100

Fortran: provide a fallback implementation of issignaling

[Bug middle-end/106578] spurious -Wuse-after-free=2 after conditional free() when not optimizing

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

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

--- Comment #3 from Gökçe Aydos  ---
> using 'tmp' instead makes it properly fire.

Dear Richard, maybe I misunderstood what you meant with *fire*. If `tmp` is
used then gcc does not *fire* any warning and works correctly, right?

[Bug c/90885] GCC should warn about 2^16 and 2^32 and 2^64 [-Wxor-used-as-pow]

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||dmalcolm at gcc dot gnu.org
  Component|c++ |c
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org

--- Comment #24 from David Malcolm  ---
I'm working on an implementation of this.

[Bug fortran/106576] Finalization of temporaries from functions not occuring

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

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

--- Comment #1 from Thomas Koenig  ---
There currently is a c.l.f. thread on this, with this test case.
Although what nagfor and xlf are doing makes sense, it does
not (to me) follow from the language of the standard.

https://groups.google.com/g/comp.lang.fortran/c/7bB13FEa10w is
the link to the thread.

[Bug tree-optimization/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

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

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

--- Comment #13 from dave.anglin at bell dot net ---
On 2022-08-10 9:30 a.m., rguenth at gcc dot gnu.org wrote:
> You could try if -fno-tree-pre reproduces it also before the change.
It doesn't.

[Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Ouch, indeed.
Looking at ieee/ieee_exceptions.F90, I think that one is ok, while
__ieee_exceptions_MOD_ieee_support_flag_16
is exported from the library, all of
__ieee_exceptions_MOD_ieee_support_flag_{4,8,16} return the same result and I
think it is the same for both IEEE quad and IBM double double formats too,
so using __ieee_exceptions_MOD_ieee_support_flag_16 for it is fine.
On the other side, ieee/ieee_arithmetic.F90 is problematic.
I must say I don't understand at all stuff like IEEE_IS_FINITE, because it
refers
to stuff like _gfortran_ieee_is_finite_16 which I don't see anywhere in
libgfortran.{so.5,a}.
Looking purely on what is exported from libgfortran.so.5 from the
ieee_arithmetic module symbols, I see:
readelf -Wa ../powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5
| grep ieee_arith | grep _16@@
   483: 001ca77020 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_io_16@@GFORTRAN_8
   555: 001ca67020 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_sqrt_16@@GFORTRAN_8
   753: 001cac1072 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_rounding_16@@GFORTRAN_8   [: 8]
   771: 001caef056 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_class_16@@GFORTRAN_8  [: 8]
   795: 001ca8f020 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_subnormal_16@@GFORTRAN_9
   823: 001ca97020 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_denormal_16@@GFORTRAN_8
   961: 001ca6f020 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_nan_16@@GFORTRAN_8
  1220: 001cae3060 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_value_16@@GFORTRAN_8  [: 8]
  1265: 001ca7f020 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_inf_16@@GFORTRAN_8
  1502: 001caad072 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_underflow_control_16@@GFORTRAN_8 
[: 8]
  1532: 001ca5f020 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_standard_16@@GFORTRAN_8
  1596: 001ca87020 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_divide_16@@GFORTRAN_8
  1703: 001ca9f020 FUNCGLOBAL DEFAULT   11
__ieee_arithmetic_MOD_ieee_support_datatype_16@@GFORTRAN_8

Now, most of the above are probably fine too, they just return true and again
that answer seems to be fine for both when
real(kind=16) is IBM double double or IEEE quad.
The problematic cases from those are:
__ieee_arithmetic_MOD_ieee_class_16
__ieee_arithmetic_MOD_ieee_value_16
The above 2 clearly need different behavior when real(kind=16) is IEEE quad vs.
IBM double double, the
implementation right now implements those for IBM double double.
So, either we need to arrange for those to be expanded inline by the frontend
(and it can be done either
by hardcoding the enumerators or say transforming the calls from working with
IEEE quad to working with
IBM double double or vice versa), or we need to add
__ieee_arithmetic_MOD_ieee_class_17
__ieee_arithmetic_MOD_ieee_value_17
entrypoints to the library and arrange for the _16 to be remapped to _17 for
these 2.
Other possibly problematic functions are
__ieee_arithmetic_MOD_ieee_support_rounding_16
__ieee_arithmetic_MOD_ieee_support_underflow_control_16
The former seems to do the exact same call in each case, so is probably fine
like the true cases,
the latter actually calls support_underflow_control_helper with kind value, but
it is ignored everywhere but alpha,
so is fine too.

For the transformation above, I mean something like handling ieee_class by
doing __builtin_fpclassify + issignalling
and __builtin_signbit and depending on the result call
__ieee_arithmetic_MOD_ieee_class_16 on sample IBM double double
values with the same properties.
Similarly, ieee_value by calling __ieee_arithmetic_MOD_ieee_value_16 first,
analyzing the result with
__builtin_fpclassify and in most cases just converting the IBM double double to
IEEE quad.
Guess NaNs (especially signalling NaN) and denormals need to be an exception.

Another question is if one needs to implement these as actual out of line
functions (even hidden), whether it is
permissible to say call some function/subroutine with ieee_value or ieee_class
as procedure argument.
Given that they are overloaded, I'd hope it is not possible.

[Bug tree-optimization/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

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

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

--- Comment #14 from dave.anglin at bell dot net ---
On 2022-08-10 1:38 p.m., dave.anglin at bell dot net wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106458
>
> --- Comment #13 from dave.anglin at bell dot net ---
> On 2022-08-10 9:30 a.m., rguenth at gcc dot gnu.org wrote:
>> You could try if -fno-tree-pre reproduces it also before the change.
> It doesn't.
But the test does not fail after the change with -fno-tree-pre.

[Bug sanitizer/106580] New: ICE with UBSan and -fsanitize-undefined-trap-on-error

[muecker at gwdg dot de via Gcc-bugs]

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

Bug ID: 106580
   Summary: ICE with UBSan and -fsanitize-undefined-trap-on-error
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: muecker at gwdg dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Created attachment 53432
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53432&action=edit
debug output

The following reduced test case produces an ICE on turnk with:

-O1 -fsanitize=undefined -fsanitize-undefined-trap-on-error


extern void f(void);
static void g(int typ)
{
switch (typ) {

case 1:
f();
}
}

extern void e(void)
{
return g(0);
}

extern void h(void)
{
return g(1);
}

https://godbolt.org/z/YdKTEfovY

[Bug middle-end/106492] [OpenMP] ICE in #pragma omp for simd and bitfields

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

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

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

https://gcc.gnu.org/g:68b8c55c7e7de8438ea97f600cdccac826b8e67d

commit r12-8678-g68b8c55c7e7de8438ea97f600cdccac826b8e67d
Author: Tobias Burnus 
Date:   Tue Aug 9 07:57:40 2022 +0200

OpenMP: Fix folding with simd's linear clause [PR106492]

gcc/ChangeLog:

PR middle-end/106492
* omp-low.cc (lower_rec_input_clauses): Add missing folding
to data type of linear-clause list item.

gcc/testsuite/ChangeLog:

PR middle-end/106492
* g++.dg/gomp/pr106492.C: New test.

(cherry picked from commit 8a16b9f983824b6b9a25275cd23b6bba8c98b800)

[Bug sanitizer/106580] ICE with UBSan and -fsanitize-undefined-trap-on-error

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 106061

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

[Bug ipa/106061] [13 Regression] during GIMPLE pass: einline ICE: verify_cgraph_node failed (edge points to wrong declaration) with -Og since r13-1204-gd68d366425369649

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

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

[Bug target/96786] rs6000: We output the wrong .machine for -mcpu=7450

[erhard_f at mailbox dot org via Gcc-bugs]

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

Erhard F.  changed:

   What|Removed |Added

 CC||erhard_f at mailbox dot org

--- Comment #2 from Erhard F.  ---
This seems to have been fixed meanwhile. My Gentoo ppc/ppc64 box says:

 # gcc-9.5.0 -S -m32 -mcpu=7450 -frecord-gcc-switches -xc -o - - < /dev/null |
grep -E 'mcpu|machine'
.ascii  "-mcpu=7450"

 # gcc-10.4.0 -S -m32 -mcpu=7450 -frecord-gcc-switches -xc -o - - < /dev/null |
grep -E 'mcpu|machine'
.machine "7450"
.ascii  "-mcpu=7450"

 # gcc-11.3.0 -S -m32 -mcpu=7450 -frecord-gcc-switches -xc -o - - < /dev/null |
grep -E 'mcpu|machine'
.machine power7
.string "GNU C17 11.3.0 -msecure-plt -m32 -mcpu=7450"

 # gcc-12.1.1 -S -m32 -mcpu=7450 -frecord-gcc-switches -xc -o - - < /dev/null |
grep -E 'mcpu|machine'
.machine "7450"
.string "GNU C17 12.1.1 20220625 -msecure-plt -m32 -mcpu=7450"

This would be on the 32bit chroot of my Talos II.

[Bug tree-optimization/106458] [12/13 Regression] glibc's malloc/tst-scratch_buffer.c test is miscompiled with gcc-12

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

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

--- Comment #15 from dave.anglin at bell dot net ---
On 2022-08-10 9:30 a.m., rguenth at gcc dot gnu.org wrote:
> hen I try with a cc1 cross I see
>
>> ./cc1 -quiet t.i -fpreprocessed -O2 -g -std=gnu11 -fgnu89-inline 
>> -fmerge-all-constants -frounding-math -fno-stack-protector -fno-common 
>> -fmath-errno-fno-pie -fopt-info-vec
> and nothing actually vectorized.  Besides the PRE there seems to be a missed
> DSE at the end (when vectorization is enabled as after the change):
>
> # DEBUG BEGIN_STMT
> memset (&buf.__space.__c, 64, 1024);
> # DEBUG BEGIN_STMT
> +  sizes[0] = 16;
> sizes[1] = 1024;
> sizes[2] = 1040;
>
> otherwise I see nothing suspicious in differences in .optimized when
> comparing -fdump-tree-optimized with/without -fno-tree-vectorize.
>
I'm not sure what's going on with the sizes[0] statement but the main
difference in .optimize with and without pre
seems to be in the handling of the old_length variable in do_test:

  Removing basic block 86
  int do_test ()
  {
-  unsigned int ivtmp.23;
-  size_t old_length;
+  unsigned int ivtmp.28;
    void * r;
    void * c;
    size_t l;

[Bug target/96786] rs6000: We output the wrong .machine for -mcpu=7450

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

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #3 from Segher Boessenkool  ---
Yes, I fuxed it in g:77eccbf39ed.  That needed the g:80fcc4b6afee fixup, and
will need more work in the future. but this PR is fixed indeed :-)

[Bug libstdc++/106581] New: [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com via Gcc-bugs]

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

Bug ID: 106581
   Summary: [Aarch64] libstdc++ segfault at end of execution
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lancethepants at gmail dot com
  Target Milestone: ---

aarch64
linux 4.1.51
GCC 12.1
uclibc-ng 1.0.41

All dynamically linked c++ executables will segfault.  Some executables will
run then segfault, some just segfault.  I think there are couple segfaulting
issues, but this is the first one to address I think. GCC 10 & 11 don't
segfault at the end of execution if they don't segfault for some other reason. 
Static linked binaries don't segfault at the end of execution using either
'-static' for fully static binary or '-static-libstdc++' to static link just
libstdc++.

Here is a backtrace of segfaulting 'hello world' c++ binary

admin@RT-AX88U-6860:~/src/hello.src# /opt/bin/gdb ./hello
GNU gdb (GDB) 11.2
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "aarch64-openwrt-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./hello...
(gdb) run
Starting program: /mmc/src/hello.src/hello
warning: Unable to determine the number of hardware watchpoints available.
warning: Unable to determine the number of hardware breakpoints available.
warning: File "/mmc/lib/libthread_db-1.0.41.so" auto-loading has been declined
by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
add-auto-load-safe-path /mmc/lib/libthread_db-1.0.41.so
line to your configuration file "/mmc/.config/gdb/gdbinit".
To completely disable this security protection add
set auto-load safe-path /
line to your configuration file "/mmc/.config/gdb/gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
info "(gdb)Auto-loading safe path"
warning: Unable to find libthread_db matching inferior's thread library, thread
debugging will not be available.
Hello, World from C++!

Program received signal SIGSEGV, Segmentation fault.
std::uncaught_exception () at
../../../../libstdc++-v3/libsupc++/eh_catch.cc:141
141 ../../../../libstdc++-v3/libsupc++/eh_catch.cc: No such file or
directory.
(gdb) backtrace
#0  std::uncaught_exception () at
../../../../libstdc++-v3/libsupc++/eh_catch.cc:141
#1  0x007fb7f0bd30 in std::ostream::sentry::~sentry (this=0x7ff340,
__in_chrg=)
at
/home/lance/tomatoware/toolchain/buildroot-git/output/build/host-gcc-final-12.1.0/build/aarch64-tomatoware-linux-uclibc/libstdc++-v3/include/ostream:466
#2  0x007fb7f0bde4 in std::ostream::flush (this=0x7fb7fe4f48 )
at
/home/lance/tomatoware/toolchain/buildroot-git/output/build/host-gcc-final-12.1.0/build/aarch64-tomatoware-linux-uclibc/libstdc++-v3/include/bits/ostream.tcc:245
#3  0x007fb7ebbc40 in std::ios_base::Init::~Init (this=,
__in_chrg=) at
../../../../../libstdc++-v3/src/c++98/ios_init.cc:135
#4  0x007fb7d401b8 in __exit_handler (status=0) at
libc/stdlib/_atexit.c:263
#5  0x007fb7d402b8 in __GI_exit (rv=0) at libc/stdlib/_atexit.c:301
#6  0x007fb7d46134 in __uClibc_main (main=0x5559d4 , argc=1,
argv=0x7ff598, app_init=0x5557d8 <_init>, app_fini=0x555a78
<_fini>, rtld_fini=0x7fb7fe94f0 <_dl_fini>, stack_end=0x7ff590)
at libc/misc/internals/__uClibc_main.c:552
#7  0x005558c4 in _start () at libc/sysdeps/linux/aarch64/crt1.S:92
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[michael.hudson at canonical dot com via Gcc-bugs]

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

--- Comment #6 from Michael Hudson-Doyle  
---
Are there any tips as to how to diagnose this further? I tried putting a
math_opt_barrier on this line:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/ieee754/ldbl-128/e_j1l.c;h=54c457681aecef079cb64d406ca89e05d2ce4fc5;hb=HEAD#l872
and it didn't help, although the failing test is hitting the case the
SET_RESTORE_ROUNDL is in.

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2022-08-10
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
This could be a bug in uclibc and TLS.

The crash is related to TLS of:
  abi::__cxa_eh_globals*
  get_global() _GLIBCXX_NOTHROW
  {
static __thread abi::__cxa_eh_globals global;
return &global;
  }

Can you provide the disassemble std::uncaught_exception of where the crash is
located?
just do "disassemble" in gdb.

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Lance Fredrickson  ---
Here is the disassemble

(gdb) disassemble
Dump of assembler code for function _ZSt18uncaught_exceptionv:
   0x007fb7eae2a8 <+0>: stp x29, x30, [sp, #-16]!
   0x007fb7eae2ac <+4>: mov x29, sp
   0x007fb7eae2b0 <+8>: bl  0x7fb7ea8dd0 <__cxa_get_globals@plt>
=> 0x007fb7eae2b4 <+12>:ldr w0, [x0, #8]
   0x007fb7eae2b8 <+16>:cmp w0, #0x0
   0x007fb7eae2bc <+20>:csetw0, ne  // ne = any
   0x007fb7eae2c0 <+24>:ldp x29, x30, [sp], #16
   0x007fb7eae2c4 <+28>:ret
End of assembler dump.

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Lance Fredrickson from comment #2)
> Here is the disassemble
> 
> (gdb) disassemble
> Dump of assembler code for function _ZSt18uncaught_exceptionv:
>0x007fb7eae2a8 <+0>: stp x29, x30, [sp, #-16]!
>0x007fb7eae2ac <+4>: mov x29, sp
>0x007fb7eae2b0 <+8>: bl  0x7fb7ea8dd0 <__cxa_get_globals@plt>
> => 0x007fb7eae2b4 <+12>:ldr w0, [x0, #8]
>0x007fb7eae2b8 <+16>:cmp w0, #0x0
>0x007fb7eae2bc <+20>:csetw0, ne  // ne = any
>0x007fb7eae2c0 <+24>:ldp x29, x30, [sp], #16
>0x007fb7eae2c4 <+28>:ret
> End of assembler dump.

"info registers"

What is the value of x0 at this point?

Can you also do "disassemble __cxa_get_globals"?

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Lance Fredrickson  ---
Here you go.

(gdb) info registers
x0 0xff6fea06f01097094268656
x1 0x7fb7ffa6c0548547831488
x2 0x0 0
x3 0x0 0
x4 0x555a9f366503877279
x5 0x7fb7dc2d5f548545506655
x6 0x57202c6f6c6c6548  6278066737626506568
x7 0x6f726620646c726f  8030593374864831087
x8 0x4064
x9 0x7fb7ffccb0548547841200
x100x7fb7e13090548545835152
x110x1 1
x120x1824
x130x7fb7ffccc0548547841216
x140x7fb7ffc2d0548547838672
x150x1 1
x160x7fb7eae3f4548546470900
x170x7fb7fe26a8548547733160
x180x0 0
x190x7fb7fe4f50548547743568
x200x7ff330549755810608
x210x555890366503876752
x220x0 0
x230x0 0
x240x0 0
x250x0 0
x260x0 0
x270x0 0
x280x0 0
x290x7ff2e0549755810528
x300x7fb7eae2b4548546470580
sp 0x7ff2e00x7ff2e0
pc 0x7fb7eae2b40x7fb7eae2b4 
cpsr   0x8000  [ EL=0 N ]
fpsr   0x0 [ ]
fpcr   0x0 [ RMode=0 ]


(gdb) disassemble __cxa_get_globals
Dump of assembler code for function __cxxabiv1::__cxa_get_globals():
   0x007fb7eae3f4 <+0>: stp x29, x30, [sp, #-16]!
   0x007fb7eae3f8 <+4>: mov x29, sp
   0x007fb7eae3fc <+8>: bl  0x7fb7eae3b8 <(anonymous
namespace)::get_global()>
   0x007fb7eae400 <+12>:ldp x29, x30, [sp], #16
   0x007fb7eae404 <+16>:ret
End of assembler dump.

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

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

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

--- Comment #5 from Andrew Pinski  ---
uclibc must have some ordering issue when it comes to atexit and shared
libraries and TLS.

Can you also do:
"info mem"

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Lance Fredrickson  ---
info mem gives

(gdb) info mem
Using memory regions provided by the target.
There are no memory regions defined.

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

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

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Lance Fredrickson from comment #6)
> info mem gives
> 
> (gdb) info mem
> Using memory regions provided by the target.
> There are no memory regions defined.

Sorry, I mean "info proc mappings"

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #7 from joseph at codesourcery dot com  ---
I'd suggest looking at the generated assembly.  I don't know exactly what 
you mean by "putting a math_opt_barrier on this line"; it would need to be 
used in a way that ensures a dependency for all the code after 
SET_RESTORE_ROUNDL (for example, "xx = math_opt_barrier (xx);").

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Lance Fredrickson  ---
Here is 'info proc mappings'

(gdb) info proc mappings
process 16896
Mapped address spaces:

  Start Addr   End Addr   Size Offset objfile
0x555000   0x556000 0x10000x0
/mmc/src/hello.src/hello
0x565000   0x566000 0x10000x0
/mmc/src/hello.src/hello
0x566000   0x567000 0x1000 0x1000
/mmc/src/hello.src/hello
0x567000   0x5790000x120000x0 [heap]
0x7fb7c9f000   0x7fb7db   0x1110000x0
/mmc/lib/libuClibc-1.0.41.so
0x7fb7db   0x7fb7dc0x10x0
0x7fb7dc   0x7fb7dc1000 0x1000   0x111000
/mmc/lib/libuClibc-1.0.41.so
0x7fb7dc1000   0x7fb7dc2000 0x1000   0x112000
/mmc/lib/libuClibc-1.0.41.so
0x7fb7dc2000   0x7fb7ddc0000x1a0000x0
0x7fb7ddc000   0x7fb7df0x140000x0
/mmc/lib/libgcc_s.so.1
0x7fb7df   0x7fb7e00x10x0
0x7fb7e0   0x7fb7e01000 0x10000x14000
/mmc/lib/libgcc_s.so.1
0x7fb7e01000   0x7fb7e02000 0x10000x15000
/mmc/lib/libgcc_s.so.1
0x7fb7e02000   0x7fb7fc6000   0x1c40000x0
/mmc/usr/lib/libstdc++.so.6.0.30
0x7fb7fc6000   0x7fb7fd60000x10x0
0x7fb7fd6000   0x7fb7fe1000 0xb000   0x1c4000
/mmc/usr/lib/libstdc++.so.6.0.30
0x7fb7fe1000   0x7fb7fe4000 0x3000   0x1cf000
/mmc/usr/lib/libstdc++.so.6.0.30
0x7fb7fe4000   0x7fb7fe8000 0x40000x0
0x7fb7fe8000   0x7fb7ff 0x80000x0
/mmc/lib/ld-uClibc-1.0.41.so
0x7fb7ffa000   0x7fb7ffd000 0x30000x0
0x7fb7ffd000   0x7fb7ffe000 0x10000x0 [vvar]
0x7fb7ffe000   0x7fb7fff000 0x10000x0 [vdso]
0x7fb7fff000   0x7fb800 0x1000 0x7000
/mmc/lib/ld-uClibc-1.0.41.so
0x7fb800   0x7fb8001000 0x1000 0x8000
/mmc/lib/ld-uClibc-1.0.41.so
0x7df000   0x800x210000x0 [stack]

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

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

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

--- Comment #9 from Andrew Pinski  ---
disassemble 0x7fb7eae3b8
Which was:
   0x007fb7eae3fc <+8>: bl  0x7fb7eae3b8 <(anonymous
namespace)::get_global()>

I am still trying to figure out how the TLS address was formed here.

[Bug libstdc++/106581] [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Lance Fredrickson  ---
(gdb) disassemble 0x7fb7eae3b8
Dump of assembler code for function (anonymous namespace)::get_global():
   0x007fb7eae3b8 <+0>: stp x29, x30, [sp, #-16]!
   0x007fb7eae3bc <+4>: mov x29, sp
   0x007fb7eae3c0 <+8>: adrpx0, 0x7fb7fe3000
<_znst15basic_stringbuficst11char_traitsicesaicee15_m_update_egpt...@got.plt>
   0x007fb7eae3c4 <+12>:ldr x1, [x0, #3248]
   0x007fb7eae3c8 <+16>:add x0, x0, #0xcb0
   0x007fb7eae3cc <+20>:blr x1
   0x007fb7eae3d0 <+24>:mrs x1, tpidr_el0
   0x007fb7eae3d4 <+28>:add x0, x1, x0
   0x007fb7eae3d8 <+32>:ldp x29, x30, [sp], #16
   0x007fb7eae3dc <+36>:ret
End of assembler dump.

[Bug target/106581] [Aarch64] libstdc++ segfault at end of execution

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
  Component|libstdc++   |target

--- Comment #11 from Andrew Pinski  ---
(In reply to Lance Fredrickson from comment #10)
> (gdb) disassemble 0x7fb7eae3b8
> Dump of assembler code for function (anonymous namespace)::get_global():
>0x007fb7eae3b8 <+0>: stp x29, x30, [sp, #-16]!
>0x007fb7eae3bc <+4>: mov x29, sp
>0x007fb7eae3c0 <+8>: adrpx0, 0x7fb7fe3000
> <_znst15basic_stringbuficst11char_traitsicesaicee15_m_update_egpt...@got.plt>
>0x007fb7eae3c4 <+12>:ldr x1, [x0, #3248]
>0x007fb7eae3c8 <+16>:add x0, x0, #0xcb0
>0x007fb7eae3cc <+20>:blr x1
>0x007fb7eae3d0 <+24>:mrs x1, tpidr_el0
>0x007fb7eae3d4 <+28>:add x0, x1, x0
>0x007fb7eae3d8 <+32>:ldp x29, x30, [sp], #16
>0x007fb7eae3dc <+36>:ret
> End of assembler dump.

That looks correct.
It is basically:

adrpx0, :tlsdesc:a
ldr x1, [x0, #:tlsdesc_lo12:a]
add x0, x0, :tlsdesc_lo12:a
.tlsdesccalla
blr x1
mrs x1, tpidr_el0
add x0, x1, x0


So now this is looking more and more like an uclibc issue rather a
GCC/libstdc++ one.
Have you reported it to them yet?

[Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from Segher Boessenkool  ---
Let me say again that IEEE QP and double-double should not be the same kind.
This very obviously cannot work at all.

[Bug target/106545] peephole.md seems like it should not exist

[vineetg at rivosinc dot com via Gcc-bugs]

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

Vineet Gupta  changed:

   What|Removed |Added

 CC||vineetg at rivosinc dot com

--- Comment #1 from Vineet Gupta  ---
How do I assign this to myself, can this only be done by maintainers ?

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[michael.hudson at canonical dot com via Gcc-bugs]

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

--- Comment #8 from Michael Hudson-Doyle  
---
I just changed

  z = xx * xx;

to

  z = math_opt_barrier(xx * xx);

which perhaps isn't sufficient.

But my reading of the assembly is that the issue is that some of the math code
is being moved _after_ the restore of the fpu state implied by
SET_RESTORE_ROUNDL (FE_TONEAREST).

I included some snippets in https://paste.ubuntu.com/p/RMdWK6yr2F/.

This seems bad?

[Bug target/106581] [Aarch64] libstdc++ segfault at end of execution

[lancethepants at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Lance Fredrickson  ---
I will send an email to their mailing list and inform them of this thread as
well. I've queried on buildroot mailing list and irc if anyone uses aarch64 +
uclibc-ng.

thanks for your attention and troubleshooting!

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[michael.hudson at canonical dot com via Gcc-bugs]

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

--- Comment #9 from Michael Hudson-Doyle  
---
I uploaded the object file with the bad code to
https://people.canonical.com/~mwh/e_j1f128.os.

[Bug target/106574] gcc 12 with O3 leads to failures in glibc's y1f128 tests

[michael.hudson at canonical dot com via Gcc-bugs]

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

--- Comment #10 from Michael Hudson-Doyle  
---
FWIW, I see a similar error on ppc64el with what looks like a similar cause. (I
also see other errors that do not go away with s/O3/O2/ so that might be
something slightly different).

O3:

(kinetic-ppc64el)root@bobonevm3:/build/glibc-9T9BfE/glibc-2.36/build-tree/ppc64el-libc#
./elf/ld64.so.2 --library-path .:./elf:./math  ./math/test-ibm128-y1
testing long double (without inline functions)
Failure: Test: y1_downward (0x2p+0)
Result:
 is: -1.07032431540937546888370772277496e-01 
-0x1.b667a3914664758b0c44371e580p-4
 should be:  -1.07032431540937546888370772277477e-01 
-0x1.b667a3914664758b0c44371e520p-4
 difference:  1.84889274661174641893373882488153e-32  
0x1.800p-106
 ulp   :  12.
 max.ulp   :  11.
Maximal error of `y1_downward'
 is  : 12 ulp
 accepted: 11 ulp
Failure: Test: y1_upward (0x1.c1bc2ep+0)
Result:
 is: -2.49838507061808223791568937534715e-01 
-0x1.ffab54c8e53c466a84209c10030p-3
 should be:  -2.49838507061808223791568937534759e-01 
-0x1.ffab54c8e53c466a84209c100a0p-3
 difference:  4.31408307542740831084539059139024e-32  
0x1.c00p-105
 ulp   :  14.
 max.ulp   :  9.
Failure: Test: y1_upward (0x2p+0)
Result:
 is: -1.07032431540937546888370772277458e-01 
-0x1.b667a3914664758b0c44371e4c0p-4
 should be:  -1.07032431540937546888370772277475e-01 
-0x1.b667a3914664758b0c44371e518p-4
 difference:  1.69481835106076755068926058947474e-32  
0x1.600p-106
 ulp   :  11.
 max.ulp   :  9.
Maximal error of `y1_upward'
 is  : 14 ulp
 accepted: 9 ulp

Test suite completed:
  175 test cases plus 171 tests for exception flags and
171 tests for errno executed.

O2:

(kinetic-ppc64el)root@bobonevm3:/build/glibc-9T9BfE/glibc-2.36/build-tree/ppc64el-libc#
./elf/ld64.so.2 --library-path .:./elf:./math  ./math/test-ibm128-y1
testing long double (without inline functions)
Failure: Test: y1_upward (0x1.c1bc2ep+0)
Result:
 is: -2.49838507061808223791568937534728e-01 
-0x1.ffab54c8e53c466a84209c10050p-3
 should be:  -2.49838507061808223791568937534759e-01 
-0x1.ffab54c8e53c466a84209c100a0p-3
 difference:  3.08148791101957736488956470813589e-32  
0x1.400p-105
 ulp   :  10.
 max.ulp   :  9.
Failure: Test: y1_upward (0x2p+0)
Result:
 is: -1.07032431540937546888370772277458e-01 
-0x1.b667a3914664758b0c44371e4c0p-4
 should be:  -1.07032431540937546888370772277475e-01 
-0x1.b667a3914664758b0c44371e518p-4
 difference:  1.69481835106076755068926058947474e-32  
0x1.600p-106
 ulp   :  11.
 max.ulp   :  9.
Maximal error of `y1_upward'
 is  : 11 ulp
 accepted: 9 ulp

Test suite completed:
  175 test cases plus 171 tests for exception flags and
171 tests for errno executed.
  3 errors occurred.

(I also see llround errors on ppc64el, no idea what's going on there...)

[Bug tree-optimization/106322] [12/13 Regression] tree-vectorize: Wrong code at O2 level (-fno-tree-vectorize is working) since r12-2404-ga1d27560770818c5

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

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

--- Comment #44 from Kewen Lin  ---
(In reply to Richard Biener from comment #43)
> (In reply to Richard Biener from comment #42)
> > I think this goes wrong in vectorizable_operation which does
> > 
> >   if (using_emulated_vectors_p
> >   && !vect_can_vectorize_without_simd_p (code))
> > 
> > to guard this but I'm not sure how this slips through?
> 
> Ah, it's an internal function.  I think we should simply return false
> during analysis for any vect_emulated_vector_p type in vectorizable_call.
> 
> Alternatively pattern recognition could also be made to fail but the above
> is definitely more future proof.

Thanks for the pointer!  I think you meant:

diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index c9534ef9b1e..ee10fa3e0fb 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -3388,6 +3388,14 @@ vectorizable_call (vec_info *vinfo,
   return false;
 }

+  if (vect_emulated_vector_p (vectype_in) || vect_emulated_vector_p
(vectype_out))
+  {
+  if (dump_enabled_p ())
+   dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
+"use emulated vector type for call\n");
+  return false;
+  }
+
   /* FORNOW */
   nunits_in = TYPE_VECTOR_SUBPARTS (vectype_in);
   nunits_out = TYPE_VECTOR_SUBPARTS (vectype_out);

Will kick off some testings on x64/aarch64/ppc64{,le} and post it later.

[Bug fortran/104382] Finalization of parent components not compliant with standard

[paul.richard.thomas at gmail dot com via Gcc-bugs]

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

--- Comment #5 from paul.richard.thomas at gmail dot com  ---
Hi Thomas,

My stepping out of gfortran activities has been for rather longer than I
expected. I had hoped to have completed the finalization work by now and to
have got on with fixing PDTs.

I will try to find the time over the summer because it is evident that a
sufficient number of colleagues are on vacation that sustaining the pace of
work might be difficult :-)

I hope that all is well with you.

Paul


On Wed, 10 Aug 2022 at 08:40, tkoenig at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104382
>
> Thomas Koenig  changed:
>
>What|Removed |Added
>
> 
>  CC||tkoenig at gcc dot
> gnu.org
>
> --- Comment #4 from Thomas Koenig  ---
> To add some variety to the tests, nagfor gives
>
>  destructor4(complicated)   2.000   2.000
>  destructor5 (simple2) 5
>  destructor5 (simple2) 6
>  destructor2(simple) 1 1
>  final_count after assignment =  4
>  destructor4(complicated)   4.000   5.000
>  destructor5 (simple2) -1
>  destructor5 (simple2) -2
>  destructor2(simple) 3 4
>  final_count after deallocation =  8
>
> --
> You are receiving this mail because:
> You reported the bug.